[PATCH v4 06/14] drm/exynos: fimd: support LCD I80 interface
To support MIPI command mode based I80 interface panel,
FIMD should do followings:
- Sets LCD I80 interface timings configuration.
- Uses "lcd_sys" as an IRQ resource and sets relevant IRQ configuration.
- Sets LCD block configuration for I80 interface.
- Sets ideal(pixel) clock is 2 times faster than the original one to
generate frame done IRQ prior to the next TE signal.
- Implements trigger feature that transfers image data if there is page
flip request, and implements TE handler to call trigger function.
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 | 287 +-
include/video/samsung_fimd.h |3 +-
3 files changed, 247 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 178d2a9..9ba1aae 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
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 bb45ab2..589017c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -20,6 +20,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -61,6 +63,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_ACTIVE(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
@@ -68,10 +88,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 = {
@@ -82,12 +106,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 {
@@ -112,15 +143,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_driver_data *driver_data;
@@ -243,6 +282,14 @@ static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
unsigned long ideal_clk = mode->htotal * mode->vtotal * mode->vrefresh;
u32 clkdiv;
+ if (ctx->i80_if) {
+
[PATCH v4 10/14] drm/panel: add S6E3FA0 driver
This patch adds MIPI DSI command mode based
S6E3FA0 AMOLED LCD Panel driver.
Signed-off-by: YoungJun Cho
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 | 568 +
3 files changed, 576 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 4ec874d..be1392e 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -30,4 +30,11 @@ config DRM_PANEL_S6E8AA0
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS
+config DRM_PANEL_S6E3FA0
+ tristate "S6E3FA0 DSI command mode panel"
+ depends on DRM && DRM_PANEL
+ depends on OF
+ select DRM_MIPI_DSI
+ select VIDEOMODE_HELPERS
+
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 8b92921..85c6738 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
+obj-$(CONFIG_DRM_PANEL_S6E3FA0) += panel-s6e3fa0.o
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
b/drivers/gpu/drm/panel/panel-s6e3fa0.c
new file mode 100644
index 000..5373ba7
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
@@ -0,0 +1,568 @@
+/*
+ * MIPI DSI command mode based s6e3fa0 AMOLED LCD 5.7 inch drm 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 videomodevm;
+
+ 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 pairs 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, 0x3c}, {0x31, 0x3d},
+ {0x32, 0x3e}, {0x33, 0x3f}, {0x34, 0x3f}, {0x35, 0x3f}, {0x36, 0x3f},
+ {0x37, 0x3f}, {0x38, 0x3f}, {0x39, 0x3f}, {0x3a, 0x3f}, {0x3b, 0x3f},
+ {0x3c, 0x3f}, {0x3d, 0x3f}, {0x3e, 0x3f}, {0x3f, 0x3f}, {0x40, 0x0c},
+ {0x41, 0x0b}, {0x42, 0x0a}, {0x43, 0x09}, {0x44, 0x08}, {0x45, 0x07},
+ {0x46, 0x06}, {0x47, 0x05}, {0x48, 0x04}, {0
[PATCH v4 13/14] 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 c3a9a66..6fde5fd 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -472,6 +472,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 CLK_SCLK_FIMD1>, <&clock CLK_FIMD1>;
--
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 v4 08/14] drm/exynos: dsi: add driver data to support Exynos5420
The offset of register DSIM_PLLTMR_REG in Exynos5420 is
different from the one in Exynos4 SoC.
In case of Exynos5420 SoC, there is no frequency band bit
in DSIM_PLLCTRL_REG,
and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead.
So this patch adds driver data to distinguish it.
Signed-off-by: YoungJun Cho
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 db760d8..c348392 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
#include
@@ -55,9 +56,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)
@@ -201,6 +205,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
@@ -234,6 +256,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;
@@ -263,11 +291,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)))
@@ -341,14 +397,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;
@@ -369,18 +420,30 @@ static unsigned long exynos_dsi_set_pll(struct exynos_dsi
*dsi,
"failed to find PLL PMS for requested frequency\n");
return -EFAULT;
}
+ dev_dbg(dsi->dev, "PLL freq %lu, (p %d, m %d, s %d)\n", fout, p, m, s);
- for (band = 0; ba
[PATCH v4 04/14] drm/exynos: add TE handler to support LCD I80 interface
To support LCD I80 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 3bf091d..504e023 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -511,3 +511,14 @@ int exynos_drm_crtc_get_pipe_from_type(struct drm_device
*drm_dev,
return -EPERM;
}
+
+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 9f74b10..875d93d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -36,4 +36,11 @@ void exynos_drm_crtc_plane_disable(struct drm_crtc *crtc,
int zpos);
int exynos_drm_crtc_get_pipe_from_type(struct drm_device *drm_dev,
unsigned int out_type);
+/*
+ * 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 36535f3..ab3a88d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -188,6 +188,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 {
@@ -206,6 +208,7 @@ struct exynos_drm_manager_ops {
void (*win_commit)(struct exynos_drm_manager *mgr, int zpos);
void (*win_enable)(struct exynos_drm_manager *mgr, int zpos);
void (*win_disable)(struct exynos_drm_manager *mgr, int zpos);
+ int (*te_handler)(struct exynos_drm_manager *mgr);
};
/*
diff --git a/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
[PATCH v4 11/14] ARM: dts: exynos4: add system register property
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 2f8bcd0..abfcbe2 100644 --- a/arch/arm/boot/dts/exynos4.dtsi +++ b/arch/arm/boot/dts/exynos4.dtsi @@ -534,6 +534,7 @@ clocks = <&clock CLK_SCLK_FIMD0>, <&clock CLK_FIMD0>; 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
[PATCH v4 12/14] ARM: dts: exynos5: add system register property
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/exynos5.dtsi |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi index 79d0608..fdead12 100644 --- a/arch/arm/boot/dts/exynos5.dtsi +++ b/arch/arm/boot/dts/exynos5.dtsi @@ -87,6 +87,7 @@ reg = <0x1440 0x4>; interrupt-names = "fifo", "vsync", "lcd_sys"; interrupts = <18 4>, <18 5>, <18 6>; + samsung,sysreg = <&sysreg_system_controller>; 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
[PATCH v4 14/14] ARM: dts: exynos5420: add dsi node
This patch adds common part of dsi node.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos5420.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 6fde5fd..43b6852 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -478,6 +478,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 CLK_SCLK_FIMD1>, <&clock CLK_FIMD1>;
--
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 v4 09/14] ARM: dts: s6e3fa0: add DT bindings
This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources and display timings.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
.../devicetree/bindings/panel/samsung,s6e3fa0.txt | 46
1 file changed, 46 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..2cd32f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
@@ -0,0 +1,46 @@
+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]
+
+Optional properties:
+
+The device node can contain one 'port' child node with one child 'endpoint'
+node, according to the bindings defined in [2]. This node should describe
+panel's video bus.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ panel@0 {
+ compatible = "samsung,s6e3fa0";
+ reg = <0>;
+ vdd3-supply = <&vcclcd_reg>;
+ vci-supply = <&vlcd_reg>;
+ reset-gpios = <&gpy7 4 0>;
+ det-gpios = <&gpg0 6 0>;
+ te-gpios = <&gpd1 7 0>;
+
+ display-timings {
+ timings0 {
+ clock-frequency = <0>;
+ hactive = <1080>;
+ vactive = <1920>;
+ hfront-porch = <2>;
+ hback-porch = <2>;
+ hsync-len = <1>;
+ vfront-porch = <1>;
+ vback-porch = <4>;
+ vsync-len = <1>;
+ };
+ };
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 00/14] drm/exynos: support LCD I80 interface display
Hi, This series adds LCD I80 interface display support for Exynos DRM driver. The FIMD(display controller) specification describes it as "LCD I80 interface" and the DSI specification describes it as "Command mode interface". This is based on exynos-drm-next branch. The previous patches, RFC: http://www.spinics.net/lists/dri-devel/msg58898.html V1: http://www.spinics.net/lists/dri-devel/msg59291.html V2: http://www.spinics.net/lists/dri-devel/msg59867.html V3: http://www.spinics.net/lists/dri-devel/msg60708.html Changelog v2: - Fixes typo and removes unnecessary error log (commented by Andrzej Hazda) - Adds missed pendlig_flip flag clear points (commented by Daniel Kurtz) Changelog v3: - Removes generic command mode and command mode display timing interface. - Moves I80 interface timings from panel DT to the FIMD(display controller) DT. Changelog v4: - Removes exynos5 sysreg(syscon) DT bindings and node from dtsi because it was already updated by linux-samsung-soc (commented by Vivek Gautam) Patches 1 and 2 fix trivial bugs. Patches 3, 4, 5 and 6 implement FIMD(display controller) I80 interface. The MIPI DSI command mode based panel generates Tearing Effect synchronization signal between MCU and FB to display video image, and FIMD should trigger to transfer video image at this signal. So the panel should receive the TE IRQ and call TE handler chains to notify it to the FIMD. Patches 7 and 8 implement to use Exynos5420 SoC DSI driver which is different from previous Exynos4 SoCs for some registers control. Patches 9 and 10 introduce MIPI DSI command mode based Samsung S6E3FA0 AMOLED 5.7" LCD drm panel driver. The ohters add DT property nodes to support MIPI DSI command mode. I welcome any comments. Thank you. Best regards YJ YoungJun Cho (14): drm/exynos: dsi: move the EoT packets configuration point drm/exynos: use wait_event_timeout() for safety usage ARM: dts: samsung-fimd: add LCD I80 interface specific properties drm/exynos: add TE handler to support LCD I80 interface drm/exynos: dsi: add TE handler to support LCD I80 interface drm/exynos: fimd: support LCD 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 property ARM: dts: exynos5: add system register property ARM: dts: exynos5420: add mipi-phy node ARM: dts: exynos5420: add dsi node .../devicetree/bindings/panel/samsung,s6e3fa0.txt | 46 ++ .../devicetree/bindings/video/exynos_dsim.txt |4 +- .../devicetree/bindings/video/samsung-fimd.txt | 28 + arch/arm/boot/dts/exynos4.dtsi |1 + arch/arm/boot/dts/exynos5.dtsi |1 + arch/arm/boot/dts/exynos5420.dtsi | 20 + drivers/gpu/drm/exynos/Kconfig |1 + drivers/gpu/drm/exynos/exynos_drm_crtc.c | 18 +- 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 | 287 -- drivers/gpu/drm/panel/Kconfig |7 + drivers/gpu/drm/panel/Makefile |1 + drivers/gpu/drm/panel/panel-s6e3fa0.c | 568 include/drm/drm_mipi_dsi.h |8 + include/video/samsung_fimd.h |3 +- 17 files changed, 1107 insertions(+), 71 deletions(-) create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 01/14] drm/exynos: dsi: move the EoT packets configuration point
This configuration could be used in MIPI DSI command mode also.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
Reviewed-by: Andrzej Hajda
---
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 6302aa6..df2d23d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -473,8 +473,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)
@@ -491,6 +489,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
[PATCH v4 02/14] drm/exynos: use wait_event_timeout() for safety usage
There could be the case that the page flip operation isn't finished correctly
with some abnormal condition such as panel reset. So this patch replaces
wait_event() with wait_event_timeout() to avoid waiting for page flip completion
infinitely.
And clears exynos_crtc->pending_flip in exynos_drm_crtc_page_flip()
when exynos_drm_crtc_mode_set_commit() is failed.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 95c9435..3bf091d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -69,8 +69,10 @@ 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);
+ if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
+ !atomic_read(&exynos_crtc->pending_flip),
+ HZ/20))
+ atomic_set(&exynos_crtc->pending_flip, 0);
drm_vblank_off(crtc->dev, exynos_crtc->pipe);
}
@@ -259,6 +261,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
spin_lock_irq(&dev->event_lock);
drm_vblank_put(dev, exynos_crtc->pipe);
list_del(&event->base.link);
+ atomic_set(&exynos_crtc->pending_flip, 0);
spin_unlock_irq(&dev->event_lock);
goto out;
--
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 v4 07/14] ARM: dts: exynos_dsim: add exynos5420 compatible to DT bindings
This patch adds relevant to exynos5420 compatible for exynos5420 SoC support. 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
[PATCH v4 05/14] drm/exynos: dsi: add TE handler to support LCD I80 interface
To support LCD I80 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 df2d23d..db760d8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -24,6 +24,7 @@
#include
#include
+#include "exynos_drm_crtc.h"
#include "exynos_drm_drv.h"
/* returns true iff both arguments logically differs */
@@ -1033,10 +1034,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
[PATCH v4 03/14] ARM: dts: samsung-fimd: add LCD I80 interface specific properties
In case of using MIPI DSI based I80 interface panel, the relevant registers should be set. So this patch adds relevant DT bindings. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- .../devicetree/bindings/video/samsung-fimd.txt | 28 1 file changed, 28 insertions(+) diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt b/Documentation/devicetree/bindings/video/samsung-fimd.txt index 2dad41b..59ff61e 100644 --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt @@ -44,6 +44,34 @@ 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 +- i80-if-timings: timing configuration for lcd i80 interface support. + - cs-setup: clock cycles for the active period of address signal is enabled + until chip select is enabled. + If not specified, the default value(0) will be used. + - wr-setup: clock cycles for the active period of CS signal is enabled until + write signal is enabled. + If not specified, the default value(0) will be used. + - wr-active: clock cycles for the active period of CS is enabled. + If not specified, the default value(1) will be used. + - wr-hold: clock cycles for the active period of CS is disabled until write + signal is disabled. + If not specified, the default value(0) will be used. + + The parameters are defined as: + +VCLK(internal) __|¯¯|_|¯¯|_|¯¯|_|¯¯|_|¯¯ + ::::: +Address Output --:|::: +Chip Select ¯¯¯|::|¯¯ + | wr-setup+1 || wr-hold+1 | + |<-->||<-->| +Write Enable||¯¯¯ +| wr-active+1| +|<-->| +Video Data -- 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
Re: [PATCH v3 13/15] ARM: dts: exynos5: add system register support
Hi YoungJun, On Thu, Jun 5, 2014 at 8:22 AM, YoungJun Cho wrote: > Hi Vivek, > > > On 06/04/2014 08:50 PM, Vivek Gautam wrote: >> >> On Mon, Jun 2, 2014 at 10:52 AM, YoungJun Cho >> wrote: >>> >>> This patch adds sysreg device node, and sysreg property >>> to fimd device node which is required to use I80 interface. >> >> >> Same here. The system register nodes have been added to exynos5250 and >> exynos5420 by the patch: >> dfbbdbf ARM: dts: Add sysreg sytem controller node to exynos5250 and >> exynos5420 >> >> May be, you may want to move those two nodes to this common file >> (exynos5.dtsi). >> > > Thank you for reporting. > I didn't check linux-samsung-soc. > > The exynos5410, 5420 and 5422 use system register with base address > 0x1005. > But exynos5260 and 5430 are different. > And I can't check exynos5250. Exynos5250 too starts with same register base address as Exynos5420, but as you say Exynos5430 and Exynos5260 starts with different base address then it make sense to keep them separate in their dtsi. (I couldn't check Exynos5430) > > So with this condition, it is reasonable to remove these sysreg relevant > patches. Sure. [snip] -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] s5p-mfc: Adding MFC v7 and v8 firmwares
Hi Ben, On Wed, Jun 4, 2014 at 5:43 PM, Ben Hutchings wrote: > On Wed, 2014-06-04 at 13:08 +0200, Kamil Debski wrote: >> Hi Arun, Ben, >> >> >> > From: arunkk.sams...@gmail.com [mailto:arunkk.sams...@gmail.com] On >> > Behalf Of Arun Kumar K >> > Sent: Wednesday, June 04, 2014 7:32 AM >> > >> > Hi Ben, >> > >> > On Wed, Jun 4, 2014 at 4:56 AM, Ben Hutchings >> > wrote: >> > > On Tue, 2014-06-03 at 20:34 +0100, Ben Hutchings wrote: >> > >> On Wed, 2014-05-21 at 18:11 +0530, Arun Kumar K wrote: >> > >> > Adding the following firmware files for MFC >> > >> > s5p-mfc-v7.fw: Used in exynos 5420 >> > >> > s5p-mfc-v8.fw: Used in exynos 5800 >> > >> > >> > >> > Signed-off-by: Arun Kumar K >> > >> > --- >> > >> > Changes from v1 >> > >> > - None >> > >> > --- >> > >> > WHENCE|2 ++ >> > >> > s5p-mfc/s5p-mfc-v7.fw | Bin 0 -> 382724 bytes >> > >> > s5p-mfc/s5p-mfc-v8.fw | Bin 0 -> 360576 bytes >> > >> > 3 files changed, 2 insertions(+) >> > >> > create mode 100644 s5p-mfc/s5p-mfc-v7.fw create mode 100644 >> > >> > s5p-mfc/s5p-mfc-v8.fw >> > >> [...] >> > >> >> > >> Applied, thanks. >> > > >> > > Just noticed a problem with all the s5p-mfc firmware: you are putting >> > > it in the s5p-mfc subdirectory, so distribution packages will install >> > > them in /lib/firmware/s5p-mfc. However, unless I'm mistaken your >> > > driver requests it with a bare filename (e.g. "s5p-mfc-v7.fw") so it >> > > won't be found. >> > > >> > >> > Yes this issue is there. >> > Kamil, are you ok with changing the fw load path to s5p-mfc/s5p-mfc*.fw >> > in the driver? >> >> We have two options here: >> 1) Change the driver to request s5p-mfc/sp5-mfc-fw* >> 2) Move the files in the firmware repository >> >> I would opt for the second option. The driver was uploaded before the >> firmware. I see that there are many firmware files in the root folder >> of the repository >> >> Ben, what is your opinion? Which is preferred: creating subdirectories >> or storing firmware in the root folder? > > I prefer subdirectories, but compatibility wins. So I'll apply the > following patch if no-one objects. > > Ben. > > --- > Subject: Move the s5p-mfc firmware out of its subdirectory > > The driver does not include this subdirectory name when requesting > firmware. > > Signed-off-by: Ben Hutchings > --- > WHENCE | 10 +- > s5p-mfc/s5p-mfc-v6-v2.fw => s5p-mfc-v6-v2.fw | Bin > s5p-mfc/s5p-mfc-v6.fw => s5p-mfc-v6.fw | Bin > s5p-mfc/s5p-mfc-v7.fw => s5p-mfc-v7.fw | Bin > s5p-mfc/s5p-mfc-v8.fw => s5p-mfc-v8.fw | Bin > s5p-mfc/s5p-mfc.fw => s5p-mfc.fw | Bin > 6 files changed, 5 insertions(+), 5 deletions(-) > rename s5p-mfc/s5p-mfc-v6-v2.fw => s5p-mfc-v6-v2.fw (100%) > rename s5p-mfc/s5p-mfc-v6.fw => s5p-mfc-v6.fw (100%) > rename s5p-mfc/s5p-mfc-v7.fw => s5p-mfc-v7.fw (100%) > rename s5p-mfc/s5p-mfc-v8.fw => s5p-mfc-v8.fw (100%) > rename s5p-mfc/s5p-mfc.fw => s5p-mfc.fw (100%) > > diff --git a/WHENCE b/WHENCE > index 6a64fc2..a172f5f 100644 > --- a/WHENCE > +++ b/WHENCE > @@ -2250,11 +2250,11 @@ Licence: Redistributable. See > LICENCE.atheros_firmware for details > > Driver: s5p-mfc - Samsung MFC video encoder/decoder driver > > -File: s5p-mfc/s5p-mfc.fw > -File: s5p-mfc/s5p-mfc-v6.fw > -File: s5p-mfc/s5p-mfc-v6-v2.fw > -File: s5p-mfc/s5p-mfc-v7.fw > -File: s5p-mfc/s5p-mfc-v8.fw > +File: s5p-mfc.fw > +File: s5p-mfc-v6.fw > +File: s5p-mfc-v6-v2.fw > +File: s5p-mfc-v7.fw > +File: s5p-mfc-v8.fw > > Licence: > Samsung grants permission to use and redistribute aforementioned firmware > diff --git a/s5p-mfc/s5p-mfc-v6-v2.fw b/s5p-mfc-v6-v2.fw > similarity index 100% > rename from s5p-mfc/s5p-mfc-v6-v2.fw > rename to s5p-mfc-v6-v2.fw > diff --git a/s5p-mfc/s5p-mfc-v6.fw b/s5p-mfc-v6.fw > similarity index 100% > rename from s5p-mfc/s5p-mfc-v6.fw > rename to s5p-mfc-v6.fw > diff --git a/s5p-mfc/s5p-mfc-v7.fw b/s5p-mfc-v7.fw > similarity index 100% > rename from s5p-mfc/s5p-mfc-v7.fw > rename to s5p-mfc-v7.fw > diff --git a/s5p-mfc/s5p-mfc-v8.fw b/s5p-mfc-v8.fw > similarity index 100% > rename from s5p-mfc/s5p-mfc-v8.fw > rename to s5p-mfc-v8.fw > diff --git a/s5p-mfc/s5p-mfc.fw b/s5p-mfc.fw > similarity index 100% > rename from s5p-mfc/s5p-mfc.fw > rename to s5p-mfc.fw > > Looks good to me. Regards Arun > -- > Ben Hutchings > Experience is what causes a person to make new mistakes instead of old ones. -- To unsubscribe from this list: send the line "unsubscribe linux-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] drm/exynos: consider deferred probe case
On 2014년 06월 04일 20:24, Andrzej Hajda wrote:
> On 05/29/2014 11:28 AM, Inki Dae wrote:
>> This patch makes sure that exynos drm framework handles deferred
>> probe case correctly.
>>
>> Sub drivers could be probed before resources, clock, regulator,
>> phy or panel, are ready for them so we should make sure that exynos
>> drm core waits until all resources are ready and sub drivers are
>> probed correctly.
>>
>> Chagelog v2:
>> - Make sure that exynos drm core tries to bind sub drivers only in case that
>> they have a pair: crtc and encoder/connector components should be a pair.
>
> Do we really need it? It adds lot of code which in fact does not improve
> exynos_drm - if some driver or device is missing drm will fail at load
> or it will start with unusable pipeline anyway, the latter can be
> changed to error as well.
Previous version also incurred unusable pipeline: crtc driver is bound
even though probe of connector/encoder driver returned error. In this
case, the crtc driver would have nothing to do alone without
connector/encoder part.
>
>> - Remove unnecessary patch:
>> drm/exynos: mipi-dsi: consider panel driver-deferred probe
>> - Return error type correctly.
>>
>> Signed-off-by: Inki Dae
>> Acked-by: Kyungmin Park
>> ---
>> drivers/gpu/drm/exynos/exynos_dp_core.c | 18 +++-
>> drivers/gpu/drm/exynos/exynos_drm_dpi.c | 22 -
>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 139
>> +-
>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 13 ++-
>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 41 ++---
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 51 ---
>> drivers/gpu/drm/exynos/exynos_hdmi.c | 78 -
>> drivers/gpu/drm/exynos/exynos_mixer.c| 17 +++-
>> 8 files changed, 304 insertions(+), 75 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index ff63901..a892586 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -1328,12 +1328,26 @@ static const struct component_ops exynos_dp_ops = {
>>
>> static int exynos_dp_probe(struct platform_device *pdev)
>> {
>> -return exynos_drm_component_add(&pdev->dev, &exynos_dp_ops);
>> +int ret;
>> +
>> +ret = exynos_drm_component_add(&pdev->dev, EXYNOS_DEVICE_TYPE_CONNECTOR,
>> +exynos_dp_display.type);
>> +if (ret)
>> +return ret;
>> +
>> +ret = component_add(&pdev->dev, &exynos_dp_ops);
>> +if (ret)
>> +exynos_drm_component_del(&pdev->dev,
>> +EXYNOS_DEVICE_TYPE_CONNECTOR);
>> +
>> +return ret;
>> }
>>
>> static int exynos_dp_remove(struct platform_device *pdev)
>> {
>> -exynos_drm_component_del(&pdev->dev, &exynos_dp_ops);
>> +component_del(&pdev->dev, &exynos_dp_ops);
>> +exynos_drm_component_del(&pdev->dev, EXYNOS_DEVICE_TYPE_CONNECTOR);
>
> As I wrote in the previous comment calling exynos_drm_component_del here
> will cause exynos_drv to stop waiting for exynos_dp to bring up drm
> again, which is wrong. The same comment is valid for all other calls of
> exynos_drm_component_del in *_remove and *_probe.
> Or maybe I miss something???
>
If we remove exynos_drm_component_del calls, the deferred probe case
doesn't work correctly. Assume that connector/encoder driver returned
-EPROBE_DEFER but its corresponding crtc driver worked correctly. In
this case, if we don't call exynos_drm_component_del function at fail
case, exynos drm core will try to bind the sub driver which returned
-EPROBE_DEFER. However, the sub driver will be probed by deferred probe
again, and will call exynos_drm_component_add again. That would be your
missing point.
>> +
>> return 0;
>> }
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
>> b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
>> index a832364..f1b8587 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
>> @@ -295,9 +295,15 @@ struct exynos_drm_display *exynos_dpi_probe(struct
>> device *dev)
>> struct exynos_dpi *ctx;
>> int ret;
>>
>> +ret = exynos_drm_component_add(dev,
>> +EXYNOS_DEVICE_TYPE_CONNECTOR,
>> +exynos_dpi_display.type);
>> +if (ret)
>> +return ERR_PTR(ret);
>> +
>> ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
>> if (!ctx)
>> -return NULL;
>> +goto err_del_component;
>>
>> ctx->dev = dev;
>> exynos_dpi_display.ctx = ctx;
>> @@ -306,16 +312,24 @@ struct exynos_drm_display *exynos_dpi_probe(struct
>> device *dev)
>> ret = exynos_dpi_parse_dt(ctx);
>> if (ret < 0) {
>> devm_kfree(dev, ctx);
>> -return NULL;
>> +goto err_del_component;
>> }
>>
>> if (ctx->panel_node) {
>>
Re: [PATCH] serial: samsung: fix typo in debug code
On Wed, Jun 04, 2014 at 06:20:41PM -0700, Joe Perches wrote:
> On Tue, 2014-06-03 at 11:53 +0200, Arnd Bergmann wrote:
> > commit e4ac92df2791 ("serial: samsung: Neaten dbg uses") introduced
> > a regression in the conversion from vsprintf to vsnprintf.
> >
> > This fixes the build error by passing the correct variable name.
> >
> > Signed-off-by: Arnd Bergmann
> > Cc: Joe Perches
> > Cc: Greg Kroah-Hartman
> > Cc: Doug Anderson
> > Cc: Kukjin Kim
> >
> > diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
> > index 3293377..c1d3ebd 100644
> > --- a/drivers/tty/serial/samsung.c
> > +++ b/drivers/tty/serial/samsung.c
> > @@ -66,7 +66,7 @@ static void dbg(const char *fmt, ...)
> > char buff[256];
> >
> > va_start(va, fmt);
> > - vscnprintf(buff, sizeof(buf), fmt, va);
> > + vscnprintf(buff, sizeof(buff), fmt, va);
> > va_end(va);
> >
> > printascii(buff);
>
> Greg?
>
> The original has ended up in Linus' -next branch.
>
> Can you please apply this sooner rather than later?
Let me work through these 3.4-stable patches first, so give me a day or
so, thanks.
greg k-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
Re: [PATCH v3 13/15] ARM: dts: exynos5: add system register support
Hi Vivek,
On 06/04/2014 08:50 PM, Vivek Gautam wrote:
On Mon, Jun 2, 2014 at 10:52 AM, YoungJun Cho wrote:
This patch adds sysreg device node, and sysreg property
to fimd device node which is required to use I80 interface.
Same here. The system register nodes have been added to exynos5250 and
exynos5420 by the patch:
dfbbdbf ARM: dts: Add sysreg sytem controller node to exynos5250 and exynos5420
May be, you may want to move those two nodes to this common file (exynos5.dtsi).
Thank you for reporting.
I didn't check linux-samsung-soc.
The exynos5410, 5420 and 5422 use system register with base address
0x1005.
But exynos5260 and 5430 are different.
And I can't check exynos5250.
So with this condition, it is reasonable to remove these sysreg relevant
patches.
Thank you.
Best regards YJ
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 79d0608..95ee496 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -81,12 +81,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
--
To unsubscribe from this list: send the line "unsubscribe linux-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] serial: samsung: fix typo in debug code
On Tue, 2014-06-03 at 11:53 +0200, Arnd Bergmann wrote:
> commit e4ac92df2791 ("serial: samsung: Neaten dbg uses") introduced
> a regression in the conversion from vsprintf to vsnprintf.
>
> This fixes the build error by passing the correct variable name.
>
> Signed-off-by: Arnd Bergmann
> Cc: Joe Perches
> Cc: Greg Kroah-Hartman
> Cc: Doug Anderson
> Cc: Kukjin Kim
>
> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
> index 3293377..c1d3ebd 100644
> --- a/drivers/tty/serial/samsung.c
> +++ b/drivers/tty/serial/samsung.c
> @@ -66,7 +66,7 @@ static void dbg(const char *fmt, ...)
> char buff[256];
>
> va_start(va, fmt);
> - vscnprintf(buff, sizeof(buf), fmt, va);
> + vscnprintf(buff, sizeof(buff), fmt, va);
> va_end(va);
>
> printascii(buff);
Greg?
The original has ended up in Linus' -next branch.
Can you please apply this sooner rather than later?
Sorry for the bother. Dunno how it happened.
I thought I compiled it with the appropriate CONFIG
settings.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: dts: Use the cros-ec-keyboard fragment in exynos5250-snow
Signed-off-by: Doug Anderson
---
arch/arm/boot/dts/exynos5250-snow.dts | 93 ++-
1 file changed, 3 insertions(+), 90 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 079fdf9..7bd2df1 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -137,7 +137,7 @@
sbs,poll-retry-count = <1>;
};
- ec: embedded-controller {
+ cros_ec: embedded-controller {
compatible = "google,cros-ec-i2c";
reg = <0x1e>;
interrupts = <6 0>;
@@ -145,95 +145,6 @@
pinctrl-names = "default";
pinctrl-0 = <&ec_irq>;
wakeup-source;
-
- keyboard-controller {
- compatible = "google,cros-ec-keyb";
- keypad,num-rows = <8>;
- keypad,num-columns = <13>;
- google,needs-ghost-filter;
- linux,keymap = <0x0001007d /*
L_META */
- 0x0002003b /* F1 */
- 0x00030030 /* B */
- 0x00040044 /* F10
*/
- 0x00060031 /* N */
- 0x0008000d /* = */
- 0x000a0064 /*
R_ALT */
-
- 0x01010001 /* ESC
*/
- 0x0102003e /* F4 */
- 0x01030022 /* G */
- 0x01040041 /* F7 */
- 0x01060023 /* H */
- 0x01080028 /* ' */
- 0x01090043 /* F9 */
- 0x010b000e /*
BKSPACE */
-
- 0x021d /*
L_CTRL */
- 0x0201000f /* TAB
*/
- 0x0202003d /* F3 */
- 0x02030014 /* T */
- 0x02040040 /* F6 */
- 0x0205001b /* ] */
- 0x02060015 /* Y */
- 0x02070056 /*
102ND */
- 0x0208001a /* [ */
- 0x02090042 /* F8 */
-
- 0x03010029 /*
GRAVE */
- 0x0302003c /* F2 */
- 0x03030006 /* 5 */
- 0x0304003f /* F5 */
- 0x03060007 /* 6 */
- 0x0308000c /* - */
- 0x030b002b /* \ */
-
- 0x0461 /*
R_CTRL */
- 0x0401001e /* A */
- 0x04020020 /* D */
- 0x04030021 /* F */
- 0x0404001f /* S */
- 0x04050025 /* K */
- 0x04060024 /* J */
- 0x04080027 /* ; */
- 0x04090026 /* L */
- 0x040a002b /* \ */
- 0x040b001c /*
ENTER */
-
- 0x0501002c /* Z */
- 0x0502002e /* C */
- 0x050
Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
On Fri, May 30, 2014 at 09:01:19PM +0200, Arnd Bergmann wrote:
> On Friday 30 May 2014 12:22:32 Dave Martin wrote:
> > > +
> > > +Examples:
> > > +=
> > > +
> > > +Single-master IOMMU:
> > > +
> > > +
> > > + iommu {
> > > + #address-cells = <0>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + master {
> > > + iommus = <&/iommu>;
> > > + };
> > > +
> > > +Multiple-master IOMMU with fixed associations:
> > > +--
> > > +
> > > + /* multiple-master IOMMU */
> > > + iommu {
> > > + /*
> > > + * Masters are statically associated with this IOMMU and
> > > + * address translation is always enabled.
> > > + */
> > > + #address-cells = <0>;
> > > + #size-cells = <0>;
> >
> > In this example, can different translations be set up for the different
> > masters?
> >
> > With no cells available to contain any sort of ID, it looks like this
> > is not possible.
>
> Correct, this example is for an IOMMU that does not use IDs but has a
> shared address space for all devices.
Couldn't these device all still have separate address spaces?
Thierry
pgpswaTg3Z3lu.pgp
Description: PGP signature
Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
On Fri, May 30, 2014 at 12:27:28PM +0100, Dave Martin wrote: > On Fri, May 30, 2014 at 08:30:08AM +0100, Thierry Reding wrote: [...] > > Arnd, can you take another look at this binding and see if there's > > anything else missing? If not I'll go through the document again and > > update all #address-cells/#size-cells references with #iommu-cells as > > appropriate and submit v3. > > How do you envisage propagation of the master ID bits downstream of the > IOMMU would be described? > > We will definitely need a way to describe this for GICv3. How those > values are propagated is likely to vary between related SoCs and doesn't > feel like it should be baked into a driver, especially for the ARM SMMU > which may get reused in radically different SoC families from different > vendors. Well, we've had cases like these in the past (power sequences come to mind). Some concepts are just too difficult or unwieldy to be put into device tree. I think that this is one of them. > The most likely types of remapping are the adding of a base offset or > some extra bits to the ID -- because not all MSIs to the GIC will > necessarily pass through the IOMMU. It's also possible that we might > see ID squashing or folding in some systems. It can easily be argued that if the algorithm used to remap the ID varies, the compatibility of the device changes. Therefore I would expect any variant of the GICv3 that deviates from the "standard" mapping (if there is such a thing) to have its own compatible string. At that point there are two possibilities: a) handle the remapping in code hooked into the driver via matching of the compatible string or b) specifying a different specifier for each of these and keep the description in DT. From an implementation point of view, variant b) is likely going to be very similar to a), though (I'm thinking .of_xlate type of functions here). Thierry pgp_inyCP5rEo.pgp Description: PGP signature
Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
On Wed, Jun 04, 2014 at 05:41:32PM +0100, Will Deacon wrote: > On Wed, Jun 04, 2014 at 03:35:10PM +0100, Thierry Reding wrote: > > On Mon, Jun 02, 2014 at 11:41:04AM +0100, Dave Martin wrote: > > > In the strictest sense, no. > > > > > > But for a large set of sane configurations, this probably works. > > > > > > Small sets of randomly-assigned IDs can just be enumerated one by one. > > > > > > We wouldn't be able to describe folding and bit shuffling, but we > > > probably don't want to encourage that anyway. > > > > I'm having some difficulty understanding this. You make it sound like > > there's a fairly arbitrary number of IDs that the SMMU can handle. So > > how is the mapping to devices defined? If you say encourage that does > > make it sound like the assignment of IDs is purely defined by some > > mechanism in software rather than in hardware. Or they are more or less > > randomly picked by someone. If that's the case, is that not something > > that should be dynamically allocated by the kernel rather than put into > > the device tree? > > The set of StreamIDs that can be generated by a master is fixed in the > hardware. The SMMU can then be programmed to map these incoming IDs onto > a context ID (or a set of context IDs), which are the IDs used internally > by the SMMU to find the page tables etc. > > The StreamID -> ContextID mapping is dynamic and controlled by software. > The Master -> StreamIDs mapping is fixed in the hardware. Okay, that sounds similar to what the Tegra SMMU does. The naming is slightly differently. "Master" is called "memory client", "StreamID" would be "SWGROUP" and "ContextID" I guess would map to what's called an "ASID" (Address Space ID) on Tegra. I'm not sure about the amount of leverage that we have to encourage the mappings that we think are easy to describe in DT and discourage those that we don't want. Last time I checked we were still playing catch up rather than being able to give recommendations to hardware engineers about what will result in sane DT content and what won't. Irrespective of the above, I still think that a generic binding based on an #iommu-cells and iommus property gives us the most flexibility. For easy cases, most of which are listed in the current proposal could easily be dealt with in convenience helpers. For the more complex cases drivers for those IOMMUs can define a specifier that make sense for the mappings they need to be able to describe. Also we're talking about a generic IOMMU binding here. That means that if some hardware comes along that's not "generic" and doesn't fit into the constraints set by this binding, then we still have the option of defining a completely different one for that particular case. Thierry pgpgeCZKqAdrG.pgp Description: PGP signature
Re: [PATCH 3/3] clocksource: exynos_mct: Optimize register reads with ldmia
Thomas, On Wed, Jun 4, 2014 at 11:05 AM, Thomas Gleixner wrote: > On Wed, 4 Jun 2014, Doug Anderson wrote: > >> As we saw in (clocksource: exynos_mct: cache mct upper count), the >> time spent reading the MCT shows up fairly high in real-world >> profiles. That means that it's worth some optimization. >> >> We get a roughly 10% speedup in userspace gettimeofday() by using an >> ldmia to read the two halfs of the MCT. That seems like a worthwhile >> thing to do. >> >> Before: 1173084 us for 100 gettimeofday in userspace >> After: 1045674 us for 100 gettimeofday in userspace >> >> NOTE: we could actually do better than this if we really wanted to. >> Technically we could register the clocksource as a 32-bit timer and >> only use the "lower" half. Doing so brings us down to 1014429 us for >> 100 gettimeofday in userspace (and doesn't even require assembly >> code). That would be an alternative to this change. > > I was about to ask exactly that question: What's the advantage of the > 64 bit dance there? AFAICT nothing. I debated whether to send out the 32-bit version, since I'd implemented both. I'm happy to send out the 32-bit version too and people can pick which they like better. Let me know. The final thing that pushed me over the edge to send the 64-bit version was that I didn't know enough about how MCT was used with respect to low power modes (we don't use AFTR / LPA modes on our system). I could actually believe that we might want to set a timer for more than 178 seconds into the future for these low power modes. If that's the case, we still need to keep around the 64-bit read code for that case. ...and once we have the 64-bit code then we might as well use it for the rest of the timers. Perhaps Tomasz will comment on this. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] clocksource: exynos_mct: Optimize register reads with ldmia
On Wed, 4 Jun 2014, Doug Anderson wrote: > As we saw in (clocksource: exynos_mct: cache mct upper count), the > time spent reading the MCT shows up fairly high in real-world > profiles. That means that it's worth some optimization. > > We get a roughly 10% speedup in userspace gettimeofday() by using an > ldmia to read the two halfs of the MCT. That seems like a worthwhile > thing to do. > > Before: 1173084 us for 100 gettimeofday in userspace > After: 1045674 us for 100 gettimeofday in userspace > > NOTE: we could actually do better than this if we really wanted to. > Technically we could register the clocksource as a 32-bit timer and > only use the "lower" half. Doing so brings us down to 1014429 us for > 100 gettimeofday in userspace (and doesn't even require assembly > code). That would be an alternative to this change. I was about to ask exactly that question: What's the advantage of the 64 bit dance there? AFAICT nothing. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] clocksource: exynos_mct: Fix ftrace
In (93bfb76 clocksource: exynos_mct: register sched_clock callback) we
supported using the MCT as a scheduler clock. We properly marked
exynos4_read_sched_clock() as notrace. However, we then went and
called another function that _wasn't_ notrace. That means if you do:
cd /sys/kernel/debug/tracing/
echo function_graph > current_tracer
You'll get a crash.
Fix this (but still let other readers of the MCT be trace-enabled) by
adding an extra function. It's important to keep other users of MCT
traceable because the MCT is actually quite slow.
Signed-off-by: Doug Anderson
---
drivers/clocksource/exynos_mct.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 8d64200..ba3a683 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -165,7 +165,7 @@ static void exynos4_mct_frc_start(u32 hi, u32 lo)
exynos4_mct_write(reg, EXYNOS4_MCT_G_TCON);
}
-static cycle_t exynos4_frc_read(struct clocksource *cs)
+static inline cycle_t notrace _exynos4_frc_read(void)
{
unsigned int lo, hi;
u32 hi2 = __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_U);
@@ -179,6 +179,11 @@ static cycle_t exynos4_frc_read(struct clocksource *cs)
return ((cycle_t)hi << 32) | lo;
}
+static cycle_t exynos4_frc_read(struct clocksource *cs)
+{
+ return _exynos4_frc_read();
+}
+
static void exynos4_frc_resume(struct clocksource *cs)
{
exynos4_mct_frc_start(0, 0);
@@ -195,7 +200,7 @@ struct clocksource mct_frc = {
static u64 notrace exynos4_read_sched_clock(void)
{
- return exynos4_frc_read(&mct_frc);
+ return _exynos4_frc_read();
}
static void __init exynos4_clocksource_init(void)
--
2.0.0.526.g5318336
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] clocksource: exynos_mct: cache mct upper count
From: Mandeep Singh Baines
Saves one register read. Note that the upper count only changes every
~178 seconds with a 24MHz source clock, so it's likely it hasn't
changed from call to call.
Before: 1323852 us for 100 gettimeofday in userspace
After: 1173084 us for 100 gettimeofday in userspace
Note that even with this change the CPU is in exynos_frc_read() more
than 2% of the time in real world profiles of ChromeOS. That
indicates that it's important to optimize.
Signed-off-by: Mandeep Singh Baines
Signed-off-by: Andrew Bresticker
Signed-off-by: Doug Anderson
---
drivers/clocksource/exynos_mct.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index ba3a683..7cbe4aa 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -167,8 +167,8 @@ static void exynos4_mct_frc_start(u32 hi, u32 lo)
static inline cycle_t notrace _exynos4_frc_read(void)
{
- unsigned int lo, hi;
- u32 hi2 = __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_U);
+ u32 lo, hi;
+ static u32 hi2;
do {
hi = hi2;
--
2.0.0.526.g5318336
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] clocksource: exynos_mct: Optimize register reads with ldmia
As we saw in (clocksource: exynos_mct: cache mct upper count), the
time spent reading the MCT shows up fairly high in real-world
profiles. That means that it's worth some optimization.
We get a roughly 10% speedup in userspace gettimeofday() by using an
ldmia to read the two halfs of the MCT. That seems like a worthwhile
thing to do.
Before: 1173084 us for 100 gettimeofday in userspace
After: 1045674 us for 100 gettimeofday in userspace
NOTE: we could actually do better than this if we really wanted to.
Technically we could register the clocksource as a 32-bit timer and
only use the "lower" half. Doing so brings us down to 1014429 us for
100 gettimeofday in userspace (and doesn't even require assembly
code). That would be an alternative to this change.
Signed-off-by: Doug Anderson
---
drivers/clocksource/exynos_mct.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 7cbe4aa..6e3017b 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -172,8 +172,9 @@ static inline cycle_t notrace _exynos4_frc_read(void)
do {
hi = hi2;
- lo = __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_L);
- hi2 = __raw_readl(reg_base + EXYNOS4_MCT_G_CNT_U);
+ asm volatile("ldmia %2, {%0, %1}"
+: "=r" (lo), "=r" (hi2)
+: "r" (reg_base + EXYNOS4_MCT_G_CNT_L));
} while (hi != hi2);
return ((cycle_t)hi << 32) | lo;
--
2.0.0.526.g5318336
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
On Wed, Jun 04, 2014 at 03:35:10PM +0100, Thierry Reding wrote: > On Mon, Jun 02, 2014 at 11:41:04AM +0100, Dave Martin wrote: > > In the strictest sense, no. > > > > But for a large set of sane configurations, this probably works. > > > > Small sets of randomly-assigned IDs can just be enumerated one by one. > > > > We wouldn't be able to describe folding and bit shuffling, but we > > probably don't want to encourage that anyway. > > I'm having some difficulty understanding this. You make it sound like > there's a fairly arbitrary number of IDs that the SMMU can handle. So > how is the mapping to devices defined? If you say encourage that does > make it sound like the assignment of IDs is purely defined by some > mechanism in software rather than in hardware. Or they are more or less > randomly picked by someone. If that's the case, is that not something > that should be dynamically allocated by the kernel rather than put into > the device tree? The set of StreamIDs that can be generated by a master is fixed in the hardware. The SMMU can then be programmed to map these incoming IDs onto a context ID (or a set of context IDs), which are the IDs used internally by the SMMU to find the page tables etc. The StreamID -> ContextID mapping is dynamic and controlled by software. The Master -> StreamIDs mapping is fixed in the hardware. Will -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
On Wed, Jun 04, 2014 at 03:01:15PM +0100, Arnd Bergmann wrote: > On Wednesday 04 June 2014 14:56:01 Will Deacon wrote: > > On Wed, Jun 04, 2014 at 02:44:03PM +0100, Thierry Reding wrote: > > > On Fri, May 30, 2014 at 09:54:37PM +0200, Arnd Bergmann wrote: > > > > On Friday 30 May 2014 22:29:13 Hiroshi Doyu wrote: > > > > > The disadvantage of this is that this limits the max number of > > > > > streamIDs > > > > > to support. If # of streamID is increased later more than 64, this > > > > > format cannot cover any more. You have to predict the max # of > > > > > streamIDs > > > > > in advance if steamID is statically assigned. > > > > > > > > > > > > > Well, the iommu specific binding could allow a variable #address-cells. > > > > That way, you just need to know the number of stream IDs for that > > > > instance > > > > of the iommu. > > > > > > That sounds fairly complicated to me. I don't see what that buys us over > > > the clarity and simplicity that the above explicit notation gives us. Is > > > it not more common for a device to have a single master rather than a > > > whole bunch of them? > > > > I've never seen a device upstream of an ARM SMMU with a single stream-id; > > they always seem to have a whole bunch of them. Calxeda's SATA controller > > had 10 IDs, for example, and a PL330 DMA controller tends to have at least > > 3. > > What are those good for? Would we just always use the first one? I think It's just an artifact of how these systems tend to be built. The StreamID is constructed out of bits on the bus (AXI and sideband), so a DMA controller could easily have one ID for reads, one for writes, one for execute. Masters capable of multiple outstanding transactions could also have sets of IDs too. The SMMU driver would point them all at the same context bank, as far as I can tell, but that means the driver does need to be aware of the incoming IDs. Rob might know how they constructed the IDs on the Calxeda SATA controller? Will -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
On Mon, Jun 02, 2014 at 11:41:04AM +0100, Dave Martin wrote:
> On Fri, May 30, 2014 at 09:49:59PM +0200, Arnd Bergmann wrote:
> > On Friday 30 May 2014 14:31:55 Rob Herring wrote:
> > > On Fri, May 30, 2014 at 2:06 PM, Arnd Bergmann wrote:
> > > > On Friday 30 May 2014 08:16:05 Rob Herring wrote:
> > > >> On Fri, May 23, 2014 at 3:33 PM, Thierry Reding
> > > >> wrote:
> > > >> > From: Thierry Reding
> > > >> > +IOMMU master node:
> > > >> > +==
> > > >> > +
> > > >> > +Devices that access memory through an IOMMU are called masters. A
> > > >> > device can
> > > >> > +have multiple master interfaces (to one or more IOMMU devices).
> > > >> > +
> > > >> > +Required properties:
> > > >> > +
> > > >> > +- iommus: A list of phandle and IOMMU specifier pairs that describe
> > > >> > the IOMMU
> > > >> > + master interfaces of the device. One entry in the list describes
> > > >> > one master
> > > >> > + interface of the device.
> > > >> > +
> > > >> > +When an "iommus" property is specified in a device tree node, the
> > > >> > IOMMU will
> > > >> > +be used for address translation. If a "dma-ranges" property exists
> > > >> > in the
> > > >> > +device's parent node it will be ignored. An exception to this rule
> > > >> > is if the
> > > >> > +referenced IOMMU is disabled, in which case the "dma-ranges"
> > > >> > property of the
> > > >> > +parent shall take effect.
> > > >>
> > > >> Just thinking out loud, could you have dma-ranges in the iommu node
> > > >> for the case when the iommu is enabled rather than putting the DMA
> > > >> window information into the iommus property?
> > > >>
> > > >> This would probably mean that you need both #iommu-cells and
> > > >> #address-cells.
> > > >
> > > > The reason for doing like this was that you may need a different window
> > > > for each device, while there can only be one dma-ranges property in
> > > > an iommu node.
> > >
> > > My suggestion was that you also put the IDs in the dma-ranges as the
> > > first cell much as ranges for PCI encodes other information in the
> > > first cell. Then you can have an entry for each ID. The downside is
> > > another special case like PCI.
> > >
> > > The argument for using #address-cells and #size-cells seems to be to
> > > align with how ranges work. If that's the route we want to go, then I
> > > say we should not stop there and actually use dma-ranges as well.
> > > Otherwise, I don't see the advantage over #iommu-cells.
> >
> > I can see how dma-ranges in bus nodes work, it just doesn't seem to
> > have any reasonable meaning in the iommu node itself.
>
> dma-ranges defines a static mapping for mastering through the bus node.
>
> The whole point of an IOMMU is that it maps dynamically, so I agree:
> I'm unclear on what dma-ranges should mean in the IOMMU node itself
> (if anything).
>
> >
> > > > I don't understand the problem. If you have stream IDs 0 through 7,
> > > > you would have
> > > >
> > > > master@a {
> > > > ...
> > > > iommus = <&smmu 0>;
> > > > };
> > > >
> > > > master@b {
> > > > ...
> > > > iommus = <&smmu 1;
> > > > };
> > > >
> > > > ...
> > > >
> > > > master@12 {
> > > > ...
> > > > iommus = <&smmu 7;
> > > > };
> > > >
> > > > and you don't need a window at all. Why would you need a mask of
> > > > some sort?
> > >
> > > 1 master with 7 IDs like this:
> > >
> > > master@a {
> > > ...
> > > iommus = <&smmu 0> <&smmu 1> <&smmu 2> <&smmu 3>
> > > <&smmu 4> <&smmu 5> <&smmu 6> <&smmu 7>;
> > > };
> > >
> > > If there was any sort of window, then it is almost certainly the same
> > > window for each ID.
>
> Do we have real examples of using a window *and* an ID? I thought the
> windowed-IOMMU concept was partly a way of encoding the ID in some
> real address bits on the bus. If you're doing that, it seems less likely
> that there is a true "ID" as such (though it is possible).
>
> > Ok, I see. In that case you'd probably want to have #address-cells = <1>
> > and #size-cells = <1> and give a range of IDs like
> >
> > iommus = <&smmu 0 8>;
> >
> > Do you think that ranges can have a meaningful definition with the ARM
> > SMMU stream IDs?
>
> In the strictest sense, no.
>
> But for a large set of sane configurations, this probably works.
>
> Small sets of randomly-assigned IDs can just be enumerated one by one.
>
> We wouldn't be able to describe folding and bit shuffling, but we
> probably don't want to encourage that anyway.
I'm having some difficulty understanding this. You make it sound like
there's a fairly arbitrary number of IDs that the SMMU can handle. So
how is the mapping to devices defined? If you say encourage that does
make it sound like the assignment of IDs is purely defined by some
mechanism in software rather than in
Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
On Wednesday 04 June 2014 14:56:01 Will Deacon wrote: > On Wed, Jun 04, 2014 at 02:44:03PM +0100, Thierry Reding wrote: > > On Fri, May 30, 2014 at 09:54:37PM +0200, Arnd Bergmann wrote: > > > On Friday 30 May 2014 22:29:13 Hiroshi Doyu wrote: > > > > The disadvantage of this is that this limits the max number of streamIDs > > > > to support. If # of streamID is increased later more than 64, this > > > > format cannot cover any more. You have to predict the max # of streamIDs > > > > in advance if steamID is statically assigned. > > > > > > > > > > Well, the iommu specific binding could allow a variable #address-cells. > > > That way, you just need to know the number of stream IDs for that instance > > > of the iommu. > > > > That sounds fairly complicated to me. I don't see what that buys us over > > the clarity and simplicity that the above explicit notation gives us. Is > > it not more common for a device to have a single master rather than a > > whole bunch of them? > > I've never seen a device upstream of an ARM SMMU with a single stream-id; > they always seem to have a whole bunch of them. Calxeda's SATA controller > had 10 IDs, for example, and a PL330 DMA controller tends to have at least > 3. What are those good for? Would we just always use the first one? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
On Wed, Jun 04, 2014 at 02:44:03PM +0100, Thierry Reding wrote: > On Fri, May 30, 2014 at 09:54:37PM +0200, Arnd Bergmann wrote: > > On Friday 30 May 2014 22:29:13 Hiroshi Doyu wrote: > > > The disadvantage of this is that this limits the max number of streamIDs > > > to support. If # of streamID is increased later more than 64, this > > > format cannot cover any more. You have to predict the max # of streamIDs > > > in advance if steamID is statically assigned. > > > > > > > Well, the iommu specific binding could allow a variable #address-cells. > > That way, you just need to know the number of stream IDs for that instance > > of the iommu. > > That sounds fairly complicated to me. I don't see what that buys us over > the clarity and simplicity that the above explicit notation gives us. Is > it not more common for a device to have a single master rather than a > whole bunch of them? I've never seen a device upstream of an ARM SMMU with a single stream-id; they always seem to have a whole bunch of them. Calxeda's SATA controller had 10 IDs, for example, and a PL330 DMA controller tends to have at least 3. Will -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
On Wednesday 04 June 2014 15:44:03 Thierry Reding wrote: > > Well, the iommu specific binding could allow a variable #address-cells. > > That way, you just need to know the number of stream IDs for that instance > > of the iommu. > > That sounds fairly complicated to me. I don't see what that buys us over > the clarity and simplicity that the above explicit notation gives us. Is > it not more common for a device to have a single master rather than a > whole bunch of them? If I understood the problem right, the case that people want to handle is not actually multiple masters but instead multiple IOMMU contexts, which you can have in a GPU to handle multiple processes drawing on different parts of the screen, or in a NIC with virtual functions assigned to KVM guests or user processes. I don't know what the number of contexts per device would be here, but I assume it may be large enough to become a nuisance to list them individually. Then again, I also don't know how IOMMUs would show those. In the cases I've seen before, you actually have an ID for the master that is separate from the context ID, but apparently SMMU isn't that smart. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
On Fri, May 30, 2014 at 09:54:37PM +0200, Arnd Bergmann wrote:
> On Friday 30 May 2014 22:29:13 Hiroshi Doyu wrote:
> >
> > IIUC the original problem, "a master with 8 streamIDs" means something
> > like below, where some devices have multiple IDs but some have a
> > single. A sinle #address-cells cannot afford those 2 masters at once.
> >
> >iommu {
> >/* the specifier represents the ID of the master */
> >#address-cells = <1>;
> >#size-cells = <0>;
> >};
> >
> > master@a {
> > ...
> > iommus = <&smmu 1 2 3>; # 3 IDs
> > };
> >
> > master@b {
> > ...
> > iommus = <&smmu 4>; # 1 ID
> > };
>
> This would not be the usual format really. It should instead be
>
> iommus = <&smmu 1>, <&smmu 2>, <&smmu 3>;
>
> which can be tedious to type.
"Tedious to type" doesn't sound like a good argument to me. I don't see
why the above would necessarily be a bad notation. It's very much up to
the point and very explicit. This very obviously translates to:
This device has three master interfaces, one for smmu ID 1, one
for smmu ID 2 and one for smmu ID 3.
> > Tegra,SMMU has a similar problem and we have used a fixed size bitmap(64
> > bit) to afford 64 stream IDs so that a single device can hold multiple
> > IDs. If we apply the same bitmap to the above exmaple:
> >
> >iommu {
> >/* the specifier represents the ID of the master */
> >#address-cells = <1>;
> >#size-cells = <0>;
> >};
> >
> > master@a {
> > ...
> > iommus = <&smmu (BIT(1) | BIT(2) | BIT(3))>; # IDs 1 2 3
> > };
> >
> > master@b {
> > ...
> > iommus = <&smmu BIT(4)>; # ID 4
> > };
> >
> > The disadvantage of this is that this limits the max number of streamIDs
> > to support. If # of streamID is increased later more than 64, this
> > format cannot cover any more. You have to predict the max # of streamIDs
> > in advance if steamID is statically assigned.
> >
>
> Well, the iommu specific binding could allow a variable #address-cells.
> That way, you just need to know the number of stream IDs for that instance
> of the iommu.
That sounds fairly complicated to me. I don't see what that buys us over
the clarity and simplicity that the above explicit notation gives us. Is
it not more common for a device to have a single master rather than a
whole bunch of them?
Thierry
pgpyUy1Lx2PG8.pgp
Description: PGP signature
Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings
On Sun, Jun 01, 2014 at 10:55:46AM +0100, Will Deacon wrote:
> On Fri, May 30, 2014 at 08:54:37PM +0100, Arnd Bergmann wrote:
> > On Friday 30 May 2014 22:29:13 Hiroshi Doyu wrote:
> > > Tegra,SMMU has a similar problem and we have used a fixed size bitmap(64
> > > bit) to afford 64 stream IDs so that a single device can hold multiple
> > > IDs. If we apply the same bitmap to the above exmaple:
> > >
> > >iommu {
> > >/* the specifier represents the ID of the master */
> > >#address-cells = <1>;
> > >#size-cells = <0>;
> > >};
> > >
> > > master@a {
> > > ...
> > > iommus = <&smmu (BIT(1) | BIT(2) | BIT(3))>; # IDs 1 2 3
> > > };
> > >
> > > master@b {
> > > ...
> > > iommus = <&smmu BIT(4)>; # ID 4
> > > };
> > >
> > > The disadvantage of this is that this limits the max number of streamIDs
> > > to support. If # of streamID is increased later more than 64, this
> > > format cannot cover any more. You have to predict the max # of streamIDs
> > > in advance if steamID is statically assigned.
> > >
> >
> > Well, the iommu specific binding could allow a variable #address-cells.
> > That way, you just need to know the number of stream IDs for that instance
> > of the iommu.
>
> In general, though, the SMMU will be able to support a large number of
> stream IDs (say a 16-bit space). The restriction we're interested in here is
> how many different stream IDs can be emitted by a single master device
> coming into the SMMU. *That* is a property of the master, not the SMMU.
>
> In the current arm,smmu binding I have a #stream-id-cells property in each
> master. I can then feed that straight into of_parse_phandle_with_args to
> enumerate the IDs for that master. The problem with that is we're
> artificially restricted by MAX_PHANDLE_ARGS.
Maybe I don't fully understand, but since we leave it up to the IOMMU
binding to define the exact meaning of #iommu-cells, can't you simply
use that to your advantage and define something like:
iommus = <&smmu 0 7>;
to mean IDs 0 to 7 for this particular IOMMU type?
Thierry
pgpheD_P9pXp8.pgp
Description: PGP signature
Re: [PATCH v2 6/6] usb: host: ohci-exynos: Use devm_ioremap_resource instead of devm_ioremap
On Wed, Jun 04, 2014 at 03:41:20PM +0530, Vivek Gautam wrote:
> Hi,
>
>
> On Sat, May 10, 2014 at 5:30 PM, Vivek Gautam
> wrote:
> > Using devm_ioremap_resource() API should actually be preferred over
> > devm_ioremap(), since the former request the mem region first and then
> > gives back the ioremap'ed memory pointer.
> > devm_ioremap_resource() calls request_mem_region(), therby preventing
> > other drivers to make any overlapping call to the same region.
> >
> > Signed-off-by: Vivek Gautam
>
> Although this patch and rest in the series are merged.
> But i have got a doubt, so making this thread alive.
>
> > ---
> > drivers/usb/host/ohci-exynos.c |7 +++
> > 1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
> > index 9cf80cb..dec691d 100644
> > --- a/drivers/usb/host/ohci-exynos.c
> > +++ b/drivers/usb/host/ohci-exynos.c
> > @@ -120,10 +120,9 @@ skip_phy:
> >
> > hcd->rsrc_start = res->start;
> > hcd->rsrc_len = resource_size(res);
> > - hcd->regs = devm_ioremap(&pdev->dev, res->start, hcd->rsrc_len);
> > - if (!hcd->regs) {
> > - dev_err(&pdev->dev, "Failed to remap I/O memory\n");
> > - err = -ENOMEM;
> > + hcd->regs = devm_ioremap_resource(&pdev->dev, res);
>
> Here, we replaced devm_ioremap() call with devm_ioremap_resource(),
> which internally requests the memory region
I guess this could lead to problems if drivers haven't been written to
cleanly split the register ranges that they access, since now two
overlapping regions may be requested and cause the drivers to fail.
> and then does a "devm_ioremap()" or "devm_ioremap_nocache()" based on
> the check for IORESOURCE_CACHEABLE flag.
>
> But this flag is not set for the resource of this device.
> So should we be explicitly setting the flag in driver ?
I don't think it makes much sense to map these registers cached anyway.
Drivers will likely expect writes to this region to take effect without
needing any kind of flushing.
Thierry
pgpsFrtvOozPs.pgp
Description: PGP signature
Re: [PATCH v6 6/7] arm64: KVM: Set physical address size related factors in runtime
On Mon, Jun 02, 2014 at 05:11:39PM +0900, Jungseok Lee wrote: > On Tuesday, May 27, 2014 11:03 PM, Christoffer Dall wrote: > > On Tue, May 27, 2014 at 03:53:49PM +0200, Christoffer Dall wrote: > > > On Mon, May 12, 2014 at 06:40:54PM +0900, Jungseok Lee wrote: > > > > This patch sets TCR_EL2.PS, VTCR_EL2.T0SZ and vttbr_baddr_mask in > > > > runtime, > > > > not compile time. > > > > > > > > In ARMv8, EL2 physical address size (TCR_EL2.PS) and stage2 input > > > > address > > > > size (VTCR_EL2.T0SZE) cannot be determined in compile time since they > > > > depends on hardware capability. > > > > > > s/depends/depend/ > > > > > > > > > > > According to Table D4-23 and Table D4-25 in ARM DDI 0487A.b document, > > > > vttbr_x is calculated using different hard-coded values with > > > > consideration > > > > > > super nit: I guess this is fixed values, and not hard-coded values > > > > > > > of T0SZ, granule size and the level of translation tables. Therefore, > > > > vttbr_baddr_mask should be determined dynamically. > > > > > > so I think there's a deeper issue here, which is that we're not > > > currently considering that for a given supported physical address size > > > (run-time) and given page granularity (compile-time), we may have some > > > flexibility in choosing the VTCR_EL2.SL0 field, and thereby the size of > > > the initial stage2 pgd, by concatinating the initial level page tables. > > > > > > Additionally, the combinations of the givens may also force us to choose > > > a specific SL0 value. > > > > > > Policy-wise, I would say we should concatenate as many initial level page > > > tables as possible when using 4K pages, iow. always set VTCR_EL2.SL0 to > > > the lowest possible value given the PARange and page size config we have > > > at hand. That should always provide increased performance for VMs at > > > the cost of maximum 16 concatenated tables, which is a 64K contiguous > > > allocation and alignment, for 4K pages. > > > > > > For 64K pages, it becomes a 256K alignment and contiguous allocation > > > requirement. One could argue that if this is not possible on your > > > system, then you have no business runninng VMs on there, but I want to > > > leave this open for comments... > > > > > Just had a brief chat with Marc, and he made me think of the fact that > > we cannot decide this freely, because the code in kvm_mmu.c assumes that > > the stage-2 page tables have the same number of levels etc. as the host > > kernel (we re-use functions like pud_offset, pud_addr_end, etc. etc.). > > > > I'm not sure this can always be aligned, so we may have to write our own > > kvm_... versions of these to accomodate the best policy for KVM. > > I agree with your opinion in performance and long-term perspective. We > should consider all combinations and re-write code if needed. > > However, I'm not sure that this work should be included in this patch series. > > If this functionality is needed, it would be good to prepare the work as > a separate patchset and drop off the last 2 KVM patches. Instead, 4 level > features should be marked as EXPERIMENTAL. > If you want to get the 4-level page tables merged earlier you should make sure KVM gets disabled when this feature is enabled, but it would be a bit of shame now that you're already worked a lot on this code. I would be very happy to see patches from you fixing this properly, but I understand it is developing into something of an effort. -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
Re: [PATCH v2 2/2] s5p-mfc: Adding MFC v7 and v8 firmwares
On Wed, 2014-06-04 at 13:08 +0200, Kamil Debski wrote: > Hi Arun, Ben, > > > > From: arunkk.sams...@gmail.com [mailto:arunkk.sams...@gmail.com] On > > Behalf Of Arun Kumar K > > Sent: Wednesday, June 04, 2014 7:32 AM > > > > Hi Ben, > > > > On Wed, Jun 4, 2014 at 4:56 AM, Ben Hutchings > > wrote: > > > On Tue, 2014-06-03 at 20:34 +0100, Ben Hutchings wrote: > > >> On Wed, 2014-05-21 at 18:11 +0530, Arun Kumar K wrote: > > >> > Adding the following firmware files for MFC > > >> > s5p-mfc-v7.fw: Used in exynos 5420 > > >> > s5p-mfc-v8.fw: Used in exynos 5800 > > >> > > > >> > Signed-off-by: Arun Kumar K > > >> > --- > > >> > Changes from v1 > > >> > - None > > >> > --- > > >> > WHENCE|2 ++ > > >> > s5p-mfc/s5p-mfc-v7.fw | Bin 0 -> 382724 bytes > > >> > s5p-mfc/s5p-mfc-v8.fw | Bin 0 -> 360576 bytes > > >> > 3 files changed, 2 insertions(+) > > >> > create mode 100644 s5p-mfc/s5p-mfc-v7.fw create mode 100644 > > >> > s5p-mfc/s5p-mfc-v8.fw > > >> [...] > > >> > > >> Applied, thanks. > > > > > > Just noticed a problem with all the s5p-mfc firmware: you are putting > > > it in the s5p-mfc subdirectory, so distribution packages will install > > > them in /lib/firmware/s5p-mfc. However, unless I'm mistaken your > > > driver requests it with a bare filename (e.g. "s5p-mfc-v7.fw") so it > > > won't be found. > > > > > > > Yes this issue is there. > > Kamil, are you ok with changing the fw load path to s5p-mfc/s5p-mfc*.fw > > in the driver? > > We have two options here: > 1) Change the driver to request s5p-mfc/sp5-mfc-fw* > 2) Move the files in the firmware repository > > I would opt for the second option. The driver was uploaded before the > firmware. I see that there are many firmware files in the root folder > of the repository > > Ben, what is your opinion? Which is preferred: creating subdirectories > or storing firmware in the root folder? I prefer subdirectories, but compatibility wins. So I'll apply the following patch if no-one objects. Ben. --- Subject: Move the s5p-mfc firmware out of its subdirectory The driver does not include this subdirectory name when requesting firmware. Signed-off-by: Ben Hutchings --- WHENCE | 10 +- s5p-mfc/s5p-mfc-v6-v2.fw => s5p-mfc-v6-v2.fw | Bin s5p-mfc/s5p-mfc-v6.fw => s5p-mfc-v6.fw | Bin s5p-mfc/s5p-mfc-v7.fw => s5p-mfc-v7.fw | Bin s5p-mfc/s5p-mfc-v8.fw => s5p-mfc-v8.fw | Bin s5p-mfc/s5p-mfc.fw => s5p-mfc.fw | Bin 6 files changed, 5 insertions(+), 5 deletions(-) rename s5p-mfc/s5p-mfc-v6-v2.fw => s5p-mfc-v6-v2.fw (100%) rename s5p-mfc/s5p-mfc-v6.fw => s5p-mfc-v6.fw (100%) rename s5p-mfc/s5p-mfc-v7.fw => s5p-mfc-v7.fw (100%) rename s5p-mfc/s5p-mfc-v8.fw => s5p-mfc-v8.fw (100%) rename s5p-mfc/s5p-mfc.fw => s5p-mfc.fw (100%) diff --git a/WHENCE b/WHENCE index 6a64fc2..a172f5f 100644 --- a/WHENCE +++ b/WHENCE @@ -2250,11 +2250,11 @@ Licence: Redistributable. See LICENCE.atheros_firmware for details Driver: s5p-mfc - Samsung MFC video encoder/decoder driver -File: s5p-mfc/s5p-mfc.fw -File: s5p-mfc/s5p-mfc-v6.fw -File: s5p-mfc/s5p-mfc-v6-v2.fw -File: s5p-mfc/s5p-mfc-v7.fw -File: s5p-mfc/s5p-mfc-v8.fw +File: s5p-mfc.fw +File: s5p-mfc-v6.fw +File: s5p-mfc-v6-v2.fw +File: s5p-mfc-v7.fw +File: s5p-mfc-v8.fw Licence: Samsung grants permission to use and redistribute aforementioned firmware diff --git a/s5p-mfc/s5p-mfc-v6-v2.fw b/s5p-mfc-v6-v2.fw similarity index 100% rename from s5p-mfc/s5p-mfc-v6-v2.fw rename to s5p-mfc-v6-v2.fw diff --git a/s5p-mfc/s5p-mfc-v6.fw b/s5p-mfc-v6.fw similarity index 100% rename from s5p-mfc/s5p-mfc-v6.fw rename to s5p-mfc-v6.fw diff --git a/s5p-mfc/s5p-mfc-v7.fw b/s5p-mfc-v7.fw similarity index 100% rename from s5p-mfc/s5p-mfc-v7.fw rename to s5p-mfc-v7.fw diff --git a/s5p-mfc/s5p-mfc-v8.fw b/s5p-mfc-v8.fw similarity index 100% rename from s5p-mfc/s5p-mfc-v8.fw rename to s5p-mfc-v8.fw diff --git a/s5p-mfc/s5p-mfc.fw b/s5p-mfc.fw similarity index 100% rename from s5p-mfc/s5p-mfc.fw rename to s5p-mfc.fw -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Re: [PATCH v3 13/15] ARM: dts: exynos5: add system register support
On Mon, Jun 2, 2014 at 10:52 AM, YoungJun Cho wrote:
> This patch adds sysreg device node, and sysreg property
> to fimd device node which is required to use I80 interface.
Same here. The system register nodes have been added to exynos5250 and
exynos5420 by the patch:
dfbbdbf ARM: dts: Add sysreg sytem controller node to exynos5250 and exynos5420
May be, you may want to move those two nodes to this common file (exynos5.dtsi).
>
> 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 79d0608..95ee496 100644
> --- a/arch/arm/boot/dts/exynos5.dtsi
> +++ b/arch/arm/boot/dts/exynos5.dtsi
> @@ -81,12 +81,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
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 03/15] ARM: dts: sysreg: add exynos5 compatible to DT bindings
Hi, On Mon, Jun 2, 2014 at 10:52 AM, YoungJun Cho wrote: > This patch adds relevant to exynos5 compatible for exynos5 SoCs. This change is not required. Please check the latest 'for-next' branch of linux-samsung tree. Recently a patch "dfbbdbf ARM: dts: Add sysreg sytem controller node to exynos5250 and exynos5420" has already updated this binding information. > > 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 -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] drm/exynos: consider deferred probe case
On 05/29/2014 11:28 AM, Inki Dae wrote:
> This patch makes sure that exynos drm framework handles deferred
> probe case correctly.
>
> Sub drivers could be probed before resources, clock, regulator,
> phy or panel, are ready for them so we should make sure that exynos
> drm core waits until all resources are ready and sub drivers are
> probed correctly.
>
> Chagelog v2:
> - Make sure that exynos drm core tries to bind sub drivers only in case that
> they have a pair: crtc and encoder/connector components should be a pair.
Do we really need it? It adds lot of code which in fact does not improve
exynos_drm - if some driver or device is missing drm will fail at load
or it will start with unusable pipeline anyway, the latter can be
changed to error as well.
> - Remove unnecessary patch:
> drm/exynos: mipi-dsi: consider panel driver-deferred probe
> - Return error type correctly.
>
> Signed-off-by: Inki Dae
> Acked-by: Kyungmin Park
> ---
> drivers/gpu/drm/exynos/exynos_dp_core.c | 18 +++-
> drivers/gpu/drm/exynos/exynos_drm_dpi.c | 22 -
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 139
> +-
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 13 ++-
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 41 ++---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 51 ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 78 -
> drivers/gpu/drm/exynos/exynos_mixer.c| 17 +++-
> 8 files changed, 304 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index ff63901..a892586 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1328,12 +1328,26 @@ static const struct component_ops exynos_dp_ops = {
>
> static int exynos_dp_probe(struct platform_device *pdev)
> {
> - return exynos_drm_component_add(&pdev->dev, &exynos_dp_ops);
> + int ret;
> +
> + ret = exynos_drm_component_add(&pdev->dev, EXYNOS_DEVICE_TYPE_CONNECTOR,
> + exynos_dp_display.type);
> + if (ret)
> + return ret;
> +
> + ret = component_add(&pdev->dev, &exynos_dp_ops);
> + if (ret)
> + exynos_drm_component_del(&pdev->dev,
> + EXYNOS_DEVICE_TYPE_CONNECTOR);
> +
> + return ret;
> }
>
> static int exynos_dp_remove(struct platform_device *pdev)
> {
> - exynos_drm_component_del(&pdev->dev, &exynos_dp_ops);
> + component_del(&pdev->dev, &exynos_dp_ops);
> + exynos_drm_component_del(&pdev->dev, EXYNOS_DEVICE_TYPE_CONNECTOR);
As I wrote in the previous comment calling exynos_drm_component_del here
will cause exynos_drv to stop waiting for exynos_dp to bring up drm
again, which is wrong. The same comment is valid for all other calls of
exynos_drm_component_del in *_remove and *_probe.
Or maybe I miss something???
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> index a832364..f1b8587 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> @@ -295,9 +295,15 @@ struct exynos_drm_display *exynos_dpi_probe(struct
> device *dev)
> struct exynos_dpi *ctx;
> int ret;
>
> + ret = exynos_drm_component_add(dev,
> + EXYNOS_DEVICE_TYPE_CONNECTOR,
> + exynos_dpi_display.type);
> + if (ret)
> + return ERR_PTR(ret);
> +
> ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> if (!ctx)
> - return NULL;
> + goto err_del_component;
>
> ctx->dev = dev;
> exynos_dpi_display.ctx = ctx;
> @@ -306,16 +312,24 @@ struct exynos_drm_display *exynos_dpi_probe(struct
> device *dev)
> ret = exynos_dpi_parse_dt(ctx);
> if (ret < 0) {
> devm_kfree(dev, ctx);
> - return NULL;
> + goto err_del_component;
> }
>
> if (ctx->panel_node) {
> ctx->panel = of_drm_find_panel(ctx->panel_node);
> - if (!ctx->panel)
> + if (!ctx->panel) {
> + exynos_drm_component_del(dev,
> + EXYNOS_DEVICE_TYPE_CONNECTOR);
> return ERR_PTR(-EPROBE_DEFER);
> + }
> }
>
> return &exynos_dpi_display;
> +
> +err_del_component:
> + exynos_drm_component_del(dev, EXYNOS_DEVICE_TYPE_CONNECTOR);
> +
> + return NULL;
> }
>
> int exynos_dpi_remove(struct device *dev)
> @@ -327,5 +341,7 @@ int exynos_dpi_remove(struct device *dev)
> encoder->funcs->destroy(encoder);
> drm_connector_cleanup(&ctx->connector);
>
> + exynos_drm_component_del(dev, EXYNOS_DEVICE_TYPE_CONNECTOR);
> +
> return 0;
> }
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>
Re: [PATCH v2] drm/exynos: consider deferred probe case
On 05/29/2014 11:28 AM, Inki Dae wrote:
> This patch makes sure that exynos drm framework handles deferred
> probe case correctly.
>
> Sub drivers could be probed before resources, clock, regulator,
> phy or panel, are ready for them so we should make sure that exynos
> drm core waits until all resources are ready and sub drivers are
> probed correctly.
>
> Chagelog v2:
> - Make sure that exynos drm core tries to bind sub drivers only in case that
> they have a pair: crtc and encoder/connector components should be a pair.
Do we really need it? It adds lot of code which in fact does not improve
exynos_drm - if some driver or device is missing drm will fail at load
or it will start with unusable pipeline anyway, the latter can be
changed to error as well.
> - Remove unnecessary patch:
> drm/exynos: mipi-dsi: consider panel driver-deferred probe
> - Return error type correctly.
>
> Signed-off-by: Inki Dae
> Acked-by: Kyungmin Park
> ---
> drivers/gpu/drm/exynos/exynos_dp_core.c | 18 +++-
> drivers/gpu/drm/exynos/exynos_drm_dpi.c | 22 -
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 139
> +-
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 13 ++-
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 41 ++---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 51 ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 78 -
> drivers/gpu/drm/exynos/exynos_mixer.c| 17 +++-
> 8 files changed, 304 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index ff63901..a892586 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1328,12 +1328,26 @@ static const struct component_ops exynos_dp_ops = {
>
> static int exynos_dp_probe(struct platform_device *pdev)
> {
> - return exynos_drm_component_add(&pdev->dev, &exynos_dp_ops);
> + int ret;
> +
> + ret = exynos_drm_component_add(&pdev->dev, EXYNOS_DEVICE_TYPE_CONNECTOR,
> + exynos_dp_display.type);
> + if (ret)
> + return ret;
> +
> + ret = component_add(&pdev->dev, &exynos_dp_ops);
> + if (ret)
> + exynos_drm_component_del(&pdev->dev,
> + EXYNOS_DEVICE_TYPE_CONNECTOR);
> +
> + return ret;
> }
>
> static int exynos_dp_remove(struct platform_device *pdev)
> {
> - exynos_drm_component_del(&pdev->dev, &exynos_dp_ops);
> + component_del(&pdev->dev, &exynos_dp_ops);
> + exynos_drm_component_del(&pdev->dev, EXYNOS_DEVICE_TYPE_CONNECTOR);
As I wrote in the previous comment calling exynos_drm_component_del here
will cause exynos_drv to stop waiting for exynos_dp to bring up drm
again, which is wrong. The same comment is valid for all other calls of
exynos_drm_component_del in *_remove and *_probe.
Or maybe I miss something???
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> index a832364..f1b8587 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> @@ -295,9 +295,15 @@ struct exynos_drm_display *exynos_dpi_probe(struct
> device *dev)
> struct exynos_dpi *ctx;
> int ret;
>
> + ret = exynos_drm_component_add(dev,
> + EXYNOS_DEVICE_TYPE_CONNECTOR,
> + exynos_dpi_display.type);
> + if (ret)
> + return ERR_PTR(ret);
> +
> ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> if (!ctx)
> - return NULL;
> + goto err_del_component;
>
> ctx->dev = dev;
> exynos_dpi_display.ctx = ctx;
> @@ -306,16 +312,24 @@ struct exynos_drm_display *exynos_dpi_probe(struct
> device *dev)
> ret = exynos_dpi_parse_dt(ctx);
> if (ret < 0) {
> devm_kfree(dev, ctx);
> - return NULL;
> + goto err_del_component;
> }
>
> if (ctx->panel_node) {
> ctx->panel = of_drm_find_panel(ctx->panel_node);
> - if (!ctx->panel)
> + if (!ctx->panel) {
> + exynos_drm_component_del(dev,
> + EXYNOS_DEVICE_TYPE_CONNECTOR);
> return ERR_PTR(-EPROBE_DEFER);
> + }
> }
>
> return &exynos_dpi_display;
> +
> +err_del_component:
> + exynos_drm_component_del(dev, EXYNOS_DEVICE_TYPE_CONNECTOR);
> +
> + return NULL;
> }
>
> int exynos_dpi_remove(struct device *dev)
> @@ -327,5 +341,7 @@ int exynos_dpi_remove(struct device *dev)
> encoder->funcs->destroy(encoder);
> drm_connector_cleanup(&ctx->connector);
>
> + exynos_drm_component_del(dev, EXYNOS_DEVICE_TYPE_CONNECTOR);
> +
> return 0;
> }
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>
RE: [PATCH v2 2/2] s5p-mfc: Adding MFC v7 and v8 firmwares
Hi Arun, Ben, > From: arunkk.sams...@gmail.com [mailto:arunkk.sams...@gmail.com] On > Behalf Of Arun Kumar K > Sent: Wednesday, June 04, 2014 7:32 AM > > Hi Ben, > > On Wed, Jun 4, 2014 at 4:56 AM, Ben Hutchings > wrote: > > On Tue, 2014-06-03 at 20:34 +0100, Ben Hutchings wrote: > >> On Wed, 2014-05-21 at 18:11 +0530, Arun Kumar K wrote: > >> > Adding the following firmware files for MFC > >> > s5p-mfc-v7.fw: Used in exynos 5420 > >> > s5p-mfc-v8.fw: Used in exynos 5800 > >> > > >> > Signed-off-by: Arun Kumar K > >> > --- > >> > Changes from v1 > >> > - None > >> > --- > >> > WHENCE|2 ++ > >> > s5p-mfc/s5p-mfc-v7.fw | Bin 0 -> 382724 bytes > >> > s5p-mfc/s5p-mfc-v8.fw | Bin 0 -> 360576 bytes > >> > 3 files changed, 2 insertions(+) > >> > create mode 100644 s5p-mfc/s5p-mfc-v7.fw create mode 100644 > >> > s5p-mfc/s5p-mfc-v8.fw > >> [...] > >> > >> Applied, thanks. > > > > Just noticed a problem with all the s5p-mfc firmware: you are putting > > it in the s5p-mfc subdirectory, so distribution packages will install > > them in /lib/firmware/s5p-mfc. However, unless I'm mistaken your > > driver requests it with a bare filename (e.g. "s5p-mfc-v7.fw") so it > > won't be found. > > > > Yes this issue is there. > Kamil, are you ok with changing the fw load path to s5p-mfc/s5p-mfc*.fw > in the driver? We have two options here: 1) Change the driver to request s5p-mfc/sp5-mfc-fw* 2) Move the files in the firmware repository I would opt for the second option. The driver was uploaded before the firmware. I see that there are many firmware files in the root folder of the repository Ben, what is your opinion? Which is preferred: creating subdirectories or storing firmware in the root folder? Best wishes, -- Kamil Debski Samsung R&D Institute Poland > > Regards > Arun > > > Ben. > > > > -- > > Ben Hutchings > > Experience is what causes a person to make new mistakes instead of > old ones. -- To unsubscribe from this list: send the line "unsubscribe linux-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 6/6] usb: host: ohci-exynos: Use devm_ioremap_resource instead of devm_ioremap
Hi,
On Sat, May 10, 2014 at 5:30 PM, Vivek Gautam wrote:
> Using devm_ioremap_resource() API should actually be preferred over
> devm_ioremap(), since the former request the mem region first and then
> gives back the ioremap'ed memory pointer.
> devm_ioremap_resource() calls request_mem_region(), therby preventing
> other drivers to make any overlapping call to the same region.
>
> Signed-off-by: Vivek Gautam
Although this patch and rest in the series are merged.
But i have got a doubt, so making this thread alive.
> ---
> drivers/usb/host/ohci-exynos.c |7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
> index 9cf80cb..dec691d 100644
> --- a/drivers/usb/host/ohci-exynos.c
> +++ b/drivers/usb/host/ohci-exynos.c
> @@ -120,10 +120,9 @@ skip_phy:
>
> hcd->rsrc_start = res->start;
> hcd->rsrc_len = resource_size(res);
> - hcd->regs = devm_ioremap(&pdev->dev, res->start, hcd->rsrc_len);
> - if (!hcd->regs) {
> - dev_err(&pdev->dev, "Failed to remap I/O memory\n");
> - err = -ENOMEM;
> + hcd->regs = devm_ioremap_resource(&pdev->dev, res);
Here, we replaced devm_ioremap() call with devm_ioremap_resource(),
which internally
requests the memory region and then does a "devm_ioremap()" or
"devm_ioremap_nocache()"
based on the check for IORESOURCE_CACHEABLE flag.
But this flag is not set for the resource of this device.
So should we be explicitly setting the flag in driver ?
The query goes for other patches too in this series, wherein
devm_ioremap() call is replaced with devm_ioremap_resource().
[snip]
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] usb: dwc3: Keeping 'resource' related code together
Putting together the code related to getting the 'IORESOURCE_MEM'
and assigning the same to dwc->xhci_resources, for increasing
the readability.
Signed-off-by: Vivek Gautam
---
Changes from v1:
- Fixed issue with 'res->start' as pointed out by Paul Zimmerman
by decrementing it back to its original value.
drivers/usb/dwc3/core.c | 44 +---
1 file changed, 25 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 3f59c12..8b1acad 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -656,6 +656,31 @@ static int dwc3_probe(struct platform_device *pdev)
return -ENODEV;
}
+ dwc->xhci_resources[0].start = res->start;
+ dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
+ DWC3_XHCI_REGS_END;
+ dwc->xhci_resources[0].flags = res->flags;
+ dwc->xhci_resources[0].name = res->name;
+
+ res->start += DWC3_GLOBALS_REGS_START;
+
+ /*
+* Request memory region but exclude xHCI regs,
+* since it will be requested by the xhci-plat driver.
+*/
+ regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(regs))
+ return PTR_ERR(regs);
+
+ dwc->regs = regs;
+ dwc->regs_size = resource_size(res);
+ /*
+* restore res->start back to its original value so that,
+* in case the probe is deferred, we don't end up getting error in
+* request the memory region the next time probe is called.
+*/
+ res->start -= DWC3_GLOBALS_REGS_START;
+
if (node) {
dwc->maximum_speed = of_usb_get_maximum_speed(node);
@@ -676,28 +701,9 @@ static int dwc3_probe(struct platform_device *pdev)
if (ret)
return ret;
- dwc->xhci_resources[0].start = res->start;
- dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
- DWC3_XHCI_REGS_END;
- dwc->xhci_resources[0].flags = res->flags;
- dwc->xhci_resources[0].name = res->name;
-
- res->start += DWC3_GLOBALS_REGS_START;
-
- /*
-* Request memory region but exclude xHCI regs,
-* since it will be requested by the xhci-plat driver.
-*/
- regs = devm_ioremap_resource(dev, res);
- if (IS_ERR(regs))
- return PTR_ERR(regs);
-
spin_lock_init(&dwc->lock);
platform_set_drvdata(pdev, dwc);
- dwc->regs = regs;
- dwc->regs_size = resource_size(res);
-
dev->dma_mask = dev->parent->dma_mask;
dev->dma_parms = dev->parent->dma_parms;
dma_set_coherent_mask(dev, dev->parent->coherent_dma_mask);
--
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] ARM: Exynos : Fix build error with thumb2
On 2 June 2014 15:40, Dave Martin wrote: > On Mon, May 26, 2014 at 09:23:45PM +0530, Santosh Shukla wrote: >> From: santosh shukla >> >> Add non-global symbol .LLl2x0_regs_phys to avoid build break in thumb2 mode. >> >> IIUC, arm assembler fail to load value of "global" variable >> l2xo_regs_phys for thum2 mode and wrapping it in non-global symbol like >> .Ll2x0_regs_phys solves the build break issue. >> >> arch/arm/mach-exynos/sleep.S: Assembler messages: >> arch/arm/mach-exynos/sleep.S:57: Error: invalid immediate for address >> calculation (value = 0x0004) >> >> fix inspired from [1] >> >> [1] https://lkml.org/lkml/2010/3/31/235 >> >> Signed-off-by: santosh shukla > > Reviewed-by: Dave Martin > Thanks. Hi Kukjin, if this patch ok with you then can you pick it up. > The binutils folks insist that this is not a bug in gas. (I disagreed, but > it's a grey area.) This is the established pattern for working round this > issue -- looks fine to me. > > Cheers > ---Dave > > >> --- >> arch/arm/mach-exynos/sleep.S |4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm/mach-exynos/sleep.S b/arch/arm/mach-exynos/sleep.S >> index a2613e9..dc8c6b6 100644 >> --- a/arch/arm/mach-exynos/sleep.S >> +++ b/arch/arm/mach-exynos/sleep.S >> @@ -54,7 +54,7 @@ ENTRY(exynos_cpu_resume) >> ldr r1, =CPU_CORTEX_A9 >> cmp r0, r1 >> bne skip_l2_resume >> - adr r0, l2x0_regs_phys >> + adr r0, .Ll2x0_regs_phys >> ldr r0, [r0] >> cmp r0, #0 >> beq skip_l2_resume >> @@ -79,6 +79,8 @@ skip_l2_resume: >> b cpu_resume >> ENDPROC(exynos_cpu_resume) >> #ifdef CONFIG_CACHE_L2X0 >> + >> +.Ll2x0_regs_phys: >> .globl l2x0_regs_phys >> l2x0_regs_phys: >> .long 0 >> -- >> 1.7.9.5 >> >> >> ___ >> linaro-kernel mailing list >> linaro-ker...@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
