[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 Acked-by: Inki Dae Acked-by: Kyungmin Park --- .../devicetree/bindings/arm/samsung/sysreg.txt |1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt index 0ab3251..fd71581 100644 --- a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt +++ b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt @@ -3,6 +3,7 @@ SAMSUNG S5P/Exynos SoC series System Registers (SYSREG) Properties: - compatible : should contain "samsung,-sysreg", "syscon"; For Exynos4 SoC series it should be "samsung,exynos4-sysreg", "syscon"; + For Exynos5 SoC series it should be "samsung,exynos5-sysreg", "syscon"; - reg : offset and length of the register set. Example: -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 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
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
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
#include
+#include "exynos_drm_crtc.h"
#include "exynos_drm_drv.h"
/* returns true iff both arguments logically differs */
@@ -1032,10 +1033,22 @@ static ssize_t exynos_dsi_host_transfer(struct
mipi_dsi_host *host,
return (ret < 0) ? ret : xfer.rx_done;
}
+static int exynos_dsi_host_te_handler(struct mipi_dsi_host *host)
+{
+ struct exynos_dsi *dsi = host_to_dsi(host);
+ struct drm_encoder *encoder = dsi->encoder;
+
+ if (!(dsi->state & DSIM_STATE_ENABLED))
+ return -EPERM;
+
+ return exynos_drm_crtc_te_handler(encoder->crtc);
+}
+
static const struct mipi_dsi_host_ops exynos_dsi_ops = {
.attach = exynos_dsi_host_attach,
.detach = exynos_dsi_host_detach,
.transfer = exynos_dsi_host_transfer,
+ .te_handler = exynos_dsi_host_te_handler,
};
static int exynos_dsi_poweron(struct exynos_dsi *dsi)
--
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 07/18] ARM: dts: samsung-fimd: add I80 specific properties
In case of using MIPI command mode interface panel, the relevant registers should be set. So this patch adds relevant DT bindings. Changelog v2: - Changes "samsung,sysreg-phandle" to "samsung,sysreg" Changelog v3: - Moves CPU timings relevant properties to panel DT (commented by Laurent Pinchart, Andrzej Hajda) Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- .../devicetree/bindings/video/samsung-fimd.txt |2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt b/Documentation/devicetree/bindings/video/samsung-fimd.txt index 2dad41b..6bf93e9 100644 --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt @@ -44,6 +44,8 @@ Optional Properties: - display-timings: timing settings for FIMD, as described in document [1]. Can be used in case timings cannot be provided otherwise or to override timings provided by the panel. +- samsung,sysreg: handle to syscon used to control the system registers +- vidout-i80-ldi: boolean to support i80 interface instead of rgb one The device node can contain 'port' child nodes according to the bindings defined in [2]. The following are properties specific to those nodes: -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 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
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
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
#include
#include
+#include
+#include
#include
#include
#include
#include
+#include
#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_twin_updated;
+ atomic_ttriggering;
+ spinlock_t win_updated_lock;
struct exynos_drm_panel_info panel;
struct fimd_d
[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
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
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
#include
#include
+#include
+#include
#include
#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
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index eb73e3b..956e5f3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -472,8 +472,6 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
if (!(dsi->mode_flags & MIPI_DSI_MODE_VSYNC_FLUSH))
reg |= DSIM_MFLUSH_VS;
- if (!(dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET))
- reg |= DSIM_EOT_DISABLE;
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
reg |= DSIM_SYNC_INFORM;
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
@@ -490,6 +488,9 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
reg |= DSIM_HSA_MODE;
}
+ if (!(dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET))
+ reg |= DSIM_EOT_DISABLE;
+
switch (dsi->format) {
case MIPI_DSI_FMT_RGB888:
reg |= DSIM_MAIN_PIX_FORMAT_RGB888;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[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
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
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
+#include
/ {
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
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
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
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+
+/* 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}, {0x22, 0x2e},
+ {0x23, 0x2f}, {0x24, 0x30}, {0x25, 0x31}, {0x26, 0x32}, {0x27, 0x33},
+ {0x28, 0x34}, {0x29, 0x35}, {0x2a, 0x36}, {0x2b, 0x37}, {0x2c, 0x38},
+ {0x2d, 0x39}, {0x2e, 0x3a}, {0x2f, 0x3b}, {0x30,
[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 Acked-by: Inki Dae Acked-by: Kyungmin Park --- .../devicetree/bindings/video/exynos_dsim.txt |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt b/Documentation/devicetree/bindings/video/exynos_dsim.txt index 33b5730..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
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos5420.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 8db792b..f0184c7 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -416,6 +416,12 @@
phy-names = "dp";
};
+ mipi_phy: video-phy@10040714 {
+ compatible = "samsung,s5pv210-mipi-video-phy";
+ reg = <0x10040714 12>;
+ #phy-cells = <1>;
+ };
+
fimd@1440 {
samsung,power-domain = <&disp_pd>;
clocks = <&clock 147>, <&clock 421>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 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
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
.../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 --:|:::
+ Chip Select ¯¯¯|::|¯¯
+ | WR-SETUP+1 || WR-HOLD+1 |
+ |<-->||<-->|
+ Write Enable||¯¯¯
+ | WR-ACTIVE+1|
+ |<-->|
+ Video Data --
+
+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
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
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
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
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
#include
+#include
#include
#include
@@ -54,9 +55,12 @@
/* FIFO memory AC characteristic register */
#define DSIM_PLLCTRL_REG 0x4c/* PLL control register */
-#define DSIM_PLLTMR_REG0x50/* PLL timer register */
#define DSIM_PHYACCHR_REG 0x54/* D-PHY AC characteristic register */
#define DSIM_PHYACCHR1_REG 0x58/* D-PHY AC characteristic register1 */
+#define DSIM_PHYCTRL_REG 0x5c
+#define DSIM_PHYTIMING_REG 0x64
+#define DSIM_PHYTIMING1_REG0x68
+#define DSIM_PHYTIMING2_REG0x6c
/* DSIM_STATUS */
#define DSIM_STOP_STATE_DAT(x) (((x) & 0xf) << 0)
@@ -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 timeout;
u8 p, s;
u16 m;
u32 reg;
@@ -368,18 +419,30 @@ static unsigned long exynos
[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
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos5.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 258dca4..f938bbb 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -88,12 +88,18 @@
status = "disabled";
};
+ sys_reg: syscon@1005 {
+ compatible = "samsung,exynos5-sysreg", "syscon";
+ reg = <0x1005 0x500>;
+ };
+
fimd@1440 {
compatible = "samsung,exynos5250-fimd";
interrupt-parent = <&combiner>;
reg = <0x1440 0x4>;
interrupt-names = "fifo", "vsync", "lcd_sys";
interrupts = <18 4>, <18 5>, <18 6>;
+ samsung,sysreg = <&sys_reg>;
status = "disabled";
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 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 Acked-by: Inki Dae Acked-by: Kyungmin Park --- arch/arm/boot/dts/exynos4.dtsi |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi index 3d14cdb..a10aa50 100644 --- a/arch/arm/boot/dts/exynos4.dtsi +++ b/arch/arm/boot/dts/exynos4.dtsi @@ -528,6 +528,7 @@ clocks = <&clock 140>, <&clock 283>; clock-names = "sclk_fimd", "fimd"; samsung,power-domain = <&pd_lcd0>; + samsung,sysreg = <&sys_reg>; status = "disabled"; }; }; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 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
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
.../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
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index e930d4f..1419d11 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -69,8 +69,9 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int
mode)
if (mode > DRM_MODE_DPMS_ON) {
/* wait for the completion of page flip. */
- wait_event(exynos_crtc->pending_flip_queue,
- atomic_read(&exynos_crtc->pending_flip) == 0);
+ wait_event_timeout(exynos_crtc->pending_flip_queue,
+ !atomic_read(&exynos_crtc->pending_flip),
+ HZ/20);
drm_vblank_off(crtc->dev, exynos_crtc->pipe);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 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
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
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
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+
+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
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+
+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 file mode 100644
index 000..d63294e
--- /dev/null
+++ b/drivers/video/of_cmdmode.c
@@ -0,0 +1,55 @@
+/*
+ * generic cmdmode helper
+ *
+ * Copyright (c) 2014 YoungJun Cho
+ *
+ * This program is free software; y
[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
---
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
---
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
---
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,
- priv->
Re: [PATCHv2 1/3] phy: Add exynos-simple-phy driver
On 5 May 2014 15:14, Kishon Vijay Abraham I 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
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
Signed-off-by: Prathyush K
---
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
---
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 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 Signed-off-by: Arun Kumar K --- 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
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
---
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 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
>> Signed-off-by: Shaik Ameer Basha
>> ---
>> 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 01/15] clk: exynos5420: Rename mux parent arrays
Hi Tomasz,
Thanks for the review.
On Tue, May 6, 2014 at 11:31 PM, Tomasz Figa wrote:
> Shaik,
>
>
> On 06.05.2014 18:26, Shaik Ameer Basha wrote:
>>
>> This patch renames the mux parent arrays as per the naming
>> convension followed by the other exynos specific clock drivers.
>>
>> Signed-off-by: Rahul Sharma
>> Signed-off-by: Shaik Ameer Basha
>> Reviewed-by: Alim Akhtar
>> ---
>> drivers/clk/samsung/clk-exynos5420.c | 359
>> ++
>> 1 file changed, 186 insertions(+), 173 deletions(-)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos5420.c
>> b/drivers/clk/samsung/clk-exynos5420.c
>> index 7a9e3b4..831670d 100644
>> --- a/drivers/clk/samsung/clk-exynos5420.c
>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>
>
> [snip]
>
>
>> static struct samsung_mux_clock exynos5420_mux_clks[] __initdata = {
>> - MUX(0, "mout_mspll_kfc", mspll_cpu_p, SRC_TOP7, 8, 2),
>> - MUX(0, "mout_mspll_cpu", mspll_cpu_p, SRC_TOP7, 12, 2),
>> - MUX(0, "mout_apll", apll_p, SRC_CPU, 0, 1),
>> - MUX(0, "mout_cpu", cpu_p, SRC_CPU, 16, 1),
>> - MUX(0, "mout_kpll", kpll_p, SRC_KFC, 0, 1),
>> - MUX(0, "mout_cpu_kfc", kfc_p, SRC_KFC, 16, 1),
>> + MUX(0, "mout_mspll_kfc", mout_mspll_cpu_p, SRC_TOP7, 8, 2),
>> + MUX(0, "mout_mspll_cpu", mout_mspll_cpu_p, SRC_TOP7, 12, 2),
>> + MUX(0, "mout_apll", mout_apll_p, SRC_CPU, 0, 1),
>> + MUX(0, "mout_cpu", mout_cpu_p, SRC_CPU, 16, 1),
>> + MUX(0, "mout_kpll", mout_kpll_p, SRC_KFC, 0, 1),
>> + MUX(0, "mout_kfc", mout_kfc_p, SRC_KFC, 16, 1),
>
>
> Here the clock name is also changed, but I'll just fix the commit message
> when applying, assuming that this change doesn't break anything.
Ok. anyways I will try to update the commit message in the next series.
Regards,
Shaik
>
>
>>
>> - MUX(0, "sclk_bpll", bpll_p, SRC_CDREX, 0, 1),
>> + MUX(0, "sclk_bpll", mout_bpll_p, SRC_CDREX, 0, 1),
>
>
> [snip]
>
>
>> static struct samsung_div_clock exynos5420_div_clks[] __initdata = {
>> DIV(0, "div_arm", "mout_cpu", DIV_CPU0, 0, 3),
>> DIV(0, "sclk_apll", "mout_apll", DIV_CPU0, 24, 3),
>> DIV(0, "armclk2", "div_arm", DIV_CPU0, 28, 3),
>> - DIV(0, "div_kfc", "mout_cpu_kfc", DIV_KFC0, 0, 3),
>> + DIV(0, "div_kfc", "mout_kfc", DIV_KFC0, 0, 3),
>
>
> Same here.
>
> 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 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
>> Signed-off-by: Shaik Ameer Basha
>> ---
>> 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 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
>> Signed-off-by: Shaik Ameer Basha
>> Reviewed-by: Alim Akhtar
>> ---
>> 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(C
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 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
>> Signed-off-by: Shaik Ameer Basha
>> ---
>> 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_acl
[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
Signed-off-by: Ajay Kumar
---
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 wrote:
> From: Rahul Sharma
>
> Ennable dp-controller for snow board.
>
> Signed-off-by: Rahul Sharma
> ---
> 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 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 wrote:
> From: Rahul Sharma
>
> Enable dp-controller for peach-pit board.
>
> Signed-off-by: Rahul Sharma
> ---
> 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 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 >> --- >> 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 R&D 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 wrote: > On 05/07/2014 12:38 PM, Rahul Sharma wrote: >> On 5 May 2014 15:14, Kishon Vijay Abraham I 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 wrote: >> On 05/07/2014 12:38 PM, Rahul Sharma wrote: >>> On 5 May 2014 15:14, Kishon Vijay Abraham I 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 > >> Acked-by: Inki Dae > >> Acked-by: Kyungmin Park > >> --- > >> > >> .../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.
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 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
>>> #include
>>> #include
>>> +#include
>>>
>>> #include
>>> #include
>>> @@ -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 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
>>> Signed-off-by: Shaik Ameer Basha
>>> ---
>>> 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 wrote:
> On 06.05.2014 20:09, Sachin Kamat wrote:
> [snip]
>> On 6 May 2014 22:14, Tomasz Figa 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
#include
#include
+#include
#include
#include
@@ -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
Re: [PATCH] net: sxgbe: Added tail point update
2014-05-07 1:14 GMT-07:00 Byungho An :
>
> 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
> ---
> 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-so
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
Signed-off-by: Ajay Kumar
---
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 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
Signed-off-by: Ajay Kumar
---
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 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
>> Signed-off-by: Ajay Kumar
>> ---
>> 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 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
>> ---
>> 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
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
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
.../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 following properties.
+Required prop
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 : > > > > 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 > > --- > > 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 wrote:
> On 04/20/2014 04:54 PM, Rahul Sharma wrote:
>> From: Rahul Sharma
>>
>> Enable support for HDMI for exynos5250 based Snow board.
>>
>> Signed-off-by: Rahul Sharma
>> ---
>> 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 Signed-off-by: Pankaj Dubey --- 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 CC: Kukjin Kim CC: Russell King Signed-off-by: Pankaj Dubey --- 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 Signed-off-by: Pankaj Dubey --- 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 Signed-off-by: Pankaj Dubey --- 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
Acked-by: Arnd Bergmann
---
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
Acked-by: Arnd Bergmann
Acked-by: Heiko Stuebner
---
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 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 >>> --- >>> 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 R&D Center >> -- >> > -- Seung-Woo Kim Samsung Software R&D 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 > > 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
Re: [PATCH v7 1/2] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Sylwester,
On Tue, May 6, 2014 at 7:57 PM, Sylwester Nawrocki
wrote:
> On 28/04/14 08:17, Vivek Gautam wrote:
>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
>> The new driver uses the generic PHY framework and will interact
>> with DWC3 controller present on Exynos5 series of SoCs.
>> Thereby, removing old phy-samsung-usb3 driver and related code
>> used untill now which was based on usb/phy framework.
>>
>> Signed-off-by: Vivek Gautam
>> ---
>>
>> Changes from v6:
>> - Addressed review comments:
>>-- Sorted config entries in Kconfig and Makefile
>>-- Made #define to_usbdrd_phy(inst) to a static inline routine.
>>-- Restructured exynos5_rate_to_clk() as suggested.
>>-- Amended 'val' field for regmap_update_bits() in the routine
>> exynos5_usbdrd_phy_isol().
>>-- Removed sentinel entry from exynos5_usbdrd_phy_cfg[] struct.
>>-- Removed check for 'match' entry in probe().
>>
>> .../devicetree/bindings/phy/samsung-phy.txt| 40 ++
>> drivers/phy/Kconfig| 11 +
>> drivers/phy/Makefile |1 +
>> drivers/phy/phy-exynos5-usbdrd.c | 627
>>
>> 4 files changed, 679 insertions(+)
>> create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> index b422e38..51efe4c 100644
>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> @@ -114,3 +114,43 @@ Example:
>> compatible = "samsung,exynos-sataphy-i2c";
>> reg = <0x38>;
>> };
>> +
>> +Samsung Exynos5 SoC series USB DRD PHY controller
>> +--
>> +
>> +Required properties:
>> +- compatible : Should be set to one of the following supported values:
>> + - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
>> + - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
>> +- reg : Register offset and length of USB DRD PHY register set;
>> +- clocks: Clock IDs array as required by the controller
>> +- clock-names: names of clocks correseponding to IDs in the clock property;
>> +Required clocks:
>> + - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
>> +used for register access.
>> + - ref: PHY's reference clock (usually crystal clock), used for
>> +PHY operations, associated by phy name. It is used to
>> +determine bit values for clock settings register.
>> +For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
>> +- samsung,pmu-syscon: phandle for PMU system controller interface, used to
>> + control pmu registers for power isolation.
>> +- samsung,pmu-offset: phy power control register offset to
>> pmu-system-controller
>> + base.
>
> It doesn't seem right to have register offset encoded in the device tree
> like this. I think it'd be more appropriate to associate such an offset
> with the compatible string's value in the driver.
Ok, it makes more sense.
Just out of curiosity, what difference would this make ?
>
> Also it might be sensible to create a new header file in include/linux/mfd/
> syscon/ for Exynos5 SoCs and put any required PMU offset definitions there.
> Instead having them scattered and possibly duplicated in various drivers.
>
>> +- #phy-cells : from the generic PHY bindings, must be 1;
>> +
>> +For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy"
>> +compatible PHYs, the second cell in the PHY specifier identifies the
>> +PHY id, which is interpreted as follows:
>> + 0 - UTMI+ type phy,
>> + 1 - PIPE3 type phy,
>> +
>> +Example:
>> + usb3_phy: usbphy@1210 {
>> + compatible = "samsung,exynos5250-usbdrd-phy";
>> + reg = <0x1210 0x100>;
>> + clocks = <&clock 286>, <&clock 1>;
>> + clock-names = "phy", "ref";
>> + samsung,pmu-syscon = <&pmu_system_controller>;
>> + samsung,pmu-offset = <0x704>;
>> + #phy-cells = <1>;
>> + };
> [...]
>> +struct usbdrd_phy_config {
>
> Isn't name of this data structure too generic ?
> Perhaps rename it to exynos_usbdrd_phy_config ?
Sure, will change this name, and thereby change the names of its instances.
>
>> + u32 id;
>> + void (*phy_isol)(struct phy_usb_instance *inst, u32 on);
>> + void (*phy_init)(struct exynos5_usbdrd_phy *phy_drd);
>> + unsigned int (*set_refclk)(struct phy_usb_instance *inst);
>> +};
>> +
>> +struct exynos5_usbdrd_phy_drvdata {
>> + const struct usbdrd_phy_config *phy_cfg;
>> +};
>> +
> [...]
>> +const struct exynos5_usbdrd_phy_drvdata exynos5420_usbdrd_phy = {
>> + .phy_cfg= exynos5_usbdrd_phy_cfg,
>> +};
>> +
>> +const struct exynos5_usbdrd_phy_drvdata exyn
[PATCH v2 0/5] ARM: dts: enable display for peach-pit and snow boards
From: Rahul Sharma 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. V2: 1) Rebase on Peach-pit dependent patches. 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 [Patch is 'ACK'ed.] 2) Arun's patch for adding peach-pit board dts file at http://www.spinics.net/lists/linux-samsung-soc/msg30103.html. [Patch is 'ACK'ed.] 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 | 33 +++ 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, 79 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
[PATCH v2 2/5] ARM: dts: enable fimd for exynos5250 based snow board
From: Rahul Sharma
Enable fimd node for snow board.
Signed-off-by: Rahul Sharma
---
arch/arm/boot/dts/exynos5250-snow.dts |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 1ce1088..796954c 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -206,4 +206,10 @@
clock-frequency = <2400>;
};
};
+
+ 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
[PATCH v2 1/5] ARM: dts: move dp hpd line to the board file for exynos5420
From: Rahul Sharma
Display controller HPD Gpio line is board specific. This patch
is moving the pinctrl for hpd gpio line to the respective board
file.
Signed-off-by: Rahul Sharma
---
arch/arm/boot/dts/exynos5420-pinctrl.dtsi |7 ---
arch/arm/boot/dts/exynos5420-smdk5420.dts |7 +++
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
index ba686e4..7e4ac17 100644
--- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
@@ -59,13 +59,6 @@
interrupt-controller;
#interrupt-cells = <2>;
};
-
- dp_hpd: dp_hpd {
- samsung,pins = "gpx0-7";
- samsung,pin-function = <3>;
- samsung,pin-pud = <0>;
- samsung,pin-drv = <0>;
- };
};
pinctrl@1341 {
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 6910485..62d38c8 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -138,6 +138,13 @@
samsung,pin-pud = <1>;
samsung,pin-drv = <0>;
};
+
+ dp_hpd: dp_hpd {
+ samsung,pins = "gpx0-7";
+ samsung,pin-function = <3>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
};
hdmi@1453 {
--
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 v2 3/5] ARM: dts: enable dp-controller for exynos5250 based snow board
From: Rahul Sharma
Enable dp-controller for snow board.
Signed-off-by: Rahul Sharma
---
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 796954c..28a755f 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -207,6 +207,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
[PATCH v2 4/5] ARM: dts: enable fimd for exynos5420 based peach-pit board
From: Rahul Sharma
Enable fimd for peach-pit board.
Signed-off-by: Rahul Sharma
---
arch/arm/boot/dts/exynos5420-peach-pit.dts |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index fae33dd..f75da5b 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -145,3 +145,8 @@
&watchdog {
timeout-sec = <32>;
};
+
+&fimd {
+ 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
[PATCH v2 5/5] ARM: dts: enable dp-controller for exynos5420 based peach-pit board
From: Rahul Sharma
Enable dp-controller for peach-pit board.
Signed-off-by: Rahul Sharma
---
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 f75da5b..ed76f33 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -74,6 +74,13 @@
samsung,pin-pud = <0>;
samsung,pin-drv = <0>;
};
+
+ dp_hpd: dp_hpd {
+ samsung,pins = "gpx2-6";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
};
&rtc {
@@ -150,3 +157,30 @@
status = "okay";
samsung,invert-vclk;
};
+
+&dp {
+ 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>;
+ };
+ };
+};
--
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 1/5] ARM: dts: move dp hpd line to the board file for exynos5420
On Sunday, April 20, 2014 8:49 PM, Rahul Sharma wrote:
>
> From: Rahul Sharma
>
> Display controller HPD Gpio line is board specific. This patch
> is moving the pinctrl for hpd gpio line to the respective board
> file.
>
> Signed-off-by: Rahul Sharma
> ---
> arch/arm/boot/dts/exynos5420-pinctrl.dtsi |7 ---
> arch/arm/boot/dts/exynos5420-smdk5420.dts |7 +++
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> index e62c8eb..5848c42 100644
> --- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> @@ -59,13 +59,6 @@
> interrupt-controller;
> #interrupt-cells = <2>;
> };
> -
> - dp_hpd: dp_hpd {
> - samsung,pins = "gpx0-7";
> - samsung,pin-function = <3>;
> - samsung,pin-pud = <0>;
> - samsung,pin-drv = <0>;
> - };
> };
(+cc Doug Anderson, Tomasz Figa)
'gpx0-7' pin is assigned for standard HPD pin. This is chip specific.
So, there should be "gpx0-7" part on chip specific dts file such as
'exynos5420-pinctrl.dtsi'.
However, some boards use GPIO as HPD pin, instead of 'gpx0-7' pin.
This is board specific. In my opinion, the following would look
better. In this way, this patch is not necessary.
1. case: Standard HPD pin is used. (smdk5420)
arch/arm/boot/dts/exynos5420-pinctrl.dts
pinctrl@1340 {
dp_hpd: dp_hpd {
samsung,pins = "gpx0-7";
samsung,pin-function = <3>;
samsung,pin-pud = <0>;
samsung,pin-drv = <0>;
};
arch/arm/boot/dts/exynos5420-smdk5420.dts
dp-controller@145B {
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd>;
...
2. case: non-standard HPD pin such as GPIO is used. (peach pit)
arch/arm/boot/dts/exynos5420-peach-pit.dts
pinctrl@1340 {
dp_hpd: dp_hpd {
samsung,pins = "gpx2-6";
samsung,pin-function = <0>;
samsung,pin-pud = <3>;
samsung,pin-drv = <0>;
};
dp-controller@145B {
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd>;
...
samsung,hpd-gpio = <&gpx2 6 0>;
Even though, there is 'dp_hpd' in exynos5420-pinctrl.dts,
'smdk5420' and 'peach pit' can use "gpx0-7" and "gpx2-6",
respectively.
A year ago, Doug Anderson and me agreed that standard HPD pin
part should be included to 'exynos5250-pinctrl.dtsi'.
(https://lkml.org/lkml/2013/5/11/134)
Best regards,
Jingoo Han
>
> pinctrl@1341 {
> diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
> b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> index 6910485..62d38c8 100644
> --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
> +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> @@ -138,6 +138,13 @@
> samsung,pin-pud = <1>;
> samsung,pin-drv = <0>;
> };
> +
> + dp_hpd: dp_hpd {
> + samsung,pins = "gpx0-7";
> + samsung,pin-function = <3>;
> + samsung,pin-pud = <0>;
> + samsung,pin-drv = <0>;
> + };
> };
>
> hdmi@1453 {
> --
> 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: [RFC V2 0/3] drm/bridge: panel and chaining
On 05/05/2014 09:52 PM, Ajay Kumar wrote: > This patchset is based on exynos-drm-next-todo branch of Inki Dae's tree at: > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > > I have just put up Rob's and Sean's idea of chaining up the bridges > in code, and have implemented basic panel controls as a chained bridge. > This works well with ptn3460 bridge chip on exynos5250-snow board. > > Still need to make use of standard list calls and figure out proper way > of deleting the bridge chain. So, this is just a rough version. As I understand this patchset tries to solve two things: 1. Implement panel as drm_bridge, to ease support for hardware chains: Crtc -> Encoder -> Bridge -> Panel 2. Add support to drm_bridge chaining, to allow software chains: drm_crtc -> drm_encoder -> drm_bridge -> drm_bridge,panel It is done using Russian doll schema, ops from the bridge calls the same ops from the next bridge and the next bridge ops can do the same. This schema means that all the bridges including the last one are seen from the drm core point of view as a one big drm_bridge. Additionally in this particular case, the first bridge (ptn3460) implements connector so it is hard to guess what is the location of the 2nd bridge in video stream chain, sometimes it is after the connector, sometimes before. All this is quite confusing. But if you look at the bridge from upstream video interface point of view it is just a panel, edp panel in case of ptn3460, ie ptn3460 on its video input side acts as a panel. On the output side it expects a panel, lvds panel in this case. So why not implement ptn3460 bridge as drm_panel which internally uses another drm_panel. With this approach everything fits much better. You do not need those (pre|post)_(enable|disable) calls, you do not need to implement connector in the bridge and you have a driver following linux driver model. And no single bit changed in drm core. I have implemented this way DSI/LVDS bridge, it was sent as RFC [1][2]. It was not accepted as Inki preferred drm_bridge but as I see the problems with drm_bridges I have decide to attract attention to much more cleaner solution. [1]: http://permalink.gmane.org/gmane.linux.drivers.devicetree/61559 [2]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/27044 Regards Andrzej > > Ajay Kumar (3): > [RFC V2 1/3] drm: implement chaining of drm bridges > [RFC V2 2/3] drm/bridge: add a dummy panel driver to support lvds bridges > [RFC V2 3/3] drm/bridge: ptn3460: support bridge chaining > > .../bindings/drm/bridge/bridge_panel.txt | 45 > drivers/gpu/drm/bridge/Kconfig | 6 + > drivers/gpu/drm/bridge/Makefile| 1 + > drivers/gpu/drm/bridge/bridge_panel.c | 240 > + > drivers/gpu/drm/bridge/ptn3460.c | 21 +- > drivers/gpu/drm/drm_crtc.c | 13 +- > include/drm/bridge/bridge_panel.h | 37 > include/drm/drm_crtc.h | 2 + > 8 files changed, 360 insertions(+), 5 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/drm/bridge/bridge_panel.txt > create mode 100644 drivers/gpu/drm/bridge/bridge_panel.c > create mode 100644 include/drm/bridge/bridge_panel.h > -- 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
