Re: [PATCH] Exynos4: cpuidle: support dual CPUs with AFTR state
Hi Daniel,
> The following driver is for exynos4210. I did not yet finished the
> other boards, so I created a specific driver for 4210 which could be
> merged later.
>
If I may ask - do you plan to develop this code for Exynos4412 in a
near future?
I did some tests (with hotplug) and it turns out, that due to static
leakage current one can save up to 12 % of power consumption when power
domains for cores are disabled.
Such notable power consumption reduction could drive (and justify) the
further development of power aware scheduling code.
If you don't have time, then I can offer myself to develop the code. I
just want to avoid potential duplication of effort.
> The driver is based on Colin Cross's driver found at:
>
> https://android.googlesource.com/kernel/exynos/+/e686b1ec67423c40b4fdf811f9a4dfa3b393a010%5E%5E!/
>
> This one was based on a 3.4 kernel and an old API.
>
> It has been refreshed, simplified and based on the recent code
> cleanup I sent today.
>
> The AFTR could be entered when all the cpus (except cpu0) are down.
> In order to reach this situation, the couple idle states are used.
>
> There is a sync barrier at the entry and the exit of the low power
> function. So all cpus will enter and exit the function at the same
> time.
>
> At this point, CPU0 knows the other cpu will power down itself. CPU0
> waits for the CPU1 to be powered down and then initiate the AFTR
> power down sequence.
>
> No interrupts are handled by CPU1, this is why we switch to the timer
> broadcast even if the local timer is not impacted by the idle state.
>
> When CPU0 wakes up, it powers up CPU1 and waits for it to boot. Then
> they both exit the idle function.
>
> This driver allows the exynos4210 to have the same power consumption
> at idle time than the one when we have to unplug CPU1 in order to let
> CPU0 to reach the AFTR state.
>
> This patch is a RFC because, we have to find a way to remove the
> macros definitions and cpu powerdown function without pulling the
> arch dependent headers.
>
> Signed-off-by: Daniel Lezcano
> ---
> arch/arm/mach-exynos/common.c| 11 +-
> drivers/cpuidle/Kconfig.arm |8 ++
> drivers/cpuidle/Makefile |1 +
> drivers/cpuidle/cpuidle-exynos4210.c | 226
> ++ 4 files changed, 245
> insertions(+), 1 deletion(-) create mode 100644
> drivers/cpuidle/cpuidle-exynos4210.c
>
> diff --git a/arch/arm/mach-exynos/common.c
> b/arch/arm/mach-exynos/common.c index d5fa21e..1765a98 100644
> --- a/arch/arm/mach-exynos/common.c
> +++ b/arch/arm/mach-exynos/common.c
> @@ -299,9 +299,18 @@ static struct platform_device exynos_cpuidle = {
> .id= -1,
> };
>
> +static struct platform_device exynos4210_cpuidle = {
> + .name = "exynos4210-cpuidle",
> + .dev.platform_data = exynos_sys_powerdown_aftr,
> + .id= -1,
> +};
> +
> void __init exynos_cpuidle_init(void)
> {
> - platform_device_register(&exynos_cpuidle);
> + if (soc_is_exynos4210())
> + platform_device_register(&exynos4210_cpuidle);
> + else
> + platform_device_register(&exynos_cpuidle);
> }
>
> void __init exynos_cpufreq_init(void)
> diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
> index 92f0c12..2772130 100644
> --- a/drivers/cpuidle/Kconfig.arm
> +++ b/drivers/cpuidle/Kconfig.arm
> @@ -51,3 +51,11 @@ config ARM_EXYNOS_CPUIDLE
> depends on ARCH_EXYNOS
> help
> Select this to enable cpuidle for Exynos processors
> +
> +config ARM_EXYNOS4210_CPUIDLE
> + bool "Cpu Idle Driver for the Exynos 4210 processor"
> + default y
> + depends on ARCH_EXYNOS
> + select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
> + help
> + Select this to enable cpuidle for the Exynos 4210 processors
> diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
> index 0d1540a..e0ec9bc 100644
> --- a/drivers/cpuidle/Makefile
> +++ b/drivers/cpuidle/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_ARM_ZYNQ_CPUIDLE)+=
> cpuidle-zynq.o obj-$(CONFIG_ARM_U8500_CPUIDLE) +=
> cpuidle-ux500.o obj-$(CONFIG_ARM_AT91_CPUIDLE) +=
> cpuidle-at91.o obj-$(CONFIG_ARM_EXYNOS_CPUIDLE)+=
> cpuidle-exynos.o +obj-$(CONFIG_ARM_EXYNOS4210_CPUIDLE)+=
> cpuidle-exynos4210.o
>
>
> ###
> # POWERPC drivers
> diff --git a/drivers/cpuidle/cpuidle-exynos4210.c
> b/drivers/cpuidle/cpuidle-exynos4210.c new file mode 100644
> index 000..56f6d51
> --- /dev/null
> +++ b/drivers/cpuidle/cpuidle-exynos4210.c
> @@ -0,0 +1,226 @@
> +/*
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Copyright (c) 2014 Linaro : Daniel Lezcano
>
> + * http://www.linaro.org
> + *
> + * Based on the work of Colin Cross
> + *
> + * This program is f
Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Tomasz,
On Thu, Apr 10, 2014 at 5:09 PM, Vivek Gautam wrote:
> On Wed, Apr 9, 2014 at 7:03 PM, Tomasz Figa wrote:
>> On 09.04.2014 13:49, Vivek Gautam wrote:
>>>
>>> Hi,
>>>
>>>
>>> On Wed, Apr 9, 2014 at 4:36 PM, Tomasz Figa wrote:
Hi Vivek,
Please see my comments inline.
On 08.04.2014 16:36, Vivek Gautam wrote:
>
>
> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
> The new driver uses the generic PHY framework and will interact
> with DWC3 controller present on Exynos5 series of SoCs.
> Thereby, removing old phy-samsung-usb3 driver and related code
> used untill now which was based on usb/phy framework.
>
> Signed-off-by: Vivek Gautam
> ---
>.../devicetree/bindings/phy/samsung-phy.txt| 42 ++
>drivers/phy/Kconfig| 11 +
>drivers/phy/Makefile |1 +
>drivers/phy/phy-exynos5-usbdrd.c | 668
>
>4 files changed, 722 insertions(+)
>create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
[snip]
> + Additional clock required for Exynos5420:
> + - usb30_sclk_100m: Additional special clock used for PHY
> operation
> + depicted as 'sclk_usbphy30' in CMU of
> Exynos5420.
Are you sure this isn't simply a gate for the ref clock, as it can be
found
on another SoC that is not upstream yet? I don't have documentation for
Exynos 5420 so I can't tell, but I'd like to ask you to recheck this.
>>>
>>>
From what i can see in the manual :
>>>
>>> sclk_usbphy30 is derived from OSCCLK.
>>> It is coming from a MUX (default input line to this is OSCCLK) and
>>> then through a DIV
>>> there's this gate.
>>>
>>>{OSCCLK + other sources} --->[MUX] ---> [DIV] --> [GATE for
>>> sclk_usbphy30]
>>>
>>> the {rate of sclk_usbphy30} == OSCCLK
>>>
>>> However the 'ref' clock that we have been using is the actual oscillator
>>> clock.
>>> And on SoC Exynos5250, we don't have any such gate (sclk_usbphy30).
>>> So should this mean that ref clock and sclk_usbphy30 are still be
>>> controlled by
>>> two different gates ?
>>>
>>
>> Is there maybe a diagram of PHY input clocks in the datasheet, like for USB
>> 2.0 PHY in Exynos4210/4412/5250 datasheets in the chapter about USB2.0
>> Device? Something like:
>>
>>
>> ||
>> | ___|
>> XusbXTI | Phy_fsel[2:0]| ___ |
>>___[X]___|| __|_|___|\__|_|
>> | | _v___ | _ ^ | |/ | |
>> _ | | || | | | | ___ | |
>> ___| | || | | | | | |_|_|
>> |___| | | X 0 ||_| PLL |__|_|_|CLK|_|_|
>> _ | | | | || |DIV|_|_|
>> |___[X] | |_| 12 |_|480 | |___| | |
>> | MHz MHz |Digital| |
>> XusbXTO | USB PHY|___| |
>> ||
>>
>>
>
> Below is the block diagram given for DRD controller.
>
> ___
> ||
> | |
> | | PHY | |
> | | controller |-|---
> | |__ | | |
> ||
> |
> | USB 3.0 | V
> | DRD |
> ---
> |Controller | |
> |
> ||USB30_SCLK_100M| USB 3.0 DRD |
> | | --->
> | PHY |
> | | Link cont. | | |
> |
> | - |
> | |
> |___| |_|
>
> Does this help ?
>
> So, USB30_SCLK_100M is the SCLK that we are talking in the driver. I
> don't see any reference to XXTI in the USB 3.0 DRD controller chapter
> (in both Exynos5250 and 5420)
> In addition to this there's one more point to be noticed here.
> On Exynos5420 system, the sclk_usbphy300 (which is the sclk_usbphy30
> for USB DRD channel 0), is also the PICO phy clock, i.e. USB 2.0 phy
> clock.
> So we should add a similar clk_get() for this clock in the
> phy-exynos5250-usb2 driver too, to support Exynos5420.
Is something clear from the above block diagram ? (alt
[RFC PATCH 11/14] ARM: dts: exynos4: add system register node
This patch adds sysreg property to fimd device node which is required to use I80 interface. Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- arch/arm/boot/dts/exynos4.dtsi |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi index 3d14cdb..a10aa50 100644 --- a/arch/arm/boot/dts/exynos4.dtsi +++ b/arch/arm/boot/dts/exynos4.dtsi @@ -528,6 +528,7 @@ clocks = <&clock 140>, <&clock 283>; clock-names = "sclk_fimd", "fimd"; samsung,power-domain = <&pd_lcd0>; + samsung,sysreg = <&sys_reg>; status = "disabled"; }; }; -- 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
[RFC PATCH 10/14] drm/panel: add S6E3FA0 driver
This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver.
Signed-off-by: YoungJun Cho
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/panel/Kconfig |7 +
drivers/gpu/drm/panel/Makefile|1 +
drivers/gpu/drm/panel/panel-s6e3fa0.c | 544 +
3 files changed, 552 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 4ec874d..be1392e 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -30,4 +30,11 @@ config DRM_PANEL_S6E8AA0
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS
+config DRM_PANEL_S6E3FA0
+ tristate "S6E3FA0 DSI command mode panel"
+ depends on DRM && DRM_PANEL
+ depends on OF
+ select DRM_MIPI_DSI
+ select VIDEOMODE_HELPERS
+
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 8b92921..85c6738 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
+obj-$(CONFIG_DRM_PANEL_S6E3FA0) += panel-s6e3fa0.o
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
b/drivers/gpu/drm/panel/panel-s6e3fa0.c
new file mode 100644
index 000..784a614
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
@@ -0,0 +1,544 @@
+/*
+ * MIPI-DSI based s6e3fa0 AMOLED LCD 5.7 inch panel driver.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * YoungJun Cho
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define MTP_ID_LEN 3
+#define GAMMA_LEVEL_NUM30
+
+struct s6e3fa0 {
+ struct device *dev;
+ struct drm_panelpanel;
+
+ struct regulator_bulk_data supplies[2];
+ struct gpio_desc*reset_gpio;
+ struct gpio_desc*det_gpio;
+ struct gpio_desc*te_gpio;
+ unsigned intpower_on_delay;
+ unsigned intreset_delay;
+ unsigned intinit_delay;
+ struct videomodevm;
+ unsigned intwidth_mm;
+ unsigned intheight_mm;
+
+ unsigned char id;
+ unsigned char vddm;
+ unsigned intbrightness;
+};
+
+#define panel_to_s6e3fa0(p) container_of(p, struct s6e3fa0, panel)
+
+static const unsigned char s6e3fa0_vddm_lut[][2] = {
+ {0x00, 0x0d}, {0x01, 0x0d}, {0x02, 0x0e}, {0x03, 0x0f}, {0x04, 0x10},
+ {0x05, 0x11}, {0x06, 0x12}, {0x07, 0x13}, {0x08, 0x14}, {0x09, 0x15},
+ {0x0a, 0x16}, {0x0b, 0x17}, {0x0c, 0x18}, {0x0d, 0x19}, {0x0e, 0x1a},
+ {0x0f, 0x1b}, {0x10, 0x1c}, {0x11, 0x1d}, {0x12, 0x1e}, {0x13, 0x1f},
+ {0x14, 0x20}, {0x15, 0x21}, {0x16, 0x22}, {0x17, 0x23}, {0x18, 0x24},
+ {0x19, 0x25}, {0x1a, 0x26}, {0x1b, 0x27}, {0x1c, 0x28}, {0x1d, 0x29},
+ {0x1e, 0x2a}, {0x1f, 0x2b}, {0x20, 0x2c}, {0x21, 0x2d}, {0x22, 0x2e},
+ {0x23, 0x2f}, {0x24, 0x30}, {0x25, 0x31}, {0x26, 0x32}, {0x27, 0x33},
+ {0x28, 0x34}, {0x29, 0x35}, {0x2a, 0x36}, {0x2b, 0x37}, {0x2c, 0x38},
+ {0x2d, 0x39}, {0x2e, 0x3a}, {0x2f, 0x3b}, {0x30, 0x3c}, {0x31, 0x3d},
+ {0x32, 0x3e}, {0x33, 0x3f}, {0x34, 0x3f}, {0x35, 0x3f}, {0x36, 0x3f},
+ {0x37, 0x3f}, {0x38, 0x3f}, {0x39, 0x3f}, {0x3a, 0x3f}, {0x3b, 0x3f},
+ {0x3c, 0x3f}, {0x3d, 0x3f}, {0x3e, 0x3f}, {0x3f, 0x3f}, {0x40, 0x0c},
+ {0x41, 0x0b}, {0x42, 0x0a}, {0x43, 0x09}, {0x44, 0x08}, {0x45, 0x07},
+ {0x46, 0x06}, {0x47, 0x05}, {0x48, 0x04}, {0x49, 0x03}, {0x4a, 0x02},
+ {0x4b, 0x01}, {0x4c, 0x40}, {0x4d, 0x41}, {0x4e, 0x42}, {0x4f, 0x43},
+ {0x50, 0x44}, {0x51, 0x45}, {0x52, 0x46}, {0x53, 0x47}, {0x54, 0x48},
+ {0x55, 0x49}, {0x56, 0x4a}, {0x57, 0x4b}, {0x58, 0x4c}, {0x59, 0x4d},
+ {0x5a, 0x4e}, {0x5b, 0x4f}, {0x5c, 0x50}, {0x5d, 0x51}, {0x5e, 0x52},
+ {0x5f, 0x53}, {0x60, 0x54}, {0x61, 0x55}, {0x62, 0x56}, {0x63, 0x57},
+ {0x64, 0x58}, {0x65, 0x59}, {0x66, 0x5a}, {0x67, 0x5b}, {0x68, 0x5c},
+ {0x69, 0x5d}, {0x6a, 0x5e}, {0x6b, 0x5f}, {0x6c, 0x60}, {0x6d, 0x61},
+ {0x6e, 0x62}, {0x6f, 0x63}, {0x70, 0x64}, {0x71, 0x65}, {0x72, 0x66},
+ {0x73, 0x67}, {0x74, 0x68}, {0x75, 0x69}, {0x76, 0x6a}, {0x77, 0x6b},
+ {0x78, 0x6c}, {0x79, 0x6d}, {0x7a, 0x6e}, {0x7b, 0x6f}, {0x7c, 0x70},
+ {0x7d, 0x71}, {0x7e, 0x72}, {0x7f, 0x73},
+};
+
+static int s6e3fa0_dcs_re
[RFC PATCH 06/14] drm/exynos: support MIPI DSI command mode
This patch adds I80 interface for FIMD to support command mode panel.
For this, the below features are added:
- Set display interface mode relevant registers properly according to the
interface type from DT
- Add TE interrupt handler
. FIMD driver should know TE signal from lcd panel to avoid tearing issue.
- Add trigger feature
. In case of command mode panel, FIMD should set trigger bit,
so that image data has to be transferred to display bus or lcd panel.
Signed-off-by: YoungJun Cho
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/Kconfig |1 +
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 11 ++
drivers/gpu/drm/exynos/exynos_drm_crtc.h |2 +
drivers/gpu/drm/exynos/exynos_drm_drv.h |2 +
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 ++
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 280 +-
include/drm/drm_mipi_dsi.h |2 +
include/video/samsung_fimd.h |3 +-
8 files changed, 270 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 5bf5bca..f4d34f0 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -28,6 +28,7 @@ config DRM_EXYNOS_FIMD
bool "Exynos DRM FIMD"
depends on DRM_EXYNOS && !FB_S3C && !ARCH_MULTIPLATFORM
select FB_MODE_HELPERS
+ select MFD_SYSCON
help
Choose this option if you want to use Exynos FIMD for DRM.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 1419d11..d902d64 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -491,3 +491,14 @@ void exynos_drm_crtc_complete_scanout(struct
drm_framebuffer *fb)
manager->ops->wait_for_vblank(manager);
}
}
+
+int exynos_drm_crtc_te_handler(struct drm_crtc *crtc)
+{
+ struct exynos_drm_manager *manager = to_exynos_crtc(crtc)->manager;
+ int ret = 0;
+
+ if (manager->ops->te_handler)
+ ret = manager->ops->te_handler(manager);
+
+ return ret;
+}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index c27b66c..8482df2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -32,4 +32,6 @@ void exynos_drm_crtc_plane_commit(struct drm_crtc *crtc, int
zpos);
void exynos_drm_crtc_plane_enable(struct drm_crtc *crtc, int zpos);
void exynos_drm_crtc_plane_disable(struct drm_crtc *crtc, int zpos);
+int exynos_drm_crtc_te_handler(struct drm_crtc *crtc);
+
#endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 4c5cf68..7cb0baf 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -186,6 +186,7 @@ struct exynos_drm_display {
* @win_commit: apply hardware specific overlay data to registers.
* @win_enable: enable hardware specific overlay.
* @win_disable: disable hardware specific overlay.
+ * @te_handler: call driver specific TE handler callback.
*/
struct exynos_drm_manager;
struct exynos_drm_manager_ops {
@@ -207,6 +208,7 @@ struct exynos_drm_manager_ops {
void (*win_commit)(struct exynos_drm_manager *mgr, int zpos);
void (*win_enable)(struct exynos_drm_manager *mgr, int zpos);
void (*win_disable)(struct exynos_drm_manager *mgr, int zpos);
+ int (*te_handler)(struct exynos_drm_manager *mgr);
};
/*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 2cf1f0b..179f2fa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -23,6 +23,7 @@
#include
#include
+#include "exynos_drm_crtc.h"
#include "exynos_drm_drv.h"
/* returns true iff both arguments logically differs */
@@ -1032,10 +1033,22 @@ static ssize_t exynos_dsi_host_transfer(struct
mipi_dsi_host *host,
return (ret < 0) ? ret : xfer.rx_done;
}
+static int exynos_dsi_host_te_handler(struct mipi_dsi_host *host)
+{
+ struct exynos_dsi *dsi = host_to_dsi(host);
+ struct drm_encoder *encoder = dsi->encoder;
+
+ if (!(dsi->state & DSIM_STATE_ENABLED))
+ return -EPERM;
+
+ return exynos_drm_crtc_te_handler(encoder->crtc);
+}
+
static const struct mipi_dsi_host_ops exynos_dsi_ops = {
.attach = exynos_dsi_host_attach,
.detach = exynos_dsi_host_detach,
.transfer = exynos_dsi_host_transfer,
+ .te_handler = exynos_dsi_host_te_handler,
};
static int exynos_dsi_poweron(struct exynos_dsi *dsi)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 40fd6cc..a7a2018 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,6 +19,8 @@
#include
#include
#i
[RFC PATCH 14/14] ARM: dts: exynos5420: add dsi node
This patch adds common part of dsi node.
Signed-off-by: YoungJun Cho
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos5420.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index f0184c7..aa2350a 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -422,6 +422,20 @@
#phy-cells = <1>;
};
+ dsi@1450 {
+ compatible = "samsung,exynos5420-mipi-dsi";
+ reg = <0x1450 0x1>;
+ interrupts = <0 82 0>;
+ samsung,power-domain = <&disp_pd>;
+ phys = <&mipi_phy 1>;
+ phy-names = "dsim";
+ clocks = <&clock 411>, <&clock 146>;
+ clock-names = "bus_clk", "pll_clk";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
fimd@1440 {
samsung,power-domain = <&disp_pd>;
clocks = <&clock 147>, <&clock 421>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 09/14] ARM: dts: s6e3fa0: add DT bindings
This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings, delays
and physical size.
Signed-off-by: YoungJun Cho
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
.../devicetree/bindings/panel/samsung,s6e3fa0.txt | 52
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
new file mode 100644
index 000..5986899
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
@@ -0,0 +1,52 @@
+Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
+
+Required properties:
+ - compatible: "samsung,s6e3fa0"
+ - reg: the virtual channel number of a DSI peripheral
+ - vdd3-supply: core voltage supply
+ - vci-supply: voltage supply for analog circuits
+ - reset-gpio: a GPIO spec for the reset pin
+ - display-timings: timings for the connected panel as described by [1]
+
+Optional properties:
+ - power-on-delay: delay after turning regulators on [ms]
+ - reset-delay: delay after reset sequence [ms]
+ - init-delay: delay after initialization sequence [ms]
+ - panel-width-mm: physical panel width [mm]
+ - panel-height-mm: physical panel height [mm]
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ panel {
+ compatible = "samsung,s6e3fa0";
+ reg = <0>;
+ vdd3-supply = <&vcclcd_reg>;
+ vci-supply = <&vlcd_reg>;
+ reset-gpio = <&gpy7 4 0>;
+ power-on-delay= <10>;
+ reset-delay = <5>;
+ init-delay = <120>;
+ panel-width-mm = <71>;
+ panel-height-mm = <126>;
+
+ display-timings {
+ timing0: timing-0 {
+ clock-frequency = <57153600>;
+ hactive = <1080>;
+ vactive = <1920>;
+ hfront-porch = <2>;
+ hback-porch = <2>;
+ hsync-len = <1>;
+ vfront-porch = <1>;
+ vback-porch = <4>;
+ vsync-len = <1>;
+ };
+ };
+ };
--
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
[RFC PATCH 13/14] ARM: dts: exynos5420: add mipi-phy node
This patch adds mipi-phy node for MIPI-DSI device.
Signed-off-by: YoungJun Cho
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos5420.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 8db792b..f0184c7 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -416,6 +416,12 @@
phy-names = "dp";
};
+ mipi_phy: video-phy@10040714 {
+ compatible = "samsung,s5pv210-mipi-video-phy";
+ reg = <0x10040714 12>;
+ #phy-cells = <1>;
+ };
+
fimd@1440 {
samsung,power-domain = <&disp_pd>;
clocks = <&clock 147>, <&clock 421>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 05/14] ARM: dts: samsung-fimd: add I80 specific properties
In case of using CPU interface panel, the relevant registers should be set. So this patch adds relevant dt bindings. Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- .../devicetree/bindings/video/samsung-fimd.txt |9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt b/Documentation/devicetree/bindings/video/samsung-fimd.txt index 2dad41b..924c2e1 100644 --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt @@ -44,6 +44,15 @@ Optional Properties: - display-timings: timing settings for FIMD, as described in document [1]. Can be used in case timings cannot be provided otherwise or to override timings provided by the panel. +- samsung,sysreg-phandle: handle to syscon used to control the system registers +- vidout-i80-ldi: boolean to support i80 interface instead of rgb one +- cs-setup: clock cycles for the active period of address signal enable until + chip select is enable in i80 interface +- wr-setup: clock cycles for the active period of CS signal enable until + write signal is enable in i80 interface +- wr-act: clock cycles for the active period of CS enable in i80 interface +- wr-hold: clock cycles for the active period of CS disable until write signal + is disable in i80 interface The device node can contain 'port' child nodes according to the bindings defined in [2]. The following are properties specific to those nodes: -- 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
[RFC PATCH 07/14] ARM: dts: exynos_dsim: add exynos5420 Soc compatible
This patch adds exynos5420 SoC support. Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- .../devicetree/bindings/video/exynos_dsim.txt |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt b/Documentation/devicetree/bindings/video/exynos_dsim.txt index 33b5730..9bbf82b 100644 --- a/Documentation/devicetree/bindings/video/exynos_dsim.txt +++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt @@ -1,7 +1,9 @@ Exynos MIPI DSI Master Required properties: - - compatible: "samsung,exynos4210-mipi-dsi" + - compatible: value should be one of the following + "samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */ + "samsung,exynos5420-mipi-dsi" /* for Exynos5420 Soc */ - reg: physical base address and length of the registers set for the device - interrupts: should contain DSI interrupt - clocks: list of clock specifiers, must contain an entry for each required -- 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
[RFC PATCH 08/14] drm/exynos: dsi: add driver data to support Exynos5420
The offset of register DSIM_PLLTMR_REG in Exynos5420 is different
from the one in Exynos4 SoC.
In case of Exynos5420 SoC, there is no frequency band bit in DSIM_PLLCTRL_REG,
and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead.
So this patch adds driver data to distinguish it.
Signed-off-by: YoungJun Cho
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 101 ---
1 file changed, 80 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 179f2fa..fcd577f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
@@ -54,9 +55,12 @@
/* FIFO memory AC characteristic register */
#define DSIM_PLLCTRL_REG 0x4c/* PLL control register */
-#define DSIM_PLLTMR_REG0x50/* PLL timer register */
#define DSIM_PHYACCHR_REG 0x54/* D-PHY AC characteristic register */
#define DSIM_PHYACCHR1_REG 0x58/* D-PHY AC characteristic register1 */
+#define DSIM_PHYCTRL_REG 0x5c
+#define DSIM_PHYTIMING_REG 0x64
+#define DSIM_PHYTIMING1_REG0x68
+#define DSIM_PHYTIMING2_REG0x6c
/* DSIM_STATUS */
#define DSIM_STOP_STATE_DAT(x) (((x) & 0xf) << 0)
@@ -233,6 +237,12 @@ struct exynos_dsi_transfer {
#define DSIM_STATE_INITIALIZED BIT(1)
#define DSIM_STATE_CMD_LPM BIT(2)
+struct exynos_dsi_driver_data {
+ unsigned int plltmr_reg;
+
+ unsigned int has_freqband:1;
+};
+
struct exynos_dsi {
struct mipi_dsi_host dsi_host;
struct drm_connector connector;
@@ -262,11 +272,39 @@ struct exynos_dsi {
spinlock_t transfer_lock; /* protects transfer_list */
struct list_head transfer_list;
+
+ struct exynos_dsi_driver_data *driver_data;
};
#define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
#define connector_to_dsi(c) container_of(c, struct exynos_dsi, connector)
+static struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
+ .plltmr_reg = 0x50,
+ .has_freqband = 1,
+};
+
+static struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
+ .plltmr_reg = 0x58,
+};
+
+static struct of_device_id exynos_dsi_of_match[] = {
+ { .compatible = "samsung,exynos4210-mipi-dsi",
+ .data = &exynos4_dsi_driver_data },
+ { .compatible = "samsung,exynos5420-mipi-dsi",
+ .data = &exynos5_dsi_driver_data },
+ { }
+};
+
+static inline struct exynos_dsi_driver_data *exynos_dsi_get_driver_data(
+ struct platform_device *pdev)
+{
+ const struct of_device_id *of_id =
+ of_match_device(exynos_dsi_of_match, &pdev->dev);
+
+ return (struct exynos_dsi_driver_data *)of_id->data;
+}
+
static void exynos_dsi_wait_for_reset(struct exynos_dsi *dsi)
{
if (wait_for_completion_timeout(&dsi->completed, msecs_to_jiffies(300)))
@@ -340,14 +378,9 @@ static unsigned long exynos_dsi_pll_find_pms(struct
exynos_dsi *dsi,
static unsigned long exynos_dsi_set_pll(struct exynos_dsi *dsi,
unsigned long freq)
{
- static const unsigned long freq_bands[] = {
- 100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
- 270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
- 510 * MHZ, 560 * MHZ, 640 * MHZ, 690 * MHZ,
- 770 * MHZ, 870 * MHZ, 950 * MHZ,
- };
+ struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
unsigned long fin, fout;
- int timeout, band;
+ int timeout;
u8 p, s;
u16 m;
u32 reg;
@@ -368,18 +401,30 @@ static unsigned long exynos_dsi_set_pll(struct exynos_dsi
*dsi,
"failed to find PLL PMS for requested frequency\n");
return -EFAULT;
}
+ dev_dbg(dsi->dev, "PLL freq %lu, (p %d, m %d, s %d)\n", fout, p, m, s);
- for (band = 0; band < ARRAY_SIZE(freq_bands); ++band)
- if (fout < freq_bands[band])
- break;
+ writel(500, dsi->reg_base + driver_data->plltmr_reg);
+
+ reg = DSIM_PLL_EN | DSIM_PLL_P(p) | DSIM_PLL_M(m) | DSIM_PLL_S(s);
+
+ if (driver_data->has_freqband) {
+ static const unsigned long freq_bands[] = {
+ 100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
+ 270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
+ 510 * MHZ, 560 * MHZ, 640 * MHZ, 690 * MHZ,
+ 770 * MHZ, 870 * MHZ, 950 * MHZ,
+ };
+ int band;
- dev_dbg(dsi->dev, "PLL freq %lu, (p %d, m %d, s %d), band %d\n", fout,
- p, m, s, band);
+ for (band = 0; band < ARRAY_SIZE(freq_bands); ++band)
+ if (f
[RFC PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset
Some phy control registers are not kept after software reset.
So this patch makes the clocks containing phy control to be set
after software reset.
Signed-off-by: YoungJun Cho
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 956e5f3..2cf1f0b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -946,10 +946,10 @@ static irqreturn_t exynos_dsi_irq(int irq, void *dev_id)
static int exynos_dsi_init(struct exynos_dsi *dsi)
{
- exynos_dsi_enable_clock(dsi);
exynos_dsi_reset(dsi);
enable_irq(dsi->irq);
exynos_dsi_wait_for_reset(dsi);
+ exynos_dsi_enable_clock(dsi);
exynos_dsi_init_link(dsi);
return 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 00/14] drm/exynos: support MIPI DSI command mode display
This patch series includes the following: - FIMD I80 interface - DSI command mode interface for Exynos5420 - S6E3FA0 command mode type panel driver - Some bugs modification The patch series is based on exynos-drm-next branch. Thank you. Best regards YJ YoungJun Cho (14): drm/exynos: dsi: move the Eot packets configuration point drm/exynos: dsi: delay setting clocks after reset drm/exynos: use wait_event_timeout() for safety usage ARM: dts: add exynos5 compatible to sysreg ARM: dts: samsung-fimd: add I80 specific properties drm/exynos: support MIPI DSI command mode ARM: dts: exynos_dsim: add exynos5420 Soc compatible drm/exynos: dsi: add driver data to support Exynos5420 ARM: dts: s6e3fa0: add DT bindings drm/panel: add S6E3FA0 driver ARM: dts: exynos4: add system register node ARM: dts: exynos5: add system register support ARM: dts: exynos5420: add mipi-phy node ARM: dts: exynos5420: add dsi node .../devicetree/bindings/arm/samsung/sysreg.txt |1 + .../devicetree/bindings/panel/samsung,s6e3fa0.txt | 52 ++ .../devicetree/bindings/video/exynos_dsim.txt |4 +- .../devicetree/bindings/video/samsung-fimd.txt |9 + arch/arm/boot/dts/exynos4.dtsi |1 + arch/arm/boot/dts/exynos5.dtsi |6 + arch/arm/boot/dts/exynos5420.dtsi | 20 + drivers/gpu/drm/exynos/Kconfig |1 + drivers/gpu/drm/exynos/exynos_drm_crtc.c | 16 +- drivers/gpu/drm/exynos/exynos_drm_crtc.h |2 + drivers/gpu/drm/exynos/exynos_drm_drv.h|2 + drivers/gpu/drm/exynos/exynos_drm_dsi.c| 121 - drivers/gpu/drm/exynos/exynos_drm_fimd.c | 280 -- drivers/gpu/drm/panel/Kconfig |7 + drivers/gpu/drm/panel/Makefile |1 + drivers/gpu/drm/panel/panel-s6e3fa0.c | 544 include/drm/drm_mipi_dsi.h |2 + include/video/samsung_fimd.h |3 +- 18 files changed, 1001 insertions(+), 71 deletions(-) create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c -- 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
[RFC PATCH 12/14] ARM: dts: exynos5: add system register support
This patch adds sysreg device node, and sysreg property to fimd device node
which is required to use I80 interface.
Signed-off-by: YoungJun Cho
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos5.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 258dca4..f938bbb 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -88,12 +88,18 @@
status = "disabled";
};
+ sys_reg: syscon@1005 {
+ compatible = "samsung,exynos5-sysreg", "syscon";
+ reg = <0x1005 0x500>;
+ };
+
fimd@1440 {
compatible = "samsung,exynos5250-fimd";
interrupt-parent = <&combiner>;
reg = <0x1440 0x4>;
interrupt-names = "fifo", "vsync", "lcd_sys";
interrupts = <18 4>, <18 5>, <18 6>;
+ samsung,sysreg = <&sys_reg>;
status = "disabled";
};
--
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
[RFC PATCH 04/14] ARM: dts: add exynos5 compatible to sysreg
This patch adds sysreg support for exynos5 SoCs. Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- .../devicetree/bindings/arm/samsung/sysreg.txt |1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt index 0ab3251..fd71581 100644 --- a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt +++ b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt @@ -3,6 +3,7 @@ SAMSUNG S5P/Exynos SoC series System Registers (SYSREG) Properties: - compatible : should contain "samsung,-sysreg", "syscon"; For Exynos4 SoC series it should be "samsung,exynos4-sysreg", "syscon"; + For Exynos5 SoC series it should be "samsung,exynos5-sysreg", "syscon"; - reg : offset and length of the register set. Example: -- 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
[RFC PATCH 03/14] drm/exynos: use wait_event_timeout() for safety usage
There could be the case that the page flip operation isn't finished correctly
with some abnormal condition such as panel reset. So this patch replaces
wait_event() with wait_event_timeout() to avoid waiting for page flip completion
infinitely.
Signed-off-by: YoungJun Cho
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index e930d4f..1419d11 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -69,8 +69,9 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int
mode)
if (mode > DRM_MODE_DPMS_ON) {
/* wait for the completion of page flip. */
- wait_event(exynos_crtc->pending_flip_queue,
- atomic_read(&exynos_crtc->pending_flip) == 0);
+ wait_event_timeout(exynos_crtc->pending_flip_queue,
+ !atomic_read(&exynos_crtc->pending_flip),
+ HZ/20);
drm_vblank_off(crtc->dev, exynos_crtc->pipe);
}
--
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
[RFC PATCH 01/14] drm/exynos: dsi: move the Eot packets configuration point
This configuration could be used in MIPI DSI command mode also.
Signed-off-by: YoungJun Cho
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index eb73e3b..956e5f3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -472,8 +472,6 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
if (!(dsi->mode_flags & MIPI_DSI_MODE_VSYNC_FLUSH))
reg |= DSIM_MFLUSH_VS;
- if (!(dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET))
- reg |= DSIM_EOT_DISABLE;
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
reg |= DSIM_SYNC_INFORM;
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
@@ -490,6 +488,9 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
reg |= DSIM_HSA_MODE;
}
+ if (!(dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET))
+ reg |= DSIM_EOT_DISABLE;
+
switch (dsi->format) {
case MIPI_DSI_FMT_RGB888:
reg |= DSIM_MAIN_PIX_FORMAT_RGB888;
--
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 08/20] cpufreq: exynos5440: Use cpufreq_for_each_entry macro for iteration
On 15 April 2014 02:39, Stratos Karafotis wrote:
> diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
> b/drivers/cpufreq/exynos5440-cpufreq.c
> static void exynos_enable_dvfs(unsigned int cur_frequency)
> {
> - unsigned int tmp, i, cpu;
> + unsigned int tmp, cpu;
> struct cpufreq_frequency_table *freq_table = dvfs_info->freq_table;
> + struct cpufreq_frequency_table *pos;
Merge above two.
> /* Disable DVFS */
> __raw_writel(0, dvfs_info->base + XMU_DVFS_CTRL);
>
> @@ -182,15 +182,15 @@ static void exynos_enable_dvfs(unsigned int
> cur_frequency)
> __raw_writel(tmp, dvfs_info->base + XMU_PMUIRQEN);
>
> /* Set initial performance index */
> - for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END; i++)
> - if (freq_table[i].frequency == cur_frequency)
> + cpufreq_for_each_entry(pos, freq_table) {
> + if (pos->frequency == cur_frequency)
> break;
> + }
>
> - if (freq_table[i].frequency == CPUFREQ_TABLE_END) {
> + if (pos->frequency == CPUFREQ_TABLE_END) {
> dev_crit(dvfs_info->dev, "Boot up frequency not supported\n");
> /* Assign the highest frequency */
> - i = 0;
> - cur_frequency = freq_table[i].frequency;
> + cur_frequency = freq_table->frequency;
First this is not readable enough and you introduced a bug here, see
below.
> }
>
> dev_info(dvfs_info->dev, "Setting dvfs initial frequency = %uKHZ",
> @@ -199,7 +199,7 @@ static void exynos_enable_dvfs(unsigned int cur_frequency)
> for (cpu = 0; cpu < CONFIG_NR_CPUS; cpu++) {
> tmp = __raw_readl(dvfs_info->base + XMU_C0_3_PSTATE + cpu *
> 4);
> tmp &= ~(P_VALUE_MASK << C0_3_PSTATE_NEW_SHIFT);
> - tmp |= (i << C0_3_PSTATE_NEW_SHIFT);
> + tmp |= ((pos - freq_table) << C0_3_PSTATE_NEW_SHIFT);
We used modified value of 'i' here earlier, i.e. 0 ..
> __raw_writel(tmp, dvfs_info->base + XMU_C0_3_PSTATE + cpu *
> 4);
> }
>
> --
> 1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/20] cpufreq: exynos: Use cpufreq_for_each_entry macro for iteration
On 15 April 2014 02:39, Stratos Karafotis wrote:
> The cpufreq core supports the cpufreq_for_each_entry macro helper
> for iteration over the cpufreq_frequency_table, so use it.
>
> It should have no functional changes.
>
> Signed-off-by: Stratos Karafotis
> ---
> drivers/cpufreq/exynos-cpufreq.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/cpufreq/exynos-cpufreq.c
> b/drivers/cpufreq/exynos-cpufreq.c
> index f99cfe2..0e19bce 100644
> --- a/drivers/cpufreq/exynos-cpufreq.c
> +++ b/drivers/cpufreq/exynos-cpufreq.c
> @@ -28,18 +28,18 @@ static unsigned int locking_frequency;
>
> static int exynos_cpufreq_get_index(unsigned int freq)
> {
> - struct cpufreq_frequency_table *freq_table = exynos_info->freq_table;
> - int index;
> + struct cpufreq_frequency_table *pos, *freq_table;
>
> - for (index = 0;
> - freq_table[index].frequency != CPUFREQ_TABLE_END; index++)
> - if (freq_table[index].frequency == freq)
> + freq_table = exynos_info->freq_table;
Keep it as it was, i.e. fill freq_table during its definition. If with
addition of
pos it is crossing 80 columns, then define pos in a separate line.
> + cpufreq_for_each_entry(pos, freq_table) {
> + if (pos->frequency == freq)
> break;
> + }
>
> - if (freq_table[index].frequency == CPUFREQ_TABLE_END)
> + if (pos->frequency == CPUFREQ_TABLE_END)
> return -EINVAL;
>
> - return index;
> + return pos - freq_table;
> }
>
> static int exynos_cpufreq_scale(unsigned int target_freq)
> --
> 1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
Hi,
On Mon, Apr 14, 2014 at 8:07 PM, Sylwester Nawrocki
wrote:
> On 08/04/14 16:36, Vivek Gautam wrote:
>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> index 28f9edb..6d99ba9 100644
>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> @@ -74,3 +74,45 @@ phy-consumer@1234 {
>>
>> Refer to DT bindings documentation of particular PHY consumer devices for
>> more
>> information about required PHYs and the way of specification.
>> +
>> +Samsung Exynos5 SoC series USB DRD PHY controller
>> +--
>> +
>> +Required properties:
>> +- compatible : Should be set to one of the following supported values:
>> + - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
>> + - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
>> +- reg : Register offset and length of USB DRD PHY register set;
>> +- clocks: Clock IDs array as required by the controller
>> +- clock-names: names of clocks correseponding to IDs in the clock property;
>> +Required clocks:
>> + - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
>> +used for register access.
>> + - ref: PHY's reference clock (usually crystal clock), associated by
>> +phy name, used to determine bit values for clock settings
>> +register.
>> + Additional clock required for Exynos5420:
>> + - usb30_sclk_100m: Additional special clock used for PHY operation
>> +depicted as 'sclk_usbphy30' in CMU of Exynos5420.
>> +- samsung,syscon-phandle: phandle for syscon interface, which is used to
>> + control pmu registers for power isolation.
>
> Why to append "-phandle" to the property's name ? If this is for PMU
> perhaps make it more explicit and name it: samsung,pmu-syscon or
> samsung,pmureg ?
Right, thanks for pointing out this.
Will rename it to samsung,pmu-syscon. That will be inline with the
phandle it points to.
--
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: [PATCHv2 5/8] ARM: EXYNOS: Support secondary CPU boot of Exynos3250
On 15 April 2014 07:29, Chanwoo Choi wrote:
> This patch fix the offset of CPU boot address and don't operate smc call
> of SMC_CMD_CPU1BOOT command for Exynos3250.
>
> Signed-off-by: Chanwoo Choi
> Acked-by: Kyungmin Park
> ---
> arch/arm/mach-exynos/firmware.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
> index aa01c42..6205d4f 100644
> --- a/arch/arm/mach-exynos/firmware.c
> +++ b/arch/arm/mach-exynos/firmware.c
> @@ -30,13 +30,16 @@ static int exynos_do_idle(void)
>
> static int exynos_cpu_boot(int cpu)
> {
> + if (soc_is_exynos3250()) {
> + return 0;
> /*
> * The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
> * But, Exynos4212 has only one secondary CPU so second parameter
> * isn't used for informing secure firmware about CPU id.
> */
> - if (soc_is_exynos4212())
> + } else if (soc_is_exynos4212()) {
> cpu = 0;
> + }
>
As you already return in case of Exynos3250, you need not change this.
First commit hunk without the opening brace should be sufficient.
> exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
> return 0;
> @@ -46,7 +49,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long
> boot_addr)
> {
> void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
>
> - if (!soc_is_exynos4212())
> + if (!soc_is_exynos4212() && !soc_is_exynos3250())
> boot_reg += 4*cpu;
>
> __raw_writel(boot_addr, boot_reg);
> --
> 1.8.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Sylwester, On Mon, Apr 14, 2014 at 7:51 PM, Sylwester Nawrocki wrote: > On 14/04/14 15:49, Vivek Gautam wrote: >> True, we don't have a scope of instantiating this driver using old >> platform device and >> old legacy board files. >> So we don't need this check then, right ? > > I think it can be dropped. > At least IMHO there is no point to increase size of the module with > an error log that has no chance to be ever called in practice. Ok, i will remove this error message and in fact this check. -- Best Regards Vivek Gautam Samsung R&D 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] arm: exynos: generalize power register address calculation
Hi Tomasz,
Thanks for the review comments,
On 14 April 2014 22:58, Tomasz Figa wrote:
> Hi Chander,
>
> Few more comments inline.
>
>
> On 09.04.2014 13:09, Chander Kashyap wrote:
>>
>> Currently status/configuration power register values are hard-coded for
>> cpu1.
>>
>> Make it generic so that it is useful for SoC's with more than two cpus.
>>
>> Signed-off-by: Chander Kashyap
>> ---
>> changes in v2 : Used existing macros for clusterid and cpuid calculation
>>
>> arch/arm/mach-exynos/hotplug.c | 15 ---
>> arch/arm/mach-exynos/platsmp.c | 20 +++-
>> arch/arm/mach-exynos/regs-pmu.h |9 +++--
>> 3 files changed, 34 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/hotplug.c
>> b/arch/arm/mach-exynos/hotplug.c
>> index 5eead53..eab6121 100644
>> --- a/arch/arm/mach-exynos/hotplug.c
>> +++ b/arch/arm/mach-exynos/hotplug.c
>> @@ -17,6 +17,7 @@
>>
>> #include
>> #include
>> +#include
>> #include
>>
>> #include
>> @@ -92,11 +93,19 @@ static inline void cpu_leave_lowpower(void)
>>
>> static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
>> {
>> + unsigned int mpidr, cpunr, cluster;
>> +
>> + mpidr = cpu_logical_map(cpu);
>> + cpunr = MPIDR_AFFINITY_LEVEL(mpidr, 0);
>> + cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
>> +
>> + /* Maximum possible cpus in a cluster can be 4 */
>> + cpunr += cluster * 4;
>
>
> This could be put in a helper, as it seems to be used both by hotplug and
> platsmp code. Also 4 could be defined as a preprocessor macro.
>
Sounds great. I will modify this.
>
>> for (;;) {
>>
>> - /* make cpu1 to be turned off at next WFI command */
>> - if (cpu == 1)
>> - __raw_writel(0, S5P_ARM_CORE1_CONFIGURATION);
>> + /* make cpu to be turned off at next WFI command */
>> + if (cpu)
>
>
> Do you need this if here at all? I don't think there would be any problem
> with this function called for CPU 0 (which shouldn't happen anyway, without
> CPU 0 hotplug support enabled).
>
Well this is to avoid corner case where someone does cpu-hotplug-out
on cpu0 manually.
>
>> + __raw_writel(0,
>> S5P_ARM_CORE_CONFIGURATION(cpunr));
>>
>> /*
>> * here's the WFI
>> diff --git a/arch/arm/mach-exynos/platsmp.c
>> b/arch/arm/mach-exynos/platsmp.c
>> index 8ea02f6..8d06b2c 100644
>> --- a/arch/arm/mach-exynos/platsmp.c
>> +++ b/arch/arm/mach-exynos/platsmp.c
>> @@ -22,6 +22,7 @@
>> #include
>>
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -92,6 +93,14 @@ static int exynos_boot_secondary(unsigned int cpu,
>> struct task_struct *idle)
>> {
>> unsigned long timeout;
>> unsigned long phys_cpu = cpu_logical_map(cpu);
>> + unsigned int mpidr, cpunr, cluster;
>> +
>> + mpidr = cpu_logical_map(cpu);
>> + cpunr = MPIDR_AFFINITY_LEVEL(mpidr, 0);
>> + cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
>> +
>> + /* Maximum possible cpus in a cluster can be 4 */
>> + cpunr += cluster * 4;
>
>
> Here basically the same code is used as in hotplug.c, so a helper would be
> nice. (e.g. cpunr = exynos_pmu_cpunr(mpidr)).
Yes,
>
>
>>
>> /*
>> * Set synchronisation state between this boot processor
>> @@ -109,14 +118,15 @@ static int exynos_boot_secondary(unsigned int cpu,
>> struct task_struct *idle)
>> */
>> write_pen_release(phys_cpu);
>>
>> - if (!(__raw_readl(S5P_ARM_CORE1_STATUS) & S5P_CORE_LOCAL_PWR_EN))
>> {
>> + if (!(__raw_readl(S5P_ARM_CORE_STATUS(cpunr))
>> + & S5P_CORE_LOCAL_PWR_EN)) {
>> __raw_writel(S5P_CORE_LOCAL_PWR_EN,
>> -S5P_ARM_CORE1_CONFIGURATION);
>> +S5P_ARM_CORE_CONFIGURATION(cpunr));
>>
>> timeout = 10;
>>
>> - /* wait max 10 ms until cpu1 is on */
>> - while ((__raw_readl(S5P_ARM_CORE1_STATUS)
>> + /* wait max 10 ms until secondary cpu is on */
>> + while ((__raw_readl(S5P_ARM_CORE_STATUS(cpunr))
>> & S5P_CORE_LOCAL_PWR_EN) != S5P_CORE_LOCAL_PWR_EN)
>> {
>> if (timeout-- == 0)
>> break;
>> @@ -125,7 +135,7 @@ static int exynos_boot_secondary(unsigned int cpu,
>> struct task_struct *idle)
>> }
>>
>> if (timeout == 0) {
>> - printk(KERN_ERR "cpu1 power enable failed");
>> + pr_err("cpu%x power enable failed", cpu);
>
>
> Shouldn't %d be used instead? "cpu a" on a 10-core machine would sound
> weird.
Ok.
>
>
>> spin_unlock(&boot_lock);
>> return -ETIMEDOUT;
>> }
>> diff --git a/arch/arm/mach-exynos/regs-pmu.h
>> b/arch/arm/mach-exynos/re
[PATCHv2 1/8] ARM: EXYNOS: Add Exynos3250 SoC ID
This patch add Exynos3250's SoC ID. Exynos 3250 is System-On-Chip(SoC) that
is based on the 32-bit RISC processor for Smartphone. Exynos3250 uses Cortex-A7
dual cores and has a target speed of 1.0GHz.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
arch/arm/mach-exynos/Kconfig | 22 ++
arch/arm/mach-exynos/exynos.c| 2 ++
arch/arm/plat-samsung/include/plat/cpu.h | 10 ++
3 files changed, 34 insertions(+)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index fc8bf18..6da8a68 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -11,6 +11,17 @@ if ARCH_EXYNOS
menu "SAMSUNG EXYNOS SoCs Support"
+config ARCH_EXYNOS3
+ bool "SAMSUNG EXYNOS3"
+ select ARM_AMBA
+ select CLKSRC_OF
+ select HAVE_ARM_SCU if SMP
+ select HAVE_SMP
+ select PINCTRL
+ select PM_GENERIC_DOMAINS if PM_RUNTIME
+ help
+ Samsung EXYNOS3 SoCs based systems
+
config ARCH_EXYNOS4
bool "SAMSUNG EXYNOS4"
default y
@@ -41,6 +52,17 @@ config ARCH_EXYNOS5
comment "EXYNOS SoCs"
+config SOC_EXYNOS3250
+ bool "SAMSUNG EXYNOS3250"
+ default y
+ depends on ARCH_EXYNOS3
+ select ARCH_HAS_BANDGAP
+ select ARM_CPU_SUSPEND if PM
+ select PINCTRL_EXYNOS
+ select SAMSUNG_DMADEV
+ help
+ Enable EXYNOS3250 CPU support
+
config CPU_EXYNOS4210
bool "SAMSUNG EXYNOS4210"
default y
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index b32a907..a603dfa 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -370,6 +370,8 @@ static void __init exynos_dt_machine_init(void)
}
static char const *exynos_dt_compat[] __initconst = {
+ "samsung,exynos3",
+ "samsung,exynos3250",
"samsung,exynos4",
"samsung,exynos4210",
"samsung,exynos4212",
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h
b/arch/arm/plat-samsung/include/plat/cpu.h
index 5992b8d..3d808f6b 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -43,6 +43,9 @@ extern unsigned long samsung_cpu_id;
#define S5PV210_CPU_ID 0x4311
#define S5PV210_CPU_MASK 0xF000
+#define EXYNOS3250_SOC_ID 0xE3472000
+#define EXYNOS3_SOC_MASK0xF000
+
#define EXYNOS4210_CPU_ID 0x4321
#define EXYNOS4212_CPU_ID 0x4322
#define EXYNOS4412_CPU_ID 0xE4412200
@@ -68,6 +71,7 @@ IS_SAMSUNG_CPU(s5p6440, S5P6440_CPU_ID, S5P64XX_CPU_MASK)
IS_SAMSUNG_CPU(s5p6450, S5P6450_CPU_ID, S5P64XX_CPU_MASK)
IS_SAMSUNG_CPU(s5pc100, S5PC100_CPU_ID, S5PC100_CPU_MASK)
IS_SAMSUNG_CPU(s5pv210, S5PV210_CPU_ID, S5PV210_CPU_MASK)
+IS_SAMSUNG_CPU(exynos3250, EXYNOS3250_SOC_ID, EXYNOS3_SOC_MASK)
IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID, EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
@@ -126,6 +130,12 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID,
EXYNOS5_SOC_MASK)
# define soc_is_s5pv210() 0
#endif
+#if defined(CONFIG_SOC_EXYNOS3250)
+# define soc_is_exynos3250()is_samsung_exynos3250()
+#else
+# define soc_is_exynos3250()0
+#endif
+
#if defined(CONFIG_CPU_EXYNOS4210)
# define soc_is_exynos4210() is_samsung_exynos4210()
#else
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 3/8] ARM: EXYNOS: Add IO mapping for PMU of Exynos3250
This patch add memory mapping for PMU (Power Management Unit) which is used
for power control of Exynos3250.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
Arnd Bergmann suggested that need proper driver instead of static memory
mapping.
As Chanho Park reply[2], Sachin Kamat already posted the DT support patch[1]
for memory mapping for SYSRAM.
[1] http://www.spinics.net/lists/linux-samsung-soc/msg27647.html
[2] https://lkml.org/lkml/2014/4/10/161
So, I'm going to re-implement following patch related to static memory mapping
after merged Sachin Kamat patch[1].
ARM: EXYNOS: Add IO mapping for PMU of Exynos3250
arch/arm/mach-exynos/exynos.c | 5 +
arch/arm/mach-exynos/include/mach/map.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index c7c9472..8f6f73d 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -41,6 +41,11 @@ static struct map_desc exynos3250_iodesc[] __initdata = {
.pfn= __phys_to_pfn(EXYNOS3_PA_SYSRAM_NS),
.length = SZ_4K,
.type = MT_DEVICE,
+ }, {
+ .virtual= (unsigned long)S5P_VA_PMU,
+ .pfn= __phys_to_pfn(EXYNOS3_PA_PMU),
+ .length = SZ_64K,
+ .type = MT_DEVICE,
},
};
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index a53981b..4aea694 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -36,6 +36,7 @@
#define EXYNOS4_PA_SYSCON 0x1001
#define EXYNOS5_PA_SYSCON 0x10050100
+#define EXYNOS3_PA_PMU 0x1002
#define EXYNOS4_PA_PMU 0x1002
#define EXYNOS5_PA_PMU 0x1004
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 2/8] ARM: EXYNOS: Add IO mapping for non-secure SYSRAM of Exynos3250
The non-secure SYSRAM is used for secondary CPU bring-up. This patch add
IO mapping for non-scure SYSRAM.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
Arnd Bergmann suggested that need proper driver instead of static memory
mapping.
As Chanho Park reply[2], Sachin Kamat already posted the DT support patch[1]
for memory mapping for SYSRAM.
[1] http://www.spinics.net/lists/linux-samsung-soc/msg27647.html
[2] https://lkml.org/lkml/2014/4/10/161
So, I'm going to re-implement following patch related to static memory mapping
after merged Sachin Kamat patch[1].
ARM: EXYNOS: Add IO mapping for non-secure SYSRAM of Exynos3250
arch/arm/mach-exynos/exynos.c | 12
arch/arm/mach-exynos/include/mach/map.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index a603dfa..c7c9472 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -35,6 +35,15 @@
#define L2_AUX_VAL 0x7C470001
#define L2_AUX_MASK 0xC200
+static struct map_desc exynos3250_iodesc[] __initdata = {
+ {
+ .virtual= (unsigned long)S5P_VA_SYSRAM_NS,
+ .pfn= __phys_to_pfn(EXYNOS3_PA_SYSRAM_NS),
+ .length = SZ_4K,
+ .type = MT_DEVICE,
+ },
+};
+
static struct map_desc exynos4_iodesc[] __initdata = {
{
.virtual= (unsigned long)S3C_VA_SYS,
@@ -275,6 +284,9 @@ static int __init exynos_fdt_map_chipid(unsigned long node,
const char *uname,
*/
static void __init exynos_map_io(void)
{
+ if (soc_is_exynos3250())
+ iotable_init(exynos3250_iodesc, ARRAY_SIZE(exynos3250_iodesc));
+
if (soc_is_exynos4())
iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 7b046b5..a53981b 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -26,6 +26,7 @@
#define EXYNOS4_PA_SYSRAM0 0x02025000
#define EXYNOS4_PA_SYSRAM1 0x0202
#define EXYNOS5_PA_SYSRAM 0x0202
+#define EXYNOS3_PA_SYSRAM_NS 0x0205F000
#define EXYNOS4210_PA_SYSRAM_NS0x0203F000
#define EXYNOS4x12_PA_SYSRAM_NS0x0204F000
#define EXYNOS5250_PA_SYSRAM_NS0x0204F000
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 6/8] ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7
This patch decide proper lowpower mode of either a15 or a9 according to own ID
from Main ID register.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
arch/arm/mach-exynos/hotplug.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..99e54e0 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -135,16 +135,22 @@ void __ref exynos_cpu_die(unsigned int cpu)
int primary_part = 0;
/*
-* we're ready for shutdown now, so do it.
-* Exynos4 is A9 based while Exynos5 is A15; check the CPU part
+* we're ready for shutdown now, so do it. Exynos4 is A9 based
+* while Exynos5 is A15/Exynos3 is A7; check the CPU part
* number by reading the Main ID register and then perform the
* appropriate sequence for entering low power.
*/
- asm("mrc p15, 0, %0, c0, c0, 0" : "=r"(primary_part) : : "cc");
- if ((primary_part & 0xfff0) == 0xc0f0)
+ primary_part = read_cpuid_part_number();
+
+ switch (primary_part) {
+ case ARM_CPU_PART_CORTEX_A7:
+ case ARM_CPU_PART_CORTEX_A15:
cpu_enter_lowpower_a15();
- else
+ break;
+ default:
cpu_enter_lowpower_a9();
+ break;
+ }
platform_do_lowpower(cpu, &spurious);
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 4/8] ARM: EXYNOS: Support secondary CPU boot of Exynos4212
From: Kyungmin Park
This patch fix the offset of CPU boot address and change parameter of smc call
of SMC_CMD_CPU1BOOT command for Exynos4212.
Signed-off-by: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
arch/arm/mach-exynos/firmware.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index 932129e..aa01c42 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -18,6 +18,8 @@
#include
+#include
+
#include "smc.h"
static int exynos_do_idle(void)
@@ -28,13 +30,24 @@ static int exynos_do_idle(void)
static int exynos_cpu_boot(int cpu)
{
+ /*
+* The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
+* But, Exynos4212 has only one secondary CPU so second parameter
+* isn't used for informing secure firmware about CPU id.
+*/
+ if (soc_is_exynos4212())
+ cpu = 0;
+
exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
return 0;
}
static int exynos_set_cpu_boot_addr(int cpu, unsigned long boot_addr)
{
- void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
+ void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
+
+ if (!soc_is_exynos4212())
+ boot_reg += 4*cpu;
__raw_writel(boot_addr, boot_reg);
return 0;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 7/8] clk: samsung: exynos3250: Add clocks using common clock framework
From: Tomasz Figa This patch add new the clock drvier of Exynos3250 SoC based on Cortex-A7 using common clock framework. The CMU (Clock Management Unit) of Exynos3250 control PLLs(Phase Locked Loops) and generate system clocks for CPU, buses, and function clocks for individual IPs. The CMU of Exynos3250 includes following clock doamins: - CPU block for Cortex-A7 MPCore processor - LEFTBUS/RIGHTBUS block - TOP block for G3D/MFC/LCD0/ISP/CAM/FSYS/MFC/PERIL/PERIR Changes from v1: - None Cc: Mike Turquette Cc: Kukjin Kim Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Signed-off-by: Tomasz Figa Signed-off-by: Chanwoo Choi Signed-off-by: Hyunhee Kim Signed-off-by: Sylwester Nawrocki Signed-off-by: Inki Dae Signed-off-by: Seung-Woo Kim Signed-off-by: Jaehoon Chung Signed-off-by: Karol Wrona Signed-off-by: YoungJun Cho Signed-off-by: Kyungmin Park --- drivers/clk/samsung/Makefile | 1 + drivers/clk/samsung/clk-exynos3250.c | 785 + include/dt-bindings/clock/exynos3250.h | 256 +++ 3 files changed, 1042 insertions(+) create mode 100644 drivers/clk/samsung/clk-exynos3250.c create mode 100644 include/dt-bindings/clock/exynos3250.h diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile index 8eb4799..d120797 100644 --- a/drivers/clk/samsung/Makefile +++ b/drivers/clk/samsung/Makefile @@ -3,6 +3,7 @@ # obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o +obj-$(CONFIG_SOC_EXYNOS3250) += clk-exynos3250.o obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o diff --git a/drivers/clk/samsung/clk-exynos3250.c b/drivers/clk/samsung/clk-exynos3250.c new file mode 100644 index 000..0574a76 --- /dev/null +++ b/drivers/clk/samsung/clk-exynos3250.c @@ -0,0 +1,785 @@ +/* + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * + * 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. + * + * Common Clock Framework support for Exynos3250 SoC. + */ + +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "clk.h" +#include "clk-pll.h" + +#define SRC_LEFTBUS0x4200 +#define DIV_LEFTBUS0x4500 +#define GATE_IP_LEFTBUS0x4800 +#define SRC_RIGHTBUS 0x8200 +#define DIV_RIGHTBUS 0x8500 +#define GATE_IP_RIGHTBUS 0x8800 +#define GATE_IP_PERIR 0x8960 +#define MPLL_LOCK 0xc010 +#define MPLL_CON0 0xc110 +#define VPLL_LOCK 0xc020 +#define VPLL_CON0 0xc120 +#define UPLL_LOCK 0xc030 +#define UPLL_CON0 0xc130 +#define SRC_TOP0 0xc210 +#define SRC_TOP1 0xc214 +#define SRC_CAM0xc220 +#define SRC_MFC0xc228 +#define SRC_G3D0xc22c +#define SRC_LCD0xc234 +#define SRC_ISP0xc238 +#define SRC_FSYS 0xc240 +#define SRC_PERIL0 0xc250 +#define SRC_PERIL1 0xc254 +#define SRC_MASK_TOP 0xc310 +#define SRC_MASK_CAM 0xc320 +#define SRC_MASK_LCD 0xc334 +#define SRC_MASK_ISP 0xc338 +#define SRC_MASK_FSYS 0xc340 +#define SRC_MASK_PERIL00xc350 +#define SRC_MASK_PERIL10xc354 +#define DIV_TOP0xc510 +#define DIV_CAM0xc520 +#define DIV_MFC0xc528 +#define DIV_G3D0xc52c +#define DIV_LCD0xc534 +#define DIV_ISP0xc538 +#define DIV_FSYS0 0xc540 +#define DIV_FSYS1 0xc544 +#define DIV_FSYS2 0xc548 +#define DIV_PERIL0 0xc550 +#define DIV_PERIL1 0xc554 +#define DIV_PERIL3 0xc55c +#define DIV_PERIL4 0xc560 +#define DIV_PERIL5 0xc564 +#define DIV_CAM1 0xc568 +#define CLKDIV2_RATIO 0xc580 +#define GATE_SCLK_CAM 0xc820 +#define GATE_SCLK_MFC 0xc828 +#define GATE_SCLK_G3D 0xc82c +#define GATE_SCLK_LCD 0xc834 +#define GATE_SCLK_ISP_TOP 0xc838 +#define GATE_SCLK_FSYS 0xc840 +#define GATE_SCLK_PERIL0xc850 +#define GATE_IP_CAM0xc920 +#define GATE_IP_MFC0xc928 +#define GATE_IP_G3D0xc92c +#define GATE_IP_LCD0xc934 +#define GATE_IP_ISP0xc938 +#define GATE_IP_FSYS 0xc940 +#define GATE_IP_PERIL 0xc950 +#define GATE_BLOCK 0xc970 +#define APLL_LOCK 0x14000 +#define APLL_CON0 0x14100 +#define SRC_CPU0x14200 +#define DI
[PATCHv2 5/8] ARM: EXYNOS: Support secondary CPU boot of Exynos3250
This patch fix the offset of CPU boot address and don't operate smc call
of SMC_CMD_CPU1BOOT command for Exynos3250.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
arch/arm/mach-exynos/firmware.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index aa01c42..6205d4f 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -30,13 +30,16 @@ static int exynos_do_idle(void)
static int exynos_cpu_boot(int cpu)
{
+ if (soc_is_exynos3250()) {
+ return 0;
/*
* The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
* But, Exynos4212 has only one secondary CPU so second parameter
* isn't used for informing secure firmware about CPU id.
*/
- if (soc_is_exynos4212())
+ } else if (soc_is_exynos4212()) {
cpu = 0;
+ }
exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
return 0;
@@ -46,7 +49,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long
boot_addr)
{
void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
- if (!soc_is_exynos4212())
+ if (!soc_is_exynos4212() && !soc_is_exynos3250())
boot_reg += 4*cpu;
__raw_writel(boot_addr, boot_reg);
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 8/8] ARM: dts: Add device tree sources for Exynos3250
From: Tomasz Figa
This patch add new exynos3250.dtsi to support Exynos3250 SoC based on Cortex-A7
dual core and includes following dt nodes:
- GIC interrupt controller
- Pinctrl to control GPIOs
- Clock controller
- CPU information (Cortex-A7 dual core)
- UART to support serial port
- MCT (Multi Core Timer)
- ADC (Analog Digital Converter)
- I2C/SPI bus
- Power domain
- PMU (Performance Monitoring Unit)
- MSHC (Mobile Storage Host Controller)
- PWM (Pluse Width Modulation)
- AMBA bus
Signed-off-by: Tomasz Figa
Signed-off-by: Chanwoo Choi
Signed-off-by: Kyungmin Park
Signed-off-by: Inki Dae
Signed-off-by: Hyunhee Kim
Signed-off-by: Jaehoon Chung
Signed-off-by: Bartlomiej Zolnierkiewicz
Cc: Ben Dooks
Cc: Kukjin Kim
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Russell King
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 477 ++
arch/arm/boot/dts/exynos3250.dtsi | 410 +
2 files changed, 887 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos3250-pinctrl.dtsi
create mode 100644 arch/arm/boot/dts/exynos3250.dtsi
diff --git a/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
new file mode 100644
index 000..976490b
--- /dev/null
+++ b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
@@ -0,0 +1,477 @@
+/*
+ * Samsung's Exynos3250 SoCs pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos3250 SoCs pin-mux and pin-config optiosn are listed as
device
+ * tree nodes are listed in this file.
+ *
+ * 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.
+*/
+
+/ {
+ pinctrl@1140 {
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpa1: gpa1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpb: gpb {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpc0: gpc0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpc1: gpc1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpd0: gpd0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpd1: gpd1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ uart0_data: uart0-data {
+ samsung,pins = "gpa0-0", "gpa0-1";
+ samsung,pin-function = <0x2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart0_fctl: uart0-fctl {
+ samsung,pins = "gpa0-2", "gpa0-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart1_data: uart1-data {
+ samsung,pins = "gpa0-4", "gpa0-5";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ uart1_fctl: uart1-fctl {
+ samsung,pins = "gpa0-6", "gpa0-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c2_bus: i2c2-bus {
+ samsung,pins = "gpa0-6", "gpa0-7";
+ samsung,pin-function = <3>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ i2c3_bus: i2c3-bus {
+ samsung,pins = "gpa1-2", "gpa1-3";
+ s
[PATCHv2 0/8] Support new Exynos3250 SoC based on Cortex-A7 dual core
This patchset support new Exynos3250 Samsung SoC based on Cortex-A7 dual core. Exynos3250 is a System-On-Chip (SoC) that is based on 32-bit RISC processor for Smartphone. It is desigend with the 28nm low-power high-K metal gate process and provides the best performance features. This patchset include some patches such as: - Support secondary CPU of Exynos3250 (cpu up/down) - Supoort uart/mct/adc/gic/i2c/spi/power-domain/pmu/mshc/pwm/amba - Support the clock control for Exynos3250 using common clk framework This patchset is completely tested and is based on following git repo/branch. - git repo : git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git - branch : for-next (Linux 3.15-rc1) Additional patch description about static memory mapping: Arnd Bergmann suggested that need proper driver instead of static memory mapping. As Chanho Park reply[2], Sachin Kamat already posted the DT support patch[1] for memory mapping for SYSRAM. [1] http://www.spinics.net/lists/linux-samsung-soc/msg27647.html [2] https://lkml.org/lkml/2014/4/10/161 So, I'm going to re-implement following patches related to static memory mapping after merged Sachin Kamat patch[1]. ARM: EXYNOS: Add IO mapping for non-secure SYSRAM of Exynos3250 ARM: EXYNOS: Add IO mapping for PMU of Exynos3250 Changes from v1: - Add new "samsung,exynos3" compatible name - Add comment about exynos_cpu_boot in Exynos4212 - Remove unnecessary 'goto' statement in firmware.c - Use read_cpuid_part_number() function instead of assembler directly - Post separated pinctrl patch from this patchset : https://lkml.org/lkml/2014/4/13/156 - Remove unused pmu interrupts due to Exynos3250 dual-core - Cosolidate all the patches related to exynos3250.dtsi into one patch - Fix gic compatible name to "cortex-a15-gic" because Cortex-A7 GIC is same - Add sign-off of sender to all this patches - Fix minor typo Chanwoo Choi (5): ARM: EXYNOS: Add Exynos3250 SoC ID ARM: EXYNOS: Add IO mapping for non-secure SYSRAM of Exynos3250 ARM: EXYNOS: Add IO mapping for PMU of Exynos3250 ARM: EXYNOS: Support secondary CPU boot of Exynos3250 ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7 Kyungmin Park (1): ARM: EXYNOS: Support secondary CPU boot of Exynos4212 Tomasz Figa (2): clk: samsung: exynos3250: Add clocks using common clock framework ARM: dts: Add device tree sources for Exynos3250 arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 477 ++ arch/arm/boot/dts/exynos3250.dtsi | 410 arch/arm/mach-exynos/Kconfig | 22 + arch/arm/mach-exynos/exynos.c | 19 + arch/arm/mach-exynos/firmware.c | 18 +- arch/arm/mach-exynos/hotplug.c| 16 +- arch/arm/mach-exynos/include/mach/map.h | 2 + arch/arm/plat-samsung/include/plat/cpu.h | 10 + drivers/clk/samsung/Makefile | 1 + drivers/clk/samsung/clk-exynos3250.c | 785 ++ include/dt-bindings/clock/exynos3250.h| 256 ++ 11 files changed, 2010 insertions(+), 6 deletions(-) create mode 100644 arch/arm/boot/dts/exynos3250-pinctrl.dtsi create mode 100644 arch/arm/boot/dts/exynos3250.dtsi create mode 100644 drivers/clk/samsung/clk-exynos3250.c create mode 100644 include/dt-bindings/clock/exynos3250.h -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8] arm64: mm: Implement 4 levels of translation tables
On Tuesday, April 15, 2014 12:14 AM, Steve Capper wrote:
> On Mon, Apr 14, 2014 at 04:41:07PM +0900, Jungseok Lee wrote:
> > This patch implements 4 levels of translation tables since 3 levels of
> > page tables with 4KB pages cannot support 40-bit physical address
> > space described in [1] due to the following issue.
> >
> > It is a restriction that kernel logical memory map with 4KB + 3 levels
> > (0xffc0-0x) cannot cover RAM region from
> > 544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create
> > mapping for this region in map_mem function since __phys_to_virt for
> > this region reaches to address overflow.
> >
> > If SoC design follows the document, [1], over 32GB RAM would be placed
> > from 544GB. Even 64GB system is supposed to use the region from 544GB
> > to 576GB for only 32GB RAM. Naturally, it would reach to enable 4
> > levels of page tables to avoid hacking __virt_to_phys and __phys_to_virt.
> >
> > However, it is recommended 4 levels of page table should be only
> > enabled if memory map is too sparse or there is about 512GB RAM.
> >
> > References
> > --
> > [1]: Principle of ARM Memory Maps, White Paper, Issue C
> >
[ ... ]
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index
> > 6b7e895..321f569 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -222,9 +222,17 @@ static void __init alloc_init_pmd(pud_t *pud,
> > unsigned long addr, static void __init alloc_init_pud(pgd_t *pgd, unsigned
> > long addr,
> > unsigned long end, unsigned long phys) {
> > - pud_t *pud = pud_offset(pgd, addr);
> > + pud_t *pud;
> > unsigned long next;
> >
> > +#ifdef CONFIG_ARM64_4_LEVELS
> > + if (pgd_none(*pgd) || pgd_bad(*pgd)) {
> > + pud = early_alloc(PTRS_PER_PUD * sizeof(pud_t));
> > + pgd_populate(&init_mm, pgd, pud);
> > + }
> > +#endif
>
> We don't need this #ifdef block, as pgd_none and pgd_bad should be zero when
> we have fewer than 4
> levels.
This block is needed to cover the third RAM region from 544GB to 1024GB
described in the document [1].
A single PGD can cover only up to 512GB with 4KB+4Level. In other words,
kernel would reach to panic if a system has RAM over 512GB memory map space.
That is why pgd_none should be handled.
Best Regards
Jungseok Lee
--
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 8/8] arm64: KVM: Implement 4 levels of translation tables for HYP and stage2
On Tuesday, April 15, 2014 1:12 AM, Marc Zyngier wrote:
> On 14/04/14 08:41, Jungseok Lee wrote:
> > This patch adds 4 levels of translation tables implementation for both
> > HYP and stage2. A combination of 4KB + 4 levels host and 4KB + 4
> > levels guest can run on ARMv8 architecture as introducing this feature.
> >
> > Signed-off-by: Jungseok Lee
> > Reviewed-by: Sungjinn Chung
> > ---
> > arch/arm/kvm/mmu.c | 96
> > +-
> > arch/arm64/include/asm/kvm_arm.h | 20
> > arch/arm64/include/asm/kvm_mmu.h |1 +
> > 3 files changed, 106 insertions(+), 11 deletions(-)
> >
> > diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c index
> > e0d4f24..6cf89ad 100644
> > --- a/arch/arm/kvm/mmu.c
> > +++ b/arch/arm/kvm/mmu.c
> > @@ -388,13 +388,46 @@ static int create_hyp_pmd_mappings(pud_t *pud,
> > unsigned long start,
> > return 0;
> > }
> >
> > +static int create_hyp_pud_mappings(pgd_t *pgd, unsigned long start,
> > + unsigned long end, unsigned long pfn,
> > + pgprot_t prot)
> > +{
> > + pud_t *pud;
> > + pmd_t *pmd;
> > + unsigned long addr, next;
> > +
> > + addr = start;
> > + do {
> > + pud = pud_offset(pgd, addr);
> > +
> > + if (pud_none_or_clear_bad(pud)) {
> > + pmd = pmd_alloc_one(NULL, addr);
> > + if (!pmd) {
> > + kvm_err("Cannot allocate Hyp pmd\n");
> > + return -ENOMEM;
> > + }
> > + pud_populate(NULL, pud, pmd);
> > + get_page(virt_to_page(pud));
> > + kvm_flush_dcache_to_poc(pud, sizeof(*pud));
> > + }
> > +
> > + next = pud_addr_end(addr, end);
> > +
> > + create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
> > + pfn += (next - addr) >> PAGE_SHIFT;
> > + } while (addr = next, addr != end);
> > +
> > + return 0;
> > +}
> > +
> > static int __create_hyp_mappings(pgd_t *pgdp,
> > unsigned long start, unsigned long end,
> > unsigned long pfn, pgprot_t prot) {
> > pgd_t *pgd;
> > +#ifdef CONFIG_ARM64_4_LEVELS
> > pud_t *pud;
> > - pmd_t *pmd;
> > +#endif
> > unsigned long addr, next;
> > int err = 0;
> >
> > @@ -403,22 +436,25 @@ static int __create_hyp_mappings(pgd_t *pgdp,
> > end = PAGE_ALIGN(end);
> > do {
> > pgd = pgdp + pgd_index(addr);
> > - pud = pud_offset(pgd, addr);
> >
> > - if (pud_none_or_clear_bad(pud)) {
> > - pmd = pmd_alloc_one(NULL, addr);
> > - if (!pmd) {
> > - kvm_err("Cannot allocate Hyp pmd\n");
> > +#ifdef CONFIG_ARM64_4_LEVELS
> > + if (pgd_none(*pgd)) {
> > + pud = pud_alloc_one(NULL, addr);
> > + if (!pud) {
> > + kvm_err("Cannot allocate Hyp pud\n");
> > err = -ENOMEM;
> > goto out;
> > }
> > - pud_populate(NULL, pud, pmd);
> > - get_page(virt_to_page(pud));
> > - kvm_flush_dcache_to_poc(pud, sizeof(*pud));
> > + pgd_populate(NULL, pgd, pud);
> > + get_page(virt_to_page(pgd));
> > + kvm_flush_dcache_to_poc(pgd, sizeof(*pgd));
> > }
> > +#endif
>
> Why do you need all these #ifdefs? The page table code should be able to cope
> with all the variations
> of presence/absence of pud/pmd (see how there is no code difference between
> 4kB (3 levels) and 64kB (2
> levels)).
Okay, I will remove it.
> > next = pgd_addr_end(addr, end);
> > - err = create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
> > +
> > + err = create_hyp_pud_mappings(pgd, addr, next, pfn, prot);
> > +
> > if (err)
> > goto out;
> > pfn += (next - addr) >> PAGE_SHIFT; @@ -563,6 +599,26 @@ void
> > kvm_free_stage2_pgd(struct kvm *kvm)
> > kvm->arch.pgd = NULL;
> > }
> >
> > +#ifdef CONFIG_ARM64_4_LEVELS
> > +static pud_t *stage2_get_pud(struct kvm *kvm, struct kvm_mmu_memory_cache
> > +*cache, phys_addr_t addr)
> > +{
> > + pgd_t *pgd;
> > + pud_t *pud;
> > +
> > + pgd = kvm->arch.pgd + pgd_index(addr);
> > + if (pgd_none(*pgd)) {
> > + if (!cache)
> > + return NULL;
> > + pud = mmu_memory_cache_alloc(cache);
> > + pgd_populate(NULL, pgd, pud);
> > + get_page(virt_to_page(pgd));
> > + }
> > +
> > + return pud_offset(pgd, addr);
> > +}
> > +#endif
>
> Same here.
Okay.
> > static pmd_t *stage2_get_pmd(struct kvm *kvm, struct kvm_mmu_memory_cache
> > *cache, phys_addr_t addr)
> > {
> > @@ -617,6 +673,24
Re: [PATCH 2/8] arm/arm64: KVM: Fix line length exceeding 80 characters
On Tuesday, April 15, 2014 1:19 AM, Marc Zyngier wrote: > On 14/04/14 08:40, Jungseok Lee wrote: > > This patch deals with checkpatch complaint as fixing line length > > exceeding 80 characters. > > > > WARNING: line over 80 characters > > > > Signed-off-by: Jungseok Lee > > Reviewed-by: Sungjinn Chung > > --- > > arch/arm/kvm/mmu.c |4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c index > > 80bb1e6..e0d4f24 100644 > > --- a/arch/arm/kvm/mmu.c > > +++ b/arch/arm/kvm/mmu.c > > @@ -563,8 +563,8 @@ void kvm_free_stage2_pgd(struct kvm *kvm) > > kvm->arch.pgd = NULL; > > } > > > > -static pmd_t *stage2_get_pmd(struct kvm *kvm, struct kvm_mmu_memory_cache > > *cache, > > -phys_addr_t addr) > > +static pmd_t *stage2_get_pmd(struct kvm *kvm, struct kvm_mmu_memory_cache > > +*cache, phys_addr_t addr) > > Please don't. This makes the code unreadable (and no, I don't care about > checkpatch ;-). Okay. I will drop this patch from the next version. It would be good to change stage2_set_pmd_huge function for readability if you don't care about checkpatch. Best Regards Jungseok Lee -- 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 7/8] arm64: mm: Implement 4 levels of translation tables
On Tuesday, April 15, 2014 12:14 AM, Steve Capper wrote:
> On Mon, Apr 14, 2014 at 04:41:07PM +0900, Jungseok Lee wrote:
> > This patch implements 4 levels of translation tables since 3 levels of
> > page tables with 4KB pages cannot support 40-bit physical address
> > space described in [1] due to the following issue.
> >
> > It is a restriction that kernel logical memory map with 4KB + 3 levels
> > (0xffc0-0x) cannot cover RAM region from
> > 544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create
> > mapping for this region in map_mem function since __phys_to_virt for
> > this region reaches to address overflow.
> >
> > If SoC design follows the document, [1], over 32GB RAM would be placed
> > from 544GB. Even 64GB system is supposed to use the region from 544GB
> > to 576GB for only 32GB RAM. Naturally, it would reach to enable 4
> > levels of page tables to avoid hacking __virt_to_phys and __phys_to_virt.
> >
> > However, it is recommended 4 levels of page table should be only
> > enabled if memory map is too sparse or there is about 512GB RAM.
> >
> > References
> > --
> > [1]: Principle of ARM Memory Maps, White Paper, Issue C
> >
>
> Hi Jungseok,
> I've given this a quick run on the Fast Model with huge pages, and it passed
> the libhugetlbfs test
> suite.
It sounds good.
> Some comments/suggestions below...
I really thank you.
> > Signed-off-by: Jungseok Lee
> > Reviewed-by: Sungjinn Chung
> > ---
> > arch/arm64/Kconfig |7 +
> > arch/arm64/include/asm/page.h |4 ++-
> > arch/arm64/include/asm/pgalloc.h | 20 ++
> > arch/arm64/include/asm/pgtable-hwdef.h |8 --
> > arch/arm64/include/asm/pgtable.h | 44
> > +--
> > arch/arm64/include/asm/tlb.h |8 ++
> > arch/arm64/kernel/head.S | 45
> > ++--
> > arch/arm64/kernel/traps.c |5
> > arch/arm64/mm/fault.c |1 +
> > arch/arm64/mm/mmu.c| 14 +-
> > 10 files changed, 148 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index
> > 431acbc..7f5270b 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -184,12 +184,19 @@ config ARM64_3_LEVELS
> > help
> > This feature enables 3 levels of translation tables.
> >
> > +config ARM64_4_LEVELS
> > + bool "4 level"
> > + depends on ARM64_4K_PAGES
> > + help
> > + This feature enables 4 levels of translation tables.
> > +
> > endchoice
> >
> > config ARM64_VA_BITS
> > int "Virtual address space size"
> > range 39 39 if ARM64_4K_PAGES && ARM64_3_LEVELS
> > range 42 42 if ARM64_64K_PAGES && ARM64_2_LEVELS
> > + range 48 48 if ARM64_4K_PAGES && ARM64_4_LEVELS
> > help
> > This feature is determined by a combination of page size and
> > level of translation tables.
> > diff --git a/arch/arm64/include/asm/page.h
> > b/arch/arm64/include/asm/page.h index 268e53d..83b5289 100644
> > --- a/arch/arm64/include/asm/page.h
> > +++ b/arch/arm64/include/asm/page.h
> > @@ -35,8 +35,10 @@
> >
> > #ifdef CONFIG_ARM64_2_LEVELS
> > #include -#else
> > +#elif defined(CONFIG_ARM64_3_LEVELS)
> > #include
> > +#else
> > +#include
> > #endif
> >
> > extern void __cpu_clear_user_page(void *p, unsigned long user); diff
> > --git a/arch/arm64/include/asm/pgalloc.h
> > b/arch/arm64/include/asm/pgalloc.h
> > index 4829837..8d745fa 100644
> > --- a/arch/arm64/include/asm/pgalloc.h
> > +++ b/arch/arm64/include/asm/pgalloc.h
> > @@ -26,6 +26,26 @@
> >
> > #define check_pgt_cache() do { } while (0)
> >
> > +#ifdef CONFIG_ARM64_4_LEVELS
> > +
> > +static inline pud_t *pud_alloc_one(struct mm_struct *mm, unsigned
> > +long addr) {
> > + return (pud_t *)get_zeroed_page(GFP_KERNEL | __GFP_REPEAT); }
> > +
> > +static inline void pud_free(struct mm_struct *mm, pud_t *pud) {
> > + BUG_ON((unsigned long)pud & (PAGE_SIZE-1));
> > + free_page((unsigned long)pud);
> > +}
> > +
> > +static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd,
> > +pud_t *pud) {
> > + set_pgd(pgd, __pgd(__pa(pud) | PUD_TYPE_TABLE));
>
> Perhaps instead use PGD_TYPE_TABLE?
pud_populate uses PMD_TYPE_TABLE. That is why I choose PUD_TYPE_TABLE
instead of PGD_TYPE_TABLE.
> > +}
> > +
> > +#endif /* CONFIG_ARM64_4_LEVELS */
> > +
> > #ifndef CONFIG_ARM64_2_LEVELS
> >
> > static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned
> > long addr) diff --git a/arch/arm64/include/asm/pgtable-hwdef.h
> > b/arch/arm64/include/asm/pgtable-hwdef.h
> > index 9cd86c6..03ad81b 100644
> > --- a/arch/arm64/include/asm/pgtable-hwdef.h
> > +++ b/arch/arm64/include/asm/pgtable-hwdef.h
> > @@ -18,8 +18,10 @@
> >
> > #ifdef CONFIG_ARM64_2_LEVELS
> > #include -#else
> > +#elif defined(CONFIG_ARM64_3_LEVELS)
> > #include
> > +#else
> > +#include
> >
Re: [PATCH 3/4] drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210 SoC
Hi Tomasz,
On 04/15/2014 12:00 AM, Tomasz Stanislawski wrote:
This patch add proper compatibles for Mixer and HDMI chip
available on exynos4210 SoCs.
Signed-off-by: Tomasz Stanislawski
---
drivers/gpu/drm/exynos/exynos_hdmi.c |3 +++
drivers/gpu/drm/exynos/exynos_mixer.c |3 +++
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index d2d6e2e..6fa63ea 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2032,6 +2032,9 @@ static struct s5p_hdmi_platform_data
*drm_hdmi_dt_parse_pdata
static struct of_device_id hdmi_match_types[] = {
{
+ .compatible = "samsung,exynos4210-hdmi",
+ .data = (void *)HDMI_TYPE13,
It's consistent with others to use struct hdmi_driver_data like
exynos5_hdmi_driver_data.
+ }, {
.compatible = "samsung,exynos5-hdmi",
.data = &exynos5_hdmi_driver_data,
}, {
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index e3306c8..fd8a9a0 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1187,6 +1187,9 @@ static struct platform_device_id mixer_driver_types[] = {
static struct of_device_id mixer_match_types[] = {
{
+ .compatible = "samsung,exynos4210-mixer",
+ .data = &exynos4210_mxr_drv_data,
+ }, {
.compatible = "samsung,exynos5-mixer",
.data = &exynos5250_mxr_drv_data,
}, {
--
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: exynos5250-snow: add ptn3460 node
Hi Sachin, On Mon, Apr 14, 2014 at 6:16 AM, Sachin Kamat wrote: > From: Doug Anderson > > Added nodes for ptn3460 driver to Snow board. > > Signed-off-by: Doug Anderson > Signed-off-by: Ajay Kumar > Signed-off-by: Sachin Kamat I'm curious, how are you testing this code on the upstream kernel before you post the patches? Especially since Doug was referring to some of these containing parts that is needed for drivers that are not yet upstreamed. -Olof -- 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: exynos5250-snow: add ptn3460 node
Sachin, On Mon, Apr 14, 2014 at 6:16 AM, Sachin Kamat wrote: > From: Doug Anderson For this patch in particular giving me authorship is pretty tenuous. I don't think I was even the author of the majority of the code in the chromium tree. > Added nodes for ptn3460 driver to Snow board. > > Signed-off-by: Doug Anderson > Signed-off-by: Ajay Kumar > Signed-off-by: Sachin Kamat > --- > arch/arm/boot/dts/exynos5250-snow.dts | 19 +++ > 1 file changed, 19 insertions(+) I don't see any problems here but really the graphics people are the ones that should be commenting. Added a few folks to the CC list. For the general GPIOs / pinctrl stuff, though: Reviewed-by: Doug Anderson ...and as Olof points out, please let us know how this was all tested. -- 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] ARM: dts: exynos5250-snow: add pinctrl for i2c-arbitrator
Tomasz,
On Mon, Apr 14, 2014 at 3:38 PM, Tomasz Figa wrote:
> Hi Doug,
>
>
> On 15.04.2014 00:30, Doug Anderson wrote:
>>
>> Sachin,
>>
>> On Mon, Apr 14, 2014 at 6:16 AM, Sachin Kamat
>> wrote:
>>>
>>> From: Doug Anderson
>>
>>
>> I probably wouldn't have bothered giving me authorship since this
>> isn't exactly a clean patch from the chromium tree (you pulled the
>> proper pieces yourself, did the commit message yourself, etc). ...but
>> I appreciate the thought and as far as I know setting the "author" in
>> cases like this is a bit of a judgement call...
>>
>> The Signed-off-by is certainly correct. ;)
>>
>>>
>>> Added i2c-arbitrator pinctrl node to Snow board.
>>>
>>> Signed-off-by: Doug Anderson
>>> Signed-off-by: Sachin Kamat
>>> ---
>>> arch/arm/boot/dts/exynos5250-snow.dts | 19 +++
>>> 1 file changed, 19 insertions(+)
>>
>>
>> This matches what's in our tree and and is what people are using, so:
>>
>> Reviewed-by: Doug Anderson
>>
>>
>>> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
>>> b/arch/arm/boot/dts/exynos5250-snow.dts
>>> index 1ce1088..32715b3 100644
>>> --- a/arch/arm/boot/dts/exynos5250-snow.dts
>>> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
>>> @@ -39,6 +39,22 @@
>>> };
>>> };
>>>
>>> + pinctrl@1340 {
>>> + arb_their_claim: arb-their-claim {
>>> + samsung,pins = "gpe0-4";
>>> + samsung,pin-function = <0>;
>>> + samsung,pin-pud = <3>;
>>> + samsung,pin-drv = <0>;
>>> + };
>>> +
>>> + arb_our_claim: arb-our-claim {
>>> + samsung,pins = "gpf0-3";
>>> + samsung,pin-function = <1>;
>>> + samsung,pin-pud = <0>;
>>> + samsung,pin-drv = <0>;
>>> + };
>>
>>
>> It's odd to me that one of these has a pullup but not the other, but I
>> think that's because the arbitration lines ended up using some other
>> signals that were originally hooked up for other usage. Certainly the
>> pullups / pulldowns match what's in our tree and also match what we
>> had in the original shipping 3.4 kernel.
>
>
> Just a wild guess, but probably the input needs a pull-up, while obviously
> the output doesn't. I don't have much idea about the arbitration thing
> happening on snow, so I can't say much about this series. (Maybe description
> of patch 1/4 should be saying a bit more about the meaning of this?)
Right, of course. I'm not sure quite what I was thinking. I think I
was getting confused since these go through level converters and my
brain was in open drain mode. ...but looking at this again this looks
reasonable.
I think the whole discussion of arbitration was from a long time ago.
I think it's fairly well documented in the "i2c-arb-gpio-challenge"
driver.
Basically it looks like Sachin is getting pinctrl stuff matched up
properly for the device tree that's upstream.
-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 3/4] ARM: dts: exynos5250-snow: add tps65090 power regulator
Sachin,
On Mon, Apr 14, 2014 at 6:16 AM, Sachin Kamat wrote:
> From: Doug Anderson
>
> Added TPS65090 regulator related nodes to Snow board.
>
> Signed-off-by: Doug Anderson
> Signed-off-by: Sachin Kamat
> ---
> arch/arm/boot/dts/exynos5250-snow.dts | 90
> +
> 1 file changed, 90 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
> b/arch/arm/boot/dts/exynos5250-snow.dts
> index 469c85d..a38fd18 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -44,6 +44,13 @@
> sd3_bus4: sd3-bus-width4 {
> samsung,pin-drv = <0>;
> };
> +
> + tps65090_irq: tps65090-irq {
> + samsung,pins = "gpx2-6";
> + samsung,pin-function = <0>;
> + samsung,pin-pud = <0>;
> + samsung,pin-drv = <0>;
> + };
> };
>
> pinctrl@1340 {
> @@ -75,6 +82,12 @@
> };
> };
>
> + vbat: vbat-fixed-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vbat-supply";
> + regulator-boot-on;
> + };
> +
> i2c-arbitrator {
> compatible = "i2c-arb-gpio-challenge";
> #address-cells = <1>;
> @@ -201,6 +214,83 @@
> 0x070c0069>;/*
> LEFT */
> };
> };
> +
> + power-regulator {
> + compatible = "ti,tps65090";
> + reg = <0x48>;
> +
> + /*
> +* Config irq to disable internal pulls
> +* even though we run in polling mode.
This comment refers to a feature that hasn't yet been sent upstream.
...but it's a good reminder and I can send it upstream now. You can
see it at:
* https://chromium-review.googlesource.com/62630
* https://chromium-review.googlesource.com/175653
Since this is only a comment I guess it's OK to refer to a feature
that hasn't yet landed (?).
> +*/
> + pinctrl-names = "default";
> + pinctrl-0 = <&tps65090_irq>;
> +
> + vsys1-supply = <&vbat>;
> + vsys2-supply = <&vbat>;
> + vsys3-supply = <&vbat>;
> + infet1-supply = <&vbat>;
> + infet2-supply = <&vbat>;
> + infet3-supply = <&vbat>;
> + infet4-supply = <&vbat>;
> + infet5-supply = <&vbat>;
> + infet6-supply = <&vbat>;
> + infet7-supply = <&vbat>;
> + vsys-l1-supply = <&vbat>;
> + vsys-l2-supply = <&vbat>;
> +
> + regulators {
> + dcdc1 {
> + ti,enable-ext-control;
> + };
> + dcdc2 {
> + ti,enable-ext-control;
> + };
> + dcdc3 {
> + ti,enable-ext-control;
> + };
> + fet1 {
> + regulator-name = "vcd_led";
> + ti,overcurrent-wait = <3>;
This is also referring to something that hasn't been sent upstream yet. See:
* https://chromium-review.googlesource.com/184607
> + };
> + tps65090_fet2: fet2 {
> + regulator-name = "video_mid";
> + regulator-always-on;
> + ti,overcurrent-wait = <3>;
> + };
> + fet3 {
> + regulator-name = "wwan_r";
> + regulator-always-on;
> + ti,overcurrent-wait = <3>;
> + };
> + fet4 {
> + regulator-name = "sdcard";
> + ti,overcurrent-wait = <3>;
> + };
> +
Re: [PATCH 1/4] ARM: dts: exynos5250-snow: add pinctrl for i2c-arbitrator
Hi Doug,
On 15.04.2014 00:30, Doug Anderson wrote:
Sachin,
On Mon, Apr 14, 2014 at 6:16 AM, Sachin Kamat wrote:
From: Doug Anderson
I probably wouldn't have bothered giving me authorship since this
isn't exactly a clean patch from the chromium tree (you pulled the
proper pieces yourself, did the commit message yourself, etc). ...but
I appreciate the thought and as far as I know setting the "author" in
cases like this is a bit of a judgement call...
The Signed-off-by is certainly correct. ;)
Added i2c-arbitrator pinctrl node to Snow board.
Signed-off-by: Doug Anderson
Signed-off-by: Sachin Kamat
---
arch/arm/boot/dts/exynos5250-snow.dts | 19 +++
1 file changed, 19 insertions(+)
This matches what's in our tree and and is what people are using, so:
Reviewed-by: Doug Anderson
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 1ce1088..32715b3 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -39,6 +39,22 @@
};
};
+ pinctrl@1340 {
+ arb_their_claim: arb-their-claim {
+ samsung,pins = "gpe0-4";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ arb_our_claim: arb-our-claim {
+ samsung,pins = "gpf0-3";
+ samsung,pin-function = <1>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
It's odd to me that one of these has a pullup but not the other, but I
think that's because the arbitration lines ended up using some other
signals that were originally hooked up for other usage. Certainly the
pullups / pulldowns match what's in our tree and also match what we
had in the original shipping 3.4 kernel.
Just a wild guess, but probably the input needs a pull-up, while
obviously the output doesn't. I don't have much idea about the
arbitration thing happening on snow, so I can't say much about this
series. (Maybe description of patch 1/4 should be saying a bit more
about the meaning of this?)
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 2/4] ARM: dts: exynos5250-snow: add pinctrl for EC irq
Sachin, On Mon, Apr 14, 2014 at 6:16 AM, Sachin Kamat wrote: > From: Doug Anderson > > Added pinctrl node for embedded controller (EC) IRQ > on Snow board. > > Signed-off-by: Doug Anderson > Signed-off-by: Sachin Kamat > --- > arch/arm/boot/dts/exynos5250-snow.dts |9 + > 1 file changed, 9 insertions(+) Reviewed-by: Doug Anderson -- 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] ARM: dts: exynos5250-snow: add pinctrl for i2c-arbitrator
Sachin,
On Mon, Apr 14, 2014 at 6:16 AM, Sachin Kamat wrote:
> From: Doug Anderson
I probably wouldn't have bothered giving me authorship since this
isn't exactly a clean patch from the chromium tree (you pulled the
proper pieces yourself, did the commit message yourself, etc). ...but
I appreciate the thought and as far as I know setting the "author" in
cases like this is a bit of a judgement call...
The Signed-off-by is certainly correct. ;)
>
> Added i2c-arbitrator pinctrl node to Snow board.
>
> Signed-off-by: Doug Anderson
> Signed-off-by: Sachin Kamat
> ---
> arch/arm/boot/dts/exynos5250-snow.dts | 19 +++
> 1 file changed, 19 insertions(+)
This matches what's in our tree and and is what people are using, so:
Reviewed-by: Doug Anderson
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
> b/arch/arm/boot/dts/exynos5250-snow.dts
> index 1ce1088..32715b3 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -39,6 +39,22 @@
> };
> };
>
> + pinctrl@1340 {
> + arb_their_claim: arb-their-claim {
> + samsung,pins = "gpe0-4";
> + samsung,pin-function = <0>;
> + samsung,pin-pud = <3>;
> + samsung,pin-drv = <0>;
> + };
> +
> + arb_our_claim: arb-our-claim {
> + samsung,pins = "gpf0-3";
> + samsung,pin-function = <1>;
> + samsung,pin-pud = <0>;
> + samsung,pin-drv = <0>;
> + };
It's odd to me that one of these has a pullup but not the other, but I
think that's because the arbitration lines ended up using some other
signals that were originally hooked up for other usage. Certainly the
pullups / pulldowns match what's in our tree and also match what we
had in the original shipping 3.4 kernel.
--
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 07/20] cpufreq: exynos: Use cpufreq_for_each_entry macro for iteration
The cpufreq core supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/exynos-cpufreq.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index f99cfe2..0e19bce 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -28,18 +28,18 @@ static unsigned int locking_frequency;
static int exynos_cpufreq_get_index(unsigned int freq)
{
- struct cpufreq_frequency_table *freq_table = exynos_info->freq_table;
- int index;
+ struct cpufreq_frequency_table *pos, *freq_table;
- for (index = 0;
- freq_table[index].frequency != CPUFREQ_TABLE_END; index++)
- if (freq_table[index].frequency == freq)
+ freq_table = exynos_info->freq_table;
+ cpufreq_for_each_entry(pos, freq_table) {
+ if (pos->frequency == freq)
break;
+ }
- if (freq_table[index].frequency == CPUFREQ_TABLE_END)
+ if (pos->frequency == CPUFREQ_TABLE_END)
return -EINVAL;
- return index;
+ return pos - freq_table;
}
static int exynos_cpufreq_scale(unsigned int target_freq)
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/20] cpufreq: exynos5440: Use cpufreq_for_each_entry macro for iteration
The cpufreq core supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
Signed-off-by: Stratos Karafotis
---
drivers/cpufreq/exynos5440-cpufreq.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
b/drivers/cpufreq/exynos5440-cpufreq.c
index a6b8214..3e3dd0c 100644
--- a/drivers/cpufreq/exynos5440-cpufreq.c
+++ b/drivers/cpufreq/exynos5440-cpufreq.c
@@ -114,25 +114,23 @@ static struct cpufreq_freqs freqs;
static int init_div_table(void)
{
- struct cpufreq_frequency_table *freq_tbl = dvfs_info->freq_table;
+ struct cpufreq_frequency_table *pos, *freq_tbl = dvfs_info->freq_table;
unsigned int tmp, clk_div, ema_div, freq, volt_id;
- int i = 0;
struct dev_pm_opp *opp;
rcu_read_lock();
- for (i = 0; freq_tbl[i].frequency != CPUFREQ_TABLE_END; i++) {
-
+ cpufreq_for_each_entry(pos, freq_tbl) {
opp = dev_pm_opp_find_freq_exact(dvfs_info->dev,
- freq_tbl[i].frequency * 1000, true);
+ pos->frequency * 1000, true);
if (IS_ERR(opp)) {
rcu_read_unlock();
dev_err(dvfs_info->dev,
"failed to find valid OPP for %u KHZ\n",
- freq_tbl[i].frequency);
+ pos->frequency);
return PTR_ERR(opp);
}
- freq = freq_tbl[i].frequency / 1000; /* In MHZ */
+ freq = pos->frequency / 1000; /* In MHZ */
clk_div = ((freq / CPU_DIV_FREQ_MAX) & P0_7_CPUCLKDEV_MASK)
<< P0_7_CPUCLKDEV_SHIFT;
clk_div |= ((freq / CPU_ATB_FREQ_MAX) & P0_7_ATBCLKDEV_MASK)
@@ -157,7 +155,8 @@ static int init_div_table(void)
tmp = (clk_div | ema_div | (volt_id << P0_7_VDD_SHIFT)
| ((freq / FREQ_UNIT) << P0_7_FREQ_SHIFT));
- __raw_writel(tmp, dvfs_info->base + XMU_PMU_P0_7 + 4 * i);
+ __raw_writel(tmp, dvfs_info->base + XMU_PMU_P0_7 + 4 *
+ (pos - freq_tbl));
}
rcu_read_unlock();
@@ -166,8 +165,9 @@ static int init_div_table(void)
static void exynos_enable_dvfs(unsigned int cur_frequency)
{
- unsigned int tmp, i, cpu;
+ unsigned int tmp, cpu;
struct cpufreq_frequency_table *freq_table = dvfs_info->freq_table;
+ struct cpufreq_frequency_table *pos;
/* Disable DVFS */
__raw_writel(0, dvfs_info->base + XMU_DVFS_CTRL);
@@ -182,15 +182,15 @@ static void exynos_enable_dvfs(unsigned int cur_frequency)
__raw_writel(tmp, dvfs_info->base + XMU_PMUIRQEN);
/* Set initial performance index */
- for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END; i++)
- if (freq_table[i].frequency == cur_frequency)
+ cpufreq_for_each_entry(pos, freq_table) {
+ if (pos->frequency == cur_frequency)
break;
+ }
- if (freq_table[i].frequency == CPUFREQ_TABLE_END) {
+ if (pos->frequency == CPUFREQ_TABLE_END) {
dev_crit(dvfs_info->dev, "Boot up frequency not supported\n");
/* Assign the highest frequency */
- i = 0;
- cur_frequency = freq_table[i].frequency;
+ cur_frequency = freq_table->frequency;
}
dev_info(dvfs_info->dev, "Setting dvfs initial frequency = %uKHZ",
@@ -199,7 +199,7 @@ static void exynos_enable_dvfs(unsigned int cur_frequency)
for (cpu = 0; cpu < CONFIG_NR_CPUS; cpu++) {
tmp = __raw_readl(dvfs_info->base + XMU_C0_3_PSTATE + cpu * 4);
tmp &= ~(P_VALUE_MASK << C0_3_PSTATE_NEW_SHIFT);
- tmp |= (i << C0_3_PSTATE_NEW_SHIFT);
+ tmp |= ((pos - freq_table) << C0_3_PSTATE_NEW_SHIFT);
__raw_writel(tmp, dvfs_info->base + XMU_C0_3_PSTATE + cpu * 4);
}
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] regulator: s2mps11: Add external GPIO control for S2MPS14
On Mon, Apr 14, 2014 at 10:09:07AM +0200, Krzysztof Kozlowski wrote: > Add support for external control over GPIO for LDO10, LDO11 and LDO12 > S2MPS14 regulators. External control can be turned on by writing 0x0 to > control register which in case of other regulators is used for disabling > them. These LDO10-LDO12 regulators can be disabled only by I2C GPIO or > PWREN pin so the patch actually allows proper way of disabling them. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 1/4] regulator: s2mps11: Move DTS parsing code to separate function
On Mon, Apr 14, 2014 at 10:09:06AM +0200, Krzysztof Kozlowski wrote: > Refactor code for parsing DTS to increase a little code readability. The > behaviour should not change. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 3/4] Documentation: regulator: s2mps11: Document external GPIO control
On Mon, Apr 14, 2014 at 10:09:08AM +0200, Krzysztof Kozlowski wrote: > Add documentation for new property for controlling (enable/disable) some > of the S2MPS14 regulators by GPIO. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 4/4] regulator: s5m8767: Use same binding for external control as in s2mps11
On Mon, Apr 14, 2014 at 10:09:09AM +0200, Krzysztof Kozlowski wrote: > - - s5m8767,pmic-ext-control-gpios: (optional) GPIO specifier for one > + - samsung,ext-control-gpios: (optional) GPIO specifier for one > GPIO controlling this regulator (enable/disable); This is > valid only for buck9. This is an incompatible change. It's OK to deprecate the old property but it's bad form to just remove it. signature.asc Description: Digital signature
Re: [PATCH] arm: exynos: generalize power register address calculation
Hi Chander,
Few more comments inline.
On 09.04.2014 13:09, Chander Kashyap wrote:
Currently status/configuration power register values are hard-coded for cpu1.
Make it generic so that it is useful for SoC's with more than two cpus.
Signed-off-by: Chander Kashyap
---
changes in v2 : Used existing macros for clusterid and cpuid calculation
arch/arm/mach-exynos/hotplug.c | 15 ---
arch/arm/mach-exynos/platsmp.c | 20 +++-
arch/arm/mach-exynos/regs-pmu.h |9 +++--
3 files changed, 34 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..eab6121 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
@@ -92,11 +93,19 @@ static inline void cpu_leave_lowpower(void)
static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
{
+ unsigned int mpidr, cpunr, cluster;
+
+ mpidr = cpu_logical_map(cpu);
+ cpunr = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+ /* Maximum possible cpus in a cluster can be 4 */
+ cpunr += cluster * 4;
This could be put in a helper, as it seems to be used both by hotplug
and platsmp code. Also 4 could be defined as a preprocessor macro.
for (;;) {
- /* make cpu1 to be turned off at next WFI command */
- if (cpu == 1)
- __raw_writel(0, S5P_ARM_CORE1_CONFIGURATION);
+ /* make cpu to be turned off at next WFI command */
+ if (cpu)
Do you need this if here at all? I don't think there would be any
problem with this function called for CPU 0 (which shouldn't happen
anyway, without CPU 0 hotplug support enabled).
+ __raw_writel(0, S5P_ARM_CORE_CONFIGURATION(cpunr));
/*
* here's the WFI
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 8ea02f6..8d06b2c 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -22,6 +22,7 @@
#include
#include
+#include
#include
#include
#include
@@ -92,6 +93,14 @@ static int exynos_boot_secondary(unsigned int cpu, struct
task_struct *idle)
{
unsigned long timeout;
unsigned long phys_cpu = cpu_logical_map(cpu);
+ unsigned int mpidr, cpunr, cluster;
+
+ mpidr = cpu_logical_map(cpu);
+ cpunr = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+ /* Maximum possible cpus in a cluster can be 4 */
+ cpunr += cluster * 4;
Here basically the same code is used as in hotplug.c, so a helper would
be nice. (e.g. cpunr = exynos_pmu_cpunr(mpidr)).
/*
* Set synchronisation state between this boot processor
@@ -109,14 +118,15 @@ static int exynos_boot_secondary(unsigned int cpu, struct
task_struct *idle)
*/
write_pen_release(phys_cpu);
- if (!(__raw_readl(S5P_ARM_CORE1_STATUS) & S5P_CORE_LOCAL_PWR_EN)) {
+ if (!(__raw_readl(S5P_ARM_CORE_STATUS(cpunr))
+ & S5P_CORE_LOCAL_PWR_EN)) {
__raw_writel(S5P_CORE_LOCAL_PWR_EN,
-S5P_ARM_CORE1_CONFIGURATION);
+S5P_ARM_CORE_CONFIGURATION(cpunr));
timeout = 10;
- /* wait max 10 ms until cpu1 is on */
- while ((__raw_readl(S5P_ARM_CORE1_STATUS)
+ /* wait max 10 ms until secondary cpu is on */
+ while ((__raw_readl(S5P_ARM_CORE_STATUS(cpunr))
& S5P_CORE_LOCAL_PWR_EN) != S5P_CORE_LOCAL_PWR_EN) {
if (timeout-- == 0)
break;
@@ -125,7 +135,7 @@ static int exynos_boot_secondary(unsigned int cpu, struct
task_struct *idle)
}
if (timeout == 0) {
- printk(KERN_ERR "cpu1 power enable failed");
+ pr_err("cpu%x power enable failed", cpu);
Shouldn't %d be used instead? "cpu a" on a 10-core machine would sound
weird.
spin_unlock(&boot_lock);
return -ETIMEDOUT;
}
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 7c029ce..16e17e4 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -104,8 +104,13 @@
#define S5P_GPS_LOWPWRS5P_PMUREG(0x139C)
#define S5P_GPS_ALIVE_LOWPWR S5P_PMUREG(0x13A0)
-#define S5P_ARM_CORE1_CONFIGURATIONS5P_PMUREG(0x2080)
-#define S5P_ARM_CORE1_STATUS S5P_PMUREG(0x2084)
+#define S5P_ARM_CORE0_CONFIGURATIONS5P_PMUREG(0x2000)
+#define S5P_ARM_CORE0_STATUS S5P_PMUREG(0x2004)
+
+#define S5P_ARM_CORE_CONFIGURATION(_cpun
Re: [PATCH] arm: exynos: generalize power register address calculation
On 14.04.2014 06:27, Chander Kashyap wrote:
Hi,
On 10 April 2014 11:18, Chander Kashyap wrote:
Hi Tomasz,
On 9 April 2014 20:15, Tomasz Figa wrote:
On 09.04.2014 15:49, Chander Kashyap wrote:
Hi Tomasz,
On 9 April 2014 17:19, Tomasz Figa wrote:
Hi Chander,
On 09.04.2014 13:09, Chander Kashyap wrote:
Currently status/configuration power register values are hard-coded for
cpu1.
Make it generic so that it is useful for SoC's with more than two cpus.
Signed-off-by: Chander Kashyap
---
changes in v2 : Used existing macros for clusterid and cpuid calculation
arch/arm/mach-exynos/hotplug.c | 15 ---
arch/arm/mach-exynos/platsmp.c | 20 +++-
arch/arm/mach-exynos/regs-pmu.h |9 +++--
3 files changed, 34 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c
b/arch/arm/mach-exynos/hotplug.c
index 5eead53..eab6121 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
@@ -92,11 +93,19 @@ static inline void cpu_leave_lowpower(void)
static inline void platform_do_lowpower(unsigned int cpu, int
*spurious)
{
+ unsigned int mpidr, cpunr, cluster;
+
+ mpidr = cpu_logical_map(cpu);
+ cpunr = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+ /* Maximum possible cpus in a cluster can be 4 */
+ cpunr += cluster * 4;
I believe this is rather a weak assumption. First of all, the limit seems
to
be hardcoded only for the few existing SoCs. In addition, the value is
not
used as a maximum, but rather it is assumed that each cluster has always
four cores.
The MPIDR register contains 2 bits for cpu id. Hence maximum number of
cpus can be 4 only (A15/A9/A7).
This is not what I meant. Exynos5260 contains 2 big cores (not 4) and 4
little cores. Are you sure that PMU register layout on Exynos5260 matches
your equation?
Yes the equation covers that as the PMU register layout takes care for that:
Address offset are as follows:
2 Big Cores:
cpu0 : 2000
cpu1: 2080
4 Little cores:
cpu0: 2200
cpu1: 2280
cpu2: 2300
cpu3: 2380
Moreover, it is assumed here that the mapping between core ID (calculated
by
the equation below) and PMU core numbers is 1:1, which is not true. On
Exynos4210, the cluster ID is always 0x09 and on Exynos4x12 it is 0x0a,
which will lead to completely wrong register offsets.
Exynos4210 and Exynos4x12, cluster ids are not passed from DT as it
breaks the gic_init_bases. Hence the Physical CpuID for Exynos4210
will be 0,1 and Exynos4x12 will be 0,1,2,3.
So it will not break.
I already have patches ready fixing GIC driver, just waiting for 3.15-rc1 to
be released. Anyway, CPU topology in DT is mandatory and Exynos4 device tree
files need to be fixed to contain them. This needs to be accounted for in
any changes touching CPU topology related code.
That's great.
I believe the proper way to deal with this is to provide per-CPU property
in
DT called "samsung,pmu-offset" that could be used be code like this to
calculate register addresses properly.
For now, I would recommend doing the above ignoring cluster ID completely
to
not break (and actually fix) single cluster systems and existing multi
cluster ones on which only the first cluster is supported now.
After that, per-CPU PMU offset should be implemented to support
multi-cluster SoCs with proper support of multiple clusters.
As of now the smp-boot (cores > 2) is broken. This is required to fix it.
SMP boot works fine on all four cores of Exynos 4412. Obiously hot-(un)plug
doesn't, but this is another issue.
It works as of now as at power on all the cores powered on. Hence the
powerOn in platsmp.c doent make any difference, It breaks in hotplug
as we always poweron cpu1, not the correct cpu.
Best regards,
Tomasz
--
with warm regards,
Chander Kashyap
Any other comments on this patch. If not then can it be merged?
Please make the patch account for supported Exynos 4 SoCs, with topology
data specified. The fact that GIC driver is buggy right now doesn't mean
that newly added code should assume that topology is not specified.
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 2/8] arm/arm64: KVM: Fix line length exceeding 80 characters
On 14/04/14 08:40, Jungseok Lee wrote: > This patch deals with checkpatch complaint as fixing line length > exceeding 80 characters. > > WARNING: line over 80 characters > > Signed-off-by: Jungseok Lee > Reviewed-by: Sungjinn Chung > --- > arch/arm/kvm/mmu.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c > index 80bb1e6..e0d4f24 100644 > --- a/arch/arm/kvm/mmu.c > +++ b/arch/arm/kvm/mmu.c > @@ -563,8 +563,8 @@ void kvm_free_stage2_pgd(struct kvm *kvm) > kvm->arch.pgd = NULL; > } > > -static pmd_t *stage2_get_pmd(struct kvm *kvm, struct kvm_mmu_memory_cache > *cache, > - phys_addr_t addr) > +static pmd_t *stage2_get_pmd(struct kvm *kvm, struct kvm_mmu_memory_cache > + *cache, phys_addr_t addr) Please don't. This makes the code unreadable (and no, I don't care about checkpatch ;-). M. -- Jazz is not dead. It just smells funny... -- 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 8/8] arm64: KVM: Implement 4 levels of translation tables for HYP and stage2
On 14/04/14 08:41, Jungseok Lee wrote:
> This patch adds 4 levels of translation tables implementation for both
> HYP and stage2. A combination of 4KB + 4 levels host and 4KB + 4 levels
> guest can run on ARMv8 architecture as introducing this feature.
>
> Signed-off-by: Jungseok Lee
> Reviewed-by: Sungjinn Chung
> ---
> arch/arm/kvm/mmu.c | 96
> +-
> arch/arm64/include/asm/kvm_arm.h | 20
> arch/arm64/include/asm/kvm_mmu.h |1 +
> 3 files changed, 106 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index e0d4f24..6cf89ad 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -388,13 +388,46 @@ static int create_hyp_pmd_mappings(pud_t *pud, unsigned
> long start,
> return 0;
> }
>
> +static int create_hyp_pud_mappings(pgd_t *pgd, unsigned long start,
> +unsigned long end, unsigned long pfn,
> +pgprot_t prot)
> +{
> + pud_t *pud;
> + pmd_t *pmd;
> + unsigned long addr, next;
> +
> + addr = start;
> + do {
> + pud = pud_offset(pgd, addr);
> +
> + if (pud_none_or_clear_bad(pud)) {
> + pmd = pmd_alloc_one(NULL, addr);
> + if (!pmd) {
> + kvm_err("Cannot allocate Hyp pmd\n");
> + return -ENOMEM;
> + }
> + pud_populate(NULL, pud, pmd);
> + get_page(virt_to_page(pud));
> + kvm_flush_dcache_to_poc(pud, sizeof(*pud));
> + }
> +
> + next = pud_addr_end(addr, end);
> +
> + create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
> + pfn += (next - addr) >> PAGE_SHIFT;
> + } while (addr = next, addr != end);
> +
> + return 0;
> +}
> +
> static int __create_hyp_mappings(pgd_t *pgdp,
>unsigned long start, unsigned long end,
>unsigned long pfn, pgprot_t prot)
> {
> pgd_t *pgd;
> +#ifdef CONFIG_ARM64_4_LEVELS
> pud_t *pud;
> - pmd_t *pmd;
> +#endif
> unsigned long addr, next;
> int err = 0;
>
> @@ -403,22 +436,25 @@ static int __create_hyp_mappings(pgd_t *pgdp,
> end = PAGE_ALIGN(end);
> do {
> pgd = pgdp + pgd_index(addr);
> - pud = pud_offset(pgd, addr);
>
> - if (pud_none_or_clear_bad(pud)) {
> - pmd = pmd_alloc_one(NULL, addr);
> - if (!pmd) {
> - kvm_err("Cannot allocate Hyp pmd\n");
> +#ifdef CONFIG_ARM64_4_LEVELS
> + if (pgd_none(*pgd)) {
> + pud = pud_alloc_one(NULL, addr);
> + if (!pud) {
> + kvm_err("Cannot allocate Hyp pud\n");
> err = -ENOMEM;
> goto out;
> }
> - pud_populate(NULL, pud, pmd);
> - get_page(virt_to_page(pud));
> - kvm_flush_dcache_to_poc(pud, sizeof(*pud));
> + pgd_populate(NULL, pgd, pud);
> + get_page(virt_to_page(pgd));
> + kvm_flush_dcache_to_poc(pgd, sizeof(*pgd));
> }
> +#endif
Why do you need all these #ifdefs? The page table code should be able to
cope with all the variations of presence/absence of pud/pmd (see how
there is no code difference between 4kB (3 levels) and 64kB (2 levels)).
> next = pgd_addr_end(addr, end);
> - err = create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
> +
> + err = create_hyp_pud_mappings(pgd, addr, next, pfn, prot);
> +
> if (err)
> goto out;
> pfn += (next - addr) >> PAGE_SHIFT;
> @@ -563,6 +599,26 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
> kvm->arch.pgd = NULL;
> }
>
> +#ifdef CONFIG_ARM64_4_LEVELS
> +static pud_t *stage2_get_pud(struct kvm *kvm, struct kvm_mmu_memory_cache
> + *cache, phys_addr_t addr)
> +{
> + pgd_t *pgd;
> + pud_t *pud;
> +
> + pgd = kvm->arch.pgd + pgd_index(addr);
> + if (pgd_none(*pgd)) {
> + if (!cache)
> + return NULL;
> + pud = mmu_memory_cache_alloc(cache);
> + pgd_populate(NULL, pgd, pud);
> + get_page(virt_to_page(pgd));
> + }
> +
> + return pud_offset(pgd, addr);
> +}
> +#endif
Same here.
> static pmd_t *stage2_get_pmd(struct kvm *kvm, struct kvm_mmu_memory_cache
>*cache, phys_addr_t addr)
> {
> @@ -617,6 +673,24 @@ static int stage2_set_pte(struct kvm *kvm, struct
> kvm_mmu_memory_cache *cache,
> pmd_t *pmd;
> pte_t *pte, old_pte;
>
> +#ifdef CONFIG_ARM64_4_LEVELS
> + pud_t *pud;
> +
> +
Re: [PATCH 1/4] drm: exynos: hdmi: simplify extracting hpd-gpio from DT
On 04/14/2014 05:00 PM, Tomasz Stanislawski wrote:
> This patch eliminates redundant checks while retrieving HPD gpio from DT
> during
> HDMI's probe().
>
> Signed-off-by: Tomasz Stanislawski
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 13 -
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 9a6d652..d2d6e2e 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -2016,23 +2016,18 @@ static struct s5p_hdmi_platform_data
> *drm_hdmi_dt_parse_pdata
> {
> struct device_node *np = dev->of_node;
> struct s5p_hdmi_platform_data *pd;
> - u32 value;
>
> pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
> if (!pd)
> - goto err_data;
> + return NULL;
>
> - if (!of_find_property(np, "hpd-gpio", &value)) {
> + pd->hpd_gpio = of_get_named_gpio(np, "hpd-gpio", 0);
> + if (gpio_is_valid(pd->hpd_gpio)) {
Sorry. Should be !gpio_is_valid().
> DRM_ERROR("no hpd gpio property found\n");
> - goto err_data;
> + return NULL;
> }
>
> - pd->hpd_gpio = of_get_named_gpio(np, "hpd-gpio", 0);
> -
> return pd;
> -
> -err_data:
> - return NULL;
> }
>
> static struct of_device_id hdmi_match_types[] = {
>
--
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 7/8] arm64: mm: Implement 4 levels of translation tables
On Mon, Apr 14, 2014 at 04:13:35PM +0100, Steve Capper wrote: > On Mon, Apr 14, 2014 at 04:41:07PM +0900, Jungseok Lee wrote: [ ... ] > > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S > > index 0fd5650..0b0b16a 100644 > > --- a/arch/arm64/kernel/head.S > > +++ b/arch/arm64/kernel/head.S > > A comment above this line needs to also be changed? > > > @@ -46,8 +46,8 @@ > > #error KERNEL_RAM_VADDR must start at 0xXXX8 > > #endif > > > > -#define SWAPPER_DIR_SIZE (3 * PAGE_SIZE) > > -#define IDMAP_DIR_SIZE (2 * PAGE_SIZE) > > +#define SWAPPER_DIR_SIZE (4 * PAGE_SIZE) > > +#define IDMAP_DIR_SIZE (3 * PAGE_SIZE) > > Again, this affects <4 levels of paging. > > > > > .globl swapper_pg_dir > > .equswapper_pg_dir, KERNEL_RAM_VADDR - SWAPPER_DIR_SIZE > > @@ -384,6 +384,20 @@ ENDPROC(__calc_phys_offset) > > .endm > > > > /* > > + * Macro to populate the PUD for the corresponding block entry in the next > > + * level (tbl) for the given virtual address. > > + * > > + * Preserves: pud, tbl, virt > > + * Corrupts: tmp1, tmp2 > > + */ > > + .macro create_pud_entry, pud, tbl, virt, tmp1, tmp2 > > + lsr \tmp1, \virt, #PUD_SHIFT > > + and \tmp1, \tmp1, #PTRS_PER_PUD - 1 // PUD index > > + orr \tmp2, \tbl, #3 // PUD entry table type > > + str \tmp2, [\pud, \tmp1, lsl #3] > > + .endm > > + > > +/* > > * Macro to populate block entries in the page table for the start..end > > * virtual range (inclusive). > > * > > @@ -445,10 +459,18 @@ __create_page_tables: > > ldr x3, =KERNEL_START > > add x3, x3, x28 // __pa(KERNEL_START) > > create_pgd_entry x25, x0, x3, x5, x6 > > +#ifdef CONFIG_ARM64_4_LEVELS > > + add x1, x0, #PAGE_SIZE > > + create_pud_entry x0, x1, x3, x5, x6 > > +#endif > > ldr x6, =KERNEL_END > > mov x5, x3 // __pa(KERNEL_START) > > add x6, x6, x28 // __pa(KERNEL_END) > > +#ifndef CONFIG_ARM64_4_LEVELS > > create_block_map x0, x7, x3, x5, x6 > > +#else > > + create_block_map x1, x7, x3, x5, x6 > > +#endif > > > > /* > > * Map the kernel image (starting with PHYS_OFFSET). > > @@ -456,9 +478,17 @@ __create_page_tables: > > add x0, x26, #PAGE_SIZE // section table address > > mov x5, #PAGE_OFFSET > > create_pgd_entry x26, x0, x5, x3, x6 > > +#ifdef CONFIG_ARM64_4_LEVELS > > + add x1, x0, #PAGE_SIZE > > + create_pud_entry x0, x1, x3, x5, x6 > > +#endif > > ldr x6, =KERNEL_END > > mov x3, x24 // phys offset > > +#ifndef CONFIG_ARM64_4_LEVELS > > create_block_map x0, x7, x3, x5, x6 > > +#else > > + create_block_map x1, x7, x3, x5, x6 > > +#endif > > > > /* > > * Map the FDT blob (maximum 2MB; must be within 512MB of > > @@ -474,14 +504,25 @@ __create_page_tables: > > add x5, x5, x6 // __va(FDT blob) > > add x6, x5, #1 << 21// 2MB for the FDT blob > > sub x6, x6, #1 // inclusive range > > +#ifndef CONFIG_ARM64_4_LEVELS > > create_block_map x0, x7, x3, x5, x6 > > +#else > > + create_block_map x1, x7, x3, x5, x6 > > +#endif > > 1: > > /* > > * Create the pgd entry for the fixed mappings. > > */ > > ldr x5, =FIXADDR_TOP// Fixed mapping virtual address > > +#ifndef CONFIG_ARM64_4_LEVELS > > add x0, x26, #2 * PAGE_SIZE // section table address > > create_pgd_entry x26, x0, x5, x6, x7 > > +#else > > + add x0, x26, #PAGE_SIZE > > + create_pgd_entry x26, x0, x5, x6, x7 > > + add x1, x0, #2 * PAGE_SIZE > > + create_pud_entry x0, x1, x5, x6, x7 > > +#endif > > So we essentially need an extra page for PUD mappings for both the > idmap and swapper mappings. Could the logic of create_pgd_entry be > adapted to call create_pud_entry for 4levels? That way a lot of #ifdefs > can be eliminated. > I forgot to mention, create_pgd_entry could also return the address that is then used as the first argument of create_block_map, that would further simplify the 4 level logic. -- 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 7/8] arm64: mm: Implement 4 levels of translation tables
On Mon, Apr 14, 2014 at 04:41:07PM +0900, Jungseok Lee wrote:
> This patch implements 4 levels of translation tables since 3 levels
> of page tables with 4KB pages cannot support 40-bit physical address
> space described in [1] due to the following issue.
>
> It is a restriction that kernel logical memory map with 4KB + 3 levels
> (0xffc0-0x) cannot cover RAM region from
> 544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create
> mapping for this region in map_mem function since __phys_to_virt for
> this region reaches to address overflow.
>
> If SoC design follows the document, [1], over 32GB RAM would be placed
> from 544GB. Even 64GB system is supposed to use the region from 544GB
> to 576GB for only 32GB RAM. Naturally, it would reach to enable 4 levels
> of page tables to avoid hacking __virt_to_phys and __phys_to_virt.
>
> However, it is recommended 4 levels of page table should be only enabled
> if memory map is too sparse or there is about 512GB RAM.
>
> References
> --
> [1]: Principle of ARM Memory Maps, White Paper, Issue C
>
Hi Jungseok,
I've given this a quick run on the Fast Model with huge pages, and it passed
the libhugetlbfs test suite.
Some comments/suggestions below...
> Signed-off-by: Jungseok Lee
> Reviewed-by: Sungjinn Chung
> ---
> arch/arm64/Kconfig |7 +
> arch/arm64/include/asm/page.h |4 ++-
> arch/arm64/include/asm/pgalloc.h | 20 ++
> arch/arm64/include/asm/pgtable-hwdef.h |8 --
> arch/arm64/include/asm/pgtable.h | 44 +--
> arch/arm64/include/asm/tlb.h |8 ++
> arch/arm64/kernel/head.S | 45
> ++--
> arch/arm64/kernel/traps.c |5
> arch/arm64/mm/fault.c |1 +
> arch/arm64/mm/mmu.c| 14 +-
> 10 files changed, 148 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 431acbc..7f5270b 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -184,12 +184,19 @@ config ARM64_3_LEVELS
> help
> This feature enables 3 levels of translation tables.
>
> +config ARM64_4_LEVELS
> + bool "4 level"
> + depends on ARM64_4K_PAGES
> + help
> + This feature enables 4 levels of translation tables.
> +
> endchoice
>
> config ARM64_VA_BITS
> int "Virtual address space size"
> range 39 39 if ARM64_4K_PAGES && ARM64_3_LEVELS
> range 42 42 if ARM64_64K_PAGES && ARM64_2_LEVELS
> + range 48 48 if ARM64_4K_PAGES && ARM64_4_LEVELS
> help
> This feature is determined by a combination of page size and
> level of translation tables.
> diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> index 268e53d..83b5289 100644
> --- a/arch/arm64/include/asm/page.h
> +++ b/arch/arm64/include/asm/page.h
> @@ -35,8 +35,10 @@
>
> #ifdef CONFIG_ARM64_2_LEVELS
> #include
> -#else
> +#elif defined(CONFIG_ARM64_3_LEVELS)
> #include
> +#else
> +#include
> #endif
>
> extern void __cpu_clear_user_page(void *p, unsigned long user);
> diff --git a/arch/arm64/include/asm/pgalloc.h
> b/arch/arm64/include/asm/pgalloc.h
> index 4829837..8d745fa 100644
> --- a/arch/arm64/include/asm/pgalloc.h
> +++ b/arch/arm64/include/asm/pgalloc.h
> @@ -26,6 +26,26 @@
>
> #define check_pgt_cache()do { } while (0)
>
> +#ifdef CONFIG_ARM64_4_LEVELS
> +
> +static inline pud_t *pud_alloc_one(struct mm_struct *mm, unsigned long addr)
> +{
> + return (pud_t *)get_zeroed_page(GFP_KERNEL | __GFP_REPEAT);
> +}
> +
> +static inline void pud_free(struct mm_struct *mm, pud_t *pud)
> +{
> + BUG_ON((unsigned long)pud & (PAGE_SIZE-1));
> + free_page((unsigned long)pud);
> +}
> +
> +static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, pud_t *pud)
> +{
> + set_pgd(pgd, __pgd(__pa(pud) | PUD_TYPE_TABLE));
Perhaps instead use PGD_TYPE_TABLE?
> +}
> +
> +#endif /* CONFIG_ARM64_4_LEVELS */
> +
> #ifndef CONFIG_ARM64_2_LEVELS
>
> static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
> diff --git a/arch/arm64/include/asm/pgtable-hwdef.h
> b/arch/arm64/include/asm/pgtable-hwdef.h
> index 9cd86c6..03ad81b 100644
> --- a/arch/arm64/include/asm/pgtable-hwdef.h
> +++ b/arch/arm64/include/asm/pgtable-hwdef.h
> @@ -18,8 +18,10 @@
>
> #ifdef CONFIG_ARM64_2_LEVELS
> #include
> -#else
> +#elif defined(CONFIG_ARM64_3_LEVELS)
> #include
> +#else
> +#include
> #endif
>
> /*
> @@ -27,7 +29,9 @@
> *
> * Level 1 descriptor (PUD).
> */
> -
> +#ifdef CONFIG_ARM64_4_LEVELS
> +#define PUD_TYPE_TABLE (_AT(pudval_t, 3) << 0)
I would be tempted to instead define:
+#define PGD_TYPE_TABLE(_AT(pgdval_t, 3) << 0)
And have that under "Level 0 descriptor (PGD)". There shouldn't be any
need for an #ifdef block.
> +#e
[PATCH 1/4] drm: exynos: hdmi: simplify extracting hpd-gpio from DT
This patch eliminates redundant checks while retrieving HPD gpio from DT during
HDMI's probe().
Signed-off-by: Tomasz Stanislawski
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 9a6d652..d2d6e2e 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2016,23 +2016,18 @@ static struct s5p_hdmi_platform_data
*drm_hdmi_dt_parse_pdata
{
struct device_node *np = dev->of_node;
struct s5p_hdmi_platform_data *pd;
- u32 value;
pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
if (!pd)
- goto err_data;
+ return NULL;
- if (!of_find_property(np, "hpd-gpio", &value)) {
+ pd->hpd_gpio = of_get_named_gpio(np, "hpd-gpio", 0);
+ if (gpio_is_valid(pd->hpd_gpio)) {
DRM_ERROR("no hpd gpio property found\n");
- goto err_data;
+ return NULL;
}
- pd->hpd_gpio = of_get_named_gpio(np, "hpd-gpio", 0);
-
return pd;
-
-err_data:
- return NULL;
}
static struct of_device_id hdmi_match_types[] = {
--
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 0/4] drm: exynos: update/fixes to HDMI driver
Hi everyone, This patchset adds 4 fixes/updates to EXYNOS DRM driver for HDMI subsystem. All comments are welcome. Regards, Tomasz Stanislawski Tomasz Stanislawski (4): drm: exynos: hdmi: simplify extracting hpd-gpio from DT drm: exynos: mixer: fix using usleep() in atomic context drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210 SoC drm: exynos: hdmi: add support for pixel clock limitation .../devicetree/bindings/video/exynos_hdmi.txt |4 +++ drivers/gpu/drm/exynos/exynos_hdmi.c | 26 ++-- drivers/gpu/drm/exynos/exynos_mixer.c |5 +++- include/media/s5p_hdmi.h |1 + 4 files changed, 27 insertions(+), 9 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 4/4] drm: exynos: hdmi: add support for pixel clock limitation
Adds support for limitation of maximal pixel clock of HDMI
signal. This feature is needed on boards that contains
lines or bridges with frequency limitations.
Signed-off-by: Tomasz Stanislawski
---
.../devicetree/bindings/video/exynos_hdmi.txt |4
drivers/gpu/drm/exynos/exynos_hdmi.c | 12
include/media/s5p_hdmi.h |1 +
3 files changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index f9187a2..8718f8d 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -28,6 +28,10 @@ Required properties:
- ddc: phandle to the hdmi ddc node
- phy: phandle to the hdmi phy node
+Optional properties:
+- max-pixel-clock: used to limit the maximal pixel clock if a board has lines,
+ connectors or bridges not capable of carring higher frequencies
+
Example:
hdmi {
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 6fa63ea..ca313b3 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -195,6 +195,7 @@ struct hdmi_context {
struct hdmi_resources res;
int hpd_gpio;
+ u32 max_pixel_clock;
enum hdmi_type type;
};
@@ -883,6 +884,9 @@ static int hdmi_mode_valid(struct drm_connector *connector,
if (ret)
return MODE_BAD;
+ if (mode->clock * 1000 > hdata->max_pixel_clock)
+ return MODE_BAD;
+
ret = hdmi_find_phy_conf(hdata, mode->clock * 1000);
if (ret < 0)
return MODE_BAD;
@@ -2027,6 +2031,8 @@ static struct s5p_hdmi_platform_data
*drm_hdmi_dt_parse_pdata
return NULL;
}
+ of_property_read_u32(np, "max-pixel-clock", &pd->max_pixel_clock);
+
return pd;
}
@@ -2063,6 +2069,11 @@ static int hdmi_probe(struct platform_device *pdev)
if (!pdata)
return -EINVAL;
+ if (!pdata->max_pixel_clock) {
+ DRM_INFO("max-pixel-clock is zero, using INF\n");
+ pdata->max_pixel_clock = ULONG_MAX;
+ }
+
hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
if (!hdata)
return -ENOMEM;
@@ -2079,6 +2090,7 @@ static int hdmi_probe(struct platform_device *pdev)
hdata->type = drv_data->type;
hdata->hpd_gpio = pdata->hpd_gpio;
+ hdata->max_pixel_clock = pdata->max_pixel_clock;
hdata->dev = dev;
ret = hdmi_resources_init(hdata);
diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
index 181642b..7272d65 100644
--- a/include/media/s5p_hdmi.h
+++ b/include/media/s5p_hdmi.h
@@ -31,6 +31,7 @@ struct s5p_hdmi_platform_data {
int mhl_bus;
struct i2c_board_info *mhl_info;
int hpd_gpio;
+ u32 max_pixel_clock;
};
#endif /* S5P_HDMI_H */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] drm: exynos: mixer: fix using usleep() in atomic context
This patch fixes calling usleep_range() after taking reg_slock using spin_lock_irqsave(). The mdelay() is used instead. Waiting in atomic context is not the best idea in general. Hopefully, waiting occurs only when Video Processor fails to reset correctly. Signed-off-by: Tomasz Stanislawski --- drivers/gpu/drm/exynos/exynos_mixer.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index ce28881..e3306c8 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -615,7 +615,7 @@ static void vp_win_reset(struct mixer_context *ctx) /* waiting until VP_SRESET_PROCESSING is 0 */ if (~vp_reg_read(res, VP_SRESET) & VP_SRESET_PROCESSING) break; - usleep_range(1, 12000); + mdelay(10); } WARN(tries == 0, "failed to reset Video Processor\n"); } -- 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] drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210 SoC
This patch add proper compatibles for Mixer and HDMI chip
available on exynos4210 SoCs.
Signed-off-by: Tomasz Stanislawski
---
drivers/gpu/drm/exynos/exynos_hdmi.c |3 +++
drivers/gpu/drm/exynos/exynos_mixer.c |3 +++
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index d2d6e2e..6fa63ea 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2032,6 +2032,9 @@ static struct s5p_hdmi_platform_data
*drm_hdmi_dt_parse_pdata
static struct of_device_id hdmi_match_types[] = {
{
+ .compatible = "samsung,exynos4210-hdmi",
+ .data = (void *)HDMI_TYPE13,
+ }, {
.compatible = "samsung,exynos5-hdmi",
.data = &exynos5_hdmi_driver_data,
}, {
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index e3306c8..fd8a9a0 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1187,6 +1187,9 @@ static struct platform_device_id mixer_driver_types[] = {
static struct of_device_id mixer_match_types[] = {
{
+ .compatible = "samsung,exynos4210-mixer",
+ .data = &exynos4210_mxr_drv_data,
+ }, {
.compatible = "samsung,exynos5-mixer",
.data = &exynos5250_mxr_drv_data,
}, {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
On 08/04/14 16:36, Vivek Gautam wrote:
> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> index 28f9edb..6d99ba9 100644
> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> @@ -74,3 +74,45 @@ phy-consumer@1234 {
>
> Refer to DT bindings documentation of particular PHY consumer devices for
> more
> information about required PHYs and the way of specification.
> +
> +Samsung Exynos5 SoC series USB DRD PHY controller
> +--
> +
> +Required properties:
> +- compatible : Should be set to one of the following supported values:
> + - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
> + - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
> +- reg : Register offset and length of USB DRD PHY register set;
> +- clocks: Clock IDs array as required by the controller
> +- clock-names: names of clocks correseponding to IDs in the clock property;
> +Required clocks:
> + - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
> +used for register access.
> + - ref: PHY's reference clock (usually crystal clock), associated by
> +phy name, used to determine bit values for clock settings
> +register.
> + Additional clock required for Exynos5420:
> + - usb30_sclk_100m: Additional special clock used for PHY operation
> +depicted as 'sclk_usbphy30' in CMU of Exynos5420.
> +- samsung,syscon-phandle: phandle for syscon interface, which is used to
> + control pmu registers for power isolation.
Why to append "-phandle" to the property's name ? If this is for PMU
perhaps make it more explicit and name it: samsung,pmu-syscon or
samsung,pmureg ?
> +- samsung,pmu-offset: phy power control register offset to
> pmu-system-controller
> + base.
> +- #phy-cells : from the generic PHY bindings, must be 1;
> +
> +For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy"
> +compatible PHYs, the second cell in the PHY specifier identifies the
> +PHY id, which is interpreted as follows:
> + 0 - UTMI+ type phy,
> + 1 - PIPE3 type phy,
--
Thanks,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
On 14/04/14 15:49, Vivek Gautam wrote: > True, we don't have a scope of instantiating this driver using old > platform device and > old legacy board files. > So we don't need this check then, right ? I think it can be dropped. At least IMHO there is no point to increase size of the module with an error log that has no chance to be ever called in practice. -- Thanks, Sylwester -- 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 RFC 0/2] drm/exynos: refactoring drm device init/deinit
On 14.04.2014 15:55, Inki Dae wrote: Hi Tomasz, Always thanks for your opinions. -Original Message- From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc- ow...@vger.kernel.org] On Behalf Of Tomasz Figa Sent: Monday, April 14, 2014 8:32 PM To: Inki Dae; 'Andrzej Hajda' Cc: 'Kyungmin Park'; 'moderated list:ARM/S5P EXYNOS AR...'; 'Russell King'; dri-de...@lists.freedesktop.org; 'Marek Szyprowski' Subject: Re: [PATCH RFC 0/2] drm/exynos: refactoring drm device init/deinit Hi Inki, On 14.04.2014 13:04, Inki Dae wrote: -Original Message- From: Andrzej Hajda [mailto:a.ha...@samsung.com] Sent: Monday, April 14, 2014 5:55 PM To: Inki Dae Cc: dri-de...@lists.freedesktop.org; moderated list:ARM/S5P EXYNOS AR...; Kyungmin Park; Marek Szyprowski Subject: Re: [PATCH RFC 0/2] drm/exynos: refactoring drm device init/deinit On 04/12/2014 04:18 PM, Inki Dae wrote: Hi Andrzej, Thanks for your contributions. 2014-04-11 23:11 GMT+09:00 Andrzej Hajda : Hi Inki, This patchset refactors drm device initialization. Details are described in respective patches. It is an alternative to DT supernode concept. The first patch uses linker sections to get rid of ifdef macros, it is not That's a good idea. :) We could avoid ugly #ifdef ~ #endif with this way. essential for 2nd patch but it makes code more readable. Similar approach is used by irqchip, clks and clk_sources. But 2nd patch doesn't seem reasnoable to me. Your approach is same as existing one conceptually. I think we need to handle drm driver in a different way from irqchip, clks and clk_sources. DRM driver means one integrated graphics card but in most embedded systems, graphics and display relevant devices have separated hardware resources. So we would need abstractional integrated hardware, display-subsystem, super device. That is why I are trying to use super device approach, and conceptually it would be right solution. It wouldn't be not good to combine those separated hardware somehow using specific codes. Conceptually both approaches are the same: we have number of devices which should be ready before we can start super-device and if any device is to be removed super-device should be removed before. The difference is in 'details': - super-node approach have list of components provided explicitly in DT special node, - in this approach list of components is constructed from devices present in the system. Creating special DT node with information which is available anyway seems to be redundant and against DT rules. CCing Russell King, What is the special DT node? You mean device node from ports property? It is supposed to use super device and its properties in mainline so I don't see what it is against DT rules. If they are really against DT rules, why component framework is in mainline? Component framework in mainline doesn't have anything in common with DT. All it does is providing tools for handling cases where a subsystem can be initialized only after all components are available. It doesn't define any means of getting the list of components, it's a task for the user of this framework to provide it. As you said above, conceptually both approaches may be the same but your approach has no any abstract hardware meaning one integrated hardware. And if conceptually both approaches are the same, it would be good to use existing infrastructure, component framework so there is no any reason to add and use specific codes. What do you mean by "abstract hardware"? Physically, in the SoC, there is no single integrated hardware block, but multiple IPs and they need to be described this way in DT. There is nothing that prevents using them separately if a user doesn't want to use Exynos DRM. Exynos DRM is a I don't think that super device approach prevents using existing device nodes separately. If a user doesn't want to use Exynos DRM, he cannot declare the super node and each IP would work well in existing way. There would be nothing to change existing device nodes. I agree that it wouldn't interfere with other possible use cases, but it is still leaking Linux- and use case- specific data to DT, which should be both OS and use case- agnostic. Especially when the goal to be achieved doesn't even require doing so (see Andrzej's enumeration using driver model objects directly). Linux-specific thing and its details should not be leaked into DT, which is a _hardware_ description method. And component framework says, "Subsystems such as ALSA, DRM and others require a single card-level device structure to represent a subsystem. However, firmware tends to describe the individual devices and the connections between them. Therefore, we need a way to gather up the individual component devices together, and indicate when we have all the component devices." Note following things: - Nothing in the quote above says that an additional DT node must be added. The framework works on generic driver model
Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
Hi,
On Mon, Apr 14, 2014 at 7:14 PM, Tomasz Figa wrote:
> On 14.04.2014 15:05, Kishon Vijay Abraham I wrote:
>>
>>
>>
>> On Monday 14 April 2014 05:35 PM, Vivek Gautam wrote:
>>>
>>> Hi Kishon,
>>>
>>>
>>> On Mon, Apr 14, 2014 at 5:24 PM, Kishon Vijay Abraham I
>>> wrote:
Hi,
On Wednesday 09 April 2014 04:36 PM, Tomasz Figa wrote:
>
> Hi Vivek,
>
> Please see my comments inline.
>
> On 08.04.2014 16:36, Vivek Gautam wrote:
>>
>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
>> The new driver uses the generic PHY framework and will interact
>> with DWC3 controller present on Exynos5 series of SoCs.
>> Thereby, removing old phy-samsung-usb3 driver and related code
>> used untill now which was based on usb/phy framework.
>>
>> Signed-off-by: Vivek Gautam
>> ---
>>.../devicetree/bindings/phy/samsung-phy.txt| 42 ++
>>drivers/phy/Kconfig| 11 +
>>drivers/phy/Makefile |1 +
>>drivers/phy/phy-exynos5-usbdrd.c | 668
>>
>>4 files changed, 722 insertions(+)
>>create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
>
>
> [snip]
>
>> +Additional clock required for Exynos5420:
>> +- usb30_sclk_100m: Additional special clock used for PHY
>> operation
>> + depicted as 'sclk_usbphy30' in CMU of Exynos5420.
>
>
> Are you sure this isn't simply a gate for the ref clock, as it can be
> found on
> another SoC that is not upstream yet? I don't have documentation for
> Exynos
> 5420 so I can't tell, but I'd like to ask you to recheck this.
>
>> +- samsung,syscon-phandle: phandle for syscon interface, which is used
>> to
>> + control pmu registers for power isolation.
>> +- samsung,pmu-offset: phy power control register offset to
>> pmu-system-controller
>> + base.
>> +- #phy-cells : from the generic PHY bindings, must be 1;
>> +
>> +For "samsung,exynos5250-usbdrd-phy" and
>> "samsung,exynos5420-usbdrd-phy"
>> +compatible PHYs, the second cell in the PHY specifier identifies the
>> +PHY id, which is interpreted as follows:
>> + 0 - UTMI+ type phy,
>> + 1 - PIPE3 type phy,
>> +
>> +Example:
>> +usb3_phy: usbphy@1210 {
>> +compatible = "samsung,exynos5250-usbdrd-phy";
>> +reg = <0x1210 0x100>;
>> +clocks = <&clock 286>, <&clock 1>;
>> +clock-names = "phy", "usb3phy_refclk";
>
>
> Binding description above doesn't mention "usb3phy_refclk" entry.
>
>> +samsung,syscon-phandle = <&pmu_syscon>;
>> +samsung,pmu-offset = <0x704>;
>> +#phy-cells = <1>;
>> +};
>
>
> [snip]
>
>> diff --git a/drivers/phy/phy-exynos5-usbdrd.c
>> b/drivers/phy/phy-exynos5-usbdrd.c
>> new file mode 100644
>> index 000..ff54a7c
>> --- /dev/null
>> +++ b/drivers/phy/phy-exynos5-usbdrd.c
>
>
> [snip]
>
>> +static int exynos5_usbdrd_phy_probe(struct platform_device *pdev)
>> +{
>> +struct device *dev = &pdev->dev;
>> +struct device_node *node = dev->of_node;
>> +struct exynos5_usbdrd_phy *phy_drd;
>> +struct phy_provider *phy_provider;
>> +struct resource *res;
>> +const struct of_device_id *match;
>> +const struct exynos5_usbdrd_phy_drvdata *drv_data;
>> +struct regmap *reg_pmu;
>> +u32 pmu_offset;
>> +int i;
>> +
>> +/*
>> + * Exynos systems are completely DT enabled,
>> + * so lets not have any platform data support for this driver.
>> + */
>> +if (!node) {
>> +dev_err(dev, "no device node found\n");
>
>
> This error message is not very meaningful. I'd rather use something
> like "This
> driver can be only instantiated using Device Tree".
how about just adding depend_on OF in Kconfig?
>>>
>>>
>>> Already added a depend on 'OF'. Copying below the part of Kconfig in this
>>> patch.
>>
>>
>> Alright.. Do we need the check then? If config_OF is enabled devices will
>> be
>> created using device tree no?
>
>
> Not necessarily. Enabling support for OF doesn't mean that it is the only
> boot method that can be used. Legacy board files may be still available. I'm
> not sure why someone would try to instantiate this driver from them, though.
True, we don't have a scope of instantiating this driver using old
platform device and
old legacy board files.
So we don't need this check then, right ?
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@v
RE: [PATCH RFC 0/2] drm/exynos: refactoring drm device init/deinit
Hi Tomasz, Always thanks for your opinions. > -Original Message- > From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc- > ow...@vger.kernel.org] On Behalf Of Tomasz Figa > Sent: Monday, April 14, 2014 8:32 PM > To: Inki Dae; 'Andrzej Hajda' > Cc: 'Kyungmin Park'; 'moderated list:ARM/S5P EXYNOS AR...'; 'Russell King'; > dri-de...@lists.freedesktop.org; 'Marek Szyprowski' > Subject: Re: [PATCH RFC 0/2] drm/exynos: refactoring drm device > init/deinit > > Hi Inki, > > On 14.04.2014 13:04, Inki Dae wrote: > > > > > >> -Original Message- > >> From: Andrzej Hajda [mailto:a.ha...@samsung.com] > >> Sent: Monday, April 14, 2014 5:55 PM > >> To: Inki Dae > >> Cc: dri-de...@lists.freedesktop.org; moderated list:ARM/S5P EXYNOS > >> AR...; Kyungmin Park; Marek Szyprowski > >> Subject: Re: [PATCH RFC 0/2] drm/exynos: refactoring drm device > >> init/deinit > >> > >> On 04/12/2014 04:18 PM, Inki Dae wrote: > >>> Hi Andrzej, > >>> > >>> Thanks for your contributions. > >>> > >>> 2014-04-11 23:11 GMT+09:00 Andrzej Hajda : > Hi Inki, > > This patchset refactors drm device initialization. Details are > described in respective patches. It is an alternative to DT > supernode > >> concept. > > The first patch uses linker sections to get rid of ifdef macros, it > is not > >>> That's a good idea. :) We could avoid ugly #ifdef ~ #endif with this > > way. > >>> > essential for 2nd patch but it makes code more readable. Similar > approach is used by irqchip, clks and clk_sources. > >>> But 2nd patch doesn't seem reasnoable to me. Your approach is same > >>> as existing one conceptually. I think we need to handle drm driver > >>> in a different way from irqchip, clks and clk_sources. > >>> > >>> DRM driver means one integrated graphics card but in most embedded > >>> systems, graphics and display relevant devices have separated > >>> hardware resources. So we would need abstractional integrated > >>> hardware, display-subsystem, super device. That is why I are trying > >>> to use super device approach, and conceptually it would be right > >>> solution. It wouldn't be not good to combine those separated > >>> hardware somehow using specific codes. > >> > >> Conceptually both approaches are the same: we have number of devices > >> which should be ready before we can start super-device and if any > >> device is to be removed super-device should be removed before. > >> The difference is in 'details': > >> - super-node approach have list of components provided explicitly in > >> DT special node, > >> - in this approach list of components is constructed from devices > >> present in the system. > >> > >> Creating special DT node with information which is available anyway > >> seems to be redundant and against DT rules. > >> > > > > CCing Russell King, > > > > What is the special DT node? You mean device node from ports property? > > > > It is supposed to use super device and its properties in mainline so > > I don't see what it is against DT rules. If they are really against DT > > rules, why component framework is in mainline? > > Component framework in mainline doesn't have anything in common with DT. > All it does is providing tools for handling cases where a subsystem can be > initialized only after all components are available. It doesn't define any > means of getting the list of components, it's a task for the user of this > framework to provide it. > > > > > As you said above, conceptually both approaches may be the same but > > your approach has no any abstract hardware meaning one integrated > > hardware. And if conceptually both approaches are the same, it would > > be good to use existing infrastructure, component framework so there > > is no any reason to add and use specific codes. > > What do you mean by "abstract hardware"? Physically, in the SoC, there is > no single integrated hardware block, but multiple IPs and they need to be > described this way in DT. There is nothing that prevents using them > separately if a user doesn't want to use Exynos DRM. Exynos DRM is a I don't think that super device approach prevents using existing device nodes separately. If a user doesn't want to use Exynos DRM, he cannot declare the super node and each IP would work well in existing way. There would be nothing to change existing device nodes. > Linux-specific thing and its details should not be leaked into DT, which > is a _hardware_ description method. > > > > > And component framework says, > > "Subsystems such as ALSA, DRM and others require a single card-level > > device structure to represent a subsystem. However, firmware tends to > > describe the individual devices and the connections between them. > > Therefore, we need a way to gather up the individual component devices > > together, and indicate when we have all the component devices." > > Note following things: > > - Nothing in the quote above says that an additional DT node must
Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
On 14.04.2014 15:40, Vivek Gautam wrote:
On Mon, Apr 14, 2014 at 6:56 PM, Kishon Vijay Abraham I wrote:
On Monday 14 April 2014 06:50 PM, Vivek Gautam wrote:
On Mon, Apr 14, 2014 at 6:29 PM, Kishon Vijay Abraham I wrote:
On Monday 14 April 2014 06:12 PM, Vivek Gautam wrote:
Hi,
On Mon, Apr 14, 2014 at 5:57 PM, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 08 April 2014 08:06 PM, Vivek Gautam wrote:
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam
---
.../devicetree/bindings/phy/samsung-phy.txt| 42 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usbdrd.c | 668
4 files changed, 722 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 28f9edb..6d99ba9 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -74,3 +74,45 @@ phy-consumer@1234 {
Refer to DT bindings documentation of particular PHY consumer devices for more
information about required PHYs and the way of specification.
+
+Samsung Exynos5 SoC series USB DRD PHY controller
+--
+
+Required properties:
+- compatible : Should be set to one of the following supported values:
+ - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
+ - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
+- reg : Register offset and length of USB DRD PHY register set;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock property;
+Required clocks:
+ - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
+used for register access.
+ - ref: PHY's reference clock (usually crystal clock), associated by
+phy name, used to determine bit values for clock settings
+register.
+ Additional clock required for Exynos5420:
+ - usb30_sclk_100m: Additional special clock used for PHY operation
+depicted as 'sclk_usbphy30' in CMU of Exynos5420.
+- samsung,syscon-phandle: phandle for syscon interface, which is used to
+ control pmu registers for power isolation.
+- samsung,pmu-offset: phy power control register offset to
pmu-system-controller
+ base.
+- #phy-cells : from the generic PHY bindings, must be 1;
+
+For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy"
+compatible PHYs, the second cell in the PHY specifier identifies the
+PHY id, which is interpreted as follows:
+ 0 - UTMI+ type phy,
+ 1 - PIPE3 type phy,
+
+Example:
+ usb3_phy: usbphy@1210 {
+ compatible = "samsung,exynos5250-usbdrd-phy";
+ reg = <0x1210 0x100>;
+ clocks = <&clock 286>, <&clock 1>;
+ clock-names = "phy", "usb3phy_refclk";
+ samsung,syscon-phandle = <&pmu_syscon>;
+ samsung,pmu-offset = <0x704>;
+ #phy-cells = <1>;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 8d3c49c..d955a05 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -166,4 +166,15 @@ config PHY_XGENE
help
This option enables support for APM X-Gene SoC multi-purpose PHY.
+config PHY_EXYNOS5_USBDRD
+ tristate "Exynos5 SoC series USB DRD PHY driver"
+ depends on ARCH_EXYNOS5 && OF
+ depends on HAS_IOMEM
+ select GENERIC_PHY
+ select MFD_SYSCON
Lets try to avoid select in Kconfig. We've got enough problems with that.
I hope you meant with "select MFD_SYSCON".
We are referencing the syscon for accessing pmu reg, for which we need
this config to be selected.
Other Exynos phy drivers also need this config and for that they have
selected this.
Do you want me to do it any other way ?
depends on is one option.
Ok, i can see there are places where depends_on MFD_SYSCON is used.
"drivers/gpu/drm/exynos/Kconfig:60"
so, do you want me to fix at other places too ?
But i also have a question here.
MFD_SYSCON is a subsystem that's facilitating us in getting our work
done here by giving an access to pmu_system_controller.
So unless MFD_SYSCON is exposed, the phy driver will not be exposed to us.
So is that valid enough really ?
maybe in the Kconfig for MFD_SYSCON, we can select it if PHY_EXYNOS5_USBDRD is
enabled?
config MFD_SYSCON
default y if PHY_EXYNOS5_USBDRD
Yes, that seems to be one option. But we will end up adding this
Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
On Mon, Apr 14, 2014 at 7:10 PM, Vivek Gautam wrote:
Just correcting mail-ids for Mark and Dong with the latest ones
(earlier ones got bounced back)
> On Mon, Apr 14, 2014 at 6:56 PM, Kishon Vijay Abraham I wrote:
>>
>>
>> On Monday 14 April 2014 06:50 PM, Vivek Gautam wrote:
>>> On Mon, Apr 14, 2014 at 6:29 PM, Kishon Vijay Abraham I
>>> wrote:
On Monday 14 April 2014 06:12 PM, Vivek Gautam wrote:
> Hi,
>
>
> On Mon, Apr 14, 2014 at 5:57 PM, Kishon Vijay Abraham I
> wrote:
>> Hi,
>>
>> On Tuesday 08 April 2014 08:06 PM, Vivek Gautam wrote:
>>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
>>> The new driver uses the generic PHY framework and will interact
>>> with DWC3 controller present on Exynos5 series of SoCs.
>>> Thereby, removing old phy-samsung-usb3 driver and related code
>>> used untill now which was based on usb/phy framework.
>>>
>>> Signed-off-by: Vivek Gautam
>>> ---
>>> .../devicetree/bindings/phy/samsung-phy.txt| 42 ++
>>> drivers/phy/Kconfig| 11 +
>>> drivers/phy/Makefile |1 +
>>> drivers/phy/phy-exynos5-usbdrd.c | 668
>>>
>>> 4 files changed, 722 insertions(+)
>>> create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> index 28f9edb..6d99ba9 100644
>>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> @@ -74,3 +74,45 @@ phy-consumer@1234 {
>>>
>>> Refer to DT bindings documentation of particular PHY consumer devices
>>> for more
>>> information about required PHYs and the way of specification.
>>> +
>>> +Samsung Exynos5 SoC series USB DRD PHY controller
>>> +--
>>> +
>>> +Required properties:
>>> +- compatible : Should be set to one of the following supported values:
>>> + - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
>>> + - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
>>> +- reg : Register offset and length of USB DRD PHY register set;
>>> +- clocks: Clock IDs array as required by the controller
>>> +- clock-names: names of clocks correseponding to IDs in the clock
>>> property;
>>> +Required clocks:
>>> + - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP
>>> clock),
>>> +used for register access.
>>> + - ref: PHY's reference clock (usually crystal clock), associated
>>> by
>>> +phy name, used to determine bit values for clock settings
>>> +register.
>>> + Additional clock required for Exynos5420:
>>> + - usb30_sclk_100m: Additional special clock used for PHY operation
>>> +depicted as 'sclk_usbphy30' in CMU of
>>> Exynos5420.
>>> +- samsung,syscon-phandle: phandle for syscon interface, which is used
>>> to
>>> + control pmu registers for power isolation.
>>> +- samsung,pmu-offset: phy power control register offset to
>>> pmu-system-controller
>>> + base.
>>> +- #phy-cells : from the generic PHY bindings, must be 1;
>>> +
>>> +For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy"
>>> +compatible PHYs, the second cell in the PHY specifier identifies the
>>> +PHY id, which is interpreted as follows:
>>> + 0 - UTMI+ type phy,
>>> + 1 - PIPE3 type phy,
>>> +
>>> +Example:
>>> + usb3_phy: usbphy@1210 {
>>> + compatible = "samsung,exynos5250-usbdrd-phy";
>>> + reg = <0x1210 0x100>;
>>> + clocks = <&clock 286>, <&clock 1>;
>>> + clock-names = "phy", "usb3phy_refclk";
>>> + samsung,syscon-phandle = <&pmu_syscon>;
>>> + samsung,pmu-offset = <0x704>;
>>> + #phy-cells = <1>;
>>> + };
>>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>>> index 8d3c49c..d955a05 100644
>>> --- a/drivers/phy/Kconfig
>>> +++ b/drivers/phy/Kconfig
>>> @@ -166,4 +166,15 @@ config PHY_XGENE
>>> help
>>> This option enables support for APM X-Gene SoC multi-purpose
>>> PHY.
>>>
>>> +config PHY_EXYNOS5_USBDRD
>>> + tristate "Exynos5 SoC series USB DRD PHY driver"
>>> + depends on ARCH_EXYNOS5 && OF
>>> + depends on HAS_IOMEM
>>> + select GENERIC_PHY
>>> + select MFD_SYSCON
>>
>> Lets try to avoid select in Kconfig. We've got enough problems with that.
>
> I hope you mea
Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
On 14.04.2014 15:05, Kishon Vijay Abraham I wrote:
On Monday 14 April 2014 05:35 PM, Vivek Gautam wrote:
Hi Kishon,
On Mon, Apr 14, 2014 at 5:24 PM, Kishon Vijay Abraham I wrote:
Hi,
On Wednesday 09 April 2014 04:36 PM, Tomasz Figa wrote:
Hi Vivek,
Please see my comments inline.
On 08.04.2014 16:36, Vivek Gautam wrote:
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam
---
.../devicetree/bindings/phy/samsung-phy.txt| 42 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usbdrd.c | 668
4 files changed, 722 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
[snip]
+Additional clock required for Exynos5420:
+- usb30_sclk_100m: Additional special clock used for PHY operation
+ depicted as 'sclk_usbphy30' in CMU of Exynos5420.
Are you sure this isn't simply a gate for the ref clock, as it can be found on
another SoC that is not upstream yet? I don't have documentation for Exynos
5420 so I can't tell, but I'd like to ask you to recheck this.
+- samsung,syscon-phandle: phandle for syscon interface, which is used to
+ control pmu registers for power isolation.
+- samsung,pmu-offset: phy power control register offset to
pmu-system-controller
+ base.
+- #phy-cells : from the generic PHY bindings, must be 1;
+
+For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy"
+compatible PHYs, the second cell in the PHY specifier identifies the
+PHY id, which is interpreted as follows:
+ 0 - UTMI+ type phy,
+ 1 - PIPE3 type phy,
+
+Example:
+usb3_phy: usbphy@1210 {
+compatible = "samsung,exynos5250-usbdrd-phy";
+reg = <0x1210 0x100>;
+clocks = <&clock 286>, <&clock 1>;
+clock-names = "phy", "usb3phy_refclk";
Binding description above doesn't mention "usb3phy_refclk" entry.
+samsung,syscon-phandle = <&pmu_syscon>;
+samsung,pmu-offset = <0x704>;
+#phy-cells = <1>;
+};
[snip]
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
new file mode 100644
index 000..ff54a7c
--- /dev/null
+++ b/drivers/phy/phy-exynos5-usbdrd.c
[snip]
+static int exynos5_usbdrd_phy_probe(struct platform_device *pdev)
+{
+struct device *dev = &pdev->dev;
+struct device_node *node = dev->of_node;
+struct exynos5_usbdrd_phy *phy_drd;
+struct phy_provider *phy_provider;
+struct resource *res;
+const struct of_device_id *match;
+const struct exynos5_usbdrd_phy_drvdata *drv_data;
+struct regmap *reg_pmu;
+u32 pmu_offset;
+int i;
+
+/*
+ * Exynos systems are completely DT enabled,
+ * so lets not have any platform data support for this driver.
+ */
+if (!node) {
+dev_err(dev, "no device node found\n");
This error message is not very meaningful. I'd rather use something like "This
driver can be only instantiated using Device Tree".
how about just adding depend_on OF in Kconfig?
Already added a depend on 'OF'. Copying below the part of Kconfig in this patch.
Alright.. Do we need the check then? If config_OF is enabled devices will be
created using device tree no?
Not necessarily. Enabling support for OF doesn't mean that it is the
only boot method that can be used. Legacy board files may be still
available. I'm not sure why someone would try to instantiate this driver
from them, though.
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 V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
On Mon, Apr 14, 2014 at 6:56 PM, Kishon Vijay Abraham I wrote:
>
>
> On Monday 14 April 2014 06:50 PM, Vivek Gautam wrote:
>> On Mon, Apr 14, 2014 at 6:29 PM, Kishon Vijay Abraham I
>> wrote:
>>>
>>>
>>> On Monday 14 April 2014 06:12 PM, Vivek Gautam wrote:
Hi,
On Mon, Apr 14, 2014 at 5:57 PM, Kishon Vijay Abraham I
wrote:
> Hi,
>
> On Tuesday 08 April 2014 08:06 PM, Vivek Gautam wrote:
>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
>> The new driver uses the generic PHY framework and will interact
>> with DWC3 controller present on Exynos5 series of SoCs.
>> Thereby, removing old phy-samsung-usb3 driver and related code
>> used untill now which was based on usb/phy framework.
>>
>> Signed-off-by: Vivek Gautam
>> ---
>> .../devicetree/bindings/phy/samsung-phy.txt| 42 ++
>> drivers/phy/Kconfig| 11 +
>> drivers/phy/Makefile |1 +
>> drivers/phy/phy-exynos5-usbdrd.c | 668
>>
>> 4 files changed, 722 insertions(+)
>> create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> index 28f9edb..6d99ba9 100644
>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> @@ -74,3 +74,45 @@ phy-consumer@1234 {
>>
>> Refer to DT bindings documentation of particular PHY consumer devices
>> for more
>> information about required PHYs and the way of specification.
>> +
>> +Samsung Exynos5 SoC series USB DRD PHY controller
>> +--
>> +
>> +Required properties:
>> +- compatible : Should be set to one of the following supported values:
>> + - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
>> + - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
>> +- reg : Register offset and length of USB DRD PHY register set;
>> +- clocks: Clock IDs array as required by the controller
>> +- clock-names: names of clocks correseponding to IDs in the clock
>> property;
>> +Required clocks:
>> + - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP
>> clock),
>> +used for register access.
>> + - ref: PHY's reference clock (usually crystal clock), associated by
>> +phy name, used to determine bit values for clock settings
>> +register.
>> + Additional clock required for Exynos5420:
>> + - usb30_sclk_100m: Additional special clock used for PHY operation
>> +depicted as 'sclk_usbphy30' in CMU of
>> Exynos5420.
>> +- samsung,syscon-phandle: phandle for syscon interface, which is used to
>> + control pmu registers for power isolation.
>> +- samsung,pmu-offset: phy power control register offset to
>> pmu-system-controller
>> + base.
>> +- #phy-cells : from the generic PHY bindings, must be 1;
>> +
>> +For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy"
>> +compatible PHYs, the second cell in the PHY specifier identifies the
>> +PHY id, which is interpreted as follows:
>> + 0 - UTMI+ type phy,
>> + 1 - PIPE3 type phy,
>> +
>> +Example:
>> + usb3_phy: usbphy@1210 {
>> + compatible = "samsung,exynos5250-usbdrd-phy";
>> + reg = <0x1210 0x100>;
>> + clocks = <&clock 286>, <&clock 1>;
>> + clock-names = "phy", "usb3phy_refclk";
>> + samsung,syscon-phandle = <&pmu_syscon>;
>> + samsung,pmu-offset = <0x704>;
>> + #phy-cells = <1>;
>> + };
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 8d3c49c..d955a05 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -166,4 +166,15 @@ config PHY_XGENE
>> help
>> This option enables support for APM X-Gene SoC multi-purpose PHY.
>>
>> +config PHY_EXYNOS5_USBDRD
>> + tristate "Exynos5 SoC series USB DRD PHY driver"
>> + depends on ARCH_EXYNOS5 && OF
>> + depends on HAS_IOMEM
>> + select GENERIC_PHY
>> + select MFD_SYSCON
>
> Lets try to avoid select in Kconfig. We've got enough problems with that.
I hope you meant with "select MFD_SYSCON".
We are referencing the syscon for accessing pmu reg, for which we need
this config to be selected.
Other Exynos phy drivers also need this config and for that they have
selected this.
Do you want me to do it any other way ?
>>>
Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
On Monday 14 April 2014 06:50 PM, Vivek Gautam wrote:
> On Mon, Apr 14, 2014 at 6:29 PM, Kishon Vijay Abraham I wrote:
>>
>>
>> On Monday 14 April 2014 06:12 PM, Vivek Gautam wrote:
>>> Hi,
>>>
>>>
>>> On Mon, Apr 14, 2014 at 5:57 PM, Kishon Vijay Abraham I
>>> wrote:
Hi,
On Tuesday 08 April 2014 08:06 PM, Vivek Gautam wrote:
> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
> The new driver uses the generic PHY framework and will interact
> with DWC3 controller present on Exynos5 series of SoCs.
> Thereby, removing old phy-samsung-usb3 driver and related code
> used untill now which was based on usb/phy framework.
>
> Signed-off-by: Vivek Gautam
> ---
> .../devicetree/bindings/phy/samsung-phy.txt| 42 ++
> drivers/phy/Kconfig| 11 +
> drivers/phy/Makefile |1 +
> drivers/phy/phy-exynos5-usbdrd.c | 668
>
> 4 files changed, 722 insertions(+)
> create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
>
> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> index 28f9edb..6d99ba9 100644
> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> @@ -74,3 +74,45 @@ phy-consumer@1234 {
>
> Refer to DT bindings documentation of particular PHY consumer devices
> for more
> information about required PHYs and the way of specification.
> +
> +Samsung Exynos5 SoC series USB DRD PHY controller
> +--
> +
> +Required properties:
> +- compatible : Should be set to one of the following supported values:
> + - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
> + - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
> +- reg : Register offset and length of USB DRD PHY register set;
> +- clocks: Clock IDs array as required by the controller
> +- clock-names: names of clocks correseponding to IDs in the clock
> property;
> +Required clocks:
> + - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP
> clock),
> +used for register access.
> + - ref: PHY's reference clock (usually crystal clock), associated by
> +phy name, used to determine bit values for clock settings
> +register.
> + Additional clock required for Exynos5420:
> + - usb30_sclk_100m: Additional special clock used for PHY operation
> +depicted as 'sclk_usbphy30' in CMU of Exynos5420.
> +- samsung,syscon-phandle: phandle for syscon interface, which is used to
> + control pmu registers for power isolation.
> +- samsung,pmu-offset: phy power control register offset to
> pmu-system-controller
> + base.
> +- #phy-cells : from the generic PHY bindings, must be 1;
> +
> +For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy"
> +compatible PHYs, the second cell in the PHY specifier identifies the
> +PHY id, which is interpreted as follows:
> + 0 - UTMI+ type phy,
> + 1 - PIPE3 type phy,
> +
> +Example:
> + usb3_phy: usbphy@1210 {
> + compatible = "samsung,exynos5250-usbdrd-phy";
> + reg = <0x1210 0x100>;
> + clocks = <&clock 286>, <&clock 1>;
> + clock-names = "phy", "usb3phy_refclk";
> + samsung,syscon-phandle = <&pmu_syscon>;
> + samsung,pmu-offset = <0x704>;
> + #phy-cells = <1>;
> + };
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 8d3c49c..d955a05 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -166,4 +166,15 @@ config PHY_XGENE
> help
> This option enables support for APM X-Gene SoC multi-purpose PHY.
>
> +config PHY_EXYNOS5_USBDRD
> + tristate "Exynos5 SoC series USB DRD PHY driver"
> + depends on ARCH_EXYNOS5 && OF
> + depends on HAS_IOMEM
> + select GENERIC_PHY
> + select MFD_SYSCON
Lets try to avoid select in Kconfig. We've got enough problems with that.
>>>
>>> I hope you meant with "select MFD_SYSCON".
>>> We are referencing the syscon for accessing pmu reg, for which we need
>>> this config to be selected.
>>> Other Exynos phy drivers also need this config and for that they have
>>> selected this.
>>>
>>> Do you want me to do it any other way ?
>>
>> depends on is one option.
>
> Ok, i can see there are places where depends_on MFD_SYSCON is used.
> "drivers/gpu/drm/exynos/Kconfig:60"
>
> so, do you want me to fix at other places t
Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
On Mon, Apr 14, 2014 at 6:29 PM, Kishon Vijay Abraham I wrote:
>
>
> On Monday 14 April 2014 06:12 PM, Vivek Gautam wrote:
>> Hi,
>>
>>
>> On Mon, Apr 14, 2014 at 5:57 PM, Kishon Vijay Abraham I
>> wrote:
>>> Hi,
>>>
>>> On Tuesday 08 April 2014 08:06 PM, Vivek Gautam wrote:
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam
---
.../devicetree/bindings/phy/samsung-phy.txt| 42 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usbdrd.c | 668
4 files changed, 722 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 28f9edb..6d99ba9 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -74,3 +74,45 @@ phy-consumer@1234 {
Refer to DT bindings documentation of particular PHY consumer devices for
more
information about required PHYs and the way of specification.
+
+Samsung Exynos5 SoC series USB DRD PHY controller
+--
+
+Required properties:
+- compatible : Should be set to one of the following supported values:
+ - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
+ - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
+- reg : Register offset and length of USB DRD PHY register set;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock
property;
+Required clocks:
+ - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP
clock),
+used for register access.
+ - ref: PHY's reference clock (usually crystal clock), associated by
+phy name, used to determine bit values for clock settings
+register.
+ Additional clock required for Exynos5420:
+ - usb30_sclk_100m: Additional special clock used for PHY operation
+depicted as 'sclk_usbphy30' in CMU of Exynos5420.
+- samsung,syscon-phandle: phandle for syscon interface, which is used to
+ control pmu registers for power isolation.
+- samsung,pmu-offset: phy power control register offset to
pmu-system-controller
+ base.
+- #phy-cells : from the generic PHY bindings, must be 1;
+
+For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy"
+compatible PHYs, the second cell in the PHY specifier identifies the
+PHY id, which is interpreted as follows:
+ 0 - UTMI+ type phy,
+ 1 - PIPE3 type phy,
+
+Example:
+ usb3_phy: usbphy@1210 {
+ compatible = "samsung,exynos5250-usbdrd-phy";
+ reg = <0x1210 0x100>;
+ clocks = <&clock 286>, <&clock 1>;
+ clock-names = "phy", "usb3phy_refclk";
+ samsung,syscon-phandle = <&pmu_syscon>;
+ samsung,pmu-offset = <0x704>;
+ #phy-cells = <1>;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 8d3c49c..d955a05 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -166,4 +166,15 @@ config PHY_XGENE
help
This option enables support for APM X-Gene SoC multi-purpose PHY.
+config PHY_EXYNOS5_USBDRD
+ tristate "Exynos5 SoC series USB DRD PHY driver"
+ depends on ARCH_EXYNOS5 && OF
+ depends on HAS_IOMEM
+ select GENERIC_PHY
+ select MFD_SYSCON
>>>
>>> Lets try to avoid select in Kconfig. We've got enough problems with that.
>>
>> I hope you meant with "select MFD_SYSCON".
>> We are referencing the syscon for accessing pmu reg, for which we need
>> this config to be selected.
>> Other Exynos phy drivers also need this config and for that they have
>> selected this.
>>
>> Do you want me to do it any other way ?
>
> depends on is one option.
Ok, i can see there are places where depends_on MFD_SYSCON is used.
"drivers/gpu/drm/exynos/Kconfig:60"
so, do you want me to fix at other places too ?
But i also have a question here.
MFD_SYSCON is a subsystem that's facilitating us in getting our work
done here by giving an access to pmu_system_controller.
So unless MF
[PATCH 4/4] ARM: dts: exynos5250-snow: add ptn3460 node
From: Doug Anderson
Added nodes for ptn3460 driver to Snow board.
Signed-off-by: Doug Anderson
Signed-off-by: Ajay Kumar
Signed-off-by: Sachin Kamat
---
arch/arm/boot/dts/exynos5250-snow.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index a38fd18..52ae335 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -32,6 +32,13 @@
samsung,pin-drv = <0>;
};
+ ptn3460_gpios: ptn3460-gpios {
+ samsung,pins = "gpy2-5", "gpx1-5";
+ samsung,pin-function = <1>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
sd3_clk: sd3-clk {
samsung,pin-drv = <0>;
};
@@ -324,4 +331,16 @@
clock-frequency = <2400>;
};
};
+
+ i2c_7: i2c@12CD {
+ ptn3460-bridge@20 {
+ compatible = "nxp,ptn3460";
+ reg = <0x20>;
+ powerdown-gpio = <&gpy2 5 0>;
+ reset-gpio = <&gpx1 5 0>;
+ edid-emulation = <5>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&ptn3460_gpios>;
+ };
+ };
};
--
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: exynos5250-snow: add tps65090 power regulator
From: Doug Anderson
Added TPS65090 regulator related nodes to Snow board.
Signed-off-by: Doug Anderson
Signed-off-by: Sachin Kamat
---
arch/arm/boot/dts/exynos5250-snow.dts | 90 +
1 file changed, 90 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 469c85d..a38fd18 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -44,6 +44,13 @@
sd3_bus4: sd3-bus-width4 {
samsung,pin-drv = <0>;
};
+
+ tps65090_irq: tps65090-irq {
+ samsung,pins = "gpx2-6";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
};
pinctrl@1340 {
@@ -75,6 +82,12 @@
};
};
+ vbat: vbat-fixed-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vbat-supply";
+ regulator-boot-on;
+ };
+
i2c-arbitrator {
compatible = "i2c-arb-gpio-challenge";
#address-cells = <1>;
@@ -201,6 +214,83 @@
0x070c0069>;/* LEFT
*/
};
};
+
+ power-regulator {
+ 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>;
+ vsys3-supply = <&vbat>;
+ infet1-supply = <&vbat>;
+ infet2-supply = <&vbat>;
+ infet3-supply = <&vbat>;
+ infet4-supply = <&vbat>;
+ infet5-supply = <&vbat>;
+ infet6-supply = <&vbat>;
+ infet7-supply = <&vbat>;
+ vsys-l1-supply = <&vbat>;
+ vsys-l2-supply = <&vbat>;
+
+ regulators {
+ dcdc1 {
+ ti,enable-ext-control;
+ };
+ dcdc2 {
+ ti,enable-ext-control;
+ };
+ dcdc3 {
+ ti,enable-ext-control;
+ };
+ fet1 {
+ regulator-name = "vcd_led";
+ ti,overcurrent-wait = <3>;
+ };
+ tps65090_fet2: fet2 {
+ regulator-name = "video_mid";
+ regulator-always-on;
+ ti,overcurrent-wait = <3>;
+ };
+ fet3 {
+ regulator-name = "wwan_r";
+ regulator-always-on;
+ ti,overcurrent-wait = <3>;
+ };
+ fet4 {
+ regulator-name = "sdcard";
+ ti,overcurrent-wait = <3>;
+ };
+ fet5 {
+ regulator-name = "camout";
+ regulator-always-on;
+ ti,overcurrent-wait = <3>;
+ };
+ fet6 {
+ regulator-name = "lcd_vdd";
+ ti,overcurrent-wait = <3>;
+ };
+ tps65090_fet7: fet7 {
+ regulator-name = "video_mid_1a";
+ regulator-always-on;
+
[PATCH 1/4] ARM: dts: exynos5250-snow: add pinctrl for i2c-arbitrator
From: Doug Anderson
Added i2c-arbitrator pinctrl node to Snow board.
Signed-off-by: Doug Anderson
Signed-off-by: Sachin Kamat
---
arch/arm/boot/dts/exynos5250-snow.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 1ce1088..32715b3 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -39,6 +39,22 @@
};
};
+ pinctrl@1340 {
+ arb_their_claim: arb-their-claim {
+ samsung,pins = "gpe0-4";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ arb_our_claim: arb-our-claim {
+ samsung,pins = "gpf0-3";
+ samsung,pin-function = <1>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+ };
+
gpio-keys {
compatible = "gpio-keys";
@@ -65,6 +81,9 @@
wait-retry-us = <3000>;
wait-free-us = <5>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&arb_our_claim &arb_their_claim>;
+
/* Use ID 104 as a hint that we're on physical bus 4 */
i2c_104: i2c@0 {
reg = <0>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: dts: exynos5250-snow: add pinctrl for EC irq
From: Doug Anderson
Added pinctrl node for embedded controller (EC) IRQ
on Snow board.
Signed-off-by: Doug Anderson
Signed-off-by: Sachin Kamat
---
arch/arm/boot/dts/exynos5250-snow.dts |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 32715b3..469c85d 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -25,6 +25,13 @@
};
pinctrl@1140 {
+ ec_irq: ec-irq {
+ samsung,pins = "gpx1-6";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
sd3_clk: sd3-clk {
samsung,pin-drv = <0>;
};
@@ -101,6 +108,8 @@
reg = <0x1e>;
interrupts = <6 0>;
interrupt-parent = <&gpx1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&ec_irq>;
wakeup-source;
keyboard-controller {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
On Monday 14 April 2014 05:35 PM, Vivek Gautam wrote:
> Hi Kishon,
>
>
> On Mon, Apr 14, 2014 at 5:24 PM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Wednesday 09 April 2014 04:36 PM, Tomasz Figa wrote:
>>> Hi Vivek,
>>>
>>> Please see my comments inline.
>>>
>>> On 08.04.2014 16:36, Vivek Gautam wrote:
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam
---
.../devicetree/bindings/phy/samsung-phy.txt| 42 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usbdrd.c | 668
4 files changed, 722 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
>>>
>>> [snip]
>>>
+Additional clock required for Exynos5420:
+- usb30_sclk_100m: Additional special clock used for PHY operation
+ depicted as 'sclk_usbphy30' in CMU of Exynos5420.
>>>
>>> Are you sure this isn't simply a gate for the ref clock, as it can be found
>>> on
>>> another SoC that is not upstream yet? I don't have documentation for Exynos
>>> 5420 so I can't tell, but I'd like to ask you to recheck this.
>>>
+- samsung,syscon-phandle: phandle for syscon interface, which is used to
+ control pmu registers for power isolation.
+- samsung,pmu-offset: phy power control register offset to
pmu-system-controller
+ base.
+- #phy-cells : from the generic PHY bindings, must be 1;
+
+For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy"
+compatible PHYs, the second cell in the PHY specifier identifies the
+PHY id, which is interpreted as follows:
+ 0 - UTMI+ type phy,
+ 1 - PIPE3 type phy,
+
+Example:
+usb3_phy: usbphy@1210 {
+compatible = "samsung,exynos5250-usbdrd-phy";
+reg = <0x1210 0x100>;
+clocks = <&clock 286>, <&clock 1>;
+clock-names = "phy", "usb3phy_refclk";
>>>
>>> Binding description above doesn't mention "usb3phy_refclk" entry.
>>>
+samsung,syscon-phandle = <&pmu_syscon>;
+samsung,pmu-offset = <0x704>;
+#phy-cells = <1>;
+};
>>>
>>> [snip]
>>>
diff --git a/drivers/phy/phy-exynos5-usbdrd.c
b/drivers/phy/phy-exynos5-usbdrd.c
new file mode 100644
index 000..ff54a7c
--- /dev/null
+++ b/drivers/phy/phy-exynos5-usbdrd.c
>>>
>>> [snip]
>>>
+static int exynos5_usbdrd_phy_probe(struct platform_device *pdev)
+{
+struct device *dev = &pdev->dev;
+struct device_node *node = dev->of_node;
+struct exynos5_usbdrd_phy *phy_drd;
+struct phy_provider *phy_provider;
+struct resource *res;
+const struct of_device_id *match;
+const struct exynos5_usbdrd_phy_drvdata *drv_data;
+struct regmap *reg_pmu;
+u32 pmu_offset;
+int i;
+
+/*
+ * Exynos systems are completely DT enabled,
+ * so lets not have any platform data support for this driver.
+ */
+if (!node) {
+dev_err(dev, "no device node found\n");
>>>
>>> This error message is not very meaningful. I'd rather use something like
>>> "This
>>> driver can be only instantiated using Device Tree".
>>
>> how about just adding depend_on OF in Kconfig?
>
> Already added a depend on 'OF'. Copying below the part of Kconfig in this
> patch.
Alright.. Do we need the check then? If config_OF is enabled devices will be
created using device tree no?
Thanks
Kishon
--
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] ARM: dts: exynos4: clean up arm-pmu node
This patch cleans a arm-pmu node up for exynos4. Only exynos4412 series
boards have four pmu interrupts. Rest of exynos4 boards, except 4412, have only
two pmu interrupts. Thus, we can define two interrupts in the
exynos4.dtsi and extends the interrupts only exynos4412.dtsi.
Cc: Chanwoo Choi
Signed-off-by: Chanho Park
---
arch/arm/boot/dts/exynos4.dtsi| 6 ++
arch/arm/boot/dts/exynos4210.dtsi | 6 --
arch/arm/boot/dts/exynos4412.dtsi | 6 ++
arch/arm/boot/dts/exynos4x12.dtsi | 6 --
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index e541ecb..6de978c 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -105,6 +105,12 @@
reg = <0x1044 0x1000>;
};
+ pmu {
+ compatible = "arm,cortex-a9-pmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <2 2>, <3 2>;
+ };
+
sys_reg: syscon@1001 {
compatible = "samsung,exynos4-sysreg", "syscon";
reg = <0x1001 0x400>;
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index cacf614..4e7610f 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -75,12 +75,6 @@
#clock-cells = <1>;
};
- pmu {
- compatible = "arm,cortex-a9-pmu";
- interrupt-parent = <&combiner>;
- interrupts = <2 2>, <3 2>;
- };
-
pinctrl_0: pinctrl@1140 {
compatible = "samsung,exynos4210-pinctrl";
reg = <0x1140 0x1000>;
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 15d3c0a..e6af870 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -26,6 +26,12 @@
samsung,combiner-nr = <20>;
};
+ pmu {
+ compatible = "arm,cortex-a9-pmu";
+ interrupt-parent = <&combiner>;
+ interrupts = <2 2>, <3 2>, <18 2>, <19 2>;
+ };
+
gic: interrupt-controller@1049 {
cpu-offset = <0x4000>;
};
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 3d77a40..318f3ac 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -31,12 +31,6 @@
mshc0 = &mshc_0;
};
- pmu {
- compatible = "arm,cortex-a9-pmu";
- interrupt-parent = <&combiner>;
- interrupts = <2 2>, <3 2>, <18 2>, <19 2>;
- };
-
pd_isp: isp-power-domain@10023CA0 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023CA0 0x20>;
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
On Monday 14 April 2014 06:12 PM, Vivek Gautam wrote:
> Hi,
>
>
> On Mon, Apr 14, 2014 at 5:57 PM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Tuesday 08 April 2014 08:06 PM, Vivek Gautam wrote:
>>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
>>> The new driver uses the generic PHY framework and will interact
>>> with DWC3 controller present on Exynos5 series of SoCs.
>>> Thereby, removing old phy-samsung-usb3 driver and related code
>>> used untill now which was based on usb/phy framework.
>>>
>>> Signed-off-by: Vivek Gautam
>>> ---
>>> .../devicetree/bindings/phy/samsung-phy.txt| 42 ++
>>> drivers/phy/Kconfig| 11 +
>>> drivers/phy/Makefile |1 +
>>> drivers/phy/phy-exynos5-usbdrd.c | 668
>>>
>>> 4 files changed, 722 insertions(+)
>>> create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> index 28f9edb..6d99ba9 100644
>>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> @@ -74,3 +74,45 @@ phy-consumer@1234 {
>>>
>>> Refer to DT bindings documentation of particular PHY consumer devices for
>>> more
>>> information about required PHYs and the way of specification.
>>> +
>>> +Samsung Exynos5 SoC series USB DRD PHY controller
>>> +--
>>> +
>>> +Required properties:
>>> +- compatible : Should be set to one of the following supported values:
>>> + - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
>>> + - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
>>> +- reg : Register offset and length of USB DRD PHY register set;
>>> +- clocks: Clock IDs array as required by the controller
>>> +- clock-names: names of clocks correseponding to IDs in the clock property;
>>> +Required clocks:
>>> + - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
>>> +used for register access.
>>> + - ref: PHY's reference clock (usually crystal clock), associated by
>>> +phy name, used to determine bit values for clock settings
>>> +register.
>>> + Additional clock required for Exynos5420:
>>> + - usb30_sclk_100m: Additional special clock used for PHY operation
>>> +depicted as 'sclk_usbphy30' in CMU of Exynos5420.
>>> +- samsung,syscon-phandle: phandle for syscon interface, which is used to
>>> + control pmu registers for power isolation.
>>> +- samsung,pmu-offset: phy power control register offset to
>>> pmu-system-controller
>>> + base.
>>> +- #phy-cells : from the generic PHY bindings, must be 1;
>>> +
>>> +For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy"
>>> +compatible PHYs, the second cell in the PHY specifier identifies the
>>> +PHY id, which is interpreted as follows:
>>> + 0 - UTMI+ type phy,
>>> + 1 - PIPE3 type phy,
>>> +
>>> +Example:
>>> + usb3_phy: usbphy@1210 {
>>> + compatible = "samsung,exynos5250-usbdrd-phy";
>>> + reg = <0x1210 0x100>;
>>> + clocks = <&clock 286>, <&clock 1>;
>>> + clock-names = "phy", "usb3phy_refclk";
>>> + samsung,syscon-phandle = <&pmu_syscon>;
>>> + samsung,pmu-offset = <0x704>;
>>> + #phy-cells = <1>;
>>> + };
>>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>>> index 8d3c49c..d955a05 100644
>>> --- a/drivers/phy/Kconfig
>>> +++ b/drivers/phy/Kconfig
>>> @@ -166,4 +166,15 @@ config PHY_XGENE
>>> help
>>> This option enables support for APM X-Gene SoC multi-purpose PHY.
>>>
>>> +config PHY_EXYNOS5_USBDRD
>>> + tristate "Exynos5 SoC series USB DRD PHY driver"
>>> + depends on ARCH_EXYNOS5 && OF
>>> + depends on HAS_IOMEM
>>> + select GENERIC_PHY
>>> + select MFD_SYSCON
>>
>> Lets try to avoid select in Kconfig. We've got enough problems with that.
>
> I hope you meant with "select MFD_SYSCON".
> We are referencing the syscon for accessing pmu reg, for which we need
> this config to be selected.
> Other Exynos phy drivers also need this config and for that they have
> selected this.
>
> Do you want me to do it any other way ?
depends on is one option.
Thanks
Kishon
--
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] ARM: dts: exynos4: add PMU syscon node
This patch adds a PMU(Power Management Unit) syscon node. This
should be required for USB Phy syscon regmap I/F.
Cc: Tomasz Figa
Cc: Kamil Debski
Signed-off-by: Chanho Park
---
arch/arm/boot/dts/exynos4.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 2f8bcd0..e565b86 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -110,6 +110,11 @@
reg = <0x1001 0x400>;
};
+ pmu_reg: syscon@1002 {
+ compatible = "samsung,exynos4-pmureg", "syscon";
+ reg = <0x1002 0x4000>;
+ };
+
dsi_0: dsi@11C8 {
compatible = "samsung,exynos4210-mipi-dsi";
reg = <0x11C8 0x1>;
--
1.8.3.2
--
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] Enable usbphy and hsotg for exynos4
This patchset enables a exynos4 usbphy and hsotg DT node for exynos4. The usb phy node uses generic exynos phy driver. The driver uses PMU syscon and SYSREG syscon phandles. Chanho Park (4): ARM: dts: exynos4: add PMU syscon node ARM: dts: exynos4: add exynos_usbphy node ARM: dts: exynos4: add hsotg device node ARM: dts: exynos4412-trats2: enable usb nodes arch/arm/boot/dts/exynos4.dtsi | 26 ++ arch/arm/boot/dts/exynos4412-trats2.dts | 10 ++ arch/arm/boot/dts/exynos4x12.dtsi | 5 + 3 files changed, 41 insertions(+) -- 1.8.3.2 -- 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/4] ARM: dts: exynos4412-trats2: enable usb nodes
This patch enables exynos_usbphy and hsotg device nodes.
Cc: Tomasz Figa
Cc: Kamil Debski
Cc: Marek Szyprowski
Signed-off-by: Chanho Park
---
arch/arm/boot/dts/exynos4412-trats2.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 9583563..a16db6c 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -665,6 +665,16 @@
};
};
+ exynos-usbphy@125B {
+ status = "okay";
+ };
+
+ hsotg@1248 {
+ vusb_d-supply = <&ldo15_reg>;
+ vusb_a-supply = <&ldo12_reg>;
+ status = "okay";
+ };
+
thermistor-ap@0 {
compatible = "ntc,ncp15wb473";
pullup-uv = <180>; /* VCC_1.8V_AP */
--
1.8.3.2
--
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: exynos4: add hsotg device node
This patch adds a hsotg node for exynos4 USB2.0 device controller.
Cc: Tomasz Figa
Cc: Kamil Debski
Cc: Marek Szyprowski
Signed-off-by: Chanho Park
---
arch/arm/boot/dts/exynos4.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 0e32d7f..e541ecb 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -288,6 +288,17 @@
#phy-cells = <1>;
};
+ hsotg@1248 {
+ compatible = "samsung,s3c6400-hsotg";
+ reg = <0x1248 0x2>;
+ interrupts = <0 71 0>;
+ clocks = <&clock 305>;
+ clock-names = "otg";
+ phys = <&exynos_usbphy 0>;
+ phy-names = "device";
+ status = "disabled";
+ };
+
ehci@1258 {
compatible = "samsung,exynos4210-ehci";
reg = <0x1258 0x100>;
--
1.8.3.2
--
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] ARM: dts: exynos4: add exynos_usbphy node
This patch enables a exynos_usbphy node for exynos4 SoCs.
A exynos4x12 usb phy node is almost same with 4210's one
except compatible string and pmu syscon.
Cc: Tomasz Figa
Cc: Kamil Debski
Signed-off-by: Chanho Park
---
arch/arm/boot/dts/exynos4.dtsi| 10 ++
arch/arm/boot/dts/exynos4x12.dtsi | 5 +
2 files changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index e565b86..0e32d7f 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -278,6 +278,16 @@
status = "disabled";
};
+ exynos_usbphy: exynos-usbphy@125B {
+ compatible = "samsung,exynos4210-usb2-phy";
+ reg = <0x125B 0x100>;
+ samsung,pmureg-phandle = <&pmu_reg>;
+ clocks = <&clock 305>, <&clock 2>;
+ clock-names = "phy", "ref";
+ status = "disabled";
+ #phy-cells = <1>;
+ };
+
ehci@1258 {
compatible = "samsung,exynos4210-ehci";
reg = <0x1258 0x100>;
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index c4a9306..3d77a40 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -243,4 +243,9 @@
clock-names = "biu", "ciu";
status = "disabled";
};
+
+ exynos-usbphy@125B {
+ compatible = "samsung,exynos4x12-usb2-phy";
+ samsung,sysreg-phandle = <&sys_reg>;
+ };
};
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
Hi,
On Mon, Apr 14, 2014 at 5:57 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Tuesday 08 April 2014 08:06 PM, Vivek Gautam wrote:
>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
>> The new driver uses the generic PHY framework and will interact
>> with DWC3 controller present on Exynos5 series of SoCs.
>> Thereby, removing old phy-samsung-usb3 driver and related code
>> used untill now which was based on usb/phy framework.
>>
>> Signed-off-by: Vivek Gautam
>> ---
>> .../devicetree/bindings/phy/samsung-phy.txt| 42 ++
>> drivers/phy/Kconfig| 11 +
>> drivers/phy/Makefile |1 +
>> drivers/phy/phy-exynos5-usbdrd.c | 668
>>
>> 4 files changed, 722 insertions(+)
>> create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> index 28f9edb..6d99ba9 100644
>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> @@ -74,3 +74,45 @@ phy-consumer@1234 {
>>
>> Refer to DT bindings documentation of particular PHY consumer devices for
>> more
>> information about required PHYs and the way of specification.
>> +
>> +Samsung Exynos5 SoC series USB DRD PHY controller
>> +--
>> +
>> +Required properties:
>> +- compatible : Should be set to one of the following supported values:
>> + - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
>> + - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
>> +- reg : Register offset and length of USB DRD PHY register set;
>> +- clocks: Clock IDs array as required by the controller
>> +- clock-names: names of clocks correseponding to IDs in the clock property;
>> +Required clocks:
>> + - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
>> +used for register access.
>> + - ref: PHY's reference clock (usually crystal clock), associated by
>> +phy name, used to determine bit values for clock settings
>> +register.
>> + Additional clock required for Exynos5420:
>> + - usb30_sclk_100m: Additional special clock used for PHY operation
>> +depicted as 'sclk_usbphy30' in CMU of Exynos5420.
>> +- samsung,syscon-phandle: phandle for syscon interface, which is used to
>> + control pmu registers for power isolation.
>> +- samsung,pmu-offset: phy power control register offset to
>> pmu-system-controller
>> + base.
>> +- #phy-cells : from the generic PHY bindings, must be 1;
>> +
>> +For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy"
>> +compatible PHYs, the second cell in the PHY specifier identifies the
>> +PHY id, which is interpreted as follows:
>> + 0 - UTMI+ type phy,
>> + 1 - PIPE3 type phy,
>> +
>> +Example:
>> + usb3_phy: usbphy@1210 {
>> + compatible = "samsung,exynos5250-usbdrd-phy";
>> + reg = <0x1210 0x100>;
>> + clocks = <&clock 286>, <&clock 1>;
>> + clock-names = "phy", "usb3phy_refclk";
>> + samsung,syscon-phandle = <&pmu_syscon>;
>> + samsung,pmu-offset = <0x704>;
>> + #phy-cells = <1>;
>> + };
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 8d3c49c..d955a05 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -166,4 +166,15 @@ config PHY_XGENE
>> help
>> This option enables support for APM X-Gene SoC multi-purpose PHY.
>>
>> +config PHY_EXYNOS5_USBDRD
>> + tristate "Exynos5 SoC series USB DRD PHY driver"
>> + depends on ARCH_EXYNOS5 && OF
>> + depends on HAS_IOMEM
>> + select GENERIC_PHY
>> + select MFD_SYSCON
>
> Lets try to avoid select in Kconfig. We've got enough problems with that.
I hope you meant with "select MFD_SYSCON".
We are referencing the syscon for accessing pmu reg, for which we need
this config to be selected.
Other Exynos phy drivers also need this config and for that they have
selected this.
Do you want me to do it any other way ?
>> + help
>> + Enable USB DRD PHY support for Exynos 5 SoC series.
>> + This driver provides PHY interface for USB 3.0 DRD controller
>> + present on Exynos5 SoC series.
>> +
>> endmenu
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index 2faf78e..31baa0c 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -18,3 +18,4 @@ obj-$(CONFIG_PHY_EXYNOS4210_USB2) +=
>> phy-exynos4210-usb2.o
>> obj-$(CONFIG_PHY_EXYNOS4X12_USB2)+= phy-exynos4x12-usb2.o
>> obj-$(CONFIG_PHY_EXYNOS5250_USB2)+= phy-exynos5250-usb2.o
>> obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
>> +obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-us
Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
Hi,
On Tuesday 08 April 2014 08:06 PM, Vivek Gautam wrote:
> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
> The new driver uses the generic PHY framework and will interact
> with DWC3 controller present on Exynos5 series of SoCs.
> Thereby, removing old phy-samsung-usb3 driver and related code
> used untill now which was based on usb/phy framework.
>
> Signed-off-by: Vivek Gautam
> ---
> .../devicetree/bindings/phy/samsung-phy.txt| 42 ++
> drivers/phy/Kconfig| 11 +
> drivers/phy/Makefile |1 +
> drivers/phy/phy-exynos5-usbdrd.c | 668
>
> 4 files changed, 722 insertions(+)
> create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
>
> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> index 28f9edb..6d99ba9 100644
> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> @@ -74,3 +74,45 @@ phy-consumer@1234 {
>
> Refer to DT bindings documentation of particular PHY consumer devices for
> more
> information about required PHYs and the way of specification.
> +
> +Samsung Exynos5 SoC series USB DRD PHY controller
> +--
> +
> +Required properties:
> +- compatible : Should be set to one of the following supported values:
> + - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
> + - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
> +- reg : Register offset and length of USB DRD PHY register set;
> +- clocks: Clock IDs array as required by the controller
> +- clock-names: names of clocks correseponding to IDs in the clock property;
> +Required clocks:
> + - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
> +used for register access.
> + - ref: PHY's reference clock (usually crystal clock), associated by
> +phy name, used to determine bit values for clock settings
> +register.
> + Additional clock required for Exynos5420:
> + - usb30_sclk_100m: Additional special clock used for PHY operation
> +depicted as 'sclk_usbphy30' in CMU of Exynos5420.
> +- samsung,syscon-phandle: phandle for syscon interface, which is used to
> + control pmu registers for power isolation.
> +- samsung,pmu-offset: phy power control register offset to
> pmu-system-controller
> + base.
> +- #phy-cells : from the generic PHY bindings, must be 1;
> +
> +For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy"
> +compatible PHYs, the second cell in the PHY specifier identifies the
> +PHY id, which is interpreted as follows:
> + 0 - UTMI+ type phy,
> + 1 - PIPE3 type phy,
> +
> +Example:
> + usb3_phy: usbphy@1210 {
> + compatible = "samsung,exynos5250-usbdrd-phy";
> + reg = <0x1210 0x100>;
> + clocks = <&clock 286>, <&clock 1>;
> + clock-names = "phy", "usb3phy_refclk";
> + samsung,syscon-phandle = <&pmu_syscon>;
> + samsung,pmu-offset = <0x704>;
> + #phy-cells = <1>;
> + };
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 8d3c49c..d955a05 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -166,4 +166,15 @@ config PHY_XGENE
> help
> This option enables support for APM X-Gene SoC multi-purpose PHY.
>
> +config PHY_EXYNOS5_USBDRD
> + tristate "Exynos5 SoC series USB DRD PHY driver"
> + depends on ARCH_EXYNOS5 && OF
> + depends on HAS_IOMEM
> + select GENERIC_PHY
> + select MFD_SYSCON
Lets try to avoid select in Kconfig. We've got enough problems with that.
> + help
> + Enable USB DRD PHY support for Exynos 5 SoC series.
> + This driver provides PHY interface for USB 3.0 DRD controller
> + present on Exynos5 SoC series.
> +
> endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 2faf78e..31baa0c 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -18,3 +18,4 @@ obj-$(CONFIG_PHY_EXYNOS4210_USB2) += phy-exynos4210-usb2.o
> obj-$(CONFIG_PHY_EXYNOS4X12_USB2)+= phy-exynos4x12-usb2.o
> obj-$(CONFIG_PHY_EXYNOS5250_USB2)+= phy-exynos5250-usb2.o
> obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
> +obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
> diff --git a/drivers/phy/phy-exynos5-usbdrd.c
> b/drivers/phy/phy-exynos5-usbdrd.c
> new file mode 100644
> index 000..ff54a7c
> --- /dev/null
> +++ b/drivers/phy/phy-exynos5-usbdrd.c
> @@ -0,0 +1,668 @@
> +/*
> + * Samsung EXYNOS5 SoC series USB DRD PHY driver
> + *
> + * Phy provider for USB 3.0 DRD controller on Exynos5 SoC series
> + *
> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
2014 already ;-)
> + * Author: V
Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Kishon,
On Mon, Apr 14, 2014 at 5:24 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Wednesday 09 April 2014 04:36 PM, Tomasz Figa wrote:
>> Hi Vivek,
>>
>> Please see my comments inline.
>>
>> On 08.04.2014 16:36, Vivek Gautam wrote:
>>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
>>> The new driver uses the generic PHY framework and will interact
>>> with DWC3 controller present on Exynos5 series of SoCs.
>>> Thereby, removing old phy-samsung-usb3 driver and related code
>>> used untill now which was based on usb/phy framework.
>>>
>>> Signed-off-by: Vivek Gautam
>>> ---
>>> .../devicetree/bindings/phy/samsung-phy.txt| 42 ++
>>> drivers/phy/Kconfig| 11 +
>>> drivers/phy/Makefile |1 +
>>> drivers/phy/phy-exynos5-usbdrd.c | 668
>>>
>>> 4 files changed, 722 insertions(+)
>>> create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
>>
>> [snip]
>>
>>> +Additional clock required for Exynos5420:
>>> +- usb30_sclk_100m: Additional special clock used for PHY operation
>>> + depicted as 'sclk_usbphy30' in CMU of Exynos5420.
>>
>> Are you sure this isn't simply a gate for the ref clock, as it can be found
>> on
>> another SoC that is not upstream yet? I don't have documentation for Exynos
>> 5420 so I can't tell, but I'd like to ask you to recheck this.
>>
>>> +- samsung,syscon-phandle: phandle for syscon interface, which is used to
>>> + control pmu registers for power isolation.
>>> +- samsung,pmu-offset: phy power control register offset to
>>> pmu-system-controller
>>> + base.
>>> +- #phy-cells : from the generic PHY bindings, must be 1;
>>> +
>>> +For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy"
>>> +compatible PHYs, the second cell in the PHY specifier identifies the
>>> +PHY id, which is interpreted as follows:
>>> + 0 - UTMI+ type phy,
>>> + 1 - PIPE3 type phy,
>>> +
>>> +Example:
>>> +usb3_phy: usbphy@1210 {
>>> +compatible = "samsung,exynos5250-usbdrd-phy";
>>> +reg = <0x1210 0x100>;
>>> +clocks = <&clock 286>, <&clock 1>;
>>> +clock-names = "phy", "usb3phy_refclk";
>>
>> Binding description above doesn't mention "usb3phy_refclk" entry.
>>
>>> +samsung,syscon-phandle = <&pmu_syscon>;
>>> +samsung,pmu-offset = <0x704>;
>>> +#phy-cells = <1>;
>>> +};
>>
>> [snip]
>>
>>> diff --git a/drivers/phy/phy-exynos5-usbdrd.c
>>> b/drivers/phy/phy-exynos5-usbdrd.c
>>> new file mode 100644
>>> index 000..ff54a7c
>>> --- /dev/null
>>> +++ b/drivers/phy/phy-exynos5-usbdrd.c
>>
>> [snip]
>>
>>> +static int exynos5_usbdrd_phy_probe(struct platform_device *pdev)
>>> +{
>>> +struct device *dev = &pdev->dev;
>>> +struct device_node *node = dev->of_node;
>>> +struct exynos5_usbdrd_phy *phy_drd;
>>> +struct phy_provider *phy_provider;
>>> +struct resource *res;
>>> +const struct of_device_id *match;
>>> +const struct exynos5_usbdrd_phy_drvdata *drv_data;
>>> +struct regmap *reg_pmu;
>>> +u32 pmu_offset;
>>> +int i;
>>> +
>>> +/*
>>> + * Exynos systems are completely DT enabled,
>>> + * so lets not have any platform data support for this driver.
>>> + */
>>> +if (!node) {
>>> +dev_err(dev, "no device node found\n");
>>
>> This error message is not very meaningful. I'd rather use something like
>> "This
>> driver can be only instantiated using Device Tree".
>
> how about just adding depend_on OF in Kconfig?
Already added a depend on 'OF'. Copying below the part of Kconfig in this patch.
config PHY_EXYNOS5_USBDRD
tristate "Exynos5 SoC series USB DRD PHY driver"
depends on ARCH_EXYNOS5 && OF
depends on HAS_IOMEM
--
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: hdmi: simplify extracting hpd-gpio from DT
Hi Tomasz,
On 04/14/2014 07:07 PM, Tomasz Stanislawski wrote:
This patch eliminates redundant checks while retrieving HPD gpio from DT during
HDMI's probe().
Signed-off-by: Tomasz Stanislawski
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index e1a2e88..300c2af 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2011,23 +2011,18 @@ static struct s5p_hdmi_platform_data
*drm_hdmi_dt_parse_pdata
{
struct device_node *np = dev->of_node;
struct s5p_hdmi_platform_data *pd;
- u32 value;
pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
if (!pd)
- goto err_data;
+ return NULL;
- if (!of_find_property(np, "hpd-gpio", &value)) {
+ pd->hpd_gpio = of_get_named_gpio_flags(np, "hpd-gpio", 0, NULL);
This is same with
pd->hpd_gpio = of_get_named_gpio(np, "hpd-gpio", 0);
+ if (pd->hpd_gpio < 0) {
How about use gpio_is_valid()?
DRM_ERROR("no hpd gpio property found\n");
- goto err_data;
+ return NULL;
}
- pd->hpd_gpio = of_get_named_gpio(np, "hpd-gpio", 0);
-
return pd;
-
-err_data:
- return NULL;
}
static struct of_device_id hdmi_match_types[] = {
Thanks.
--
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 v8 1/3] ARM: EXYNOS: Add support for EXYNOS5410 SoC
On 04/14/2014 03:03 PM, Arnd Bergmann wrote:
On Monday 14 April 2014 11:17:38 Tarek Dakhran wrote:
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -159,6 +159,15 @@ static struct map_desc exynos5250_iodesc[] __initdata = {
},
};
+static struct map_desc exynos5410_iodesc[] __initdata = {
+ {
+ .virtual= (unsigned long)S5P_VA_SYSRAM_NS,
+ .pfn= __phys_to_pfn(EXYNOS5410_PA_SYSRAM_NS),
+ .length = SZ_4K,
+ .type = MT_DEVICE,
+ },
+};
+
static struct map_desc exynos5_iodesc[] __initdata = {
NAK
Why does this keep coming up?
Arnd
We need this memory region because boot address for exynos5410 located
here, same as for 5250.
--
Best regards,
Tarek Dakhran
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
Hi,
On Wednesday 09 April 2014 04:36 PM, Tomasz Figa wrote:
> Hi Vivek,
>
> Please see my comments inline.
>
> On 08.04.2014 16:36, Vivek Gautam wrote:
>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
>> The new driver uses the generic PHY framework and will interact
>> with DWC3 controller present on Exynos5 series of SoCs.
>> Thereby, removing old phy-samsung-usb3 driver and related code
>> used untill now which was based on usb/phy framework.
>>
>> Signed-off-by: Vivek Gautam
>> ---
>> .../devicetree/bindings/phy/samsung-phy.txt| 42 ++
>> drivers/phy/Kconfig| 11 +
>> drivers/phy/Makefile |1 +
>> drivers/phy/phy-exynos5-usbdrd.c | 668
>>
>> 4 files changed, 722 insertions(+)
>> create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
>
> [snip]
>
>> +Additional clock required for Exynos5420:
>> +- usb30_sclk_100m: Additional special clock used for PHY operation
>> + depicted as 'sclk_usbphy30' in CMU of Exynos5420.
>
> Are you sure this isn't simply a gate for the ref clock, as it can be found on
> another SoC that is not upstream yet? I don't have documentation for Exynos
> 5420 so I can't tell, but I'd like to ask you to recheck this.
>
>> +- samsung,syscon-phandle: phandle for syscon interface, which is used to
>> + control pmu registers for power isolation.
>> +- samsung,pmu-offset: phy power control register offset to
>> pmu-system-controller
>> + base.
>> +- #phy-cells : from the generic PHY bindings, must be 1;
>> +
>> +For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy"
>> +compatible PHYs, the second cell in the PHY specifier identifies the
>> +PHY id, which is interpreted as follows:
>> + 0 - UTMI+ type phy,
>> + 1 - PIPE3 type phy,
>> +
>> +Example:
>> +usb3_phy: usbphy@1210 {
>> +compatible = "samsung,exynos5250-usbdrd-phy";
>> +reg = <0x1210 0x100>;
>> +clocks = <&clock 286>, <&clock 1>;
>> +clock-names = "phy", "usb3phy_refclk";
>
> Binding description above doesn't mention "usb3phy_refclk" entry.
>
>> +samsung,syscon-phandle = <&pmu_syscon>;
>> +samsung,pmu-offset = <0x704>;
>> +#phy-cells = <1>;
>> +};
>
> [snip]
>
>> diff --git a/drivers/phy/phy-exynos5-usbdrd.c
>> b/drivers/phy/phy-exynos5-usbdrd.c
>> new file mode 100644
>> index 000..ff54a7c
>> --- /dev/null
>> +++ b/drivers/phy/phy-exynos5-usbdrd.c
>
> [snip]
>
>> +static int exynos5_usbdrd_phy_probe(struct platform_device *pdev)
>> +{
>> +struct device *dev = &pdev->dev;
>> +struct device_node *node = dev->of_node;
>> +struct exynos5_usbdrd_phy *phy_drd;
>> +struct phy_provider *phy_provider;
>> +struct resource *res;
>> +const struct of_device_id *match;
>> +const struct exynos5_usbdrd_phy_drvdata *drv_data;
>> +struct regmap *reg_pmu;
>> +u32 pmu_offset;
>> +int i;
>> +
>> +/*
>> + * Exynos systems are completely DT enabled,
>> + * so lets not have any platform data support for this driver.
>> + */
>> +if (!node) {
>> +dev_err(dev, "no device node found\n");
>
> This error message is not very meaningful. I'd rather use something like "This
> driver can be only instantiated using Device Tree".
how about just adding depend_on OF in Kconfig?
Thanks
Kishon
--
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 RFC 0/2] drm/exynos: refactoring drm device init/deinit
Hi Inki, On 14.04.2014 13:04, Inki Dae wrote: -Original Message- From: Andrzej Hajda [mailto:a.ha...@samsung.com] Sent: Monday, April 14, 2014 5:55 PM To: Inki Dae Cc: dri-de...@lists.freedesktop.org; moderated list:ARM/S5P EXYNOS AR...; Kyungmin Park; Marek Szyprowski Subject: Re: [PATCH RFC 0/2] drm/exynos: refactoring drm device init/deinit On 04/12/2014 04:18 PM, Inki Dae wrote: Hi Andrzej, Thanks for your contributions. 2014-04-11 23:11 GMT+09:00 Andrzej Hajda : Hi Inki, This patchset refactors drm device initialization. Details are described in respective patches. It is an alternative to DT supernode concept. The first patch uses linker sections to get rid of ifdef macros, it is not That's a good idea. :) We could avoid ugly #ifdef ~ #endif with this way. essential for 2nd patch but it makes code more readable. Similar approach is used by irqchip, clks and clk_sources. But 2nd patch doesn't seem reasnoable to me. Your approach is same as existing one conceptually. I think we need to handle drm driver in a different way from irqchip, clks and clk_sources. DRM driver means one integrated graphics card but in most embedded systems, graphics and display relevant devices have separated hardware resources. So we would need abstractional integrated hardware, display-subsystem, super device. That is why I are trying to use super device approach, and conceptually it would be right solution. It wouldn't be not good to combine those separated hardware somehow using specific codes. Conceptually both approaches are the same: we have number of devices which should be ready before we can start super-device and if any device is to be removed super-device should be removed before. The difference is in 'details': - super-node approach have list of components provided explicitly in DT special node, - in this approach list of components is constructed from devices present in the system. Creating special DT node with information which is available anyway seems to be redundant and against DT rules. CCing Russell King, What is the special DT node? You mean device node from ports property? It is supposed to use super device and its properties in mainline so I don't see what it is against DT rules. If they are really against DT rules, why component framework is in mainline? Component framework in mainline doesn't have anything in common with DT. All it does is providing tools for handling cases where a subsystem can be initialized only after all components are available. It doesn't define any means of getting the list of components, it's a task for the user of this framework to provide it. As you said above, conceptually both approaches may be the same but your approach has no any abstract hardware meaning one integrated hardware. And if conceptually both approaches are the same, it would be good to use existing infrastructure, component framework so there is no any reason to add and use specific codes. What do you mean by "abstract hardware"? Physically, in the SoC, there is no single integrated hardware block, but multiple IPs and they need to be described this way in DT. There is nothing that prevents using them separately if a user doesn't want to use Exynos DRM. Exynos DRM is a Linux-specific thing and its details should not be leaked into DT, which is a _hardware_ description method. And component framework says, "Subsystems such as ALSA, DRM and others require a single card-level device structure to represent a subsystem. However, firmware tends to describe the individual devices and the connections between them. Therefore, we need a way to gather up the individual component devices together, and indicate when we have all the component devices." Note following things: - Nothing in the quote above says that an additional DT node must be added. The framework works on generic driver model level, above the description level (such as DT). - Andrzej's method implements the same concept as component framework, except that: a) it does so in a much more simple way (compare amount of code needed for Andrzej's approach and inside component framework), b) doesn't require component initialization to be undone on every master bring-up failure, c) uses the list of drivers known at compilation time to the Exynos DRM subsystem to build the list of devices to wait for d) doesn't introduce any new DT bindings, for virtual, Linux-specific things, e) doesn't duplicate compatible strings in an array used only to support systems that didn't have nodes required by those new DT bindings (as done in your exynos_drm_bind_lagacy_dt()), f) doesn't require two-step initialization (probe() and bind()), as opposed to component subsystem. As you can see, it's a pure list of benefits, without any obvious drawbacks, except that some generic code (more or less applicable here) is not used. However, I wonder whether some of Andrzej's ideas couldn't be
Re: [PATCH v8 1/3] ARM: EXYNOS: Add support for EXYNOS5410 SoC
On Monday 14 April 2014 11:17:38 Tarek Dakhran wrote:
> --- a/arch/arm/mach-exynos/exynos.c
> +++ b/arch/arm/mach-exynos/exynos.c
> @@ -159,6 +159,15 @@ static struct map_desc exynos5250_iodesc[] __initdata = {
> },
> };
>
> +static struct map_desc exynos5410_iodesc[] __initdata = {
> + {
> + .virtual= (unsigned long)S5P_VA_SYSRAM_NS,
> + .pfn= __phys_to_pfn(EXYNOS5410_PA_SYSRAM_NS),
> + .length = SZ_4K,
> + .type = MT_DEVICE,
> + },
> +};
> +
> static struct map_desc exynos5_iodesc[] __initdata = {
NAK
Why does this keep coming up?
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 RFC 0/2] drm/exynos: refactoring drm device init/deinit
> -Original Message- > From: Andrzej Hajda [mailto:a.ha...@samsung.com] > Sent: Monday, April 14, 2014 5:55 PM > To: Inki Dae > Cc: dri-de...@lists.freedesktop.org; moderated list:ARM/S5P EXYNOS AR...; > Kyungmin Park; Marek Szyprowski > Subject: Re: [PATCH RFC 0/2] drm/exynos: refactoring drm device > init/deinit > > On 04/12/2014 04:18 PM, Inki Dae wrote: > > Hi Andrzej, > > > > Thanks for your contributions. > > > > 2014-04-11 23:11 GMT+09:00 Andrzej Hajda : > >> Hi Inki, > >> > >> This patchset refactors drm device initialization. Details are > >> described in respective patches. It is an alternative to DT supernode > concept. > >> > >> The first patch uses linker sections to get rid of ifdef macros, it > >> is not > > That's a good idea. :) We could avoid ugly #ifdef ~ #endif with this way. > > > >> essential for 2nd patch but it makes code more readable. Similar > >> approach is used by irqchip, clks and clk_sources. > > But 2nd patch doesn't seem reasnoable to me. Your approach is same as > > existing one conceptually. I think we need to handle drm driver in a > > different way from irqchip, clks and clk_sources. > > > > DRM driver means one integrated graphics card but in most embedded > > systems, graphics and display relevant devices have separated hardware > > resources. So we would need abstractional integrated hardware, > > display-subsystem, super device. That is why I are trying to use super > > device approach, and conceptually it would be right solution. It > > wouldn't be not good to combine those separated hardware somehow using > > specific codes. > > Conceptually both approaches are the same: we have number of devices which > should be ready before we can start super-device and if any device is to > be removed super-device should be removed before. > The difference is in 'details': > - super-node approach have list of components provided explicitly in DT > special node, > - in this approach list of components is constructed from devices present > in the system. > > Creating special DT node with information which is available anyway seems > to be redundant and against DT rules. > CCing Russell King, What is the special DT node? You mean device node from ports property? It is supposed to use super device and its properties in mainline so I don't see what it is against DT rules. If they are really against DT rules, why component framework is in mainline? As you said above, conceptually both approaches may be the same but your approach has no any abstract hardware meaning one integrated hardware. And if conceptually both approaches are the same, it would be good to use existing infrastructure, component framework so there is no any reason to add and use specific codes. And component framework says, "Subsystems such as ALSA, DRM and others require a single card-level device structure to represent a subsystem. However, firmware tends to describe the individual devices and the connections between them. Therefore, we need a way to gather up the individual component devices together, and indicate when we have all the component devices." Thanks, Inki Dae > Regarding the old approach, I would not compare it with the current ones > as it has two main flaws: > - it is not aware of deferred probing, or more precisely it assumes that > driver registration instantly triggers device probing (it happens to be > true) and no probe of drm component will happen later (and this is false > assumption, eg. deferred probe), > - it do not remove super-device in case of removal of any of components. > > Regards > Andrzej > > > > > I have updated and tested super device approach with existing dt > > support so there wouldn't be any dt broken issue. I will post next > > version of this patch series soon, maybe tomorrow or the day after > > tomorrow. > > > > Thanks, > > Inki Dae > > > >> The patchset is based on exynos-drm-next branch. > >> > >> Regards > >> Andrzej > >> > >> > >> Andrzej Hajda (2): > >> drm/exynos: refactor drm drivers registration code > >> drm/exynos: initialize drm master only when all exynos drm devices > are > >> ready > >> > >> drivers/gpu/drm/exynos/Makefile | 2 + > >> drivers/gpu/drm/exynos/exynos_dp_core.c | 37 ++-- > >> drivers/gpu/drm/exynos/exynos_drm.lds.S | 9 + > >> drivers/gpu/drm/exynos/exynos_drm_drv.c | 279 + > --- > >> drivers/gpu/drm/exynos/exynos_drm_drv.h | 20 +- > >> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 42 +++-- > >> drivers/gpu/drm/exynos/exynos_drm_fimc.c| 35 ++-- > >> drivers/gpu/drm/exynos/exynos_drm_fimd.c| 38 ++-- > >> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 17 +- > >> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 30 +-- > >> drivers/gpu/drm/exynos/exynos_drm_ipp.c | 18 +- > >> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 27 ++- > >> drivers/gpu/drm/exynos/exynos_drm_vidi.c| 18 +- > >> drivers/gpu/drm/exynos/exynos_hdmi.c
Re: [PATCH v2 2/6] PCI: tegra: use new OF interrupt mapping when possible
On Sat, Apr 12, 2014 at 2:11 AM, Jason Gunthorpe
wrote:
> On Fri, Apr 11, 2014 at 11:10:59PM +0530, Srikanth Thokala wrote:
>
>> I see this error too on my setup (Xilinx PCIe Root Complex Driver),
>> https://lkml.org/lkml/2014/3/3/183
>
>> After digging into it, I see I need to override the API
>> pcibios_get_phb_of_node()
>
> No, as I pointed out before, the DT node comes in through
> pci_scan_root_bus:
Thanks Jason for the advice, it is working.
Srikanth
>
> +static struct pci_bus __init *xilinx_pcie_scan_bus(int nr,
> + struct pci_sys_data *sys)
> +{
> + struct xilinx_pcie_port *port = sys_to_pcie(sys);
> + struct pci_bus *bus;
> +
> + if (port) {
> + port->root_busno = sys->busnr;
> + bus = pci_scan_root_bus(NULL, sys->busnr, &xilinx_pcie_ops,
>^^
>
> You can't pass NULL here and have DT work properly.
>
> See http://www.spinics.net/lists/arm-kernel/msg312392.html
>
> Jason
--
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] drm: exynos: hdmi: simplify extracting hpd-gpio from DT
This patch eliminates redundant checks while retrieving HPD gpio from DT during
HDMI's probe().
Signed-off-by: Tomasz Stanislawski
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index e1a2e88..300c2af 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2011,23 +2011,18 @@ static struct s5p_hdmi_platform_data
*drm_hdmi_dt_parse_pdata
{
struct device_node *np = dev->of_node;
struct s5p_hdmi_platform_data *pd;
- u32 value;
pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
if (!pd)
- goto err_data;
+ return NULL;
- if (!of_find_property(np, "hpd-gpio", &value)) {
+ pd->hpd_gpio = of_get_named_gpio_flags(np, "hpd-gpio", 0, NULL);
+ if (pd->hpd_gpio < 0) {
DRM_ERROR("no hpd gpio property found\n");
- goto err_data;
+ return NULL;
}
- pd->hpd_gpio = of_get_named_gpio(np, "hpd-gpio", 0);
-
return pd;
-
-err_data:
- return NULL;
}
static struct of_device_id hdmi_match_types[] = {
--
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 7/8] arm64: mm: Implement 4 levels of translation tables
On Monday, April 14, 2014 6:34 PM, Steve Capper wrote: > On Mon, Apr 14, 2014 at 06:24:55PM +0900, Jungseok Lee wrote: > > On Monday, April 14, 2014 6:14 PM, Steve Capper wrote: > > > On Mon, Apr 13, 2014 at 04:41:07PM +0900, Jungseok Lee wrote: > > > > This patch implements 4 levels of translation tables since 3 > > > > levels of page tables with 4KB pages cannot support 40-bit > > > > physical address space described in [1] due to the following issue. > > > > > > > > It is a restriction that kernel logical memory map with 4KB + 3 > > > > levels > > > > (0xffc0-0x) cannot cover RAM region > > > > from 544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to > > > > create mapping for this region in map_mem function since > > > > __phys_to_virt for this region reaches to address overflow. > > > > > > > > If SoC design follows the document, [1], over 32GB RAM would be > > > > placed from 544GB. Even 64GB system is supposed to use the region > > > > from 544GB to 576GB for only 32GB RAM. Naturally, it would reach > > > > to enable 4 levels of page tables to avoid hacking __virt_to_phys and > > > > __phys_to_virt. > > > > > > > > However, it is recommended 4 levels of page table should be only > > > > enabled if memory map is too sparse or there is about 512GB RAM. > > > > > > Hi, > > > So I thought I'd apply this series and have a play, this patch > > > doesn't apply cleanly for me, please see below why... > > > > This pathset is based on 3.15-rc1. > > Thanks, yes that applies cleanly for me now. Okay, it sounds good. > > > > > [ ... ] > > > > > > > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S > > > > index 0fd5650..0b0b16a 100644 > > > > --- a/arch/arm64/kernel/head.S > > > > +++ b/arch/arm64/kernel/head.S > > > > @@ -46,8 +46,8 @@ > > > > #error KERNEL_RAM_VADDR must start at 0xXXX8 #endif > > > > > > > > -#define SWAPPER_DIR_SIZE (3 * PAGE_SIZE) > > > > -#define IDMAP_DIR_SIZE (2 * PAGE_SIZE) > > > > +#define SWAPPER_DIR_SIZE (4 * PAGE_SIZE) > > > > +#define IDMAP_DIR_SIZE (3 * PAGE_SIZE) > > > > > > > > .globl swapper_pg_dir > > > > .equswapper_pg_dir, KERNEL_RAM_VADDR - SWAPPER_DIR_SIZE > > > > @@ -384,6 +384,20 @@ ENDPROC(__calc_phys_offset) > > > > .endm > > > > > > > > /* > > > > + * Macro to populate the PUD for the corresponding block entry in > > > > +the next > > > > + * level (tbl) for the given virtual address. > > > > + * > > > > + * Preserves: pud, tbl, virt > > > > + * Corrupts: tmp1, tmp2 > > > > + */ > > > > + .macro create_pud_entry, pud, tbl, virt, tmp1, tmp2 > > > > + lsr \tmp1, \virt, #PUD_SHIFT > > > > + and \tmp1, \tmp1, #PTRS_PER_PUD - 1 // PUD index > > > > + orr \tmp2, \tbl, #3 // PUD entry table type > > > > + str \tmp2, [\pud, \tmp1, lsl #3] > > > > + .endm > > > > + > > > > +/* > > > > * Macro to populate block entries in the page table for the start..end > > > > * virtual range (inclusive). > > > > * > > > > @@ -445,10 +459,18 @@ __create_page_tables: > > > > ldr x3, =KERNEL_START > > > > add x3, x3, x28 // __pa(KERNEL_START) > > > > > > I don't think we have C++ style comments in the kernel. Also, I > > > can't see any references to =KERNEL_START in arch/arm64/kernel/head.S > > > (from 3.14 down). > > > > C++ style comments are prevalent in arch/arm64/kernel/head.S. I've > > C++ followed the > > code style written previously. > > Apologies, my mistake, I've been staring at arch/arm too long where @ is used. It's okay. Best Regards Jungseok Lee -- 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 7/8] arm64: mm: Implement 4 levels of translation tables
On Mon, Apr 14, 2014 at 06:24:55PM +0900, Jungseok Lee wrote: > On Monday, April 14, 2014 6:14 PM, Steve Capper wrote: > > On Mon, Apr 13, 2014 at 04:41:07PM +0900, Jungseok Lee wrote: > > > This patch implements 4 levels of translation tables since 3 levels of > > > page tables with 4KB pages cannot support 40-bit physical address > > > space described in [1] due to the following issue. > > > > > > It is a restriction that kernel logical memory map with 4KB + 3 levels > > > (0xffc0-0x) cannot cover RAM region from > > > 544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create > > > mapping for this region in map_mem function since __phys_to_virt for > > > this region reaches to address overflow. > > > > > > If SoC design follows the document, [1], over 32GB RAM would be placed > > > from 544GB. Even 64GB system is supposed to use the region from 544GB > > > to 576GB for only 32GB RAM. Naturally, it would reach to enable 4 > > > levels of page tables to avoid hacking __virt_to_phys and __phys_to_virt. > > > > > > However, it is recommended 4 levels of page table should be only > > > enabled if memory map is too sparse or there is about 512GB RAM. > > > > Hi, > > So I thought I'd apply this series and have a play, this patch doesn't > > apply cleanly for me, please > > see below why... > > This pathset is based on 3.15-rc1. Thanks, yes that applies cleanly for me now. > > > [ ... ] > > > > > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index > > > 0fd5650..0b0b16a 100644 > > > --- a/arch/arm64/kernel/head.S > > > +++ b/arch/arm64/kernel/head.S > > > @@ -46,8 +46,8 @@ > > > #error KERNEL_RAM_VADDR must start at 0xXXX8 #endif > > > > > > -#define SWAPPER_DIR_SIZE (3 * PAGE_SIZE) > > > -#define IDMAP_DIR_SIZE (2 * PAGE_SIZE) > > > +#define SWAPPER_DIR_SIZE (4 * PAGE_SIZE) > > > +#define IDMAP_DIR_SIZE (3 * PAGE_SIZE) > > > > > > .globl swapper_pg_dir > > > .equswapper_pg_dir, KERNEL_RAM_VADDR - SWAPPER_DIR_SIZE > > > @@ -384,6 +384,20 @@ ENDPROC(__calc_phys_offset) > > > .endm > > > > > > /* > > > + * Macro to populate the PUD for the corresponding block entry in the > > > +next > > > + * level (tbl) for the given virtual address. > > > + * > > > + * Preserves:pud, tbl, virt > > > + * Corrupts: tmp1, tmp2 > > > + */ > > > + .macro create_pud_entry, pud, tbl, virt, tmp1, tmp2 > > > + lsr \tmp1, \virt, #PUD_SHIFT > > > + and \tmp1, \tmp1, #PTRS_PER_PUD - 1 // PUD index > > > + orr \tmp2, \tbl, #3 // PUD entry table type > > > + str \tmp2, [\pud, \tmp1, lsl #3] > > > + .endm > > > + > > > +/* > > > * Macro to populate block entries in the page table for the start..end > > > * virtual range (inclusive). > > > * > > > @@ -445,10 +459,18 @@ __create_page_tables: > > > ldr x3, =KERNEL_START > > > add x3, x3, x28 // __pa(KERNEL_START) > > > > I don't think we have C++ style comments in the kernel. Also, I can't see > > any references to > > =KERNEL_START in arch/arm64/kernel/head.S (from 3.14 down). > > C++ style comments are prevalent in arch/arm64/kernel/head.S. I've followed > the > code style written previously. Apologies, my mistake, I've been staring at arch/arm too long where @ is used. Cheers, -- Steve -- 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 7/8] arm64: mm: Implement 4 levels of translation tables
On Monday, April 14, 2014 6:14 PM, Steve Capper wrote: > On Mon, Apr 13, 2014 at 04:41:07PM +0900, Jungseok Lee wrote: > > This patch implements 4 levels of translation tables since 3 levels of > > page tables with 4KB pages cannot support 40-bit physical address > > space described in [1] due to the following issue. > > > > It is a restriction that kernel logical memory map with 4KB + 3 levels > > (0xffc0-0x) cannot cover RAM region from > > 544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create > > mapping for this region in map_mem function since __phys_to_virt for > > this region reaches to address overflow. > > > > If SoC design follows the document, [1], over 32GB RAM would be placed > > from 544GB. Even 64GB system is supposed to use the region from 544GB > > to 576GB for only 32GB RAM. Naturally, it would reach to enable 4 > > levels of page tables to avoid hacking __virt_to_phys and __phys_to_virt. > > > > However, it is recommended 4 levels of page table should be only > > enabled if memory map is too sparse or there is about 512GB RAM. > > Hi, > So I thought I'd apply this series and have a play, this patch doesn't apply > cleanly for me, please > see below why... This pathset is based on 3.15-rc1. > [ ... ] > > > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S index > > 0fd5650..0b0b16a 100644 > > --- a/arch/arm64/kernel/head.S > > +++ b/arch/arm64/kernel/head.S > > @@ -46,8 +46,8 @@ > > #error KERNEL_RAM_VADDR must start at 0xXXX8 #endif > > > > -#define SWAPPER_DIR_SIZE (3 * PAGE_SIZE) > > -#define IDMAP_DIR_SIZE (2 * PAGE_SIZE) > > +#define SWAPPER_DIR_SIZE (4 * PAGE_SIZE) > > +#define IDMAP_DIR_SIZE (3 * PAGE_SIZE) > > > > .globl swapper_pg_dir > > .equswapper_pg_dir, KERNEL_RAM_VADDR - SWAPPER_DIR_SIZE > > @@ -384,6 +384,20 @@ ENDPROC(__calc_phys_offset) > > .endm > > > > /* > > + * Macro to populate the PUD for the corresponding block entry in the > > +next > > + * level (tbl) for the given virtual address. > > + * > > + * Preserves: pud, tbl, virt > > + * Corrupts: tmp1, tmp2 > > + */ > > + .macro create_pud_entry, pud, tbl, virt, tmp1, tmp2 > > + lsr \tmp1, \virt, #PUD_SHIFT > > + and \tmp1, \tmp1, #PTRS_PER_PUD - 1 // PUD index > > + orr \tmp2, \tbl, #3 // PUD entry table type > > + str \tmp2, [\pud, \tmp1, lsl #3] > > + .endm > > + > > +/* > > * Macro to populate block entries in the page table for the start..end > > * virtual range (inclusive). > > * > > @@ -445,10 +459,18 @@ __create_page_tables: > > ldr x3, =KERNEL_START > > add x3, x3, x28 // __pa(KERNEL_START) > > I don't think we have C++ style comments in the kernel. Also, I can't see any > references to > =KERNEL_START in arch/arm64/kernel/head.S (from 3.14 down). C++ style comments are prevalent in arch/arm64/kernel/head.S. I've followed the code style written previously. You can see this change in the commit, ea8c2e1124457f266f82effc3e6558552527943a). It's title is "arm64: Extend the idmap to the whole kernel image". > > create_pgd_entry x25, x0, x3, x5, x6 > > +#ifdef CONFIG_ARM64_4_LEVELS > > + add x1, x0, #PAGE_SIZE > > + create_pud_entry x0, x1, x3, x5, x6 > > +#endif > > ldr x6, =KERNEL_END > > mov x5, x3 // __pa(KERNEL_START) > > add x6, x6, x28 // __pa(KERNEL_END) > > +#ifndef CONFIG_ARM64_4_LEVELS > > create_block_map x0, x7, x3, x5, x6 > > +#else > > + create_block_map x1, x7, x3, x5, x6 > > +#endif > > > > /* > > * Map the kernel image (starting with PHYS_OFFSET). > > @@ -456,9 +478,17 @@ __create_page_tables: > > add x0, x26, #PAGE_SIZE // section table address > > mov x5, #PAGE_OFFSET > > create_pgd_entry x26, x0, x5, x3, x6 > > +#ifdef CONFIG_ARM64_4_LEVELS > > + add x1, x0, #PAGE_SIZE > > + create_pud_entry x0, x1, x3, x5, x6 > > +#endif > > ldr x6, =KERNEL_END > > mov x3, x24 // phys offset > > +#ifndef CONFIG_ARM64_4_LEVELS > > create_block_map x0, x7, x3, x5, x6 > > +#else > > + create_block_map x1, x7, x3, x5, x6 > > +#endif > > > > /* > > * Map the FDT blob (maximum 2MB; must be within 512MB of @@ -474,14 > > +504,25 @@ __create_page_tables: > > add x5, x5, x6 // __va(FDT blob) > > add x6, x5, #1 << 21// 2MB for the FDT blob > > sub x6, x6, #1 // inclusive range > > +#ifndef CONFIG_ARM64_4_LEVELS > > create_block_map x0, x7, x3, x5, x6 > > +#else > > + create_block_map x1, x7, x3, x5, x6 > > +#endif > > 1: > > /* > > * Create the pgd entry for the fixed mappings. > > */ > > ldr x5, =FIXADDR_TOP// Fixed mapping virtual address > > +#ifndef CONFIG_ARM64_4_LEVELS > > add x0, x
Re: [PATCH 7/8] arm64: mm: Implement 4 levels of translation tables
On Mon, Apr 13, 2014 at 04:41:07PM +0900, Jungseok Lee wrote: > This patch implements 4 levels of translation tables since 3 levels > of page tables with 4KB pages cannot support 40-bit physical address > space described in [1] due to the following issue. > > It is a restriction that kernel logical memory map with 4KB + 3 levels > (0xffc0-0x) cannot cover RAM region from > 544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create > mapping for this region in map_mem function since __phys_to_virt for > this region reaches to address overflow. > > If SoC design follows the document, [1], over 32GB RAM would be placed > from 544GB. Even 64GB system is supposed to use the region from 544GB > to 576GB for only 32GB RAM. Naturally, it would reach to enable 4 levels > of page tables to avoid hacking __virt_to_phys and __phys_to_virt. > > However, it is recommended 4 levels of page table should be only enabled > if memory map is too sparse or there is about 512GB RAM. Hi, So I thought I'd apply this series and have a play, this patch doesn't apply cleanly for me, please see below why... [ ... ] > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S > index 0fd5650..0b0b16a 100644 > --- a/arch/arm64/kernel/head.S > +++ b/arch/arm64/kernel/head.S > @@ -46,8 +46,8 @@ > #error KERNEL_RAM_VADDR must start at 0xXXX8 > #endif > > -#define SWAPPER_DIR_SIZE (3 * PAGE_SIZE) > -#define IDMAP_DIR_SIZE (2 * PAGE_SIZE) > +#define SWAPPER_DIR_SIZE (4 * PAGE_SIZE) > +#define IDMAP_DIR_SIZE (3 * PAGE_SIZE) > > .globl swapper_pg_dir > .equswapper_pg_dir, KERNEL_RAM_VADDR - SWAPPER_DIR_SIZE > @@ -384,6 +384,20 @@ ENDPROC(__calc_phys_offset) > .endm > > /* > + * Macro to populate the PUD for the corresponding block entry in the next > + * level (tbl) for the given virtual address. > + * > + * Preserves:pud, tbl, virt > + * Corrupts: tmp1, tmp2 > + */ > + .macro create_pud_entry, pud, tbl, virt, tmp1, tmp2 > + lsr \tmp1, \virt, #PUD_SHIFT > + and \tmp1, \tmp1, #PTRS_PER_PUD - 1 // PUD index > + orr \tmp2, \tbl, #3 // PUD entry table type > + str \tmp2, [\pud, \tmp1, lsl #3] > + .endm > + > +/* > * Macro to populate block entries in the page table for the start..end > * virtual range (inclusive). > * > @@ -445,10 +459,18 @@ __create_page_tables: > ldr x3, =KERNEL_START > add x3, x3, x28 // __pa(KERNEL_START) I don't think we have C++ style comments in the kernel. Also, I can't see any references to =KERNEL_START in arch/arm64/kernel/head.S (from 3.14 down). > create_pgd_entry x25, x0, x3, x5, x6 > +#ifdef CONFIG_ARM64_4_LEVELS > + add x1, x0, #PAGE_SIZE > + create_pud_entry x0, x1, x3, x5, x6 > +#endif > ldr x6, =KERNEL_END > mov x5, x3 // __pa(KERNEL_START) > add x6, x6, x28 // __pa(KERNEL_END) > +#ifndef CONFIG_ARM64_4_LEVELS > create_block_map x0, x7, x3, x5, x6 > +#else > + create_block_map x1, x7, x3, x5, x6 > +#endif > > /* >* Map the kernel image (starting with PHYS_OFFSET). > @@ -456,9 +478,17 @@ __create_page_tables: > add x0, x26, #PAGE_SIZE // section table address > mov x5, #PAGE_OFFSET > create_pgd_entry x26, x0, x5, x3, x6 > +#ifdef CONFIG_ARM64_4_LEVELS > + add x1, x0, #PAGE_SIZE > + create_pud_entry x0, x1, x3, x5, x6 > +#endif > ldr x6, =KERNEL_END > mov x3, x24 // phys offset > +#ifndef CONFIG_ARM64_4_LEVELS > create_block_map x0, x7, x3, x5, x6 > +#else > + create_block_map x1, x7, x3, x5, x6 > +#endif > > /* >* Map the FDT blob (maximum 2MB; must be within 512MB of > @@ -474,14 +504,25 @@ __create_page_tables: > add x5, x5, x6 // __va(FDT blob) > add x6, x5, #1 << 21// 2MB for the FDT blob > sub x6, x6, #1 // inclusive range > +#ifndef CONFIG_ARM64_4_LEVELS > create_block_map x0, x7, x3, x5, x6 > +#else > + create_block_map x1, x7, x3, x5, x6 > +#endif > 1: > /* >* Create the pgd entry for the fixed mappings. >*/ > ldr x5, =FIXADDR_TOP// Fixed mapping virtual address > +#ifndef CONFIG_ARM64_4_LEVELS > add x0, x26, #2 * PAGE_SIZE // section table address > create_pgd_entry x26, x0, x5, x6, x7 > +#else > + add x0, x26, #PAGE_SIZE > + create_pgd_entry x26, x0, x5, x6, x7 > + add x1, x0, #2 * PAGE_SIZE > + create_pud_entry x0, x1, x5, x6, x7 > +#endif > > /* >* Since the page tables have been populated with non-cacheable What tree is this series based on? Thanks, -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-sam
