[RFC v4 PATCH v2 06/18] ARM: dts: sysreg: add exynos5 compatible to DT bindings
This patch adds relevant to exynos5 compatible for exynos5 SoCs. Changelog v2: - Changes title and description (commented by Sachin Kamat) Signed-off-by: YoungJun Cho yj44@samsung.com Acked-by: Inki Dae inki@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- .../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,chip name-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 v4 PATCH 00/18] drm/exynos: support MIPI DSI command mode display
This patch series includes the followings: - Generic command mode interface - FIMD I80 interface - DSI command mode interface for Exynos5420 SoC - S6E3FA0 command mode type panel driver This patch series is based on exynos-drm-next branch. Previous patch set, RFC v1: http://www.spinics.net/lists/dri-devel/msg57513.html RFC v2: http://www.spinics.net/lists/dri-devel/msg57945.html RFC v3: http://www.spinics.net/lists/dri-devel/msg58364.html Changelog v2: - Moves panel delays and size DT properties to panel probe routine. - Moves CPU timings relevant DT properties from FIMD to panel DT. Changelog v3: - Splits core and driver patchset. - Renames CPU timings to CPU mode timings. - Enhances panel code readability. Changelog v4: - Implements generic command mode interface. - Adds command mode information to drm_display_mode. - Removes CPU mode timings. Thank you. Best regards YJ YoungJun Cho (18): drm/exynos: dsi: move the EoT packets configuration point drm/exynos: use wait_event_timeout() for safety usage ARM: dts: video: add command mode display timing DT bindings video: add command mode and command mode display timing drm_modes: add command mode helpers ARM: dts: sysreg: add exynos5 compatible to DT bindings ARM: dts: samsung-fimd: add I80 specific properties drm/exynos: add TE handler to support MIPI DSI command mode interface drm/exynos: dsi: add TE handler to support command mode interface drm/exynos: fimd: support I80 interface ARM: dts: exynos_dsim: add exynos5420 compatible to DT bindings 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 | 45 ++ .../bindings/video/cmdmode-display-timing.txt | 64 +++ .../devicetree/bindings/video/exynos_dsim.txt |4 +- .../devicetree/bindings/video/samsung-fimd.txt |2 + arch/arm/boot/dts/exynos4.dtsi |1 + arch/arm/boot/dts/exynos5.dtsi |6 + arch/arm/boot/dts/exynos5420.dtsi | 21 + drivers/gpu/drm/drm_modes.c| 59 ++ drivers/gpu/drm/exynos/Kconfig |1 + drivers/gpu/drm/exynos/exynos_drm_crtc.c | 16 +- drivers/gpu/drm/exynos/exynos_drm_crtc.h |7 + drivers/gpu/drm/exynos/exynos_drm_drv.h|3 + drivers/gpu/drm/exynos/exynos_drm_dsi.c| 175 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 277 -- drivers/gpu/drm/panel/Kconfig |7 + drivers/gpu/drm/panel/Makefile |1 + drivers/gpu/drm/panel/panel-s6e3fa0.c | 570 drivers/video/Kconfig |3 + drivers/video/Makefile |2 + drivers/video/cmdmode.c| 42 ++ drivers/video/cmdmode_display_timing.c | 26 + drivers/video/of_cmdmode.c | 55 ++ drivers/video/of_cmdmode_display_timing.c | 212 include/drm/drm_mipi_dsi.h |8 + include/drm/drm_modes.h| 12 + include/video/cmdmode.h| 67 +++ include/video/cmdmode_display_timing.h | 59 ++ include/video/of_cmdmode.h | 19 + include/video/of_cmdmode_display_timing.h | 26 + include/video/samsung_fimd.h |3 +- 31 files changed, 1723 insertions(+), 71 deletions(-) create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt create mode 100644 Documentation/devicetree/bindings/video/cmdmode-display-timing.txt create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c create mode 100644 drivers/video/cmdmode.c create mode 100644 drivers/video/cmdmode_display_timing.c create mode 100644 drivers/video/of_cmdmode.c create mode 100644 drivers/video/of_cmdmode_display_timing.c create mode 100644 include/video/cmdmode.h create mode 100644 include/video/cmdmode_display_timing.h create mode 100644 include/video/of_cmdmode.h create mode 100644 include/video/of_cmdmode_display_timing.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
[RFC v4 PATCH 09/18] drm/exynos: dsi: add TE handler to support command mode interface
To support command mode interface, the DSI host calls this handler
to notify the panel tearing effect synchronization signal to the
CRTC device manager to trigger to transfer video image.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 956e5f3..4a918ec 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -23,6 +23,7 @@
#include video/mipi_display.h
#include video/videomode.h
+#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)
--
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 v4 PATCH v3 10/18] drm/exynos: fimd: support I80 interface
To support MIPI DSI command mode interface, FIMD should do followings:
- Sets LCD block configuration for I80 interface.
- Uses lcd_sys as an IRQ resource and sets relevant IRQ configuration.
- Implements trigger feature which transfers image date if there is
page flip request, and implements TE handler to call trigger function.
- Sets command mode timings configuration.
- Sets ideal(pixel) clock is 2 times faster than the original one to
generate frame done IRQ prior to the next TE signal.
Changelog v2:
- Uses macros for TRIGCON register for readability (commented by Sachin)
Changelog v3:
- Removes using mode-private routine
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/Kconfig |1 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 277 +-
include/video/samsung_fimd.h |3 +-
3 files changed, 237 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_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 40fd6cc..50098e5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,11 +19,14 @@
#include linux/of.h
#include linux/of_device.h
#include linux/pm_runtime.h
+#include linux/mfd/syscon.h
+#include linux/regmap.h
#include video/of_display_timing.h
#include video/of_videomode.h
#include video/samsung_fimd.h
#include drm/exynos_drm.h
+#include drm/drm_panel.h
#include exynos_drm_drv.h
#include exynos_drm_fbdev.h
@@ -59,6 +62,24 @@
/* color key value register for hardware window 1 ~ 4. */
#define WKEYCON1_BASE(x) ((WKEYCON1 + 0x140) + ((x - 1) * 8))
+/* i80 / RGB trigger control register */
+#define TRIGCON0x1A4
+#define TRGMODE_I80_RGB_ENABLE_I80 (1 0)
+#define SWTRGCMD_I80_RGB_ENABLE(1 1)
+
+/* display mode change control register except exynos4 */
+#define VIDOUT_CON 0x000
+#define VIDOUT_CON_F_I80_LDI0 (0x2 8)
+
+/* i80 interface control for main LDI register */
+#define I80IFCONFAx(x) (0x1B0 + (x) * 4)
+#define I80IFCONFBx(x) (0x1B8 + (x) * 4)
+#define LCD_CS_SETUP(x)((x) 16)
+#define LCD_WR_SETUP(x)((x) 12)
+#define LCD_WR_ACT(x) ((x) 8)
+#define LCD_WR_HOLD(x) ((x) 4)
+#define I80IFEN_ENABLE (1 0)
+
/* FIMD has totally five hardware windows. */
#define WINDOWS_NR 5
@@ -66,10 +87,14 @@
struct fimd_driver_data {
unsigned int timing_base;
+ unsigned int lcdblk_off;
+ unsigned int lcdblk_vt_shift;
+ unsigned int lcdblk_bypass_shift;
unsigned int has_shadowcon:1;
unsigned int has_clksel:1;
unsigned int has_limited_fmt:1;
+ unsigned int has_vidoutcon:1;
};
static struct fimd_driver_data s3c64xx_fimd_driver_data = {
@@ -80,12 +105,19 @@ static struct fimd_driver_data s3c64xx_fimd_driver_data = {
static struct fimd_driver_data exynos4_fimd_driver_data = {
.timing_base = 0x0,
+ .lcdblk_off = 0x210,
+ .lcdblk_vt_shift = 10,
+ .lcdblk_bypass_shift = 1,
.has_shadowcon = 1,
};
static struct fimd_driver_data exynos5_fimd_driver_data = {
.timing_base = 0x2,
+ .lcdblk_off = 0x214,
+ .lcdblk_vt_shift = 24,
+ .lcdblk_bypass_shift = 15,
.has_shadowcon = 1,
+ .has_vidoutcon = 1,
};
struct fimd_win_data {
@@ -110,15 +142,23 @@ struct fimd_context {
struct clk *bus_clk;
struct clk *lcd_clk;
void __iomem*regs;
+ struct regmap *sysreg;
struct drm_display_mode mode;
struct fimd_win_datawin_data[WINDOWS_NR];
unsigned intdefault_win;
unsigned long irq_flags;
+ u32 vidcon0;
u32 vidcon1;
+ u32 vidout_con;
+ u32 i80ifcon;
+ booli80_if;
boolsuspended;
int pipe;
wait_queue_head_t wait_vsync_queue;
atomic_twait_vsync_event;
+ atomic_t
[RFC v4 PATCH 05/18] drm_modes: add command mode helpers
This patch adds helper functions to convert cmdmode
to drm_display_mode
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/drm_modes.c | 59 +++
include/drm/drm_modes.h | 12 +
2 files changed, 71 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 8b41057..7451893 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -37,6 +37,8 @@
#include drm/drm_crtc.h
#include video/of_videomode.h
#include video/videomode.h
+#include video/of_cmdmode.h
+#include video/cmdmode.h
#include drm/drm_modes.h
#include drm_crtc_internal.h
@@ -651,6 +653,63 @@ EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
#endif /* CONFIG_OF */
#endif /* CONFIG_VIDEOMODE_HELPERS */
+#ifdef CONFIG_CMDMODE_HELPERS
+int drm_display_mode_from_cmdmode(const struct cmdmode *cm,
+ struct drm_display_mode *dmode)
+{
+ dmode-hdisplay = cm-hactive;
+ dmode-htotal = dmode-hsync_end = dmode-hsync_start = dmode-hdisplay;
+
+ dmode-vdisplay = cm-vactive;
+ dmode-vtotal = dmode-vsync_end = dmode-vsync_start = dmode-vdisplay;
+
+ dmode-clock = cm-pixelclock / 1000;
+
+ dmode-cs_setup = cm-cs_setup;
+ dmode-wr_setup = cm-wr_setup;
+ dmode-wr_active = cm-wr_active;
+ dmode-wr_hold = cm-wr_hold;
+
+ dmode-flags = 0;
+ drm_mode_set_name(dmode);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(drm_display_mode_from_cmdmode);
+
+#ifdef CONFIG_OF
+/**
+ * of_get_drm_cmdmode_display_mode - get a drm_display_mode from devicetree
+ * @np: device_node with the timing specification
+ * @dmode: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * This function is expensive and should only be used, if only one mode is to
be
+ * read from DT. To get multiple modes start with
+ * of_get_cmdmode_display_timings and work with that instead.
+ */
+int of_get_drm_cmdmode_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode, int index)
+{
+ struct cmdmode cm;
+ int ret;
+
+ ret = of_get_cmdmode(np, cm, index);
+ if (ret)
+ return ret;
+
+ drm_display_mode_from_cmdmode(cm, dmode);
+
+ pr_debug(%s: got %dx%d display mode from %s\n,
+ of_node_full_name(np), cm.hactive, cm.vactive, np-name);
+ drm_mode_debug_printmodeline(dmode);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_drm_cmdmode_display_mode);
+#endif /* CONFIG_OF */
+#endif /* CONFIG_CMDMODE_HELPERS */
+
/**
* drm_mode_set_name - set the name on a mode
* @mode: name will be set in this mode
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 2dbbf99..53ecd03 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -144,6 +144,12 @@ struct drm_display_mode {
int vrefresh; /* in Hz */
int hsync; /* in kHz */
enum hdmi_picture_aspect picture_aspect_ratio;
+
+ /* Command mode info - refers to video/cmdmode.h */
+ int cs_setup;
+ int wr_setup;
+ int wr_active;
+ int wr_hold;
};
/* mode specified on the command line */
@@ -176,6 +182,7 @@ static inline bool drm_mode_is_stereo(const struct
drm_display_mode *mode)
struct drm_connector;
struct drm_cmdline_mode;
+struct cmdmode;
struct drm_display_mode *drm_mode_create(struct drm_device *dev);
void drm_mode_destroy(struct drm_device *dev, struct drm_display_mode *mode);
@@ -200,6 +207,11 @@ void drm_display_mode_from_videomode(const struct
videomode *vm,
int of_get_drm_display_mode(struct device_node *np,
struct drm_display_mode *dmode,
int index);
+extern int drm_display_mode_from_cmdmode(const struct cmdmode *cm,
+ struct drm_display_mode *dmode);
+extern int of_get_drm_cmdmode_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode,
+ int index);
void drm_mode_set_name(struct drm_display_mode *mode);
int drm_mode_hsync(const struct drm_display_mode *mode);
--
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 v4 PATCH 01/18] 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 yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
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
[RFC v4 PATCH v2 18/18] ARM: dts: exynos5420: add dsi node
This patch adds common part of dsi node.
Changelog v2:
- Uses clock macros instead of numbers (commented by Sachin Kamat)
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index f0184c7..f1030f5 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -17,6 +17,7 @@
#include exynos5420-pinctrl.dtsi
#include dt-bindings/clk/exynos-audss-clk.h
+#include dt-bindings/clock/exynos5420.h
/ {
compatible = samsung,exynos5420;
@@ -422,6 +423,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 CLK_DSIM1, clock CLK_SCLK_MIPI1;
+ clock-names = bus_clk, pll_clk;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ };
+
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 v4 PATCH v5 14/18] drm/panel: add S6E3FA0 driver
This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver.
Changelog v2:
- Declares delay, size properties in probe routine instead of DT
Changelog v3:
- Moves CPU mode timings relevant properties from FIMD DT
(commented by Laurent Pinchart, Andrzej Hajda)
Changelog v4:
- Enhances readability, vddm readi failure case and removes duplicated power off
(commented by Andrzej Hajda)
Changelog v5:
- Uses command mode helper functions instead of videomode one
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/panel/Kconfig |7 +
drivers/gpu/drm/panel/Makefile|1 +
drivers/gpu/drm/panel/panel-s6e3fa0.c | 570 +
3 files changed, 578 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..fa51237 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 CMDMODE_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..a3b2d7e
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
@@ -0,0 +1,570 @@
+/*
+ * MIPI-DSI based s6e3fa0 AMOLED LCD 5.7 inch panel driver.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * YoungJun Cho yj44@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include drm/drmP.h
+#include drm/drm_mipi_dsi.h
+#include drm/drm_panel.h
+
+#include linux/gpio/consumer.h
+#include linux/regulator/consumer.h
+
+#include video/mipi_display.h
+#include video/of_cmdmode.h
+#include video/cmdmode.h
+
+/* Manufacturer Command Set */
+#define MCS_GLOBAL_PARAMETER 0xb0
+#define MCS_AID0xb2
+#define MCS_ELVSSOPT 0xb6
+#define MCS_TEMPERATURE_SET0xb8
+#define MCS_PENTILE_CTRL 0xc0
+#define MCS_GAMMA_MODE 0xca
+#define MCS_VDDM 0xd7
+#define MCS_ALS0xe3
+#define MCS_ERR_FG 0xed
+#define MCS_KEY_LEV1 0xf0
+#define MCS_PANEL_UPDATE 0xf7
+#define MCS_KEY_LEV2 0xfc
+#define MCS_RE 0xfe
+#define MCS_TOUT2_HSYNC0xff
+
+/* Content Adaptive Brightness Control */
+#define DCS_WRITE_CABC 0x55
+
+#define MTP_ID_LEN 3
+#define GAMMA_LEVEL_NUM30
+
+#define DEFAULT_VDDM_VAL 0x15
+
+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;
+ struct cmdmode cm;
+
+ unsigned intpower_on_delay;
+ unsigned intreset_delay;
+ unsigned intinit_delay;
+ 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)
+
+/* VDD Memory Lookup Table contains paires of {ReadValue, WriteValue} */
+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},
[RFC v4 PATCH v2 11/18] ARM: dts: exynos_dsim: add exynos5420 compatible to DT bindings
This patch adds relevant to exynos5420 compatible for exynos5420 SoC support. Changelog v2: - Changes title, description and fixes typo (commented by Sachin Kamat) Signed-off-by: YoungJun Cho yj44@samsung.com Acked-by: Inki Dae inki@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- .../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..29bf3b2 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 SoCs */ - 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 v4 PATCH 17/18] ARM: dts: exynos5420: add mipi-phy node
This patch adds mipi-phy node for MIPI-DSI device.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
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 v4 PATCH 03/18] ARM: dts: video: add command mode display timing DT bindings
This patch adds DT bindings for command mode display timing.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../bindings/video/cmdmode-display-timing.txt | 64
1 file changed, 64 insertions(+)
create mode 100644
Documentation/devicetree/bindings/video/cmdmode-display-timing.txt
diff --git a/Documentation/devicetree/bindings/video/cmdmode-display-timing.txt
b/Documentation/devicetree/bindings/video/cmdmode-display-timing.txt
new file mode 100644
index 000..7cedfe4
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/cmdmode-display-timing.txt
@@ -0,0 +1,64 @@
+cmdmode-display-timing bindings
+===
+
+cmdmode-display-timings node
+
+
+required properties:
+ - none
+
+optional properties:
+ - native-mode: The native mode for the display, in case multiple modes are
+ provided. When omitted, assume the first node is the native.
+
+timing subnode
+--
+
+required properties:
+ - clock-frequency: display clock in Hz
+ - hactive, vactive: display resolution
+ - cs-setup: clock cycles for the active period of address signal is enabled
+ until chip select is enabled.
+ - wr-setup: clock cycles for the active period of CS signal is enabled until
+ write signal is enabled.
+ - wr-active: clock cycles for the active period of CS is enabled.
+ - wr-hold: clock cycles for the active period of CS is disabled until write
+ signal is disabled.
+
+optional properties:
+
+There are different ways of describing the capabilities of a display. The
+devicetree representation corresponds to the one commonly found in datasheets
+for displays. If a display supports multiple signal timings, the native-mode
+can be specified.
+
+The parameters are defined as:
+
+ VCLK(internal) __|¯¯|_|¯¯|_|¯¯|_|¯¯|_|¯¯
+:::::
+ Address Output --:XXX::::XX
+| CS-SETUP+1 |:::
+|--|:::
+ Chip Select ¯¯¯|::|¯¯
+ | WR-SETUP+1 || WR-HOLD+1 |
+ |--||--|
+ Write Enable||¯¯¯
+ | WR-ACTIVE+1|
+ |--|
+ Video Data X--
+
+Example:
+
+ cmdmode-display-timings {
+ native-mode = timing0;
+ timing0: 1080p24 {
+ /* 1920x1080p24 */
+ clock-frequency = 5200;
+ hactive = 1920;
+ vactive = 1080;
+ cs-setup = 0;
+ wr-setup = 0;
+ wr-active = 1;
+ wr-hold = 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 v4 PATCH 08/18] drm/exynos: add TE handler to support MIPI DSI command mode interface
To support MIPI DSI command mode interface, the panel should generates
Tearing Effect synchronization signal between MCU and FB to display
video images.
And the display controller should trigger to transfer video image at
this signal.
So the panel receives the TE IRQ, then calls this handler chains
to notify it to the display controller.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 11 +++
drivers/gpu/drm/exynos/exynos_drm_crtc.h |7 +++
drivers/gpu/drm/exynos/exynos_drm_drv.h |3 +++
include/drm/drm_mipi_dsi.h |8
4 files changed, 29 insertions(+)
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..eb78c16 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -32,4 +32,11 @@ 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);
+/*
+ * This function calls the crtc device(manager)'s te_handler() callback
+ * to trigger to transfer video image at the tearing effect synchronization
+ * signal.
+ */
+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..4d8865d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -186,6 +186,8 @@ 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: trigger to transfer video image at the tearing effect
+ * synchronization signal if there is a page flip request.
*/
struct exynos_drm_manager;
struct exynos_drm_manager_ops {
@@ -207,6 +209,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/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 7209df1..f6d4c85 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -49,6 +49,13 @@ struct mipi_dsi_msg {
* @detach: detach DSI device from DSI host
* @transfer: send and/or receive DSI packet, return number of received bytes,
* or error
+ * @te_handler: call the crtc te_handler() callback from DSI host.
+ * The panel generates tearing effect synchronization signal
+ * between MCU and FB to display video images.
+ * And the display controller should trigger to transfer video
+ * image at this signal.
+ * So the panel receives the TE IRQ, then calls this handler
+ * to notify it to the display controller.
*/
struct mipi_dsi_host_ops {
int (*attach)(struct mipi_dsi_host *host,
@@ -57,6 +64,7 @@ struct mipi_dsi_host_ops {
struct mipi_dsi_device *dsi);
ssize_t (*transfer)(struct mipi_dsi_host *host,
struct mipi_dsi_msg *msg);
+ int (*te_handler)(struct mipi_dsi_host *host);
};
/**
--
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 v4 PATCH v3 12/18] 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.
Changelog v2:
- Moves exynos_dsi_enable_clocks() after exynos_dsi_reset()
(commented by Andrzej Hajda)
- Splits D-PHY control setting routines from PLL setting one
(commented by Andrzej Hajda)
Changelog v3:
- Uses macro for DSIM_PHYCTRL register (commented by Sachin)
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 157 ++-
1 file changed, 135 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 4a918ec..50eb8ac 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -17,6 +17,7 @@
#include linux/clk.h
#include linux/irq.h
+#include linux/of_device.h
#include linux/phy/phy.h
#include linux/regulator/consumer.h
@@ -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)
@@ -200,6 +204,24 @@
#define DSIM_PLL_M(x) ((x) 4)
#define DSIM_PLL_S(x) ((x) 1)
+/* DSIM_PHYCTRL */
+#define DSIM_PHYCTRL_ULPS_EXIT(x) (((x) 0x1ff) 0)
+
+/* DSIM_PHYTIMING */
+#define DSIM_PHYTIMING_LPX(x) ((x) 8)
+#define DSIM_PHYTIMING_HS_EXIT(x) ((x) 0)
+
+/* DSIM_PHYTIMING1 */
+#define DSIM_PHYTIMING1_CLK_PREPARE(x) ((x) 24)
+#define DSIM_PHYTIMING1_CLK_ZERO(x)((x) 16)
+#define DSIM_PHYTIMING1_CLK_POST(x)((x) 8)
+#define DSIM_PHYTIMING1_CLK_TRAIL(x) ((x) 0)
+
+/* DSIM_PHYTIMING2 */
+#define DSIM_PHYTIMING2_HS_PREPARE(x) ((x) 16)
+#define DSIM_PHYTIMING2_HS_ZERO(x) ((x) 8)
+#define DSIM_PHYTIMING2_HS_TRAIL(x)((x) 0)
+
#define DSI_MAX_BUS_WIDTH 4
#define DSI_NUM_VIRTUAL_CHANNELS 4
#define DSI_TX_FIFO_SIZE 2048
@@ -233,6 +255,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 +290,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 +396,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
[RFC v4 PATCH 16/18] 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 yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
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 v4 PATCH 15/18] 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 yj44@samsung.com Acked-by: Inki Dae inki@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- 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 v4 PATCH v7 13/18] ARM: dts: s6e3fa0: add DT bindings
This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings and cpu mode timings.
Changelog v2:
- Adds unit address (commented by Sachin Kamat)
Changelog v3:
- Removes optional delay, size properties (commented by Laurent Pinchart)
- Adds OLED detection, TE gpio properties
Changelog v4:
- Moves CPU timings relevant properties from FIMD DT
(commented by Laurent Pinchart, Andrzej Hajda)
Changelog v5:
- Fixes gpio property names (commented by Andrzej Hajda)
Changelog v6:
- Renames CPU timings to CPU mode timings
- Modifies CPU mode timings internal properties relevant things
(commented by Laurent Pinchart, Andrzej Hajda)
Changelog v7:
- Uses cmdmode-display-timings only
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/panel/samsung,s6e3fa0.txt | 45
1 file changed, 45 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..c9a3fbd
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
@@ -0,0 +1,45 @@
+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-gpios: a GPIO spec for the reset pin
+ - det-gpios: a GPIO spec for the OLED detection pin
+ - te-gpios: a GPIO spec for the TE pin
+ - cmdmode-display-timings: command mode interface timings for the connected
+ panel as described by [1]
+
+Optional properties:
+
+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/cmdmode-display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ panel@0 {
+ compatible = samsung,s6e3fa0;
+ reg = 0;
+ vdd3-supply = vcclcd_reg;
+ vci-supply = vlcd_reg;
+ reset-gpios = gpy7 4 0;
+ det-gpios = gpg0 6 0;
+ te-gpios = gpd1 7 0;
+
+ cmdmode-display-timings {
+ timing-0 {
+ clock-frequency = 0;
+ hactive = 1080;
+ vactive = 1920;
+ cs-setup = 0;
+ wr-setup = 0;
+ wr-active = 1;
+ wr-hold = 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 v4 PATCH 02/18] 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 yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
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 v4 PATCH 04/18] video: add command mode and command mode display timing
This patch is based on videomode and display_timing relevant codes.
To support command mode panel, it does not need to guide its timing
information to the display controller like video mode panel,
but it requires signal timings to transfer video data.
So this patch adds cmdmode struct, cmdmode_display_timing struct and
the according helper functions to convert cmdmode_display_timing
to a generic cmdmode.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/video/Kconfig |3 +
drivers/video/Makefile|2 +
drivers/video/cmdmode.c | 42 ++
drivers/video/cmdmode_display_timing.c| 26
drivers/video/of_cmdmode.c| 55
drivers/video/of_cmdmode_display_timing.c | 212 +
include/video/cmdmode.h | 67 +
include/video/cmdmode_display_timing.h| 59
include/video/of_cmdmode.h| 19 +++
include/video/of_cmdmode_display_timing.h | 26
10 files changed, 511 insertions(+)
create mode 100644 drivers/video/cmdmode.c
create mode 100644 drivers/video/cmdmode_display_timing.c
create mode 100644 drivers/video/of_cmdmode.c
create mode 100644 drivers/video/of_cmdmode_display_timing.c
create mode 100644 include/video/cmdmode.h
create mode 100644 include/video/cmdmode_display_timing.h
create mode 100644 include/video/of_cmdmode.h
create mode 100644 include/video/of_cmdmode_display_timing.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index dade5b7..2022244 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -36,6 +36,9 @@ config VIDEO_OUTPUT_CONTROL
config VIDEOMODE_HELPERS
bool
+config CMDMODE_HELPERS
+ bool
+
config HDMI
bool
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index ae17ddf..922edbd 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -175,6 +175,8 @@ obj-$(CONFIG_FB_VIRTUAL) += vfb.o
#video output switch sysfs driver
obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o
obj-$(CONFIG_VIDEOMODE_HELPERS) += display_timing.o videomode.o
+obj-$(CONFIG_CMDMODE_HELPERS) += cmdmode_display_timing.o cmdmode.o
ifeq ($(CONFIG_OF),y)
obj-$(CONFIG_VIDEOMODE_HELPERS) += of_display_timing.o of_videomode.o
+obj-$(CONFIG_CMDMODE_HELPERS) += of_cmdmode_display_timing.o of_cmdmode.o
endif
diff --git a/drivers/video/cmdmode.c b/drivers/video/cmdmode.c
new file mode 100644
index 000..3d3eeb8
--- /dev/null
+++ b/drivers/video/cmdmode.c
@@ -0,0 +1,42 @@
+/*
+ * generic cmdmode display timing functions
+ *
+ * Copyright (c) 2014 YoungJun Cho yj44@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/errno.h
+#include linux/export.h
+#include video/cmdmode_display_timing.h
+#include video/cmdmode.h
+
+void cmdmode_from_timing(const struct cmdmode_display_timing *cmdt,
+ struct cmdmode *cm)
+{
+ cm-pixelclock = cmdt-pixelclock;
+ cm-hactive = cmdt-hactive;
+ cm-vactive = cmdt-vactive;
+ cm-cs_setup = cmdt-cs_setup;
+ cm-wr_setup = cmdt-wr_setup;
+ cm-wr_active = cmdt-wr_active;
+ cm-wr_hold = cmdt-wr_hold;
+}
+EXPORT_SYMBOL_GPL(cmdmode_from_timing);
+
+int cmdmode_from_timings(const struct cmdmode_display_timings *cmdts,
+ struct cmdmode *cm, unsigned int index)
+{
+ struct cmdmode_display_timing *cmdt;
+
+ cmdt = cmdmode_display_timings_get(cmdts, index);
+ if (!cmdt)
+ return -EINVAL;
+
+ cmdmode_from_timing(cmdt, cm);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(cmdmode_from_timings);
diff --git a/drivers/video/cmdmode_display_timing.c
b/drivers/video/cmdmode_display_timing.c
new file mode 100644
index 000..88bab08
--- /dev/null
+++ b/drivers/video/cmdmode_display_timing.c
@@ -0,0 +1,26 @@
+/*
+ * generic cmdmode display timing functions
+ *
+ * Copyright (c) 2014 YoungJun Cho yj44@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/export.h
+#include linux/slab.h
+#include video/cmdmode_display_timing.h
+
+void cmdmode_display_timings_release(struct cmdmode_display_timings *cmdts)
+{
+ if (cmdts-timings) {
+ unsigned int i;
+
+ for (i = 0; i cmdts-num_timings; i++)
+ kfree(cmdts-timings[i]);
+ kfree(cmdts-timings);
+ }
+ kfree(cmdts);
+}
+EXPORT_SYMBOL_GPL(cmdmode_display_timings_release);
diff --git a/drivers/video/of_cmdmode.c b/drivers/video/of_cmdmode.c
new
[PATCH] net: sxgbe: Added tail point update
This patch adds tail point update function for rx path
after rx_refill function. It indicates tail point for rx dma.
Signed-off-by: Byungho An bh74...@samsung.com
---
drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c | 14 +-
drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h |4
drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c |5 +
3 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c
index 49240c9..249b0e0 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c
@@ -112,7 +112,7 @@ static void sxgbe_dma_channel_init(void __iomem *ioaddr,
int cha_num,
dma_addr = dma_rx + ((r_rsize - 1) * SXGBE_DESC_SIZE_BYTES);
writel(lower_32_bits(dma_addr),
- ioaddr + SXGBE_DMA_CHA_RXDESC_LADD_REG(cha_num));
+ ioaddr + SXGBE_DMA_CHA_RXDESC_TAILPTR_REG(cha_num));
/* program the ring sizes */
writel(t_rsize - 1, ioaddr + SXGBE_DMA_CHA_TXDESC_RINGLEN_REG(cha_num));
writel(r_rsize - 1, ioaddr + SXGBE_DMA_CHA_RXDESC_RINGLEN_REG(cha_num));
@@ -370,6 +370,17 @@ static void sxgbe_enable_tso(void __iomem *ioaddr, u8
chan_num)
writel(ctrl, ioaddr + SXGBE_DMA_CHA_TXCTL_REG(chan_num));
}
+static void sxgbe_dma_update_rxdesc_tail_ptr(void __iomem *ioaddr, u8 chan_num,
+ dma_addr_t dma_rx_phy, int cur_rx,
+ int rxsize)
+{
+ u32 reg_val;
+
+ reg_val = (dma_rx_phy 0x) + ((cur_rx % rxsize) *
+ SXGBE_DESC_SIZE_BYTES);
+ writel(reg_val, ioaddr + SXGBE_DMA_CHA_RXDESC_TAILPTR_REG(chan_num));
+}
+
static const struct sxgbe_dma_ops sxgbe_dma_ops = {
.init = sxgbe_dma_init,
.cha_init = sxgbe_dma_channel_init,
@@ -386,6 +397,7 @@ static const struct sxgbe_dma_ops sxgbe_dma_ops = {
.rx_dma_int_status = sxgbe_rx_dma_int_status,
.rx_watchdog= sxgbe_dma_rx_watchdog,
.enable_tso = sxgbe_enable_tso,
+ .update_rxdesc_tail_ptr = sxgbe_dma_update_rxdesc_tail_ptr,
};
const struct sxgbe_dma_ops *sxgbe_get_dma_ops(void)
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h
index 843fa9b..a06e01e 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h
@@ -43,6 +43,10 @@ struct sxgbe_dma_ops {
void (*rx_watchdog)(void __iomem *ioaddr, u32 riwt);
/* Enable TSO for each DMA channel */
void (*enable_tso)(void __iomem *ioaddr, u8 chan_num);
+ void (*update_rxdesc_tail_ptr)(void __iomem *ioaddr, u8 chan_num,
+ dma_addr_t dma_rx, int r_rentry,
+ int r_rsize);
+
};
const struct sxgbe_dma_ops *sxgbe_get_dma_ops(void);
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
index 93bf151..7dc3449 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
@@ -1521,6 +1521,7 @@ static int sxgbe_rx(struct sxgbe_priv_data *priv, int
limit)
skb_put(skb, frame_len);
skb-ip_summed = checksum;
+ skb-protocol = eth_type_trans(skb, priv-dev);
if (checksum == CHECKSUM_NONE)
netif_receive_skb(skb);
else
@@ -1530,6 +1531,10 @@ static int sxgbe_rx(struct sxgbe_priv_data *priv, int
limit)
}
sxgbe_rx_refill(priv);
+ priv-hw-dma-update_rxdesc_tail_ptr(priv-ioaddr, qnum,
+ priv-rxq[qnum]-dma_rx_phy,
+ priv-rxq[qnum]-cur_rx,
+ priv-dma_rx_size);
return count;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 5/6] arm64: mm: Implement 4 levels of translation tables
On Wed, May 07, 2014 at 01:22:50PM +0900, Jungseok Lee wrote: On Tuesday, May 06, 2014 7:49 PM, Christoffer Dall wrote: On Thu, May 01, 2014 at 11:34:16AM +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. Who recommends this then? This paragraph just confuses me. It is a paraphrase of Catalin's comment: I agree, we should only enable 4-levels of page table if we have close to 512GB of RAM or the range is too sparse but I would actually push back on the hardware guys to keep it tighter. The above message comes from the discussion on 4 levels. http://www.spinics.net/linux/lists/arm-kernel/msg319055.html Hmm, I find it just confusing in the commit message and think it's more clear if you take it out. The only relevant bits here are that if you want to be able to address an address map of a certain size, you need this feature. It should be enabled on all systems that have such address maps to take advantage of the available hardware - arguing to hardware vendors on which systems to produce is fine, but a Linux commit message doesn't have to iterate on it - IMHO. -Christoffer -- 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] net: sxgbe: fixed mtl and dma channel feature
This patch fixes mtl queue and dma channel value
and adds mtl qsize for FIFO setting.
Signed-off-by: Byungho An bh74...@samsung.com
---
drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
index 7dc3449..bf4447a 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
@@ -889,14 +889,19 @@ static int sxgbe_get_hw_features(struct sxgbe_priv_data *
const priv)
/* Read First Capability Register CAP[2] */
rval = priv-hw-mac-get_hw_feature(priv-ioaddr, 2);
if (rval) {
- features-rx_mtl_queues = SXGBE_HW_FEAT_RX_MTL_QUEUES(rval);
- features-tx_mtl_queues = SXGBE_HW_FEAT_TX_MTL_QUEUES(rval);
- features-rx_dma_channels = SXGBE_HW_FEAT_RX_DMA_CHANNELS(rval);
- features-tx_dma_channels = SXGBE_HW_FEAT_TX_DMA_CHANNELS(rval);
+ features-rx_mtl_queues = SXGBE_HW_FEAT_RX_MTL_QUEUES(rval) + 1;
+ features-tx_mtl_queues = SXGBE_HW_FEAT_TX_MTL_QUEUES(rval) + 1;
+ features-rx_dma_channels = SXGBE_HW_FEAT_RX_DMA_CHANNELS(rval)
+ 1;
+ features-tx_dma_channels = SXGBE_HW_FEAT_TX_DMA_CHANNELS(rval)
+ 1;
features-pps_output_count = SXGBE_HW_FEAT_PPS_OUTPUTS(rval);
features-aux_input_count = SXGBE_HW_FEAT_AUX_SNAPSHOTS(rval);
}
+ features-rx_mtl_qsize = (1 (features-rxfifo_size + 7)) /
+ features-rx_mtl_queues;
+ features-tx_mtl_qsize = (1 (features-txfifo_size + 7)) /
+ features-tx_mtl_queues;
+
return rval;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] net: sxgbe: Added condition for non fix_burst mode
This patch adds the condition for non fixed burst mode
and separates into two conditions depending on pbl value.
Signed-off-by: Byungho An bh74...@samsung.com
---
drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c | 32 ---
drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h |2 +-
drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c |3 ++-
3 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c
index bb9b5b8..49240c9 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c
@@ -45,7 +45,8 @@ static int sxgbe_dma_init(void __iomem *ioaddr, int
fix_burst, int burst_map)
static void sxgbe_dma_channel_init(void __iomem *ioaddr, int cha_num,
int fix_burst, int pbl, dma_addr_t dma_tx,
- dma_addr_t dma_rx, int t_rsize, int r_rsize)
+ dma_addr_t dma_rx, int t_rsize, int r_rsize,
+ int buf_size)
{
u32 reg_val;
dma_addr_t dma_addr;
@@ -57,12 +58,37 @@ static void sxgbe_dma_channel_init(void __iomem *ioaddr,
int cha_num,
writel(reg_val, ioaddr + SXGBE_DMA_CHA_CTL_REG(cha_num));
/* program the TX pbl */
reg_val = readl(ioaddr + SXGBE_DMA_CHA_TXCTL_REG(cha_num));
- reg_val |= (pbl SXGBE_DMA_TXPBL_LSHIFT);
+ reg_val |= pbl SXGBE_DMA_TXPBL_LSHIFT;
writel(reg_val, ioaddr + SXGBE_DMA_CHA_TXCTL_REG(cha_num));
/* program the RX pbl */
reg_val = readl(ioaddr + SXGBE_DMA_CHA_RXCTL_REG(cha_num));
- reg_val |= (pbl SXGBE_DMA_RXPBL_LSHIFT);
+ reg_val |= pbl SXGBE_DMA_RXPBL_LSHIFT;
writel(reg_val, ioaddr + SXGBE_DMA_CHA_RXCTL_REG(cha_num));
+ } else {
+ if (pbl 32) {
+ /* program the pblx8 */
+ reg_val |= SXGBE_DMA_PBL_X8MODE;
+ writel(reg_val, ioaddr +
SXGBE_DMA_CHA_CTL_REG(cha_num));
+ /* program the TX pbl */
+ reg_val = readl(ioaddr +
SXGBE_DMA_CHA_TXCTL_REG(cha_num));
+ reg_val |= (pbl 3) SXGBE_DMA_TXPBL_LSHIFT;
+ writel(reg_val, ioaddr +
SXGBE_DMA_CHA_TXCTL_REG(cha_num));
+ /* program the RX pbl */
+ reg_val = readl(ioaddr +
SXGBE_DMA_CHA_RXCTL_REG(cha_num));
+ reg_val |= (pbl 3) SXGBE_DMA_RXPBL_LSHIFT |
+ buf_size SXGBE_DMA_BLENMAP_LSHIFT;
+ writel(reg_val, ioaddr +
SXGBE_DMA_CHA_RXCTL_REG(cha_num));
+ } else {
+ /* program the TX pbl */
+ reg_val = readl(ioaddr +
SXGBE_DMA_CHA_TXCTL_REG(cha_num));
+ reg_val |= pbl SXGBE_DMA_TXPBL_LSHIFT;
+ writel(reg_val, ioaddr +
SXGBE_DMA_CHA_TXCTL_REG(cha_num));
+ /* program the RX pbl */
+ reg_val = readl(ioaddr +
SXGBE_DMA_CHA_RXCTL_REG(cha_num));
+ reg_val |= pbl SXGBE_DMA_RXPBL_LSHIFT |
+ buf_size SXGBE_DMA_BLENMAP_LSHIFT;
+ writel(reg_val, ioaddr +
SXGBE_DMA_CHA_RXCTL_REG(cha_num));
+ }
}
/* program desc registers */
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h
index 1607b54..843fa9b 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h
@@ -25,7 +25,7 @@ struct sxgbe_dma_ops {
int (*init)(void __iomem *ioaddr, int fix_burst, int burst_map);
void (*cha_init)(void __iomem *ioaddr, int cha_num, int fix_burst,
int pbl, dma_addr_t dma_tx, dma_addr_t dma_rx,
-int t_rzie, int r_rsize);
+int t_rzie, int r_rsize, int buf_size);
void (*enable_dma_transmission)(void __iomem *ioaddr, int dma_cnum);
void (*enable_dma_irq)(void __iomem *ioaddr, int dma_cnum);
void (*disable_dma_irq)(void __iomem *ioaddr, int dma_cnum);
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
index 82a9a98..93bf151 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
@@ -944,7 +944,8 @@ static int sxgbe_init_dma_engine(struct sxgbe_priv_data
*priv)
fixed_burst, pbl,
(priv-txq[queue_num])-dma_tx_phy,
(priv-rxq[queue_num])-dma_rx_phy,
-
Re: [PATCHv2 1/3] phy: Add exynos-simple-phy driver
On 5 May 2014 15:14, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Wednesday 09 April 2014 03:31 PM, Sylwester Nawrocki wrote: Hi, On 09/04/14 11:12, Rahul Sharma wrote: Idea looks good. How about keeping compatible which is independent of SoC, something like samsung,exynos-simple-phy and provide Reg and Bit through phy provider node. This way we can avoid SoC specific hardcoding in phy driver and don't need to look into dt bindings for each new SoC. I believe it is a not recommended approach. Why not? We should try to avoid hard coding in the driver code. Moreover by avoiding hardcoding we can make it a generic driver for single bit PHYs. +1. @Tomasz, any plans to consider this approach for simple phy driver? Regards, Rahul Sharma. Cheers 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] drm/exynos: use 4WORD dma burst length for small fbs
From: Rahul Sharma rahul.sha...@samsung.com
In case of exynos, setting dma-burst to 16Word causes permanent
tearing for very small buffers, e.g. cursor buffer. Burst Mode
switching, which is based on overlay size is not recommended as
overlay size varies a lot towards the end of the screen. This
causes unstable DMA which results into tearing again.
Rendering small buffers with lower burst size doesn't
cause any noticable performance overhead. 128 pixel width is
selected based on mulitple experiments with exynos5 SoCs.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Prathyush K prathyus...@samsung.com
---
Based on Inki Dae's exynos-drm-next branch.
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 40fd6cc..ef56077 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -38,6 +38,7 @@
*/
#define FIMD_DEFAULT_FRAMERATE 60
+#define MIN_FB_WIDTH_FOR_16WORD_BURST 128
/* position control register for hardware window 0, 2 ~ 4.*/
#define VIDOSD_A(win) (VIDOSD_BASE + 0x00 + (win) * 16)
@@ -446,6 +447,19 @@ static void fimd_win_set_pixfmt(struct fimd_context *ctx,
unsigned int win)
DRM_DEBUG_KMS(bpp = %d\n, win_data-bpp);
+ /*
+* In case of exynos, setting dma-burst to 16Word causes permanent
+* tearing for very small buffers, e.g. cursor buffer. Burst Mode
+* switching which is based on overlay size is not recommended as
+* overlay size varies alot towards the end of the screen and rapid
+* movement causes unstable DMA which results into iommu crash/tear.
+*/
+
+ if (win_data-fb_width MIN_FB_WIDTH_FOR_16WORD_BURST) {
+ val = ~WINCONx_BURSTLEN_MASK;
+ val |= WINCONx_BURSTLEN_4WORD;
+ }
+
writel(val, ctx-regs + WINCON(win));
}
--
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] [media] s5p-mfc: Dequeue sequence header after STREAMON
MFCv6 encoder needs specific minimum number of buffers to
be queued in the CAPTURE plane. This minimum number will
be known only when the sequence header is generated.
So we used to allow STREAMON on the CAPTURE plane only after
sequence header is generated and checked with the minimum
buffer requirement.
But this causes a problem that we call a vb2_buffer_done
for the sequence header buffer before doing a STREAON on the
CAPTURE plane. This used to still work fine until this patch
was merged b3379c6201bb3555298cdbf0aa004af260f2a6a4.
This problem should also come in earlier MFC firmware versions
if the application calls STREAMON on CAPTURE with some delay
after doing STREAMON on OUTPUT.
So this patch keeps the header buffer until the other frame
buffers are ready and dequeues it just before the first frame
is ready.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 ++
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|6 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index d64b680..4fd1034 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -523,6 +523,7 @@ struct s5p_mfc_codec_ops {
* @output_state: state of the output buffers queue
* @src_bufs: information on allocated source buffers
* @dst_bufs: information on allocated destination buffers
+ * @header_mb: buf pointer of the encoded sequence header
* @sequence: counter for the sequence number for v4l2
* @dec_dst_flag: flags for buffers queued in the hardware
* @dec_src_buf_size: size of the buffer for source buffers in decoding
@@ -607,6 +608,7 @@ struct s5p_mfc_ctx {
int src_bufs_cnt;
struct s5p_mfc_buf dst_bufs[MFC_MAX_BUFFERS];
int dst_bufs_cnt;
+ struct s5p_mfc_buf *header_mb;
unsigned int sequence;
unsigned long dec_dst_flag;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index a9a23e1..e7dddb0 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -787,7 +787,7 @@ static int enc_post_seq_start(struct s5p_mfc_ctx *ctx)
ctx-dst_queue_cnt--;
vb2_set_plane_payload(dst_mb-b, 0,
s5p_mfc_hw_call(dev-mfc_ops, get_enc_strm_size, dev));
- vb2_buffer_done(dst_mb-b, VB2_BUF_STATE_DONE);
+ ctx-header_mb = dst_mb;
spin_unlock_irqrestore(dev-irqlock, flags);
}
@@ -845,6 +845,10 @@ static int enc_post_frame_start(struct s5p_mfc_ctx *ctx)
unsigned int strm_size;
unsigned long flags;
+ if (ctx-header_mb) {
+ vb2_buffer_done(ctx-header_mb-b, VB2_BUF_STATE_DONE);
+ ctx-header_mb = NULL;
+ }
slice_type = s5p_mfc_hw_call(dev-mfc_ops, get_enc_slice_type, dev);
strm_size = s5p_mfc_hw_call(dev-mfc_ops, get_enc_strm_size, dev);
mfc_debug(2, Encoded slice type: %d\n, slice_type);
--
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] [media] s5p-mfc: Update scratch buffer size for VP8 encoder
From: Kiran AVND avnd.ki...@samsung.com Scratch buffer size updated for vp8 encoding as per the latest v7 firmware. As the new macro increases the scratch buffer size, it is backward compatible with the older firmware too. Signed-off-by: Kiran AVND avnd.ki...@samsung.com Signed-off-by: Arun Kumar K arun...@samsung.com --- drivers/media/platform/s5p-mfc/regs-mfc-v7.h |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v7.h b/drivers/media/platform/s5p-mfc/regs-mfc-v7.h index 82c96fa..1a5c6fd 100644 --- a/drivers/media/platform/s5p-mfc/regs-mfc-v7.h +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v7.h @@ -54,6 +54,7 @@ (SZ_1M + ((w) * 144) + (8192 * (h)) + 49216) #define S5P_FIMV_SCRATCH_BUF_SIZE_VP8_ENC_V7(w, h) \ - (((w) * 48) + (((w) + 1) / 2 * 128) + 144 + 8192) + (((w) * 48) + 8192 + w) + 1) / 2) * 128) + 144 + \ + ((w) * 16) * ((h) * 16)) * 3) / 2) * 4)) #endif /*_REGS_MFC_V7_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] drm/exynos: allocate non-contigous buffers when iommu is enabled
From: Rahul Sharma rahul.sha...@samsung.com
Allow to allocate non-contigous buffers when iommu is enabled.
Currently, it tries to allocates contigous buffer which consistently
fail for large buffers and then fall back to non contigous. Apart
from being slow, this implementation is also very noisy and fills
the screen with alloc fail logs.
Change-Id: I523e95aa308122ed2edc55e065ae6eb8be996541
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 5d88924..7136945 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -624,22 +624,20 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv,
args-pitch = args-width * ((args-bpp + 7) / 8);
args-size = args-pitch * args-height;
- exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG |
- EXYNOS_BO_WC, args-size);
- /*
-* If physically contiguous memory allocation fails and if IOMMU is
-* supported then try to get buffer from non physically contiguous
-* memory area.
-*/
- if (IS_ERR(exynos_gem_obj) is_drm_iommu_supported(dev)) {
- dev_warn(dev-dev, contiguous FB allocation failed, falling
back to non-contiguous\n);
+ if (is_drm_iommu_supported(dev)) {
+ exynos_gem_obj = exynos_drm_gem_create(dev,
+ EXYNOS_BO_NONCONTIG | EXYNOS_BO_WC,
+ args-size);
+ } else {
exynos_gem_obj = exynos_drm_gem_create(dev,
- EXYNOS_BO_NONCONTIG | EXYNOS_BO_WC,
- args-size);
+ EXYNOS_BO_CONTIG | EXYNOS_BO_WC,
+ args-size);
}
- if (IS_ERR(exynos_gem_obj))
+ if (IS_ERR(exynos_gem_obj)) {
+ dev_warn(dev-dev, FB allocation failed.\n);
return PTR_ERR(exynos_gem_obj);
+ }
ret = exynos_drm_gem_handle_create(exynos_gem_obj-base, file_priv,
args-handle);
--
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 14/15] clk: exynos5420: add misc clocks
Hi Tomasz,
On Tue, May 6, 2014 at 11:19 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Shaik,
On 06.05.2014 18:26, Shaik Ameer Basha wrote:
This patch adds some missing miscellaneous clocks specific
to exynos5420.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/clk/samsung/clk-exynos5420.c | 14 +++---
include/dt-bindings/clock/exynos5420.h |2 ++
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index e0e749d..e69e820 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -273,7 +273,8 @@ PNAME(mout_group5_p) = {mout_sclk_vpll,
mout_sclk_dpll};
PNAME(mout_fimd1_final_p) = {mout_fimd1, mout_fimd1_opt};
PNAME(mout_sw_aclk66_p) = {dout_aclk66, mout_sclk_spll};
-PNAME(mout_user_aclk66_peric_p)= { fin_pll, mout_sw_aclk66 };
+PNAME(mout_user_aclk66_peric_p)= { fin_pll, mout_sw_aclk66};
+PNAME(mout_user_pclk66_gpio_p) = {mout_sw_aclk66, ffactor_sw_aclk66};
PNAME(mout_sw_aclk200_fsys_p) = {dout_aclk200_fsys, mout_sclk_spll};
PNAME(mout_sw_pclk200_fsys_p) = {dout_pclk200_fsys, mout_sclk_spll};
@@ -372,10 +373,13 @@ static struct samsung_fixed_rate_clock
exynos5420_fixed_rate_clks[] __initdata =
};
static struct samsung_fixed_factor_clock exynos5420_fixed_factor_clks[]
__initdata = {
- FFACTOR(0, sclk_hsic_12m, fin_pll, 1, 2, 0),
+ FFACTOR(0, ffactor_hsic_12m, fin_pll, 1, 2, 0),
+ FFACTOR(0, ffactor_sw_aclk66, mout_sw_aclk66, 1, 2, 0),
Is the ffactor_ prefix also present in the datasheet? If not, it should be
removed from clock names as well.
Its not there in manual.
As we are differentiating muxes and dividers with mout and dout
this prefix is added
to differentiate fixed factor clocks.
shall I keep it or not?
Regards,
Shaik Ameer Basha
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 10/15] clk: exynos5420: update clocks for FSYS and FSYS2 blocks
Hi Tomasz,
On Tue, May 6, 2014 at 11:13 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Shaik,
On 06.05.2014 18:26, Shaik Ameer Basha wrote:
This patch adds more clocks from FSYS and FSYS2 blocks
and uses GATE_IP_* registers for gating IPs.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/clk/samsung/clk-exynos5420.c | 41
++
1 file changed, 27 insertions(+), 14 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index f0460b4..6d88ae2 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
[snip]
@@ -736,12 +749,9 @@ static struct samsung_gate_clock
exynos5420_gate_clks[] __initdata = {
GATE(CLK_SCLK_USBPHY300, sclk_usbphy300, dout_usbphy300,
GATE_TOP_SCLK_FSYS, 8, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_USBD300, sclk_usbd300, dout_usbd300,
- GATE_TOP_SCLK_FSYS, 9, CLK_SET_RATE_PARENT, 0),
+ GATE_TOP_SCLK_FSYS, 9, CLK_IGNORE_UNUSED, 0),
Why CLK_IGNORE_UNUSED? Also CLK_SET_RATE_PARENT seems quite right for this
clock.
Sorry, that was a hack for some internal USB testing. Some how it got
merged with this series.
I will revert it to CLK_SET_RATE_PARENT.
GATE(CLK_SCLK_USBD301, sclk_usbd301, dout_usbd301,
- GATE_TOP_SCLK_FSYS, 10, CLK_SET_RATE_PARENT, 0),
-
- GATE(CLK_SCLK_USBD301, sclk_unipro, dout_unipro,
- SRC_MASK_FSYS, 24, CLK_SET_RATE_PARENT, 0),
+ GATE_TOP_SCLK_FSYS, 10, CLK_IGNORE_UNUSED, 0),
Same here.
Same here :)
/* Display */
GATE(CLK_SCLK_FIMD1, sclk_fimd1, dout_fimd1,
@@ -760,20 +770,23 @@ static struct samsung_gate_clock
exynos5420_gate_clks[] __initdata = {
GATE_TOP_SCLK_MAU, 0, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_MAUPCM0, sclk_maupcm0, dout_maupcm0,
GATE_TOP_SCLK_MAU, 1, CLK_SET_RATE_PARENT, 0),
- /* FSYS */
+
+ /* FSYS Block */
GATE(CLK_TSI, tsi, aclk200_fsys, GATE_BUS_FSYS0, 0, 0, 0),
GATE(CLK_PDMA0, pdma0, aclk200_fsys, GATE_BUS_FSYS0, 1, 0, 0),
GATE(CLK_PDMA1, pdma1, aclk200_fsys, GATE_BUS_FSYS0, 2, 0, 0),
GATE(CLK_UFS, ufs, aclk200_fsys2, GATE_BUS_FSYS0, 3, 0, 0),
- GATE(CLK_RTIC, rtic, aclk200_fsys, GATE_BUS_FSYS0, 5, 0, 0),
- GATE(CLK_MMC0, mmc0, aclk200_fsys2, GATE_BUS_FSYS0, 12, 0, 0),
- GATE(CLK_MMC1, mmc1, aclk200_fsys2, GATE_BUS_FSYS0, 13, 0, 0),
- GATE(CLK_MMC2, mmc2, aclk200_fsys2, GATE_BUS_FSYS0, 14, 0, 0),
+ GATE(CLK_RTIC, rtic, aclk200_fsys, GATE_IP_FSYS, 9, 0, 0),
+ GATE(CLK_MMC0, mmc0, aclk200_fsys2, GATE_IP_FSYS, 12, 0, 0),
+ GATE(CLK_MMC1, mmc1, aclk200_fsys2, GATE_IP_FSYS, 13, 0, 0),
+ GATE(CLK_MMC2, mmc2, aclk200_fsys2, GATE_IP_FSYS, 14, 0, 0),
GATE(CLK_SROMC, sromc, aclk200_fsys2,
- GATE_BUS_FSYS0, 19, CLK_IGNORE_UNUSED, 0),
- GATE(CLK_USBH20, usbh20, aclk200_fsys, GATE_BUS_FSYS0, 20, 0,
0),
- GATE(CLK_USBD300, usbd300, aclk200_fsys, GATE_BUS_FSYS0, 21,
0, 0),
- GATE(CLK_USBD301, usbd301, aclk200_fsys, GATE_BUS_FSYS0, 28,
0, 0),
+ GATE_IP_FSYS, 17, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_USBH20, usbh20, aclk200_fsys, GATE_IP_FSYS, 18, 0,
0),
+ GATE(CLK_USBD300, usbd300, aclk200_fsys, GATE_IP_FSYS, 19, 0,
0),
+ GATE(CLK_USBD301, usbd301, aclk200_fsys, GATE_IP_FSYS, 20, 0,
0),
+ GATE(CLK_SCLK_UNIPRO, sclk_unipro, dout_unipro,
+ GATE_IP_FSYS, 23, CLK_SET_RATE_PARENT, 0),
Gating an SCLK through an GATE_IP_* register looks a bit unusual. The
original entry for this clock had SRC_MASK_FSYS register used. Also there is
the GATE_TOP_SCLK_FSYS register, are you sure that there is no bit for this
clock there?
Thanks for catching this. SRC_MASK_FSYS is the right offset for this clock.
I will update this in next series.
Regards,
Shaik
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 08/15] clk: exynos5420: update clocks for PERIS and GEN blocks
Hi Tomasz,
On Tue, May 6, 2014 at 11:06 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Shaik,
On 06.05.2014 18:26, Shaik Ameer Basha wrote:
This patch fixes some parent-child relationships according
to the latest datasheet and adds more clocks related to
PERIS and GEN blocks.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
Reviewed-by: Alim Akhtar alim.akh...@samsung.com
---
drivers/clk/samsung/clk-exynos5420.c | 81
include/dt-bindings/clock/exynos5420.h |5 ++
2 files changed, 55 insertions(+), 31 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index c86ecbb..af13e6c 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -83,6 +83,7 @@
#define SCLK_DIV_ISP1 0x10584
#define DIV2_RATIO0 0x10590
#define GATE_BUS_TOP 0x10700
+#define GATE_BUS_GEN 0x1073c
#define GATE_BUS_FSYS00x10740
#define GATE_BUS_PERIC0x10750
#define GATE_BUS_PERIC1 0x10754
@@ -96,6 +97,7 @@
#define GATE_IP_G3D 0x10930
#define GATE_IP_GEN 0x10934
#define GATE_IP_PERIC 0x10950
+#define GATE_IP_PERIS 0x10960
#define GATE_IP_MSCL 0x10970
#define GATE_TOP_SCLK_GSCL0x10820
#define GATE_TOP_SCLK_DISP1 0x10828
@@ -172,6 +174,7 @@ static unsigned long exynos5420_clk_regs[] __initdata
= {
SCLK_DIV_ISP1,
DIV2_RATIO0,
GATE_BUS_TOP,
+ GATE_BUS_GEN,
GATE_BUS_FSYS0,
GATE_BUS_PERIC,
GATE_BUS_PERIC1,
@@ -185,6 +188,7 @@ static unsigned long exynos5420_clk_regs[] __initdata
= {
GATE_IP_G3D,
GATE_IP_GEN,
GATE_IP_PERIC,
+ GATE_IP_PERIS,
GATE_IP_MSCL,
GATE_TOP_SCLK_GSCL,
GATE_TOP_SCLK_DISP1,
@@ -608,6 +612,10 @@ static struct samsung_div_clock exynos5420_div_clks[]
__initdata = {
/* MSCL Block */
DIV(0, dout_mscl_blk, aclk400_mscl, DIV2_RATIO0, 28, 2),
+ /* PSGEN */
+ DIV(0, dout_gen_blk, mout_user_aclk266, DIV2_RATIO0, 8, 1),
+ DIV(0, dout_jpg_blk, aclk166, DIV2_RATIO0, 20, 1),
+
/* ISP Block */
DIV(0, dout_isp_sensor0, mout_isp_sensor, SCLK_DIV_ISP0, 8,
8),
DIV(0, dout_isp_sensor1, mout_isp_sensor, SCLK_DIV_ISP0, 16,
8),
@@ -623,10 +631,6 @@ static struct samsung_div_clock exynos5420_div_clks[]
__initdata = {
};
static struct samsung_gate_clock exynos5420_gate_clks[] __initdata = {
- /* TODO: Re-verify the CG bits for all the gate clocks */
- GATE_A(CLK_MCT, pclk_st, aclk66_psgen, GATE_BUS_PERIS1, 2, 0,
0,
- mct),
-
GATE(0, aclk200_fsys, mout_user_aclk200_fsys,
GATE_BUS_FSYS0, 9, CLK_IGNORE_UNUSED, 0),
GATE(0, aclk200_fsys2, mout_user_aclk200_fsys2,
@@ -776,28 +780,51 @@ static struct samsung_gate_clock
exynos5420_gate_clks[] __initdata = {
GATE(CLK_KEYIF, keyif, aclk66_peric, GATE_BUS_PERIC, 22, 0,
0),
+ /* PERIS Block */
GATE(CLK_CHIPID, chipid, aclk66_psgen,
- GATE_BUS_PERIS0, 12, CLK_IGNORE_UNUSED, 0),
+ GATE_IP_PERIS, 0, CLK_IGNORE_UNUSED, 0),
GATE(CLK_SYSREG, sysreg, aclk66_psgen,
- GATE_BUS_PERIS0, 13, CLK_IGNORE_UNUSED, 0),
- GATE(CLK_TZPC0, tzpc0, aclk66_psgen, GATE_BUS_PERIS0, 18, 0,
0),
- GATE(CLK_TZPC1, tzpc1, aclk66_psgen, GATE_BUS_PERIS0, 19, 0,
0),
- GATE(CLK_TZPC2, tzpc2, aclk66_psgen, GATE_BUS_PERIS0, 20, 0,
0),
- GATE(CLK_TZPC3, tzpc3, aclk66_psgen, GATE_BUS_PERIS0, 21, 0,
0),
- GATE(CLK_TZPC4, tzpc4, aclk66_psgen, GATE_BUS_PERIS0, 22, 0,
0),
- GATE(CLK_TZPC5, tzpc5, aclk66_psgen, GATE_BUS_PERIS0, 23, 0,
0),
- GATE(CLK_TZPC6, tzpc6, aclk66_psgen, GATE_BUS_PERIS0, 24, 0,
0),
- GATE(CLK_TZPC7, tzpc7, aclk66_psgen, GATE_BUS_PERIS0, 25, 0,
0),
- GATE(CLK_TZPC8, tzpc8, aclk66_psgen, GATE_BUS_PERIS0, 26, 0,
0),
- GATE(CLK_TZPC9, tzpc9, aclk66_psgen, GATE_BUS_PERIS0, 27, 0,
0),
-
- GATE(CLK_HDMI_CEC, hdmi_cec, aclk66_psgen, GATE_BUS_PERIS1, 0,
0,
- 0),
+ GATE_IP_PERIS, 1, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_TZPC0, tzpc0, aclk66_psgen, GATE_IP_PERIS, 6, 0, 0),
+ GATE(CLK_TZPC1, tzpc1, aclk66_psgen, GATE_IP_PERIS, 7, 0, 0),
+ GATE(CLK_TZPC2, tzpc2, aclk66_psgen, GATE_IP_PERIS, 8, 0, 0),
+ GATE(CLK_TZPC3, tzpc3, aclk66_psgen, GATE_IP_PERIS, 9, 0, 0),
+ GATE(CLK_TZPC4, tzpc4, aclk66_psgen, GATE_IP_PERIS, 10, 0, 0),
+ GATE(CLK_TZPC5, tzpc5, aclk66_psgen, GATE_IP_PERIS, 11, 0, 0),
+ GATE(CLK_TZPC6, tzpc6, aclk66_psgen, GATE_IP_PERIS, 12, 0, 0),
+ GATE(CLK_TZPC7, tzpc7, aclk66_psgen, GATE_IP_PERIS,
Re: [PATCH v4 06/15] clk: exynos5420: update clocks for DISP1 block
Hi Tomasz,
On Tue, May 6, 2014 at 10:48 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Shaik,
On 06.05.2014 18:26, Shaik Ameer Basha wrote:
This patch corrects some child-parent clock relationships,
and updates the clocks according to the latest datasheet.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/clk/samsung/clk-exynos5420.c | 58
++--
include/dt-bindings/clock/exynos5420.h |3 +-
2 files changed, 43 insertions(+), 18 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 5bc4798..9750659 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -61,7 +61,8 @@
#define SRC_TOP10 0x10280
#define SRC_TOP11 0x10284
#define SRC_TOP12 0x10288
-#defineSRC_MASK_DISP10 0x1032c
+#define SRC_MASK_TOP2 0x10308
+#define SRC_MASK_DISP100x1032c
#define SRC_MASK_FSYS 0x10340
#define SRC_MASK_PERIC0 0x10350
#define SRC_MASK_PERIC1 0x10354
@@ -100,6 +101,7 @@
#define GATE_TOP_SCLK_MAU 0x1083c
#define GATE_TOP_SCLK_FSYS0x10840
#define GATE_TOP_SCLK_PERIC 0x10850
+#define TOP_SPARE2 0x10b08
#define BPLL_LOCK 0x20010
#define BPLL_CON0 0x20110
#define SRC_CDREX 0x20200
@@ -146,6 +148,7 @@ static unsigned long exynos5420_clk_regs[] __initdata
= {
SRC_TOP10,
SRC_TOP11,
SRC_TOP12,
+ SRC_MASK_TOP2,
SRC_MASK_DISP10,
SRC_MASK_FSYS,
SRC_MASK_PERIC0,
@@ -186,6 +189,7 @@ static unsigned long exynos5420_clk_regs[] __initdata
= {
GATE_TOP_SCLK_MAU,
GATE_TOP_SCLK_FSYS,
GATE_TOP_SCLK_PERIC,
+ TOP_SPARE2,
SRC_CDREX,
SRC_KFC,
DIV_KFC0,
@@ -252,6 +256,7 @@ PNAME(mout_group3_p) = {mout_sclk_rpll,
mout_sclk_spll};
PNAME(mout_group4_p) = {mout_sclk_ipll, mout_sclk_dpll,
mout_sclk_mpll};
PNAME(mout_group5_p) = {mout_sclk_vpll, mout_sclk_dpll};
+PNAME(mout_fimd1_final_p) = {mout_fimd1, mout_fimd1_opt};
PNAME(mout_sw_aclk66_p) = {dout_aclk66, mout_sclk_spll};
PNAME(mout_aclk66_peric_p)= { fin_pll, mout_sw_aclk66 };
@@ -271,7 +276,7 @@ PNAME(mout_sw_aclk333_432_isp_p) =
{dout_aclk333_432_isp, mout_sclk_spll};
PNAME(mout_user_aclk333_432_isp_p) = {fin_pll,
mout_sw_aclk333_432_isp};
PNAME(mout_sw_aclk200_p) = {dout_aclk200, mout_sclk_spll};
-PNAME(mout_aclk200_disp1_p) = {fin_pll, mout_sw_aclk200};
+PNAME(mout_user_aclk200_disp1_p) = {fin_pll, mout_sw_aclk200};
PNAME(mout_sw_aclk400_mscl_p) = {dout_aclk400_mscl, mout_sclk_spll};
PNAME(mout_user_aclk400_mscl_p) = {fin_pll,
mout_sw_aclk400_mscl};
@@ -293,7 +298,9 @@ PNAME(mout_sw_aclk300_gscl_p) = {dout_aclk300_gscl,
mout_sclk_spll};
PNAME(mout_user_aclk300_gscl_p) = {fin_pll,
mout_sw_aclk300_gscl};
PNAME(mout_sw_aclk300_disp1_p) = {dout_aclk300_disp1,
mout_sclk_spll};
+PNAME(mout_sw_aclk400_disp1_p) = {dout_aclk400_disp1,
mout_sclk_spll};
PNAME(mout_user_aclk300_disp1_p) = {fin_pll, mout_sw_aclk300_disp1};
+PNAME(mout_user_aclk400_disp1_p) = {fin_pll, mout_sw_aclk400_disp1};
PNAME(mout_sw_aclk300_jpeg_p) = {dout_aclk300_jpeg, mout_sclk_spll};
PNAME(mout_user_aclk300_jpeg_p) = {fin_pll, mout_sw_aclk300_jpeg};
@@ -368,6 +375,7 @@ static struct samsung_mux_clock exynos5420_mux_clks[]
__initdata = {
MUX(0, mout_aclk166, mout_group1_p, SRC_TOP1, 24, 2),
MUX(0, mout_aclk333, mout_group1_p, SRC_TOP1, 28, 2),
+ MUX(0, mout_aclk400_disp1, mout_group1_p, SRC_TOP2, 4, 2),
MUX(0, mout_aclk333_g2d, mout_group1_p, SRC_TOP2, 8, 2),
MUX(0, mout_aclk266_g2d, mout_group1_p, SRC_TOP2, 12, 2),
MUX(0, mout_aclk_g3d, mout_group5_p, SRC_TOP2, 16, 1),
@@ -379,7 +387,8 @@ static struct samsung_mux_clock exynos5420_mux_clks[]
__initdata = {
SRC_TOP3, 0, 1),
MUX(0, mout_user_aclk400_mscl, mout_user_aclk400_mscl_p,
SRC_TOP3, 4, 1),
- MUX(0, mout_aclk200_disp1, mout_aclk200_disp1_p, SRC_TOP3, 8,
1),
+ MUX(0, mout_user_aclk200_disp1, mout_user_aclk200_disp1_p,
+ SRC_TOP3, 8, 1),
MUX(0, mout_user_aclk200_fsys2, mout_user_aclk200_fsys2_p,
SRC_TOP3, 12, 1),
MUX(0, mout_user_aclk200_fsys, mout_user_aclk200_fsys_p,
@@ -398,6 +407,8 @@ static struct samsung_mux_clock exynos5420_mux_clks[]
__initdata = {
MUX(0, mout_user_aclk166, mout_user_aclk166_p, SRC_TOP4, 24, 1),
MUX(0, mout_user_aclk333, mout_user_aclk333_p, SRC_TOP4, 28, 1),
+ MUX(0, mout_user_aclk400_disp1, mout_user_aclk400_disp1_p,
+ SRC_TOP5, 0, 1),
MUX(0, mout_aclk66_psgen,
[PATCH] ARM: dts: enable pwm backlight on exynos5250-snow
Add PWM backlight node for exynos5250 and enable the same on exynos5250
based snow board.
Signed-off-by: Olof Johansson o...@lixom.net
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
arch/arm/boot/dts/exynos5250-pinctrl.dtsi |7 +++
arch/arm/boot/dts/exynos5250-snow.dts |5 +
arch/arm/boot/dts/exynos5250.dtsi | 10 ++
3 files changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
index 9a49e68..2a4680c 100644
--- a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
@@ -351,6 +351,13 @@
samsung,pin-drv = 0;
};
+ backlight_pwm: backlight-pwm {
+ samsung,pins = gpb2-0;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
i2c7_bus: i2c7-bus {
samsung,pins = gpb2-2, gpb2-3;
samsung,pin-function = 3;
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 1ce1088..9fcd3e8 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -206,4 +206,9 @@
clock-frequency = 2400;
};
};
+
+ backlight {
+ status = okay;
+ };
+
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 3742331..89a9955 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -593,6 +593,16 @@
clock-names = timers;
};
+ backlight: backlight {
+ compatible = pwm-backlight;
+ pwms = pwm 0 100 0;
+ brightness-levels = 0 100 500 1000 1500 2000 2500 2800;
+ default-brightness-level = 7;
+ pinctrl-0 = backlight_pwm;
+ pinctrl-names = default;
+ status = disabled;
+ };
+
amba {
#address-cells = 1;
#size-cells = 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
Re: [PATCH 3/5] ARM: dts: enable dp-controller for exynos5250 based snow board
Hi Kukjin,
The only dependency for this patch is new property samsung,hpd-gpio which
is acked by Jingoo Han, Maintainer, exynos DP at
http://oascentral.opensubscriber.com/message/dri-de...@lists.freedesktop.org/17150750.html.
All remaining properties are as per existing DT bindings.
@Jingoo, I want to request you to review the dp-controller nodes for
exynos5420 and 5250.
Please consider it for merge.
Regards,
Rahul Sharma.
On 20 April 2014 17:18, Rahul Sharma rahul.sha...@samsung.com wrote:
From: Rahul Sharma rahul.sha...@samsung.com
Ennable dp-controller for snow board.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/boot/dts/exynos5250-snow.dts | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 09f363d..60cc2a8 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -344,6 +344,33 @@
};
};
+ dp-controller@145B {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = dp_hpd;
+ samsung,color-space = 0;
+ samsung,dynamic-range = 0;
+ samsung,ycbcr-coeff = 0;
+ samsung,color-depth = 1;
+ samsung,link-rate = 0x0a;
+ samsung,lane-count = 2;
+ samsung,hpd-gpio = gpx0 7 0;
+ display-timings {
+ native-mode = timing1;
+ timing1: timing@1 {
+ clock-frequency = 70589280;
+ hactive = 1366;
+ vactive = 768;
+ hfront-porch = 40;
+ hback-porch = 40;
+ hsync-len = 32;
+ vback-porch = 10;
+ vfront-porch = 12;
+ vsync-len = 6;
+ };
+ };
+ };
+
fimd@1440 {
status = okay;
samsung,invert-vclk;
--
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: [PATCHv2 1/3] phy: Add exynos-simple-phy driver
On 05/07/2014 12:38 PM, Rahul Sharma wrote: On 5 May 2014 15:14, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Wednesday 09 April 2014 03:31 PM, Sylwester Nawrocki wrote: Hi, On 09/04/14 11:12, Rahul Sharma wrote: Idea looks good. How about keeping compatible which is independent of SoC, something like samsung,exynos-simple-phy and provide Reg and Bit through phy provider node. This way we can avoid SoC specific hardcoding in phy driver and don't need to look into dt bindings for each new SoC. I believe it is a not recommended approach. Why not? We should try to avoid hard coding in the driver code. Moreover by avoiding hardcoding we can make it a generic driver for single bit PHYs. +1. @Tomasz, any plans to consider this approach for simple phy driver? Regards, Rahul Sharma. Hi Rahul, Initially, I wanted to make a very generic driver and to add bit and register (or its offset) attribute to the PHY node. However, there was a very strong opposition from DT maintainers to adding any bit related configuration to DT. The current solution was designed to be a trade-off between being generic and being accepted :). Regards, Tomasz Stanislawski Cheers 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 5/5] ARM: dts: enable dp-controller for exynos5420 based peach-pit board
Hi Kukjin,
I have same update for this patch. The new DT property is Acked at
http://oascentral.opensubscriber.com/message/dri-de...@lists.freedesktop.org/17150750.html
Please consider it for merge.
Regards,
Rahul Sharma.
On 20 April 2014 17:18, Rahul Sharma rahul.sha...@samsung.com wrote:
From: Rahul Sharma rahul.sha...@samsung.com
Enable dp-controller for peach-pit board.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 34
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index d6eaa1f..e6199e1 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -61,6 +61,13 @@
samsung,pin-pud = 1;
samsung,pin-drv = 0;
};
+
+ dp_hpd: dp_hpd {
+ samsung,pins = gpx2-6;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 3;
+ samsung,pin-drv = 0;
+ };
};
pinctrl@1401 {
@@ -249,6 +256,33 @@
status = okay;
};
+ dp-controller@145B {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = dp_hpd;
+ samsung,color-space = 0;
+ samsung,dynamic-range = 0;
+ samsung,ycbcr-coeff = 0;
+ samsung,color-depth = 1;
+ samsung,link-rate = 0x06;
+ samsung,lane-count = 2;
+ samsung,hpd-gpio = gpx2 6 0;
+ display-timings {
+ native-mode = timing1;
+ timing1: timing@1 {
+ clock-frequency = 70589280;
+ hactive = 1366;
+ vactive = 768;
+ hfront-porch = 40;
+ hback-porch = 40;
+ hsync-len = 32;
+ vback-porch = 10;
+ vfront-porch = 12;
+ vsync-len = 6;
+ };
+ };
+ };
+
fimd@1440 {
status = okay;
samsung,invert-vclk;
--
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 2/4] drm/exynos/mixer: use MXR_GRP_SXY_SY
On Wed, May 7, 2014 at 1:14 PM, Seung-Woo Kim sw0312@samsung.com wrote: Hi Daniel, On 2014년 05월 05일 00:26, Daniel Kurtz wrote: Mixer hardware supports offsetting dma from start of source buffer using the MXR_GRP_SXY register. Signed-off-by: Daniel Kurtz djku...@chromium.org --- drivers/gpu/drm/exynos/exynos_mixer.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index 475eb49..40cf39b 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -529,13 +529,11 @@ static void mixer_graph_buffer(struct mixer_context *ctx, int win) dst_x_offset = win_data-crtc_x; dst_y_offset = win_data-crtc_y; + src_x_offset = win_data-fb_x; + src_y_offset = win_data-fb_y; /* converting dma address base and source offset */ - dma_addr = win_data-dma_addr - + (win_data-fb_x * win_data-bpp 3) - + (win_data-fb_y * win_data-fb_width * win_data-bpp 3); - src_x_offset = 0; - src_y_offset = 0; + dma_addr = win_data-dma_addr; Basically, you are right and source offset register can be used. But because of limitation of resolution for mixer up to 1920x1080, I considered modified soruce dma address to set one frame buffer, which is bigger than 1920x1080, on to both fimd and hdmi. Hi Seung-Woo, I do not see why the maximum MIXER resolution matters for choosing between offsetting BASE or using SXY. Let's say you have one big 1920x1908 framebuffer, with a span of 1920, starting at dma_addr (there is no extra padding at the end of the line). Let's say you wanted the mixer to scan out 1920x1080 pixels starting from (0, 800) in the framebuffer, and start drawing them at (0,0) on the screen. What we currently do is: BASE = dma_addr + (800 * 1080 * 4) SPAN = 1920 SXY = SX(0) | SY(0) WH = W(1920) | H(1080) DXY = DX(0) | DY(0) I am proposing we do: BASE = dma_addr SPAN = 1920 SXY = SX(0) | SY(800) WH = W(1920) | H(1080) DXY = DX(0) | DY(0) In both cases, the mixer resolution is 1920x1080. My motivation for wanting to program an un-modified dma_addr into BASE is so we can then just check BASE_S to determine from which buffer the mixer is actively being scanned out without worrying about the source offset, since the source offset can change for a given framebuffer (for example, when doing panning, or if an overlay is used for a HW cursor). Best Regards, -Daniel Regards, - Seung-Woo Kim if (win_data-scan_flags DRM_MODE_FLAG_INTERLACE) ctx-interlace = true; -- Seung-Woo Kim Samsung Software RD Center -- -- 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 1/3] phy: Add exynos-simple-phy driver
On 7 May 2014 19:06, Tomasz Stanislawski t.stanisl...@samsung.com wrote: On 05/07/2014 12:38 PM, Rahul Sharma wrote: On 5 May 2014 15:14, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Wednesday 09 April 2014 03:31 PM, Sylwester Nawrocki wrote: Hi, On 09/04/14 11:12, Rahul Sharma wrote: Idea looks good. How about keeping compatible which is independent of SoC, something like samsung,exynos-simple-phy and provide Reg and Bit through phy provider node. This way we can avoid SoC specific hardcoding in phy driver and don't need to look into dt bindings for each new SoC. I believe it is a not recommended approach. Why not? We should try to avoid hard coding in the driver code. Moreover by avoiding hardcoding we can make it a generic driver for single bit PHYs. +1. @Tomasz, any plans to consider this approach for simple phy driver? Regards, Rahul Sharma. Hi Rahul, Initially, I wanted to make a very generic driver and to add bit and register (or its offset) attribute to the PHY node. However, there was a very strong opposition from DT maintainers to adding any bit related configuration to DT. The current solution was designed to be a trade-off between being generic and being accepted :). Thanks Tomasz, Ok got it. lets discuss it again and conclude it. @Kishon, DT-folks, The original RFC patch from Tomasz (at https://lkml.org/lkml/2013/10/21/313) added simple phy driver as Generic-simple-phy with these properties: + of_property_read_u32(dev-of_node, mask, sphy-mask); + of_property_read_u32(dev-of_node, on-value, sphy-on_value); + of_property_read_u32(dev-of_node, off-value, sphy-off_value); Shall we consider the same solution again for generic simple phy driver which just expose on/off control through register bit. Regards, Rahul Sharma Regards, Tomasz Stanislawski Cheers Kishon ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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 1/3] phy: Add exynos-simple-phy driver
[CCing more DT-folks :)] On 07.05.2014 16:19, Rahul Sharma wrote: On 7 May 2014 19:06, Tomasz Stanislawski t.stanisl...@samsung.com wrote: On 05/07/2014 12:38 PM, Rahul Sharma wrote: On 5 May 2014 15:14, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Wednesday 09 April 2014 03:31 PM, Sylwester Nawrocki wrote: Hi, On 09/04/14 11:12, Rahul Sharma wrote: Idea looks good. How about keeping compatible which is independent of SoC, something like samsung,exynos-simple-phy and provide Reg and Bit through phy provider node. This way we can avoid SoC specific hardcoding in phy driver and don't need to look into dt bindings for each new SoC. I believe it is a not recommended approach. Why not? We should try to avoid hard coding in the driver code. Moreover by avoiding hardcoding we can make it a generic driver for single bit PHYs. +1. @Tomasz, any plans to consider this approach for simple phy driver? Regards, Rahul Sharma. Hi Rahul, Initially, I wanted to make a very generic driver and to add bit and register (or its offset) attribute to the PHY node. However, there was a very strong opposition from DT maintainers to adding any bit related configuration to DT. The current solution was designed to be a trade-off between being generic and being accepted :). Thanks Tomasz, Ok got it. lets discuss it again and conclude it. @Kishon, DT-folks, The original RFC patch from Tomasz (at https://lkml.org/lkml/2013/10/21/313) added simple phy driver as Generic-simple-phy with these properties: + of_property_read_u32(dev-of_node, mask, sphy-mask); + of_property_read_u32(dev-of_node, on-value, sphy-on_value); + of_property_read_u32(dev-of_node, off-value, sphy-off_value); Shall we consider the same solution again for generic simple phy driver which just expose on/off control through register bit. Regards, Rahul Sharma Regards, Tomasz Stanislawski Cheers Kishon ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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 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: [RFC v3 PATCH v6 11/16] ARM: dts: s6e3fa0: add DT bindings
On Wednesday 07 May 2014 10:05:46 YoungJun Cho wrote:
Hi Andrzej
Thank you for comments.
On 05/05/2014 07:35 PM, Andrzej Hajda wrote:
On 04/27/2014 03:50 AM, YoungJun Cho wrote:
This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings and cpu mode
timings.
Changelog v2:
- Adds unit address (commented by Sachin Kamat)
Changelog v3:
- Removes optional delay, size properties (commented by Laurent Pinchart)
- Adds OLED detection, TE gpio properties
Changelog v4:
- Moves CPU timings relevant properties from FIMD DT
(commeted by Laurent Pinchart, Andrzej Hajda)
Changelog v5:
- Fixes gpio property names (commented by Andrzej Hajda)
Changelog v6:
- Renames CPU timings to CPU mode timings
- Modifies CPU mode timings internal properties relevant things
(commeted by Laurent Pinchart, Andrzej Hajda)
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/panel/samsung,s6e3fa0.txt | 68
1 file changed, 68 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..9f06645
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
@@ -0,0 +1,68 @@
+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-gpios: a GPIO spec for the reset pin
+ - det-gpios: a GPIO spec for the OLED detection pin
+ - te-gpios: a GPIO spec for the TE pin
+ - display-timings: timings for the connected panel as described by [1]
This still bothers me, it forces users to provide bunch of fake
properties (four porches, two syncs and clock-frequency) just because we
need to pass somehow pixel width and height. And do we really need pixel
dimension to be passed via DT? I guess it could be:
- hardcoded into the driver,
- derived from the panel id,
- maybe read from the panel, this is the best option I guess but I am
not sure if panel provides an API for this.
I have been trying to only use cpu-mode-timings without display-timings
for next RFC v4.
As you mentioned, the only required things in display-timings are
clock-frequency, hactive and vactive.
I put them into cpu-mode-timings, but strictly speaking,
cpu-mode-timings is not related with display timing, it is data
transmission mode switch timing.
And there is no interface for this in drm (display) mode yet.
So I'm not sure what is the generic method to treat them.
If the sync-related properties are not used, they should not be specified. I
don't really like bundling the timing-related properties with the bus timings
though, I would rather make the sync-related properties optional in the
display timing node.
However, I'm pretty sure that your panel does have horizontal and vertical
blanking, and that information is needed in the display timings to compute the
frame rate accurately. The porch and sync length properties might not be
needed individually, but their total value is required.
+ - cpu-mode-timings: CPU interface timings for the connected panel,
+ and it contains following properties.
+Required properties:
+ - wr-active: clock cycles for the active period of CS enable
in CPU + interface.
+Optional properties:
+ - cs-setup: clock cycles for the active period of address
signal
+ enable until chip select is enable in CPU interface.
+ If not specified, the default value(0) will be used.
+ - wr-setup: clock cycles for the active period of CS signal
enable + until write signal is enable in CPU interface.
+ If not specified, the default value(0) will be used.
+ - wr-hold: clock cycles for the active period of CS disable
until + write signal is disable in CPU interface.
+ If not specified, the default value(0) will be used.
+
+Optional properties:
+
+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@0 {
+ compatible = samsung,s6e3fa0;
+ reg = 0;
+ vdd3-supply = vcclcd_reg;
+ vci-supply = vlcd_reg;
+
Re: [PATCH v2 1/2] ARM: EXYNOS: Map SYSRAM through generic SRAM bindings
On 06.05.2014 20:09, Sachin Kamat wrote:
[snip]
On 6 May 2014 22:14, Tomasz Figa tomasz.f...@gmail.com wrote:
[snip]
On 06.05.2014 10:10, Sachin Kamat wrote:
[snip]
diff --git a/arch/arm/mach-exynos/platsmp.c
b/arch/arm/mach-exynos/platsmp.c
index 03e5e9f94705..ccbcdd7b8a86 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -20,6 +20,7 @@
#include linux/jiffies.h
#include linux/smp.h
#include linux/io.h
+#include linux/of_address.h
#include asm/cacheflush.h
#include asm/smp_plat.h
@@ -33,11 +34,35 @@
extern void exynos4_secondary_startup(void);
+static void __iomem *sram_base_addr;
+void __iomem *sram_ns_base_addr;
This is probably just a matter of preference, but I'd make this static and
provide a getter function, like exynos_get_sram_ns_base();
Also this address seems to be used by the firmware code exclusively. If we
want to make the firmware code more self-contained, maybe the mapping of
firmware-specific SRAM region could be handled there, instead? This would
also eliminate the need for having an exported variable or getter function.
What do you think?
I thought of the same. However 2 reasons prevented me from implementing this.
1. Code duplication
2. This code should be executed only once. I put it in exynos_firmware_init.
However it gave a crash while doing of_iomap. So moved it back to the current
location.
Right, exynos_firmware_init() is called too early, before ioremap() is
available, so there is no good place to put this in firmware code. So,
let's keep this as is for now and eventually move it to firmware if
needed and/or a proper method of initialization is available.
+
+static void __init exynos_smp_prepare_sram(void)
+{
+ struct device_node *node;
+
+ for_each_compatible_node(node, NULL, samsung,exynos4210-sram) {
+ if (of_device_is_available(node)) {
+ sram_base_addr = of_iomap(node, 0);
+ if (!sram_base_addr)
+ pr_err(Secondary CPU boot address not
found\n);
I don't think this is an error at this stage. Some platforms might not have
either of these SRAM reserved regions (such as those using INFORM registers
instead). Instead, the base address should be checked whenever it is needed
and errors should be handled then, like in exynos_set_cpu_boot_addr().
Yes. This is more from an information perspective. Probably pr_warn or
pr_info would
be better?
IMHO this shouldn't produce any messages at this stage. Just whenever
either of addresses is actually needed and is not initialized a message
should be printed.
+}
+
static inline void __iomem *cpu_boot_reg_base(void)
{
if (soc_is_exynos4210() samsung_rev() == EXYNOS4210_REV_1_1)
return S5P_INFORM5;
- return S5P_VA_SYSRAM;
+ return sram_base_addr;
}
static inline void __iomem *cpu_boot_reg(int cpu)
@@ -147,7 +172,8 @@ static int exynos_boot_secondary(unsigned int cpu,
struct task_struct *idle)
* and fall back to boot register if it fails.
*/
if (call_firmware_op(set_cpu_boot_addr, phys_cpu,
boot_addr))
- __raw_writel(boot_addr, cpu_boot_reg(phys_cpu));
+ if (cpu_boot_reg_base())
+ __raw_writel(boot_addr,
cpu_boot_reg(phys_cpu));
I'd rework this for proper error handling, e.g.
int ret;
/* ... */
ret = call_firmware_op(set_cpu_boot_addr, phys_cpu, boot_addr);
if (ret ret != -ENOSYS)
goto fail;
if (ret == -ENOSYS) {
/* Fall back to firmware-less way. */
void __iomem *boot_reg = cpu_boot_reg(phys_cpu);
if (IS_ERR(boot_reg)) {
ret = PTR_ERR(boot_reg);
goto fail;
}
}
/* ... */
fail:
/* Clean-up after error */
Of course, cpu_boot_reg() will need to be converted to follow the ERR_PTR()
model, but IMHO proper error handling is a good reason to do so.
How about handling this separately outside this patch?
This patch is already changing surroundings of this code, so I'd say it
should do it the right way from the start.
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] net: sxgbe: Added condition for non fix_burst mode
Please start numbering your patches and submit patch sets properly.
You need to provide:
1) A header posting with subject [PATCH 0/${N}] blah blah blah
that describes at a high level what the patch series does.
2) The patches, in the correct order, numbered in the subject
line in the format [PATCH X/${N}] ...
Otherwise I have no idea what order the patches are supposed
to be applied, whether the patches depend upon eachother, and
if so in what way.
I'm not applying these sxgbe patches until you start posting
them properly, thank you.
--
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 14/15] clk: exynos5420: add misc clocks
On 07.05.2014 14:00, Shaik Ameer Basha wrote:
Hi Tomasz,
On Tue, May 6, 2014 at 11:19 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Shaik,
On 06.05.2014 18:26, Shaik Ameer Basha wrote:
This patch adds some missing miscellaneous clocks specific
to exynos5420.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
drivers/clk/samsung/clk-exynos5420.c | 14 +++---
include/dt-bindings/clock/exynos5420.h |2 ++
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index e0e749d..e69e820 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -273,7 +273,8 @@ PNAME(mout_group5_p) = {mout_sclk_vpll,
mout_sclk_dpll};
PNAME(mout_fimd1_final_p) = {mout_fimd1, mout_fimd1_opt};
PNAME(mout_sw_aclk66_p) = {dout_aclk66, mout_sclk_spll};
-PNAME(mout_user_aclk66_peric_p)= { fin_pll, mout_sw_aclk66 };
+PNAME(mout_user_aclk66_peric_p)= { fin_pll, mout_sw_aclk66};
+PNAME(mout_user_pclk66_gpio_p) = {mout_sw_aclk66, ffactor_sw_aclk66};
PNAME(mout_sw_aclk200_fsys_p) = {dout_aclk200_fsys, mout_sclk_spll};
PNAME(mout_sw_pclk200_fsys_p) = {dout_pclk200_fsys, mout_sclk_spll};
@@ -372,10 +373,13 @@ static struct samsung_fixed_rate_clock
exynos5420_fixed_rate_clks[] __initdata =
};
static struct samsung_fixed_factor_clock exynos5420_fixed_factor_clks[]
__initdata = {
- FFACTOR(0, sclk_hsic_12m, fin_pll, 1, 2, 0),
+ FFACTOR(0, ffactor_hsic_12m, fin_pll, 1, 2, 0),
+ FFACTOR(0, ffactor_sw_aclk66, mout_sw_aclk66, 1, 2, 0),
Is the ffactor_ prefix also present in the datasheet? If not, it should be
removed from clock names as well.
Its not there in manual.
As we are differentiating muxes and dividers with mout and dout
this prefix is added
to differentiate fixed factor clocks.
shall I keep it or not?
mout and div prefixes are also used in documentation, at least in case
of previous Exynos SoCs. In case of Exynos5420 I can see CLKDIV_ prefix
used for dividers, so after stripping the CLK part which is simply
redundant, we are left with div_ prefix as in Exynos4 - not sure why in
Exynos5420 driver dout_ prefix was used, I must have missed that in
review, but I simply didn't have any the documentation for this chip at
that time.
I don't see those hsic_12m and sw_aclk66 clocks in my version of the
datasheet (probably an old version) so I can't say what would be the
proper names for both, but I wouldn't add ffactor_ there.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] ARM: EXYNOS: Map SYSRAM through generic SRAM bindings
Hi Tomasz,
On 7 May 2014 22:33, Tomasz Figa t.f...@samsung.com wrote:
On 06.05.2014 20:09, Sachin Kamat wrote:
[snip]
On 6 May 2014 22:14, Tomasz Figa tomasz.f...@gmail.com wrote:
[snip]
On 06.05.2014 10:10, Sachin Kamat wrote:
[snip]
diff --git a/arch/arm/mach-exynos/platsmp.c
b/arch/arm/mach-exynos/platsmp.c
index 03e5e9f94705..ccbcdd7b8a86 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -20,6 +20,7 @@
#include linux/jiffies.h
#include linux/smp.h
#include linux/io.h
+#include linux/of_address.h
#include asm/cacheflush.h
#include asm/smp_plat.h
@@ -33,11 +34,35 @@
extern void exynos4_secondary_startup(void);
+static void __iomem *sram_base_addr;
+void __iomem *sram_ns_base_addr;
This is probably just a matter of preference, but I'd make this static and
provide a getter function, like exynos_get_sram_ns_base();
Also this address seems to be used by the firmware code exclusively. If we
want to make the firmware code more self-contained, maybe the mapping of
firmware-specific SRAM region could be handled there, instead? This would
also eliminate the need for having an exported variable or getter function.
What do you think?
I thought of the same. However 2 reasons prevented me from implementing this.
1. Code duplication
2. This code should be executed only once. I put it in exynos_firmware_init.
However it gave a crash while doing of_iomap. So moved it back to the current
location.
Right, exynos_firmware_init() is called too early, before ioremap() is
available, so there is no good place to put this in firmware code. So,
let's keep this as is for now and eventually move it to firmware if
needed and/or a proper method of initialization is available.
OK.
+
+static void __init exynos_smp_prepare_sram(void)
+{
+ struct device_node *node;
+
+ for_each_compatible_node(node, NULL, samsung,exynos4210-sram) {
+ if (of_device_is_available(node)) {
+ sram_base_addr = of_iomap(node, 0);
+ if (!sram_base_addr)
+ pr_err(Secondary CPU boot address not
found\n);
I don't think this is an error at this stage. Some platforms might not have
either of these SRAM reserved regions (such as those using INFORM registers
instead). Instead, the base address should be checked whenever it is needed
and errors should be handled then, like in exynos_set_cpu_boot_addr().
Yes. This is more from an information perspective. Probably pr_warn or
pr_info would
be better?
IMHO this shouldn't produce any messages at this stage. Just whenever
either of addresses is actually needed and is not initialized a message
should be printed.
OK.
+}
+
static inline void __iomem *cpu_boot_reg_base(void)
{
if (soc_is_exynos4210() samsung_rev() == EXYNOS4210_REV_1_1)
return S5P_INFORM5;
- return S5P_VA_SYSRAM;
+ return sram_base_addr;
}
static inline void __iomem *cpu_boot_reg(int cpu)
@@ -147,7 +172,8 @@ static int exynos_boot_secondary(unsigned int cpu,
struct task_struct *idle)
* and fall back to boot register if it fails.
*/
if (call_firmware_op(set_cpu_boot_addr, phys_cpu,
boot_addr))
- __raw_writel(boot_addr, cpu_boot_reg(phys_cpu));
+ if (cpu_boot_reg_base())
+ __raw_writel(boot_addr,
cpu_boot_reg(phys_cpu));
I'd rework this for proper error handling, e.g.
int ret;
/* ... */
ret = call_firmware_op(set_cpu_boot_addr, phys_cpu, boot_addr);
if (ret ret != -ENOSYS)
goto fail;
if (ret == -ENOSYS) {
/* Fall back to firmware-less way. */
void __iomem *boot_reg = cpu_boot_reg(phys_cpu);
if (IS_ERR(boot_reg)) {
ret = PTR_ERR(boot_reg);
goto fail;
}
}
/* ... */
fail:
/* Clean-up after error */
Of course, cpu_boot_reg() will need to be converted to follow the ERR_PTR()
model, but IMHO proper error handling is a good reason to do so.
How about handling this separately outside this patch?
This patch is already changing surroundings of this code, so I'd say it
should do it the right way from the start.
Yes, I have incorporated it in my patch. Will send the same tomorrow.
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: sxgbe: Added tail point update
2014-05-07 1:14 GMT-07:00 Byungho An bh74...@samsung.com:
This patch adds tail point update function for rx path
after rx_refill function. It indicates tail point for rx dma.
Signed-off-by: Byungho An bh74...@samsung.com
---
drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c | 14 +-
drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h |4
drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c |5 +
3 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c
index 49240c9..249b0e0 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c
@@ -112,7 +112,7 @@ static void sxgbe_dma_channel_init(void __iomem *ioaddr,
int cha_num,
dma_addr = dma_rx + ((r_rsize - 1) * SXGBE_DESC_SIZE_BYTES);
writel(lower_32_bits(dma_addr),
- ioaddr + SXGBE_DMA_CHA_RXDESC_LADD_REG(cha_num));
+ ioaddr + SXGBE_DMA_CHA_RXDESC_TAILPTR_REG(cha_num));
/* program the ring sizes */
writel(t_rsize - 1, ioaddr +
SXGBE_DMA_CHA_TXDESC_RINGLEN_REG(cha_num));
writel(r_rsize - 1, ioaddr +
SXGBE_DMA_CHA_RXDESC_RINGLEN_REG(cha_num));
@@ -370,6 +370,17 @@ static void sxgbe_enable_tso(void __iomem *ioaddr, u8
chan_num)
writel(ctrl, ioaddr + SXGBE_DMA_CHA_TXCTL_REG(chan_num));
}
+static void sxgbe_dma_update_rxdesc_tail_ptr(void __iomem *ioaddr, u8
chan_num,
+ dma_addr_t dma_rx_phy, int
cur_rx,
+ int rxsize)
I think that at some point you should revisit your abstraction, all
the patches that I see do take a void __iomem * argument as the first
function argument, you should probably use your driver private context
here. The day you support a different version of the hardware, there
might be other differences that need to be taken care of.
+{
+ u32 reg_val;
+
+ reg_val = (dma_rx_phy 0x) + ((cur_rx % rxsize) *
+ SXGBE_DESC_SIZE_BYTES);
+ writel(reg_val, ioaddr + SXGBE_DMA_CHA_RXDESC_TAILPTR_REG(chan_num));
+}
+
static const struct sxgbe_dma_ops sxgbe_dma_ops = {
.init = sxgbe_dma_init,
.cha_init = sxgbe_dma_channel_init,
@@ -386,6 +397,7 @@ static const struct sxgbe_dma_ops sxgbe_dma_ops = {
.rx_dma_int_status = sxgbe_rx_dma_int_status,
.rx_watchdog= sxgbe_dma_rx_watchdog,
.enable_tso = sxgbe_enable_tso,
+ .update_rxdesc_tail_ptr = sxgbe_dma_update_rxdesc_tail_ptr,
};
const struct sxgbe_dma_ops *sxgbe_get_dma_ops(void)
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h
index 843fa9b..a06e01e 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h
@@ -43,6 +43,10 @@ struct sxgbe_dma_ops {
void (*rx_watchdog)(void __iomem *ioaddr, u32 riwt);
/* Enable TSO for each DMA channel */
void (*enable_tso)(void __iomem *ioaddr, u8 chan_num);
+ void (*update_rxdesc_tail_ptr)(void __iomem *ioaddr, u8 chan_num,
+ dma_addr_t dma_rx, int r_rentry,
+ int r_rsize);
+
};
const struct sxgbe_dma_ops *sxgbe_get_dma_ops(void);
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
index 93bf151..7dc3449 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
@@ -1521,6 +1521,7 @@ static int sxgbe_rx(struct sxgbe_priv_data *priv, int
limit)
skb_put(skb, frame_len);
skb-ip_summed = checksum;
+ skb-protocol = eth_type_trans(skb, priv-dev);
if (checksum == CHECKSUM_NONE)
netif_receive_skb(skb);
else
@@ -1530,6 +1531,10 @@ static int sxgbe_rx(struct sxgbe_priv_data *priv, int
limit)
}
sxgbe_rx_refill(priv);
+ priv-hw-dma-update_rxdesc_tail_ptr(priv-ioaddr, qnum,
+ priv-rxq[qnum]-dma_rx_phy,
+ priv-rxq[qnum]-cur_rx,
+ priv-dma_rx_size);
return count;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Florian
--
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
Re: [PATCH] ARM: dts: enable pwm backlight on exynos5250-snow
Hi Ajay,
On 07.05.2014 14:56, Ajay Kumar wrote:
Add PWM backlight node for exynos5250 and enable the same on exynos5250
based snow board.
Signed-off-by: Olof Johansson o...@lixom.net
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
arch/arm/boot/dts/exynos5250-pinctrl.dtsi |7 +++
arch/arm/boot/dts/exynos5250-snow.dts |5 +
arch/arm/boot/dts/exynos5250.dtsi | 10 ++
3 files changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
index 9a49e68..2a4680c 100644
--- a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
@@ -351,6 +351,13 @@
samsung,pin-drv = 0;
};
+ backlight_pwm: backlight-pwm {
+ samsung,pins = gpb2-0;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
This looks like a generic PWM output function, not specific to backlight
in any way.
Please see patch [1] adding PWM output pin groups for Exynos5420 for
reference.
[1]
https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg29869.html
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: enable pwm backlight on exynos5250-snow
On 07.05.2014 22:47, Ajay kumar wrote:
Tomasz,
On Thu, May 8, 2014 at 2:04 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Ajay,
On 07.05.2014 14:56, Ajay Kumar wrote:
Add PWM backlight node for exynos5250 and enable the same on exynos5250
based snow board.
Signed-off-by: Olof Johansson o...@lixom.net
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
arch/arm/boot/dts/exynos5250-pinctrl.dtsi |7 +++
arch/arm/boot/dts/exynos5250-snow.dts |5 +
arch/arm/boot/dts/exynos5250.dtsi | 10 ++
3 files changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
index 9a49e68..2a4680c 100644
--- a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
@@ -351,6 +351,13 @@
samsung,pin-drv = 0;
};
+ backlight_pwm: backlight-pwm {
+ samsung,pins = gpb2-0;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
This looks like a generic PWM output function, not specific to backlight in
any way.
Please see patch [1] adding PWM output pin groups for Exynos5420 for
reference.
[1]
https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg29869.html
Right! I just referred to the manual again, and it actually reads TOUT_0.
So, I should be probably renaming this as pwm0_out like in the other patch?
Yes, please. You should also add remaining ones, while at it. Basically
same patch as [1] but for Exynos5250.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: enable pwm backlight on exynos5250-snow
Tomasz,
On Thu, May 8, 2014 at 2:04 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Ajay,
On 07.05.2014 14:56, Ajay Kumar wrote:
Add PWM backlight node for exynos5250 and enable the same on exynos5250
based snow board.
Signed-off-by: Olof Johansson o...@lixom.net
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
arch/arm/boot/dts/exynos5250-pinctrl.dtsi |7 +++
arch/arm/boot/dts/exynos5250-snow.dts |5 +
arch/arm/boot/dts/exynos5250.dtsi | 10 ++
3 files changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
index 9a49e68..2a4680c 100644
--- a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
@@ -351,6 +351,13 @@
samsung,pin-drv = 0;
};
+ backlight_pwm: backlight-pwm {
+ samsung,pins = gpb2-0;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
This looks like a generic PWM output function, not specific to backlight in
any way.
Please see patch [1] adding PWM output pin groups for Exynos5420 for
reference.
[1]
https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg29869.html
Right! I just referred to the manual again, and it actually reads TOUT_0.
So, I should be probably renaming this as pwm0_out like in the other patch?
Ajay
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Add atmel trackpad node to 5250 cros
Tomasz,
On Thu, Apr 24, 2014 at 9:57 AM, Tomasz Figa t.f...@samsung.com wrote:
Hi Arun,
On 14.04.2014 08:35, Arun Kumar K wrote:
The newer versions of exynos5250 based Snow boards have
atmel trackpad. Updating relevant nodes for the same.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
arch/arm/boot/dts/exynos5250-cros-common.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
index 2c1560d..658f086 100644
--- a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
@@ -28,6 +28,13 @@
samsung,pin-pud = 0;
};
+ trackpad_irq: trackpad-irq {
+ samsung,pins = gpx1-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
max77686_irq: max77686-irq {
samsung,pins = gpx3-2;
samsung,pin-function = 0;
@@ -191,6 +198,9 @@
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 378000;
+ pinctrl-names = default;
+ pinctrl-0 = i2c1_bus trackpad_irq;
Please add trackpad_irq to trackpad node instead. Pinctrl properties of i2c
node should contain only i2c-related pins.
This was a workaround for a limitation of the i2c subsystem which need
to be fixed before atmel support can land upstream.
The problem is that there are two sources for the trackpad on this
hardware. They are pin compatible, so some boards may have one
trackpad and other (mostly newer) boards may have the other.
The i2c bus is probable, so the theory is that you can just specify
both of trackpads and one will fail to be found. The problem (at
least on 3.8) was that the pinctrl subsystem held onto the pins. :(
I just tried now to see if I could reproduce this on ToT. ...and it
turns out that the atmel_mxt_ts doesn't support device tree upstream.
Right at the top of mxt_probe I see:
if (!pdata)
return -EINVAL;
I actually find a patch (from you!) that adds some device tree support
at https://patchwork.kernel.org/patch/2393631/. ...though
interestingly enough our current tree somehow gets by without
specifying all of those properties. +Benson may be able to give more
details?
Until atmel device tree support lands, though, I think this patch is stalled.
+ reg = 0x25;
+ compatible = atmel,atmel_mxt_tp;
+ interrupts = 2 0;
+ interrupt-parent = gpx1;
+ wakeup-source;
+ };
Hmm, why are there 3 different nodes here? Could you explain what one by one
for what hardware they are?
cyapa: the Cypress trackpad that shipped with original exynos5250-snow
atmel: some newer exynos5250-snow ship with this
atmel-bootloader: appears to be a hack to get around the fact that you
can only specify one i2c address through the device tree. I'm told
that sometimes this device shows up at a different address. On x86
machines with this they use i2c_new_probed_device which allows you
to pass in a list of addresses, it seems. I'm not sure how this
should really translate to the device tree.
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3 PATCH v6 11/16] ARM: dts: s6e3fa0: add DT bindings
Hi Laurent,
Thank you for comments.
On 05/08/2014 01:00 AM, Laurent Pinchart wrote:
On Wednesday 07 May 2014 10:05:46 YoungJun Cho wrote:
Hi Andrzej
Thank you for comments.
On 05/05/2014 07:35 PM, Andrzej Hajda wrote:
On 04/27/2014 03:50 AM, YoungJun Cho wrote:
This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings and cpu mode
timings.
Changelog v2:
- Adds unit address (commented by Sachin Kamat)
Changelog v3:
- Removes optional delay, size properties (commented by Laurent Pinchart)
- Adds OLED detection, TE gpio properties
Changelog v4:
- Moves CPU timings relevant properties from FIMD DT
(commeted by Laurent Pinchart, Andrzej Hajda)
Changelog v5:
- Fixes gpio property names (commented by Andrzej Hajda)
Changelog v6:
- Renames CPU timings to CPU mode timings
- Modifies CPU mode timings internal properties relevant things
(commeted by Laurent Pinchart, Andrzej Hajda)
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/panel/samsung,s6e3fa0.txt | 68
1 file changed, 68 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..9f06645
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
@@ -0,0 +1,68 @@
+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-gpios: a GPIO spec for the reset pin
+ - det-gpios: a GPIO spec for the OLED detection pin
+ - te-gpios: a GPIO spec for the TE pin
+ - display-timings: timings for the connected panel as described by [1]
This still bothers me, it forces users to provide bunch of fake
properties (four porches, two syncs and clock-frequency) just because we
need to pass somehow pixel width and height. And do we really need pixel
dimension to be passed via DT? I guess it could be:
- hardcoded into the driver,
- derived from the panel id,
- maybe read from the panel, this is the best option I guess but I am
not sure if panel provides an API for this.
I have been trying to only use cpu-mode-timings without display-timings
for next RFC v4.
As you mentioned, the only required things in display-timings are
clock-frequency, hactive and vactive.
I put them into cpu-mode-timings, but strictly speaking,
cpu-mode-timings is not related with display timing, it is data
transmission mode switch timing.
And there is no interface for this in drm (display) mode yet.
So I'm not sure what is the generic method to treat them.
If the sync-related properties are not used, they should not be specified. I
don't really like bundling the timing-related properties with the bus timings
though, I would rather make the sync-related properties optional in the
display timing node.
Yes, I agree with you.
So in RFC v4, I used cmdmode-display-timings instead of display-timings
and cpu-mode-timings.
Please refer to http://www.spinics.net/lists/dri-devel/msg58916.html.
However, I'm pretty sure that your panel does have horizontal and vertical
blanking, and that information is needed in the display timings to compute the
Yes, this is also right.
However the horizontal / vertical blanking and relevant porch times are
calculated by command mode panel inside.
The command mode panel has a internal graphic ram and shows(refreshes)
it by itself. So the only thing the user(display controller) has to do
is to transfer video data to update the internal graphic ram in TE
signal time.
frame rate accurately. The porch and sync length properties might not be
needed individually, but their total value is required.
Yes, the total values are required to drm display mode.
So I did like below command mode helper function.
+int drm_display_mode_from_cmdmode(const struct cmdmode *cm,
+ struct drm_display_mode *dmode)
+{
+ dmode-hdisplay = cm-hactive;
+ dmode-htotal = dmode-hsync_end = dmode-hsync_start = dmode-hdisplay;
+
+ dmode-vdisplay = cm-vactive;
+ dmode-vtotal = dmode-vsync_end = dmode-vsync_start = dmode-vdisplay;
+
+ dmode-clock = cm-pixelclock / 1000;
+
+ dmode-cs_setup = cm-cs_setup;
+ dmode-wr_setup = cm-wr_setup;
+ dmode-wr_active = cm-wr_active;
+ dmode-wr_hold = cm-wr_hold;
+
+ dmode-flags = 0;
+ drm_mode_set_name(dmode);
+
+ return 0;
+}
Please refer to http://www.spinics.net/lists/dri-devel/msg58909.html
Thank you.
Best regards YJ
+ - cpu-mode-timings: CPU interface timings for the connected panel,
+ and it contains
RE: [PATCH] net: sxgbe: Added condition for non fix_burst mode
David Miller wrote:
Please start numbering your patches and submit patch sets properly.
You need to provide:
1) A header posting with subject [PATCH 0/${N}] blah blah blah
that describes at a high level what the patch series does.
2) The patches, in the correct order, numbered in the subject
line in the format [PATCH X/${N}] ...
Otherwise I have no idea what order the patches are supposed
to be applied, whether the patches depend upon eachother, and
if so in what way.
I'm not applying these sxgbe patches until you start posting
them properly, thank you.
Ok, I'll repost patches
--
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] net: sxgbe: Added tail point update
Florian Fainelli wrote: 2014-05-07 1:14 GMT-07:00 Byungho An bh74...@samsung.com: This patch adds tail point update function for rx path after rx_refill function. It indicates tail point for rx dma. Signed-off-by: Byungho An bh74...@samsung.com --- drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c | 14 +- drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h |4 drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c |5 + 3 files changed, 22 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c index 49240c9..249b0e0 100644 --- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c +++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c @@ -112,7 +112,7 @@ static void sxgbe_dma_channel_init(void __iomem *ioaddr, int cha_num, dma_addr = dma_rx + ((r_rsize - 1) * SXGBE_DESC_SIZE_BYTES); writel(lower_32_bits(dma_addr), - ioaddr + SXGBE_DMA_CHA_RXDESC_LADD_REG(cha_num)); + ioaddr + SXGBE_DMA_CHA_RXDESC_TAILPTR_REG(cha_num)); /* program the ring sizes */ writel(t_rsize - 1, ioaddr + SXGBE_DMA_CHA_TXDESC_RINGLEN_REG(cha_num)); writel(r_rsize - 1, ioaddr + SXGBE_DMA_CHA_RXDESC_RINGLEN_REG(cha_num)); @@ -370,6 +370,17 @@ static void sxgbe_enable_tso(void __iomem *ioaddr, u8 chan_num) writel(ctrl, ioaddr + SXGBE_DMA_CHA_TXCTL_REG(chan_num)); } +static void sxgbe_dma_update_rxdesc_tail_ptr(void __iomem *ioaddr, u8 chan_num, + dma_addr_t dma_rx_phy, int cur_rx, + int rxsize) I think that at some point you should revisit your abstraction, all the patches that I see do take a void __iomem * argument as the first function argument, you should probably use your driver private context here. The day you support a different version of the hardware, there might be other differences that need to be taken care of. I agree with you, it would be more robust for different version of the hardware and make simple function argument. But most functions of this driver deal with read/write register using ioaddr. As of now I think it is enough but I'll consider it later. [snip] -- Florian -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] ARM: dts: enable hdmi for exynos5250 based snow board
Thanks Tushar,
On 28 April 2014 12:00, Tushar Behera tushar.beh...@linaro.org wrote:
On 04/20/2014 04:54 PM, Rahul Sharma wrote:
From: Rahul Sharma rahul.sha...@samsung.com
Enable support for HDMI for exynos5250 based Snow board.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
arch/arm/boot/dts/exynos5250-cros-common.dtsi | 13 -
arch/arm/boot/dts/exynos5250-snow.dts |7 +++
2 files changed, 19 insertions(+), 1 deletion(-)
[ ... ]
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 52ae335..586cd38 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -343,4 +343,11 @@
pinctrl-0 = ptn3460_gpios;
};
};
+
+ hdmi {
+ hdmi-en-supply = tps65090_fet7;
Looks like tps65090_fet7 is not defined yet or might be not mentioned as
dependency.
I should have mentioned one more dependency on Sachin's patches for
snow DTS.( https://patches.linaro.org/28325/ ). Sorry for confusion.
Regards,
Rahul Sharma.
+ vdd-supply = ldo8_reg;
+ vdd_osc-supply = ldo10_reg;
+ vdd_pll-supply = ldo8_reg;
+ };
};
--
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
[PATCH v4 0/4] Introduce new Kconfig for Samsung common clock
Introduce a new Kconfig file for Samsung common clock infrastructure related config options. As current Samsung common clock gets compiled based on PLAT_SAMSUNG, but moving ahead with ARM64 we can not have any more such config options, so this patch introduce new COMMON_CLK_SAMSUNG invisible option. This option also select COMMON_CLK so ARCH Kconfig just need to select COMMON_CLK_SAMSUNG in case they want to use Samsung common clock. This series is based on Kukjin's for-next branch. I am just respinning this patch after rebasing. I have already addressed all review comments discussed here [1]. [1]: http://lkml.org/lkml/2014/3/19/216 V4: 1) Rebased on latest Kukjin's for-next branch. V3: 1) Re-organized patches for preventing bisect issues. 2) Rebase on top of latest Kukjin's for-next branch. 3) Compile tested exynos_defconfig, s3c6400_defconfig and s3c2410_defconfig after each commit. V2: 1) Adding new Kconfig file for Samsung common clock. 2) Make COMMON_CLK_SAMSUNG option invisible. (as suggested by Tomasz Figa) 3) Let COMMON_CLK_SAMSUNG select COMMON_CLK. (as suggested by Tomasz Figa) 4) Move S3C24XX clock config option in new Kconfig file. Pankaj Dubey (4): clk: samsung: add new Kconfig for Samsung common clock option ARM: select COMMON_CLK_SAMSUNG for ARCH_EXYNOS and ARCH_S3C64XX ARM: S3C24XX: move S3C24XX clock Kconfig options to Samsung clock Kconfig file drivers: clk: use COMMON_CLK_SAMSUNG for Samsung clock support arch/arm/Kconfig |4 ++-- arch/arm/mach-s3c24xx/Kconfig | 14 -- drivers/clk/Kconfig |2 ++ drivers/clk/Makefile |2 +- drivers/clk/samsung/Kconfig | 12 5 files changed, 17 insertions(+), 17 deletions(-) create mode 100644 drivers/clk/samsung/Kconfig -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/4] clk: samsung: add new Kconfig for Samsung common clock option
This patch adds new Kconfig file for adding new COMMON_CLK_SAMSUNG option. Samsung platforms can select this for using common clock infrastructure. CC: Mike Turquette mturque...@linaro.org Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- drivers/clk/Kconfig |2 ++ drivers/clk/samsung/Kconfig |3 +++ 2 files changed, 5 insertions(+) create mode 100644 drivers/clk/samsung/Kconfig diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 6f56d3a..ba24366 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -115,3 +115,5 @@ endmenu source drivers/clk/bcm/Kconfig source drivers/clk/mvebu/Kconfig + +source drivers/clk/samsung/Kconfig diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig new file mode 100644 index 000..fc8696b --- /dev/null +++ b/drivers/clk/samsung/Kconfig @@ -0,0 +1,3 @@ +config COMMON_CLK_SAMSUNG + bool + select COMMON_CLK -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/4] ARM: S3C24XX: move S3C24XX clock Kconfig options to Samsung clock Kconfig file
This patch moves S3C24XX specific clock Kconfig options into clk/samsung/Kconfig and also removes COMMON_CLK selection from mach-s3c24xx/Kconfig as S3C24XX_COMMON_CLK is selecting it's dependency. CC: Ben Dooks ben-li...@fluff.org CC: Kukjin Kim kgene@samsung.com CC: Russell King li...@arm.linux.org.uk Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/mach-s3c24xx/Kconfig | 14 -- drivers/clk/samsung/Kconfig |9 + 2 files changed, 9 insertions(+), 14 deletions(-) diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig index fbafb9a..e645ece 100644 --- a/arch/arm/mach-s3c24xx/Kconfig +++ b/arch/arm/mach-s3c24xx/Kconfig @@ -39,7 +39,6 @@ config CPU_S3C2410 config CPU_S3C2412 bool SAMSUNG S3C2412 - select COMMON_CLK select CPU_ARM926T select CPU_LLSERIAL_S3C2440 select S3C2412_COMMON_CLK @@ -50,7 +49,6 @@ config CPU_S3C2412 config CPU_S3C2416 bool SAMSUNG S3C2416/S3C2450 - select COMMON_CLK select CPU_ARM926T select CPU_LLSERIAL_S3C2440 select S3C2416_PM if PM @@ -88,7 +86,6 @@ config CPU_S3C244X config CPU_S3C2443 bool SAMSUNG S3C2443 - select COMMON_CLK select CPU_ARM920T select CPU_LLSERIAL_S3C2440 select S3C2443_COMMON_CLK @@ -364,11 +361,6 @@ config S3C2412_PM_SLEEP if CPU_S3C2412 -config S3C2412_COMMON_CLK - bool - help - Build the s3c2412 clock driver based on the common clock framework. - config CPU_S3C2412_ONLY bool depends on !CPU_S3C2410 !CPU_S3C2416 !CPU_S3C2440 \ @@ -651,12 +643,6 @@ endif # CPU_S3C2442 if CPU_S3C2443 || CPU_S3C2416 -config S3C2443_COMMON_CLK - bool - help - Temporary symbol to build the clock driver based on the common clock - framework. - config S3C2443_DMA bool help diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig index fc8696b..baf28cb 100644 --- a/drivers/clk/samsung/Kconfig +++ b/drivers/clk/samsung/Kconfig @@ -1,3 +1,12 @@ config COMMON_CLK_SAMSUNG bool select COMMON_CLK + +config S3C2412_COMMON_CLK + bool + select COMMON_CLK_SAMSUNG + +config S3C2443_COMMON_CLK + bool + select COMMON_CLK_SAMSUNG + -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/4] ARM: select COMMON_CLK_SAMSUNG for ARCH_EXYNOS and ARCH_S3C64XX
This patch selects COMMON_CLK_SAMSUNG for EXYNOS and S3C64XX SoC and removes COMMON_CLK selection as COMMON_CLK_SAMSUNG selects it's dependency. CC: Russell King li...@arm.linux.org.uk Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index ab438cb..0edb868 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -754,7 +754,7 @@ config ARCH_S3C64XX select ATAGS select CLKDEV_LOOKUP select CLKSRC_SAMSUNG_PWM - select COMMON_CLK + select COMMON_CLK_SAMSUNG select CPU_V6K select GENERIC_CLOCKEVENTS select GPIO_SAMSUNG @@ -835,7 +835,7 @@ config ARCH_EXYNOS select ARCH_REQUIRE_GPIOLIB select ARCH_SPARSEMEM_ENABLE select ARM_GIC - select COMMON_CLK + select COMMON_CLK_SAMSUNG select CPU_V7 select GENERIC_CLOCKEVENTS select HAVE_S3C2410_I2C if I2C -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/4] drivers: clk: use COMMON_CLK_SAMSUNG for Samsung clock support
This patch replaces PLAT_SAMSUNG with COMMON_CLK_SAMSUNG for Samsung common clock support. Any Samsung SoC want to use Samsung common clock infrastructure can simply select COMMON_CLK_SAMSUNG. CC: Mike Turquette mturque...@linaro.org Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- drivers/clk/Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index 5f8a287..17d7f13 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -41,7 +41,7 @@ obj-$(CONFIG_PLAT_ORION) += mvebu/ obj-$(CONFIG_ARCH_MXS) += mxs/ obj-$(CONFIG_COMMON_CLK_QCOM) += qcom/ obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/ -obj-$(CONFIG_PLAT_SAMSUNG) += samsung/ +obj-$(CONFIG_COMMON_CLK_SAMSUNG) += samsung/ obj-$(CONFIG_ARCH_SHMOBILE_MULTI) += shmobile/ obj-$(CONFIG_ARCH_SIRF)+= sirf/ obj-$(CONFIG_ARCH_SOCFPGA) += socfpga/ -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] Documentation: DT: Exynos: Bind SRAM though DT
Add SRAM binding documentation.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Acked-by: Arnd Bergmann a...@arndb.de
---
No changes since v1.
---
.../devicetree/bindings/arm/exynos/smp-sram.txt| 38
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/exynos/smp-sram.txt
diff --git a/Documentation/devicetree/bindings/arm/exynos/smp-sram.txt
b/Documentation/devicetree/bindings/arm/exynos/smp-sram.txt
new file mode 100644
index ..c9ff2f58f9b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/exynos/smp-sram.txt
@@ -0,0 +1,38 @@
+Samsung Exynos SRAM for SMP bringup:
+
+
+Samsung SMP-capable Exynos SoCs use part of the SRAM for the bringup
+of the secondary cores. Once the core gets powered up it executes the
+code that is residing at some specific location of the SRAM.
+
+Therefore reserved section sub-nodes have to be added to the mmio-sram
+declaration. These nodes are of two types depending upon secure or
+non-secure execution environment.
+
+Required sub-node properties:
+- compatible : depending upon boot mode, should be
+ samsung,exynos4210-sram : for Secure SYSRAM
+ samsung,exynos4210-sram-ns : for Non-secure SYSRAM
+
+The rest of the properties should follow the generic mmio-sram discription
+found in ../../misc/sram.txt
+
+Example:
+
+ sram@0202 {
+ compatible = mmio-sram;
+ reg = 0x0202 0x54000;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0 0x0202 0x54000;
+
+ smp-sram@0 {
+ compatible = samsung,exynos4210-sram;
+ reg = 0x0 0x1000;
+ };
+
+ smp-sram@53000 {
+ compatible = samsung,exynos4210-sram-ns;
+ reg = 0x53000 0x1000;
+ };
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] ARM: EXYNOS: Map SYSRAM through generic SRAM bindings
Instead of hardcoding the SYSRAM details for each SoC,
pass this information through device tree (DT) and make
the code SoC agnostic. Generic SRAM bindings are used
for achieving this.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Acked-by: Arnd Bergmann a...@arndb.de
Acked-by: Heiko Stuebner he...@sntech.de
---
Changes since v2.
* Updated sysram node for Universal C210 board - Thanks to
Tomasz Figa for testing and updating the same.
* Added error handling code.
* Break if matching node found.
* Remove unnecessary error messages.
This patch is based on linux next (next-20140501) on top of
my Kconfig consolidation patch
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/28642
Tested on 4210/4412 Origen, 5250/5420 Arndale and SMDK5420 boards.
---
arch/arm/Kconfig|1 +
arch/arm/boot/dts/exynos4210-universal_c210.dts | 15 ++
arch/arm/boot/dts/exynos4210.dtsi | 18 +++
arch/arm/boot/dts/exynos4x12.dtsi | 18 +++
arch/arm/boot/dts/exynos5250.dtsi | 18 +++
arch/arm/boot/dts/exynos5420.dtsi | 18 +++
arch/arm/mach-exynos/common.h |1 +
arch/arm/mach-exynos/exynos.c | 64 ---
arch/arm/mach-exynos/firmware.c |8 ++-
arch/arm/mach-exynos/include/mach/map.h |7 ---
arch/arm/mach-exynos/platsmp.c | 56 ++--
11 files changed, 148 insertions(+), 76 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a6d19b1a..f66ea9453df9 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -855,6 +855,7 @@ config ARCH_EXYNOS
select S5P_DEV_MFC
select SAMSUNG_DMADEV
select SPARSE_IRQ
+ select SRAM
select USE_OF
help
Support for SAMSUNG's EXYNOS SoCs (EXYNOS4/5)
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 63e34b24b04f..a62c0ff25917 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -28,6 +28,21 @@
bootargs = console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rw
rootwait earlyprintk panic=5 maxcpus=1;
};
+ sram@0202 {
+ smp-sram@0 {
+ status = disabled;
+ };
+
+ smp-sram@5000 {
+ compatible = samsung,exynos4210-sram;
+ reg = 0x5000 0x1000;
+ };
+
+ smp-sram@1f000 {
+ status = disabled;
+ };
+ };
+
mct@1005 {
compatible = none;
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index cacf6140dd2f..d3d727b0c263 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -31,6 +31,24 @@
pinctrl2 = pinctrl_2;
};
+ sram@0202 {
+ compatible = mmio-sram;
+ reg = 0x0202 0x2;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0 0x0202 0x2;
+
+ smp-sram@0 {
+ compatible = samsung,exynos4210-sram;
+ reg = 0x0 0x1000;
+ };
+
+ smp-sram@1f000 {
+ compatible = samsung,exynos4210-sram-ns;
+ reg = 0x1f000 0x1000;
+ };
+ };
+
pd_lcd1: lcd1-power-domain@10023CA0 {
compatible = samsung,exynos4210-pd;
reg = 0x10023CA0 0x20;
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index c4a9306f8529..75fb3e7e3999 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -37,6 +37,24 @@
interrupts = 2 2, 3 2, 18 2, 19 2;
};
+ sram@0202 {
+ compatible = mmio-sram;
+ reg = 0x0202 0x4;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0 0x0202 0x4;
+
+ smp-sram@0 {
+ compatible = samsung,exynos4210-sram;
+ reg = 0x0 0x1000;
+ };
+
+ smp-sram@2f000 {
+ compatible = samsung,exynos4210-sram-ns;
+ reg = 0x2f000 0x1000;
+ };
+ };
+
pd_isp: isp-power-domain@10023CA0 {
compatible = samsung,exynos4210-pd;
reg = 0x10023CA0 0x20;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 37423314a028..8d724d56a5c6 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -72,6 +72,24 @@
};
};
+ sram@0202 {
+
Re: [PATCH 2/4] drm/exynos/mixer: use MXR_GRP_SXY_SY
Hello Daniel, On 2014년 05월 07일 23:14, Daniel Kurtz wrote: On Wed, May 7, 2014 at 1:14 PM, Seung-Woo Kim sw0312@samsung.com wrote: Hi Daniel, On 2014년 05월 05일 00:26, Daniel Kurtz wrote: Mixer hardware supports offsetting dma from start of source buffer using the MXR_GRP_SXY register. Signed-off-by: Daniel Kurtz djku...@chromium.org --- drivers/gpu/drm/exynos/exynos_mixer.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index 475eb49..40cf39b 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -529,13 +529,11 @@ static void mixer_graph_buffer(struct mixer_context *ctx, int win) dst_x_offset = win_data-crtc_x; dst_y_offset = win_data-crtc_y; + src_x_offset = win_data-fb_x; + src_y_offset = win_data-fb_y; /* converting dma address base and source offset */ - dma_addr = win_data-dma_addr - + (win_data-fb_x * win_data-bpp 3) - + (win_data-fb_y * win_data-fb_width * win_data-bpp 3); - src_x_offset = 0; - src_y_offset = 0; + dma_addr = win_data-dma_addr; Basically, you are right and source offset register can be used. But because of limitation of resolution for mixer up to 1920x1080, I considered modified soruce dma address to set one frame buffer, which is bigger than 1920x1080, on to both fimd and hdmi. Hi Seung-Woo, I do not see why the maximum MIXER resolution matters for choosing between offsetting BASE or using SXY. Let's say you have one big 1920x1908 framebuffer, with a span of 1920, starting at dma_addr (there is no extra padding at the end of the line). Let's say you wanted the mixer to scan out 1920x1080 pixels starting from (0, 800) in the framebuffer, and start drawing them at (0,0) on the screen. What we currently do is: BASE = dma_addr + (800 * 1080 * 4) SPAN = 1920 SXY = SX(0) | SY(0) WH = W(1920) | H(1080) DXY = DX(0) | DY(0) I am proposing we do: BASE = dma_addr SPAN = 1920 SXY = SX(0) | SY(800) WH = W(1920) | H(1080) DXY = DX(0) | DY(0) In both cases, the mixer resolution is 1920x1080. In my test to show each half of big one framebuffer (3840 x 1080) to FIMD from 0 to 1079 and MIXER from 1080 to 3839 with exynos4210 and exynos4412, it was failed to show proper hdmi display. Also it is same for framebuffer (1920 x 2160). AFAIK, it is mainly because mixer dma has limitation of dma memory size. In this case, I set register as like: BASE = dma_addr /* 3840 x 1080 x 4 */ SPAN = 3840 SXY = SX(1920) | SY(0) WH = W(1920) | H(1080) DXY = DX(0) | DY(0) or: BASE = dma_addr /* 1920 x 2160 x 4 */ SPAN = 1920 SXY = SX(0) | SY(1080) WH = W(1920) | H(1080) DXY = DX(0) | DY(0) but these two setting did not show hdmi display as I expected. So I used modified dma address. My motivation for wanting to program an un-modified dma_addr into BASE is so we can then just check BASE_S to determine from which buffer the mixer is actively being scanned out without worrying about the source offset, since the source offset can change for a given framebuffer (for example, when doing panning, or if an overlay is used for a HW cursor). Actually, this patch is exactly same with my first implementation, so I completely understand your motivation. Anyway, I was focus on extended displays with one buffer, so I wrote modified dma base address. Thanks and Regards, - Seung-Woo Kim Best Regards, -Daniel Regards, - Seung-Woo Kim if (win_data-scan_flags DRM_MODE_FLAG_INTERLACE) ctx-interlace = true; -- Seung-Woo Kim Samsung Software RD Center -- -- Seung-Woo Kim Samsung Software RD Center -- -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] ARM: dts: enable display for peach-pit and snow boards
On Sunday, April 20, 2014 8:49 PM, Rahul Sharma wrote: From: Rahul Sharma rahul.sha...@samsung.com Add nodes for fimd and dp controller for exynos5250 based snow and exynos5420 based peach-pit board. This series is based on Kukjin Kims, for-next branch. It is dependent on 1) Andrew Bresticker's patch for hpd gpio addition, avilable at http://www.spinics.net/lists/linux-samsung-soc/msg28827.html 2) Arun's patch for adding peach-pit board dts file at http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg28846.html. One more thing. These patches were based against the following patches. 3) Rahul Sharma's patch for hdmi support for exynos5 based dt files. ([PATCH 0/7] ARM: dts: enable hdmi for exynos5 based peach and snow boards) http://www.spinics.net/lists/linux-samsung-soc/msg29011.html Please check the dependency. Anyone does not want to waste the time, due to patch breakage. Best regards, Jingoo Han Rahul Sharma (5): ARM: dts: move dp hpd line to the board file for exynos5420 ARM: dts: enable fimd for exynos5250 based snow board ARM: dts: enable dp-controller for exynos5250 based snow board ARM: dts: enable fimd for exynos5420 based peach-pit board ARM: dts: enable dp-controller for exynos5420 based peach-pit board arch/arm/boot/dts/exynos5250-snow.dts | 32 +++ arch/arm/boot/dts/exynos5420-peach-pit.dts | 39 arch/arm/boot/dts/exynos5420-pinctrl.dtsi |7 - arch/arm/boot/dts/exynos5420-smdk5420.dts |7 + 4 files changed, 78 insertions(+), 7 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
