Re: [PATCH v3 1/2] cpufreq / OPP: Allow boost frequency to be looked up from device tree
Hi Nishanth, Viresh
If I may add my 2 cents.
On Tue, May 13, 2014 at 10:40 PM, Viresh Kumar
viresh.ku...@linaro.org wrote:
On 14 May 2014 06:32, Thomas Abraham ta.oma...@gmail.com wrote:
[...]
+#ifdef CONFIG_CPU_FREQ_BOOST_SW
+ if (of_find_property(dev-of_node, boost-frequency,
len)) {
Does this mean another block inside the cpu node ? Like this: ?
cpu@0 {
compatible = arm,cortex-a9;
reg = 0;
next-level-cache = L2;
operating-points =
/* kHzuV */
792000 110
396000 95
198000 85
;
boost-frequency =
792000
198000
;
I think that the above approach is more appealing [*].
};
I think it we might better add another field in the opp block as
these OPPs are rather boost one..
If we change the meaning to be:
operating-points =
/* kHzuV boost? */
792000 110 1
396000 950
We are adding a modifier to the OPP definition here and does imply
every platform which may or maynot require boost need to indicate
that - basically fails at least my least common description for a
generic definition. As I had indicated in other threads - we are back
to the discussion of additional properties to an OPP..
Option 1:
- describe modifiers separately (as in boost-frequencies) - that
operate based on data from opp table.
Option 2:
- keep adding to the description of opp as time goes by - every SoC
has it's own set of quirks that are needed for an OPP - I know that at
TI, we have certain OPPs that can only be enabled *if* custom
hardware driver is enabled, and similar stories. - yet another
example is enable the OPP if efuse X, bit Y is set.
Personally, looking at the various descriptions and bL, cpu-idle
states dependencies on OPPs, etc.. Option 2 is a non-scalable
approach.
I agree with Nishanth here, that point 1 (as described by Viresh at
[*]) is a more scalable approach.
[...]
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] [media] s5p-mfc: add init buffer cmd to MFCV6
From: avnd kiran avnd.ki...@samsung.com
Latest MFC v6 firmware requires tile mode and loop filter
setting to be done as part of Init buffer command, in sync
with v7. Since there are two versions of v6 firmware with
different interfaces, it is differenciated using the version
number read back from firmware which is a hexadecimal value
based on the firmware date.
Signed-off-by: avnd kiran avnd.ki...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Changes from v2
- Addressed Kamil's comment
https://patchwork.linuxtv.org/patch/22989/
Changes from v1
- Check for v6 firmware date for differenciating old and new firmware
as per comments from Kamil and Sylwester.
---
drivers/media/platform/s5p-mfc/regs-mfc-v6.h|1 +
drivers/media/platform/s5p-mfc/regs-mfc-v7.h|2 --
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 ++
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c |8
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 21 ++---
5 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
index 8d0b686..b47567c 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
@@ -132,6 +132,7 @@
#define S5P_FIMV_D_METADATA_BUFFER_ADDR_V6 0xf448
#define S5P_FIMV_D_METADATA_BUFFER_SIZE_V6 0xf44c
#define S5P_FIMV_D_NUM_MV_V6 0xf478
+#define S5P_FIMV_D_INIT_BUFFER_OPTIONS_V6 0xf47c
#define S5P_FIMV_D_CPB_BUFFER_ADDR_V6 0xf4b0
#define S5P_FIMV_D_CPB_BUFFER_SIZE_V6 0xf4b4
diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v7.h
b/drivers/media/platform/s5p-mfc/regs-mfc-v7.h
index ea5ec2a..82c96fa 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc-v7.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v7.h
@@ -18,8 +18,6 @@
#define S5P_FIMV_CODEC_VP8_ENC_V7 25
/* Additional registers for v7 */
-#define S5P_FIMV_D_INIT_BUFFER_OPTIONS_V7 0xf47c
-
#define S5P_FIMV_E_SOURCE_FIRST_ADDR_V70xf9e0
#define S5P_FIMV_E_SOURCE_SECOND_ADDR_V7 0xf9e4
#define S5P_FIMV_E_SOURCE_THIRD_ADDR_V70xf9e8
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 4d17df9..f5404a6 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -287,6 +287,7 @@ struct s5p_mfc_priv_buf {
* @warn_start:hardware error code from which warnings start
* @mfc_ops: ops structure holding HW operation function pointers
* @mfc_cmds: cmd structure holding HW commands function pointers
+ * @ver: firmware sub version
*
*/
struct s5p_mfc_dev {
@@ -330,6 +331,7 @@ struct s5p_mfc_dev {
int warn_start;
struct s5p_mfc_hw_ops *mfc_ops;
struct s5p_mfc_hw_cmds *mfc_cmds;
+ int ver;
};
/**
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index ee05f2d..b86744f 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -238,7 +238,6 @@ static inline void s5p_mfc_clear_cmds(struct s5p_mfc_dev
*dev)
/* Initialize hardware */
int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
{
- unsigned int ver;
int ret;
mfc_debug_enter();
@@ -300,12 +299,13 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
return -EIO;
}
if (IS_MFCV6_PLUS(dev))
- ver = mfc_read(dev, S5P_FIMV_FW_VERSION_V6);
+ dev-ver = mfc_read(dev, S5P_FIMV_FW_VERSION_V6);
else
- ver = mfc_read(dev, S5P_FIMV_FW_VERSION);
+ dev-ver = mfc_read(dev, S5P_FIMV_FW_VERSION);
mfc_debug(2, MFC F/W version : %02xyy, %02xmm, %02xdd\n,
- (ver 16) 0xFF, (ver 8) 0xFF, ver 0xFF);
+ (dev-ver 16) 0xFF, (dev-ver 8) 0xFF,
+ dev-ver 0xFF);
s5p_mfc_clock_off();
mfc_debug_leave();
return 0;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index 90edb19..444f0e8 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -48,6 +48,9 @@
#define OFFSETA(x) (((x) - dev-port_a) S5P_FIMV_MEM_OFFSET)
#define OFFSETB(x) (((x) - dev-port_b) S5P_FIMV_MEM_OFFSET)
+/* v2 interface version date of MFCv6 firmware */
+#define MFC_V6_FIRMWARE_INTERFACE_V2 0x120629
+
/* Allocate temporary buffers for decoding */
static int s5p_mfc_alloc_dec_temp_buffers_v6(struct s5p_mfc_ctx *ctx)
{
@@ -1269,6 +1272,18 @@ static int s5p_mfc_set_enc_params_vp8(struct s5p_mfc_ctx
*ctx)
return 0;
}
+/* Check if newer v6 firmware with changed init
Re: [PATCH v4 1/8] cpufreq: cpufreq-cpu0: allow use of optional boost mode frequencies
Hi Viresh, Tomas,
On 14 May 2014 06:41, Thomas Abraham ta.oma...@gmail.com wrote:
From: Thomas Abraham thomas...@samsung.com
Lookup for the optional boost-frequency property in cpu0 node and if
available, enable support for boost mode frequencies. The
frequencies usable in boost mode are determined while preparing the
cpufreq table from the list of operating points available.
Cc: Shawn Guo shawn@linaro.org
Cc: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
.../devicetree/bindings/cpufreq/cpufreq-cpu0.txt |2 ++
drivers/cpufreq/Kconfig| 11
+++ drivers/cpufreq/cpufreq-cpu0.c |
5 + 3 files changed, 18 insertions(+), 0 deletions(-)
diff --git
a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt index
f055515..60f321a 100644 ---
a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt +++
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt @@
-19,6 +19,8 @@ Optional properties:
- cooling-min-level:
- cooling-max-level:
Please refer to
Documentation/devicetree/bindings/thermal/thermal.txt. +-
boost-frequency:
+ Please refer to
Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
Examples:
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 1fbe11f..0ca4485 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -194,6 +194,17 @@ config GENERIC_CPUFREQ_CPU0
If in doubt, say N.
+config GENERIC_CPUFREQ_CPU0_BOOST
Get rid of this.. just not required.
I think that you can rely solely on the CPU_FREQ_BOOST_SW flag if the
original author of cpufreq-cpu0.c don't mind.
+ bool Boost frequency support for generic CPU0 cpufreq
driver
+ depends on GENERIC_CPUFREQ_CPU0
+ select CPU_FREQ_BOOST_SW
+ help
+ This enables support for software managed overclocking
(BOOST). It
+ allows usage of special frequencies (those beyond the
normal operating
+ frequencies).
+
+ If in doubt, say N.
+
menu x86 CPU frequency scaling drivers
depends on X86
source drivers/cpufreq/Kconfig.x86
diff --git a/drivers/cpufreq/cpufreq-cpu0.c
b/drivers/cpufreq/cpufreq-cpu0.c index 1bf6bba..e6c21a8 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -194,6 +194,11 @@ static int cpu0_cpufreq_probe(struct
platform_device *pdev) transition_latency += ret * 1000;
}
+#ifdef CONFIG_GENERIC_CPUFREQ_CPU0_BOOST
+ if (of_find_property(cpu_dev-of_node, boost-frequency,
NULL))
Lets see what happens to the other thread for this.
+ cpu0_cpufreq_driver.boost_supported = true;
+#endif
+
ret = cpufreq_register_driver(cpu0_cpufreq_driver);
if (ret) {
pr_err(failed register driver: %d\n, ret);
--
1.7.4.4
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/8] cpufreq: cpufreq-cpu0: allow use of optional boost mode frequencies
On 14 May 2014 11:47, Lukasz Majewski l.majew...@samsung.com wrote: I think that you can rely solely on the CPU_FREQ_BOOST_SW flag if the original author of cpufreq-cpu0.c don't mind. We don't have to. struct cpufreq_driver: boost_supported is always available. Just update it without any ugly #ifdefs .. -- To unsubscribe from this list: send the line unsubscribe linux-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 1/2] cpufreq / OPP: Allow boost frequency to be looked up from device tree
On 14 May 2014 11:39, Lukasz Majewski l.majew...@samsung.com wrote: I agree with Nishanth here, that point 1 (as described by Viresh at [*]) is a more scalable approach. The only reason why I wanted all that to be done at OPP level was to ensure if somebody else also needs it apart from cpufreq, they don't have to duplicate code and find it.. As it is present at a central place.. But if no other code is going to look for that, it may just be fine as is.. -- To unsubscribe from this list: send the line unsubscribe linux-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] [media] s5p-mfc: Don't allocate codec buffers on STREAMON.
From: Pawel Osciak posc...@chromium.org
Currently, we allocate private codec buffers on STREAMON, which may fail
if we are out of memory. We don't check for failure though, which will
make us crash with the codec accessing random memory.
We shouldn't be failing STREAMON with out of memory errors though. So move
the allocation of private codec buffers to REQBUFS for OUTPUT queue. Also,
move MFC instance opening and closing to REQBUFS as well, as it's tied to
allocation and deallocation of private codec buffers.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Posting only patch 3/3 of the patchset -
MFC cleanup of reqbuf, streamon, open and close
addressing a minor comment from Kamil.
Other dependent patches are:
s5p-mfc: Extract open/close MFC instance commands.
s5p-mfc: Fixes for decode REQBUFS.
Changes from v1
- Addressed review comment from Kamil
https://patchwork.linuxtv.org/patch/23162/
---
drivers/media/platform/s5p-mfc/s5p_mfc.c |8 +++
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c |1 +
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 30 +++--
3 files changed, 18 insertions(+), 21 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 2faf7e6..aa08aa2 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -650,6 +650,7 @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
case S5P_MFC_R2H_CMD_CLOSE_INSTANCE_RET:
clear_work_bit(ctx);
+ ctx-inst_no = MFC_NO_INSTANCE_SET;
ctx-state = MFCINST_FREE;
wake_up(ctx-queue);
goto irq_cleanup_hw;
@@ -770,7 +771,7 @@ static int s5p_mfc_open(struct file *file)
goto err_bad_node;
}
ctx-fh.ctrl_handler = ctx-ctrl_handler;
- ctx-inst_no = -1;
+ ctx-inst_no = MFC_NO_INSTANCE_SET;
/* Load firmware if this is the first instance */
if (dev-num_inst == 1) {
dev-watchdog_timer.expires = jiffies +
@@ -880,12 +881,11 @@ static int s5p_mfc_release(struct file *file)
vb2_queue_release(ctx-vq_dst);
/* Mark context as idle */
clear_work_bit_irqsave(ctx);
- /* If instance was initialised then
+ /* If instance was initialised and not yet freed,
* return instance and free resources */
- if (ctx-inst_no != MFC_NO_INSTANCE_SET) {
+ if (ctx-state != MFCINST_FREE ctx-state != MFCINST_INIT) {
mfc_debug(2, Has to free instance\n);
s5p_mfc_close_mfc_inst(dev, ctx);
- ctx-inst_no = MFC_NO_INSTANCE_SET;
}
/* hardware locking scheme */
if (dev-curr_ctx == ctx-num)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index 84d4f9d..2001a75 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -459,5 +459,6 @@ void s5p_mfc_close_mfc_inst(struct s5p_mfc_dev *dev, struct
s5p_mfc_ctx *ctx)
if (ctx-type == MFCINST_DECODER)
s5p_mfc_hw_call(dev-mfc_ops, release_dec_desc_buffer, ctx);
+ ctx-inst_no = MFC_NO_INSTANCE_SET;
ctx-state = MFCINST_FREE;
}
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index efc78ae..4586186 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -475,11 +475,11 @@ static int reqbufs_output(struct s5p_mfc_dev *dev, struct
s5p_mfc_ctx *ctx,
ret = vb2_reqbufs(ctx-vq_src, reqbufs);
if (ret)
goto out;
+ s5p_mfc_close_mfc_inst(dev, ctx);
ctx-src_bufs_cnt = 0;
+ ctx-output_state = QUEUE_FREE;
} else if (ctx-output_state == QUEUE_FREE) {
- /* Can only request buffers after the instance
-* has been opened.
-*/
+ /* Can only request buffers when we have a valid format set. */
WARN_ON(ctx-src_bufs_cnt != 0);
if (ctx-state != MFCINST_INIT) {
mfc_err(Reqbufs called in an invalid state\n);
@@ -493,6 +493,13 @@ static int reqbufs_output(struct s5p_mfc_dev *dev, struct
s5p_mfc_ctx *ctx,
if (ret)
goto out;
+ ret = s5p_mfc_open_mfc_inst(dev, ctx);
+ if (ret) {
+ reqbufs-count = 0;
+ vb2_reqbufs(ctx-vq_src, reqbufs);
+ goto out;
+ }
+
ctx-output_state = QUEUE_BUFS_REQUESTED;
} else {
mfc_err(Buffers have already been requested\n);
@@ -594,7 +601,7 @@ static int vidioc_querybuf(struct file *file, void *priv,
[PATCH 08/18] drm/exynos: add TE handler to support MIPI DSI command mode interface
To support MIPI DSI command mode interface, the panel should generates
Tearing Effect synchronization signal between MCU and FB to display
video images.
And the display controller should trigger to transfer video image at
this signal.
So the panel receives the TE IRQ, then calls this handler chains
to notify it to the display controller.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 11 +++
drivers/gpu/drm/exynos/exynos_drm_crtc.h |7 +++
drivers/gpu/drm/exynos/exynos_drm_drv.h |3 +++
include/drm/drm_mipi_dsi.h |8
4 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 485fa26..2567ae0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -509,3 +509,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 e82e620..54b08d7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -181,6 +181,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 {
@@ -199,6 +201,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 05/18] drm_modes: add command mode helpers
This patch adds helper functions to convert cmdmode
to drm_display_mode
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/drm_modes.c | 59 +++
include/drm/drm_modes.h | 12 +
2 files changed, 71 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index bedf189..8977381 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -37,6 +37,8 @@
#include drm/drm_crtc.h
#include video/of_videomode.h
#include video/videomode.h
+#include video/of_cmdmode.h
+#include video/cmdmode.h
#include drm/drm_modes.h
#include drm_crtc_internal.h
@@ -651,6 +653,63 @@ EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
#endif /* CONFIG_OF */
#endif /* CONFIG_VIDEOMODE_HELPERS */
+#ifdef CONFIG_CMDMODE_HELPERS
+int drm_display_mode_from_cmdmode(const struct cmdmode *cm,
+ struct drm_display_mode *dmode)
+{
+ dmode-hdisplay = cm-hactive;
+ dmode-htotal = dmode-hsync_end = dmode-hsync_start = dmode-hdisplay;
+
+ dmode-vdisplay = cm-vactive;
+ dmode-vtotal = dmode-vsync_end = dmode-vsync_start = dmode-vdisplay;
+
+ dmode-clock = cm-pixelclock / 1000;
+
+ dmode-cs_setup = cm-cs_setup;
+ dmode-wr_setup = cm-wr_setup;
+ dmode-wr_active = cm-wr_active;
+ dmode-wr_hold = cm-wr_hold;
+
+ dmode-flags = 0;
+ drm_mode_set_name(dmode);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(drm_display_mode_from_cmdmode);
+
+#ifdef CONFIG_OF
+/**
+ * of_get_drm_cmdmode_display_mode - get a drm_display_mode from devicetree
+ * @np: device_node with the timing specification
+ * @dmode: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * This function is expensive and should only be used, if only one mode is to
be
+ * read from DT. To get multiple modes start with
+ * of_get_cmdmode_display_timings and work with that instead.
+ */
+int of_get_drm_cmdmode_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode, int index)
+{
+ struct cmdmode cm;
+ int ret;
+
+ ret = of_get_cmdmode(np, cm, index);
+ if (ret)
+ return ret;
+
+ drm_display_mode_from_cmdmode(cm, dmode);
+
+ pr_debug(%s: got %dx%d display mode from %s\n,
+ of_node_full_name(np), cm.hactive, cm.vactive, np-name);
+ drm_mode_debug_printmodeline(dmode);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_drm_cmdmode_display_mode);
+#endif /* CONFIG_OF */
+#endif /* CONFIG_CMDMODE_HELPERS */
+
/**
* drm_mode_set_name - set the name on a mode
* @mode: name will be set in this mode
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 91d0582..0d29754 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -144,6 +144,12 @@ struct drm_display_mode {
int vrefresh; /* in Hz */
int hsync; /* in kHz */
enum hdmi_picture_aspect picture_aspect_ratio;
+
+ /* Command mode info - refers to video/cmdmode.h */
+ int cs_setup;
+ int wr_setup;
+ int wr_active;
+ int wr_hold;
};
/* mode specified on the command line */
@@ -176,6 +182,7 @@ static inline bool drm_mode_is_stereo(const struct
drm_display_mode *mode)
struct drm_connector;
struct drm_cmdline_mode;
+struct cmdmode;
struct drm_display_mode *drm_mode_create(struct drm_device *dev);
void drm_mode_destroy(struct drm_device *dev, struct drm_display_mode *mode);
@@ -200,6 +207,11 @@ void drm_display_mode_from_videomode(const struct
videomode *vm,
int of_get_drm_display_mode(struct device_node *np,
struct drm_display_mode *dmode,
int index);
+extern int drm_display_mode_from_cmdmode(const struct cmdmode *cm,
+ struct drm_display_mode *dmode);
+extern int of_get_drm_cmdmode_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode,
+ int index);
void drm_mode_set_name(struct drm_display_mode *mode);
int drm_mode_hsync(const struct drm_display_mode *mode);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/18] ARM: dts: video: add command mode display timing DT bindings
This patch adds DT bindings for command mode display timing.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../bindings/video/cmdmode-display-timing.txt | 64
1 file changed, 64 insertions(+)
create mode 100644
Documentation/devicetree/bindings/video/cmdmode-display-timing.txt
diff --git a/Documentation/devicetree/bindings/video/cmdmode-display-timing.txt
b/Documentation/devicetree/bindings/video/cmdmode-display-timing.txt
new file mode 100644
index 000..7cedfe4
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/cmdmode-display-timing.txt
@@ -0,0 +1,64 @@
+cmdmode-display-timing bindings
+===
+
+cmdmode-display-timings node
+
+
+required properties:
+ - none
+
+optional properties:
+ - native-mode: The native mode for the display, in case multiple modes are
+ provided. When omitted, assume the first node is the native.
+
+timing subnode
+--
+
+required properties:
+ - clock-frequency: display clock in Hz
+ - hactive, vactive: display resolution
+ - cs-setup: clock cycles for the active period of address signal is enabled
+ until chip select is enabled.
+ - wr-setup: clock cycles for the active period of CS signal is enabled until
+ write signal is enabled.
+ - wr-active: clock cycles for the active period of CS is enabled.
+ - wr-hold: clock cycles for the active period of CS is disabled until write
+ signal is disabled.
+
+optional properties:
+
+There are different ways of describing the capabilities of a display. The
+devicetree representation corresponds to the one commonly found in datasheets
+for displays. If a display supports multiple signal timings, the native-mode
+can be specified.
+
+The parameters are defined as:
+
+ VCLK(internal) __|¯¯|_|¯¯|_|¯¯|_|¯¯|_|¯¯
+:::::
+ Address Output --:XXX::::XX
+| CS-SETUP+1 |:::
+|--|:::
+ Chip Select ¯¯¯|::|¯¯
+ | WR-SETUP+1 || WR-HOLD+1 |
+ |--||--|
+ Write Enable||¯¯¯
+ | WR-ACTIVE+1|
+ |--|
+ Video Data X--
+
+Example:
+
+ cmdmode-display-timings {
+ native-mode = timing0;
+ timing0: 1080p24 {
+ /* 1920x1080p24 */
+ clock-frequency = 5200;
+ hactive = 1920;
+ vactive = 1080;
+ cs-setup = 0;
+ wr-setup = 0;
+ wr-active = 1;
+ wr-hold = 0;
+ };
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/18] 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 yj44@samsung.com Acked-by: Inki Dae inki@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/video/exynos_dsim.txt |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt b/Documentation/devicetree/bindings/video/exynos_dsim.txt index 33b5730..29bf3b2 100644 --- a/Documentation/devicetree/bindings/video/exynos_dsim.txt +++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt @@ -1,7 +1,9 @@ Exynos MIPI DSI Master Required properties: - - compatible: samsung,exynos4210-mipi-dsi + - compatible: value should be one of the following + samsung,exynos4210-mipi-dsi /* for Exynos4 SoCs */ + samsung,exynos5420-mipi-dsi /* for Exynos5420 SoCs */ - reg: physical base address and length of the registers set for the device - interrupts: should contain DSI interrupt - clocks: list of clock specifiers, must contain an entry for each required -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/18] drm/exynos: use wait_event_timeout() for safety usage
There could be the case that the page flip operation isn't finished correctly
with some abnormal condition such as panel reset. So this patch replaces
wait_event() with wait_event_timeout() to avoid waiting for page flip completion
infinitely.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 95c9435..485fa26 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -69,8 +69,9 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int
mode)
if (mode DRM_MODE_DPMS_ON) {
/* wait for the completion of page flip. */
- wait_event(exynos_crtc-pending_flip_queue,
- atomic_read(exynos_crtc-pending_flip) == 0);
+ wait_event_timeout(exynos_crtc-pending_flip_queue,
+ !atomic_read(exynos_crtc-pending_flip),
+ HZ/20);
drm_vblank_off(crtc-dev, exynos_crtc-pipe);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/18] drm/exynos: dsi: move the EoT packets configuration point
This configuration could be used in MIPI DSI command mode also.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 84661fe..0a4e3ce 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 13/18] ARM: dts: s6e3fa0: add DT bindings
This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources, display timings and cpu mode timings.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/panel/samsung,s6e3fa0.txt | 45
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
new file mode 100644
index 000..c9a3fbd
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
@@ -0,0 +1,45 @@
+Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
+
+Required properties:
+ - compatible: samsung,s6e3fa0
+ - reg: the virtual channel number of a DSI peripheral
+ - vdd3-supply: core voltage supply
+ - vci-supply: voltage supply for analog circuits
+ - reset-gpios: a GPIO spec for the reset pin
+ - det-gpios: a GPIO spec for the OLED detection pin
+ - te-gpios: a GPIO spec for the TE pin
+ - cmdmode-display-timings: command mode interface timings for the connected
+ panel as described by [1]
+
+Optional properties:
+
+The device node can contain one 'port' child node with one child 'endpoint'
+node, according to the bindings defined in [2]. This node should describe
+panel's video bus.
+
+[1]: Documentation/devicetree/bindings/video/cmdmode-display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ panel@0 {
+ compatible = samsung,s6e3fa0;
+ reg = 0;
+ vdd3-supply = vcclcd_reg;
+ vci-supply = vlcd_reg;
+ reset-gpios = gpy7 4 0;
+ det-gpios = gpg0 6 0;
+ te-gpios = gpd1 7 0;
+
+ cmdmode-display-timings {
+ timing-0 {
+ clock-frequency = 0;
+ hactive = 1080;
+ vactive = 1920;
+ cs-setup = 0;
+ wr-setup = 0;
+ wr-active = 1;
+ wr-hold = 0;
+ };
+ };
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/18] drm/exynos: dsi: add driver data to support Exynos5420
The offset of register DSIM_PLLTMR_REG in Exynos5420 is different
from the one in Exynos4 SoC.
In case of Exynos5420 SoC, there is no frequency band bit in DSIM_PLLCTRL_REG,
and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead.
So this patch adds driver data to distinguish it.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 157 ++-
1 file changed, 135 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 783d7a5..35d636b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -17,6 +17,7 @@
#include linux/clk.h
#include linux/irq.h
+#include linux/of_device.h
#include linux/phy/phy.h
#include linux/regulator/consumer.h
#include linux/component.h
@@ -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
[PATCH 16/18] ARM: dts: exynos5: add system register support
This patch adds sysreg device node, and sysreg property to fimd device node
which is required to use I80 interface.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos5.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 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
[PATCH 04/18] video: add command mode and command mode display timing
This patch is based on videomode and display_timing relevant codes.
To support command mode panel, it does not need to guide its timing
information to the display controller like video mode panel,
but it requires signal timings to transfer video data.
So this patch adds cmdmode struct, cmdmode_display_timing struct and
the according helper functions to convert cmdmode_display_timing
to a generic cmdmode.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/video/Kconfig |3 +
drivers/video/Makefile|2 +
drivers/video/cmdmode.c | 42 ++
drivers/video/cmdmode_display_timing.c| 26
drivers/video/of_cmdmode.c| 55
drivers/video/of_cmdmode_display_timing.c | 212 +
include/video/cmdmode.h | 67 +
include/video/cmdmode_display_timing.h| 59
include/video/of_cmdmode.h| 19 +++
include/video/of_cmdmode_display_timing.h | 26
10 files changed, 511 insertions(+)
create mode 100644 drivers/video/cmdmode.c
create mode 100644 drivers/video/cmdmode_display_timing.c
create mode 100644 drivers/video/of_cmdmode.c
create mode 100644 drivers/video/of_cmdmode_display_timing.c
create mode 100644 include/video/cmdmode.h
create mode 100644 include/video/cmdmode_display_timing.h
create mode 100644 include/video/of_cmdmode.h
create mode 100644 include/video/of_cmdmode_display_timing.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index c7b4f0f..7090ee5 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -38,6 +38,9 @@ config VGASTATE
config VIDEOMODE_HELPERS
bool
+config CMDMODE_HELPERS
+ bool
+
config HDMI
bool
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 9ad3c17..619dd99 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -8,6 +8,8 @@ obj-y += backlight/
obj-y+= fbdev/
obj-$(CONFIG_VIDEOMODE_HELPERS) += display_timing.o videomode.o
+obj-$(CONFIG_CMDMODE_HELPERS) += cmdmode_display_timing.o cmdmode.o
ifeq ($(CONFIG_OF),y)
obj-$(CONFIG_VIDEOMODE_HELPERS) += of_display_timing.o of_videomode.o
+obj-$(CONFIG_CMDMODE_HELPERS) += of_cmdmode_display_timing.o of_cmdmode.o
endif
diff --git a/drivers/video/cmdmode.c b/drivers/video/cmdmode.c
new file mode 100644
index 000..3d3eeb8
--- /dev/null
+++ b/drivers/video/cmdmode.c
@@ -0,0 +1,42 @@
+/*
+ * generic cmdmode display timing functions
+ *
+ * Copyright (c) 2014 YoungJun Cho yj44@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/errno.h
+#include linux/export.h
+#include video/cmdmode_display_timing.h
+#include video/cmdmode.h
+
+void cmdmode_from_timing(const struct cmdmode_display_timing *cmdt,
+ struct cmdmode *cm)
+{
+ cm-pixelclock = cmdt-pixelclock;
+ cm-hactive = cmdt-hactive;
+ cm-vactive = cmdt-vactive;
+ cm-cs_setup = cmdt-cs_setup;
+ cm-wr_setup = cmdt-wr_setup;
+ cm-wr_active = cmdt-wr_active;
+ cm-wr_hold = cmdt-wr_hold;
+}
+EXPORT_SYMBOL_GPL(cmdmode_from_timing);
+
+int cmdmode_from_timings(const struct cmdmode_display_timings *cmdts,
+ struct cmdmode *cm, unsigned int index)
+{
+ struct cmdmode_display_timing *cmdt;
+
+ cmdt = cmdmode_display_timings_get(cmdts, index);
+ if (!cmdt)
+ return -EINVAL;
+
+ cmdmode_from_timing(cmdt, cm);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(cmdmode_from_timings);
diff --git a/drivers/video/cmdmode_display_timing.c
b/drivers/video/cmdmode_display_timing.c
new file mode 100644
index 000..88bab08
--- /dev/null
+++ b/drivers/video/cmdmode_display_timing.c
@@ -0,0 +1,26 @@
+/*
+ * generic cmdmode display timing functions
+ *
+ * Copyright (c) 2014 YoungJun Cho yj44@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/export.h
+#include linux/slab.h
+#include video/cmdmode_display_timing.h
+
+void cmdmode_display_timings_release(struct cmdmode_display_timings *cmdts)
+{
+ if (cmdts-timings) {
+ unsigned int i;
+
+ for (i = 0; i cmdts-num_timings; i++)
+ kfree(cmdts-timings[i]);
+ kfree(cmdts-timings);
+ }
+ kfree(cmdts);
+}
+EXPORT_SYMBOL_GPL(cmdmode_display_timings_release);
diff --git a/drivers/video/of_cmdmode.c b/drivers/video/of_cmdmode.c
new file mode 100644
index 000..d63294e
---
[PATCH 00/18] drm/exynos: support MIPI DSI command mode display
Hi, This series is for the Exynos DRM driver to support MIPI DSI command mode display and based on exynos-drm-next branch. The previous patches, RFC: http://www.spinics.net/lists/dri-devel/msg58898.html Patches 1 and 2 fix trivial bugs. Patches 3 and 4 introduce command mode and command mode display timing. These are based on video mode and (video mode) display timing. The MIPI DSI command mode interface panel does not require (video mode) display timing, but it requires signal timings to distinguish command data and video data so command mode and command mode display timing are used for it. Patch 5 converts command mode to drm display mode. Patches 6, 7, 8, 9 and 10 implement FIMD(display controller) I80 interface. The MIPI DSI command mode interface 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 then calls TE handler chains to notify it to the FIMD. Patches 11 and 12 implement to use Exynos5420 SoC DSI driver which is different from previous Exynos4 SoCs for some registers control. Patches 13 and 14 introduce MIPI DSI command interface Samsung S6E3FA0 AMOLED 5.7 LCD panel driver. Patch 15 is device tree source file for Exynos4 SoCs to support MIPI DSI command mode. The others are device tree source files for Exynos5420 to support MIPI DSI (command mode) driver. I welcome any comments. Thank you. Best regards YJ YoungJun Cho (18): drm/exynos: dsi: move the EoT packets configuration point drm/exynos: use wait_event_timeout() for safety usage ARM: dts: video: add command mode display timing DT bindings video: add command mode and command mode display timing drm_modes: add command mode helpers ARM: dts: sysreg: add exynos5 compatible to DT bindings ARM: dts: samsung-fimd: add I80 specific properties drm/exynos: add TE handler to support MIPI DSI command mode interface drm/exynos: dsi: add TE handler to support command mode interface drm/exynos: fimd: support I80 interface ARM: dts: exynos_dsim: add exynos5420 compatible to DT bindings drm/exynos: dsi: add driver data to support Exynos5420 ARM: dts: s6e3fa0: add DT bindings drm/panel: add S6E3FA0 driver ARM: dts: exynos4: add system register node ARM: dts: exynos5: add system register support ARM: dts: exynos5420: add mipi-phy node ARM: dts: exynos5420: add dsi node .../devicetree/bindings/arm/samsung/sysreg.txt |1 + .../devicetree/bindings/panel/samsung,s6e3fa0.txt | 45 ++ .../bindings/video/cmdmode-display-timing.txt | 64 +++ .../devicetree/bindings/video/exynos_dsim.txt |4 +- .../devicetree/bindings/video/samsung-fimd.txt |2 + arch/arm/boot/dts/exynos4.dtsi |1 + arch/arm/boot/dts/exynos5.dtsi |6 + arch/arm/boot/dts/exynos5420.dtsi | 20 + drivers/gpu/drm/drm_modes.c| 59 ++ drivers/gpu/drm/exynos/Kconfig |1 + drivers/gpu/drm/exynos/exynos_drm_crtc.c | 16 +- drivers/gpu/drm/exynos/exynos_drm_crtc.h |7 + drivers/gpu/drm/exynos/exynos_drm_drv.h|3 + drivers/gpu/drm/exynos/exynos_drm_dsi.c| 175 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 277 -- drivers/gpu/drm/panel/Kconfig |7 + drivers/gpu/drm/panel/Makefile |1 + drivers/gpu/drm/panel/panel-s6e3fa0.c | 570 drivers/video/Kconfig |3 + drivers/video/Makefile |2 + drivers/video/cmdmode.c| 42 ++ drivers/video/cmdmode_display_timing.c | 26 + drivers/video/of_cmdmode.c | 55 ++ drivers/video/of_cmdmode_display_timing.c | 212 include/drm/drm_mipi_dsi.h |8 + include/drm/drm_modes.h| 12 + include/video/cmdmode.h| 67 +++ include/video/cmdmode_display_timing.h | 59 ++ include/video/of_cmdmode.h | 19 + include/video/of_cmdmode_display_timing.h | 26 + include/video/samsung_fimd.h |3 +- 31 files changed, 1722 insertions(+), 71 deletions(-) create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt create mode 100644 Documentation/devicetree/bindings/video/cmdmode-display-timing.txt create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c create mode 100644 drivers/video/cmdmode.c create mode 100644 drivers/video/cmdmode_display_timing.c create mode 100644 drivers/video/of_cmdmode.c create mode 100644 drivers/video/of_cmdmode_display_timing.c create mode 100644 include/video/cmdmode.h create mode 100644 include/video/cmdmode_display_timing.h
[PATCH 18/18] ARM: dts: exynos5420: add dsi node
This patch adds common part of dsi node.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 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 15/18] ARM: dts: exynos4: add system register node
This patch adds sysreg property to fimd device node which is required to use I80 interface. Signed-off-by: YoungJun Cho yj44@samsung.com Acked-by: Inki Dae inki@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/boot/dts/exynos4.dtsi |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi index 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 14/18] drm/panel: add S6E3FA0 driver
This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/panel/Kconfig |7 +
drivers/gpu/drm/panel/Makefile|1 +
drivers/gpu/drm/panel/panel-s6e3fa0.c | 570 +
3 files changed, 578 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 4ec874d..fa51237 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -30,4 +30,11 @@ config DRM_PANEL_S6E8AA0
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS
+config DRM_PANEL_S6E3FA0
+ tristate S6E3FA0 DSI command mode panel
+ depends on DRM DRM_PANEL
+ depends on OF
+ select DRM_MIPI_DSI
+ select CMDMODE_HELPERS
+
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 8b92921..85c6738 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
+obj-$(CONFIG_DRM_PANEL_S6E3FA0) += panel-s6e3fa0.o
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
b/drivers/gpu/drm/panel/panel-s6e3fa0.c
new file mode 100644
index 000..a3b2d7e
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
@@ -0,0 +1,570 @@
+/*
+ * MIPI-DSI based s6e3fa0 AMOLED LCD 5.7 inch panel driver.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * YoungJun Cho yj44@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include drm/drmP.h
+#include drm/drm_mipi_dsi.h
+#include drm/drm_panel.h
+
+#include linux/gpio/consumer.h
+#include linux/regulator/consumer.h
+
+#include video/mipi_display.h
+#include video/of_cmdmode.h
+#include video/cmdmode.h
+
+/* Manufacturer Command Set */
+#define MCS_GLOBAL_PARAMETER 0xb0
+#define MCS_AID0xb2
+#define MCS_ELVSSOPT 0xb6
+#define MCS_TEMPERATURE_SET0xb8
+#define MCS_PENTILE_CTRL 0xc0
+#define MCS_GAMMA_MODE 0xca
+#define MCS_VDDM 0xd7
+#define MCS_ALS0xe3
+#define MCS_ERR_FG 0xed
+#define MCS_KEY_LEV1 0xf0
+#define MCS_PANEL_UPDATE 0xf7
+#define MCS_KEY_LEV2 0xfc
+#define MCS_RE 0xfe
+#define MCS_TOUT2_HSYNC0xff
+
+/* Content Adaptive Brightness Control */
+#define DCS_WRITE_CABC 0x55
+
+#define MTP_ID_LEN 3
+#define GAMMA_LEVEL_NUM30
+
+#define DEFAULT_VDDM_VAL 0x15
+
+struct s6e3fa0 {
+ struct device *dev;
+ struct drm_panelpanel;
+
+ struct regulator_bulk_data supplies[2];
+ struct gpio_desc*reset_gpio;
+ struct gpio_desc*det_gpio;
+ struct gpio_desc*te_gpio;
+ struct cmdmode cm;
+
+ unsigned intpower_on_delay;
+ unsigned intreset_delay;
+ unsigned intinit_delay;
+ unsigned intwidth_mm;
+ unsigned intheight_mm;
+
+ unsigned char id;
+ unsigned char vddm;
+ unsigned intbrightness;
+};
+
+#define panel_to_s6e3fa0(p) container_of(p, struct s6e3fa0, panel)
+
+/* VDD Memory Lookup Table contains paires of {ReadValue, WriteValue} */
+static const unsigned char s6e3fa0_vddm_lut[][2] = {
+ {0x00, 0x0d}, {0x01, 0x0d}, {0x02, 0x0e}, {0x03, 0x0f}, {0x04, 0x10},
+ {0x05, 0x11}, {0x06, 0x12}, {0x07, 0x13}, {0x08, 0x14}, {0x09, 0x15},
+ {0x0a, 0x16}, {0x0b, 0x17}, {0x0c, 0x18}, {0x0d, 0x19}, {0x0e, 0x1a},
+ {0x0f, 0x1b}, {0x10, 0x1c}, {0x11, 0x1d}, {0x12, 0x1e}, {0x13, 0x1f},
+ {0x14, 0x20}, {0x15, 0x21}, {0x16, 0x22}, {0x17, 0x23}, {0x18, 0x24},
+ {0x19, 0x25}, {0x1a, 0x26}, {0x1b, 0x27}, {0x1c, 0x28}, {0x1d, 0x29},
+ {0x1e, 0x2a}, {0x1f, 0x2b}, {0x20, 0x2c}, {0x21, 0x2d}, {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},
+
[PATCH 09/18] drm/exynos: dsi: add TE handler to support command mode interface
To support command mode interface, the DSI host calls this handler
to notify the panel tearing effect synchronization signal to the
CRTC device manager to trigger to transfer video image.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 0a4e3ce..783d7a5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -24,6 +24,7 @@
#include video/mipi_display.h
#include video/videomode.h
+#include exynos_drm_crtc.h
#include exynos_drm_drv.h
/* returns true iff both arguments logically differs */
@@ -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 17/18] ARM: dts: exynos5420: add mipi-phy node
This patch adds mipi-phy node for MIPI-DSI device.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 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 10/18] drm/exynos: fimd: support I80 interface
To support MIPI DSI command mode interface, FIMD should do followings:
- Sets LCD block configuration for I80 interface.
- Uses lcd_sys as an IRQ resource and sets relevant IRQ configuration.
- Implements trigger feature which transfers image date if there is
page flip request, and implements TE handler to call trigger function.
- Sets command mode timings configuration.
- Sets ideal(pixel) clock is 2 times faster than the original one to
generate frame done IRQ prior to the next TE signal.
Signed-off-by: YoungJun Cho yj44@samsung.com
Acked-by: Inki Dae inki@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/Kconfig |1 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 277 +-
include/video/samsung_fimd.h |3 +-
3 files changed, 237 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 5bf5bca..f4d34f0 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -28,6 +28,7 @@ config DRM_EXYNOS_FIMD
bool Exynos DRM FIMD
depends on DRM_EXYNOS !FB_S3C !ARCH_MULTIPLATFORM
select FB_MODE_HELPERS
+ select MFD_SYSCON
help
Choose this option if you want to use Exynos FIMD for DRM.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 173ee97..9d585f9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -20,11 +20,14 @@
#include linux/of_device.h
#include linux/pm_runtime.h
#include linux/component.h
+#include linux/mfd/syscon.h
+#include linux/regmap.h
#include video/of_display_timing.h
#include video/of_videomode.h
#include video/samsung_fimd.h
#include drm/exynos_drm.h
+#include drm/drm_panel.h
#include exynos_drm_drv.h
#include exynos_drm_fbdev.h
@@ -60,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_ACT(x) ((x) 8)
+#define LCD_WR_HOLD(x) ((x) 4)
+#define I80IFEN_ENABLE (1 0)
+
/* FIMD has totally five hardware windows. */
#define WINDOWS_NR 5
@@ -67,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 = {
@@ -81,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 {
@@ -111,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
[PATCH 06/18] ARM: dts: sysreg: add exynos5 compatible to DT bindings
This patch adds relevant to exynos5 compatible for exynos5 SoCs. Signed-off-by: YoungJun Cho yj44@samsung.com Acked-by: Inki Dae inki@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/arm/samsung/sysreg.txt |1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt index 0ab3251..fd71581 100644 --- a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt +++ b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt @@ -3,6 +3,7 @@ SAMSUNG S5P/Exynos SoC series System Registers (SYSREG) Properties: - compatible : should contain samsung,chip name-sysreg, syscon; For Exynos4 SoC series it should be samsung,exynos4-sysreg, syscon; + For Exynos5 SoC series it should be samsung,exynos5-sysreg, syscon; - reg : offset and length of the register set. Example: -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/18] ARM: dts: samsung-fimd: add I80 specific properties
In case of using MIPI command mode interface panel, the relevant registers should be set. So this patch adds relevant DT bindings. Signed-off-by: YoungJun Cho yj44@samsung.com Acked-by: Inki Dae inki@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/video/samsung-fimd.txt |2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt b/Documentation/devicetree/bindings/video/samsung-fimd.txt index 2dad41b..6bf93e9 100644 --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt @@ -44,6 +44,8 @@ Optional Properties: - display-timings: timing settings for FIMD, as described in document [1]. Can be used in case timings cannot be provided otherwise or to override timings provided by the panel. +- samsung,sysreg: handle to syscon used to control the system registers +- vidout-i80-ldi: boolean to support i80 interface instead of rgb one The device node can contain 'port' child nodes according to the bindings defined in [2]. The following are properties specific to those nodes: -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] [media] s5p-mfc: Dequeue sequence header after STREAMON
MFCv6 encoder needs specific minimum number of buffers to
be queued in the CAPTURE plane. This minimum number will
be known only when the sequence header is generated.
So we used to allow STREAMON on the CAPTURE plane only after
sequence header is generated and checked with the minimum
buffer requirement.
But this causes a problem that we call a vb2_buffer_done
for the sequence header buffer before doing a STREAON on the
CAPTURE plane. This used to still work fine until this patch
was merged -
b3379c6 : vb2: only call start_streaming if sufficient buffers are queued
This problem should also come in earlier MFC firmware versions
if the application calls STREAMON on CAPTURE with some delay
after doing STREAMON on OUTPUT.
So this patch keeps the header buffer until the other frame
buffers are ready and dequeues it just before the first frame
is ready.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Changes from v1
- Addressed review comments from Sachin
https://patchwork.linuxtv.org/patch/23839/
---
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 ++
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|6 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index f5404a6..cc2b96e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -523,6 +523,7 @@ struct s5p_mfc_codec_ops {
* @output_state: state of the output buffers queue
* @src_bufs: information on allocated source buffers
* @dst_bufs: information on allocated destination buffers
+ * @header_mb: buffer pointer of the encoded sequence header
* @sequence: counter for the sequence number for v4l2
* @dec_dst_flag: flags for buffers queued in the hardware
* @dec_src_buf_size: size of the buffer for source buffers in decoding
@@ -607,6 +608,7 @@ struct s5p_mfc_ctx {
int src_bufs_cnt;
struct s5p_mfc_buf dst_bufs[MFC_MAX_BUFFERS];
int dst_bufs_cnt;
+ struct s5p_mfc_buf *header_mb;
unsigned int sequence;
unsigned long dec_dst_flag;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index f8c7053..0c8d593e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -787,7 +787,7 @@ static int enc_post_seq_start(struct s5p_mfc_ctx *ctx)
ctx-dst_queue_cnt--;
vb2_set_plane_payload(dst_mb-b, 0,
s5p_mfc_hw_call(dev-mfc_ops, get_enc_strm_size, dev));
- vb2_buffer_done(dst_mb-b, VB2_BUF_STATE_DONE);
+ ctx-header_mb = dst_mb;
spin_unlock_irqrestore(dev-irqlock, flags);
}
@@ -845,6 +845,10 @@ static int enc_post_frame_start(struct s5p_mfc_ctx *ctx)
unsigned int strm_size;
unsigned long flags;
+ if (ctx-header_mb) {
+ vb2_buffer_done(ctx-header_mb-b, VB2_BUF_STATE_DONE);
+ ctx-header_mb = NULL;
+ }
slice_type = s5p_mfc_hw_call(dev-mfc_ops, get_enc_slice_type, dev);
strm_size = s5p_mfc_hw_call(dev-mfc_ops, get_enc_strm_size, dev);
mfc_debug(2, Encoded slice type: %d\n, slice_type);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] s5p-mfc: Update scratch buffer size for MPEG4
Update the MPEG4 decoder scratch buffer size as per the new v6 firmware. This updation is increasing the size and so is backward compatible with older v6 firmwares. Signed-off-by: Arun Kumar K arun...@samsung.com --- drivers/media/platform/s5p-mfc/regs-mfc-v6.h |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h index b47567c..fd04f84 100644 --- a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h @@ -382,8 +382,7 @@ (DIV_ROUND_UP((mbw) * (mbh), 32) * 16)) #define S5P_FIMV_SCRATCH_BUF_SIZE_H264_DEC_V6(w, h)(((w) * 192) + 64) #define S5P_FIMV_SCRATCH_BUF_SIZE_MPEG4_DEC_V6(w, h) \ - ((w) * ((h) * 64 + 144) + (2048/16 * (h) * 64) + \ -(2048/16 * 256 + 8320)) + ((w) * 144 + 8192 * (h) + 49216 + 1048576) #define S5P_FIMV_SCRATCH_BUF_SIZE_VC1_DEC_V6(w, h) \ (2096 * ((w) + (h) + 1)) #define S5P_FIMV_SCRATCH_BUF_SIZE_H263_DEC_V6(w, h)((w) * 400) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] Add MFCv8 support
This patchset adds MFCv8 support to the s5p-mfc driver. MFCv8 has the same operation sequence as that of v6+, but there is some shuffling of the registers happened. So to re-use the exisiting code, register access uses context variables instead of macros. The patchset modifies opr_v6 file to use register variables and is tested on mfc v5, v6, v7 and v8 based boards. The patchset is based on the following set of patches posted for MFC which are currently under review: s5p-mfc: Update scratch buffer size for MPEG4 s5p-mfc: Add support for resolution change event v4l: Add source change event s5p-mfc: Don't try to resubmit VP8 bitstream buffer for decode. s5p-mfc: Update scratch buffer size for VP8 encoder s5p-mfc: Dequeue sequence header after STREAMON s5p-mfc: Don't allocate codec buffers on STREAMON. s5p-mfc: Extract open/close MFC instance commands. s5p-mfc: Fixes for decode REQBUFS. s5p-mfc: Copy timestamps only when a frame is produced. s5p-mfc: add init buffer cmd to MFCV6 s5p-mfc: Add a control for IVF format for VP8 encoder Changes from v1 - Included encoder support for v8 patch - Addressed review comments from Kamil Sachin https://patchwork.linuxtv.org/patch/23770/ https://patchwork.linuxtv.org/patch/23768/ Arun Kumar K (1): [media] s5p-mfc: Rename IS_MFCV7 macro Kiran AVND (3): [media] s5p-mfc: Add variants to access mfc registers [media] s5p-mfc: Core support to add v8 decoder [media] s5p-mfc: Core support for v8 encoder .../devicetree/bindings/media/s5p-mfc.txt |3 +- drivers/media/platform/s5p-mfc/regs-mfc-v8.h | 124 +++ drivers/media/platform/s5p-mfc/s5p_mfc.c | 33 + drivers/media/platform/s5p-mfc/s5p_mfc_common.h|7 +- drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |4 + drivers/media/platform/s5p-mfc/s5p_mfc_enc.c |2 +- drivers/media/platform/s5p-mfc/s5p_mfc_opr.c |6 + drivers/media/platform/s5p-mfc/s5p_mfc_opr.h | 254 ++ drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c| 849 +--- drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h|7 +- 10 files changed, 1007 insertions(+), 282 deletions(-) create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v8.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] [media] s5p-mfc: Rename IS_MFCV7 macro
Renaming the IS_MFCV7 macro to IS_MFCV7_PLUS for the
addition of MFCv8 support which reuses the v7 code.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 +-
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|2 +-
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 14 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 8d85590..7b7053d 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -706,6 +706,6 @@ void set_work_bit_irqsave(struct s5p_mfc_ctx *ctx);
(dev-variant-port_num ? 1 : 0) : 0) : 0)
#define IS_TWOPORT(dev)(dev-variant-port_num == 2 ? 1 : 0)
#define IS_MFCV6_PLUS(dev) (dev-variant-version = 0x60 ? 1 : 0)
-#define IS_MFCV7(dev) (dev-variant-version = 0x70 ? 1 : 0)
+#define IS_MFCV7_PLUS(dev) (dev-variant-version = 0x70 ? 1 : 0)
#endif /* S5P_MFC_COMMON_H_ */
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 0c8d593e..e7dddb0 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -1049,7 +1049,7 @@ static int vidioc_try_fmt(struct file *file, void *priv,
struct v4l2_format *f)
return -EINVAL;
}
- if (!IS_MFCV7(dev) (fmt-fourcc == V4L2_PIX_FMT_VP8)) {
+ if (!IS_MFCV7_PLUS(dev) (fmt-fourcc == V4L2_PIX_FMT_VP8)) {
mfc_err(VP8 is supported only in MFC v7\n);
return -EINVAL;
}
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index 47890e8..9a503ca 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -116,7 +116,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct
s5p_mfc_ctx *ctx)
(ctx-mv_count * ctx-mv_size);
break;
case S5P_MFC_CODEC_MPEG4_DEC:
- if (IS_MFCV7(dev)) {
+ if (IS_MFCV7_PLUS(dev)) {
ctx-scratch_buf_size =
S5P_FIMV_SCRATCH_BUF_SIZE_MPEG4_DEC_V7(
mb_width,
@@ -357,7 +357,7 @@ static void s5p_mfc_enc_calc_src_size_v6(struct s5p_mfc_ctx
*ctx)
ctx-chroma_size = ALIGN((mb_width * mb_height) * 128, 256);
/* MFCv7 needs pad bytes for Luma and Chroma */
- if (IS_MFCV7(ctx-dev)) {
+ if (IS_MFCV7_PLUS(ctx-dev)) {
ctx-luma_size += MFC_LUMA_PAD_BYTES_V7;
ctx-chroma_size += MFC_CHROMA_PAD_BYTES_V7;
}
@@ -1283,7 +1283,7 @@ static int s5p_mfc_set_enc_params_vp8(struct s5p_mfc_ctx
*ctx)
/* Check if newer v6 firmware with changed init buffer interface */
static bool s5p_mfc_is_v6_fw_v2(struct s5p_mfc_dev *dev)
{
- if (IS_MFCV7(dev))
+ if (IS_MFCV7_PLUS(dev))
return false;
/*
* FW date is in BCD format xx120629. So checking for
@@ -1320,7 +1320,7 @@ static int s5p_mfc_init_decode_v6(struct s5p_mfc_ctx *ctx)
WRITEL(ctx-display_delay, mfc_regs-d_display_delay);
}
- if (IS_MFCV7(dev) || s5p_mfc_is_v6_fw_v2(dev)) {
+ if (IS_MFCV7_PLUS(dev) || s5p_mfc_is_v6_fw_v2(dev)) {
WRITEL(reg, mfc_regs-d_dec_options);
reg = 0;
}
@@ -1335,7 +1335,7 @@ static int s5p_mfc_init_decode_v6(struct s5p_mfc_ctx *ctx)
if (ctx-dst_fmt-fourcc == V4L2_PIX_FMT_NV12MT_16X16)
reg |= (0x1 S5P_FIMV_D_OPT_TILE_MODE_SHIFT_V6);
- if (IS_MFCV7(dev) || s5p_mfc_is_v6_fw_v2(dev))
+ if (IS_MFCV7_PLUS(dev) || s5p_mfc_is_v6_fw_v2(dev))
WRITEL(reg, mfc_regs-d_init_buffer_options);
else
WRITEL(reg, mfc_regs-d_dec_options);
@@ -1423,7 +1423,7 @@ static int s5p_mfc_init_encode_v6(struct s5p_mfc_ctx *ctx)
}
/* Set stride lengths for v7 above */
- if (IS_MFCV7(dev)) {
+ if (IS_MFCV7_PLUS(dev)) {
WRITEL(ctx-img_width, mfc_regs-e_source_first_plane_stride);
WRITEL(ctx-img_width, mfc_regs-e_source_second_plane_stride);
}
@@ -2165,7 +2165,7 @@ const struct s5p_mfc_regs
*s5p_mfc_init_regs_v6_plus(struct s5p_mfc_dev *dev)
R(e_h264_frame_packing_sei_info,
S5P_FIMV_E_H264_FRAME_PACKING_SEI_INFO_V6);
- if (!IS_MFCV7(dev))
+ if (!IS_MFCV7_PLUS(dev))
goto done;
/* Initialize registers used in MFC v7 */
--
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
[PATCH v2 4/4] [media] s5p-mfc: Core support for v8 encoder
From: Kiran AVND avnd.ki...@samsung.com
This patch adds core support for v8 encoder. This
patch also adds register definitions and buffer size
requirements for H264 VP8 encoding, needed for new
firmware version v8 for MFC
Signed-off-by: Kiran AVND avnd.ki...@samsung.com
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/regs-mfc-v8.h| 30 +++
drivers/media/platform/s5p-mfc/s5p_mfc.c|2 +
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 61 +++
3 files changed, 83 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
b/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
index c84d120..cc7cbec 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
@@ -72,16 +72,46 @@
/* SEI related information */
#define S5P_FIMV_D_FRAME_PACK_SEI_AVAIL_V8 0xf6dc
+/* Encoder Registers */
+#define S5P_FIMV_E_FIXED_PICTURE_QP_V8 0xf794
+#define S5P_FIMV_E_RC_CONFIG_V80xf798
+#define S5P_FIMV_E_RC_QP_BOUND_V8 0xf79c
+#define S5P_FIMV_E_RC_RPARAM_V80xf7a4
+#define S5P_FIMV_E_MB_RC_CONFIG_V8 0xf7a8
+#define S5P_FIMV_E_PADDING_CTRL_V8 0xf7ac
+#define S5P_FIMV_E_MV_HOR_RANGE_V8 0xf7b4
+#define S5P_FIMV_E_MV_VER_RANGE_V8 0xf7b8
+
+#define S5P_FIMV_E_VBV_BUFFER_SIZE_V8 0xf78c
+#define S5P_FIMV_E_VBV_INIT_DELAY_V8 0xf790
+
+#define S5P_FIMV_E_ASPECT_RATIO_V8 0xfb4c
+#define S5P_FIMV_E_EXTENDED_SAR_V8 0xfb50
+#define S5P_FIMV_E_H264_OPTIONS_V8 0xfb54
+
/* MFCv8 Context buffer sizes */
#define MFC_CTX_BUF_SIZE_V8(30 * SZ_1K)/* 30KB */
#define MFC_H264_DEC_CTX_BUF_SIZE_V8 (2 * SZ_1M) /* 2MB */
#define MFC_OTHER_DEC_CTX_BUF_SIZE_V8 (20 * SZ_1K)/* 20KB */
+#define MFC_H264_ENC_CTX_BUF_SIZE_V8 (100 * SZ_1K) /* 100KB */
+#define MFC_OTHER_ENC_CTX_BUF_SIZE_V8 (10 * SZ_1K)/* 10KB */
/* Buffer size defines */
+#define S5P_FIMV_TMV_BUFFER_SIZE_V8(w, h) (((w) + 1) * ((h) + 1) * 8)
+
#define S5P_FIMV_SCRATCH_BUF_SIZE_H264_DEC_V8(w, h)(((w) * 704) + 2176)
#define S5P_FIMV_SCRATCH_BUF_SIZE_VP8_DEC_V8(w, h) \
(((w) * 576 + (h) * 128) + 4128)
+#define S5P_FIMV_SCRATCH_BUF_SIZE_H264_ENC_V8(w, h) \
+ (((w) * 592) + 2336)
+#define S5P_FIMV_SCRATCH_BUF_SIZE_VP8_ENC_V8(w, h) \
+ (((w) * 576) + 10512 + \
+ ((w) * 16) * ((h) * 16)) * 3) / 2) * 4))
+#define S5P_FIMV_ME_BUFFER_SIZE_V8(imw, imh, mbw, mbh) \
+ ((DIV_ROUND_UP((mbw * 16), 64) * DIV_ROUND_UP((mbh * 16), 64) * 256) \
++ (DIV_ROUND_UP((mbw) * (mbh), 32) * 16))
+
/* BUffer alignment defines */
#define S5P_FIMV_D_ALIGN_PLANE_SIZE_V8 64
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index c8d7ba0..ea72502 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1441,6 +1441,8 @@ struct s5p_mfc_buf_size_v6 mfc_buf_size_v8 = {
.dev_ctx= MFC_CTX_BUF_SIZE_V8,
.h264_dec_ctx = MFC_H264_DEC_CTX_BUF_SIZE_V8,
.other_dec_ctx = MFC_OTHER_DEC_CTX_BUF_SIZE_V8,
+ .h264_enc_ctx = MFC_H264_ENC_CTX_BUF_SIZE_V8,
+ .other_enc_ctx = MFC_OTHER_ENC_CTX_BUF_SIZE_V8,
};
struct s5p_mfc_buf_size buf_size_v8 = {
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index eeaf122..43d0bb8 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -80,7 +80,12 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct s5p_mfc_ctx
*ctx)
ctx-luma_size, ctx-chroma_size, ctx-mv_size);
mfc_debug(2, Totals bufs: %d\n, ctx-total_dpb_count);
} else if (ctx-type == MFCINST_ENCODER) {
- ctx-tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
+ if (IS_MFCV8(dev))
+ ctx-tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
+ ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V8(mb_width, mb_height),
+ S5P_FIMV_TMV_BUFFER_ALIGN_V6);
+ else
+ ctx-tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V6(mb_width, mb_height),
S5P_FIMV_TMV_BUFFER_ALIGN_V6);
@@ -90,10 +95,16 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct
s5p_mfc_ctx *ctx)
ctx-chroma_dpb_size = ALIGN((mb_width * mb_height) *
S5P_FIMV_CHROMA_MB_TO_PIXEL_V6,
S5P_FIMV_CHROMA_DPB_BUFFER_ALIGN_V6);
- ctx-me_buffer_size = ALIGN(S5P_FIMV_ME_BUFFER_SIZE_V6(
-
[PATCH v2 3/4] [media] s5p-mfc: Core support to add v8 decoder
From: Kiran AVND avnd.ki...@samsung.com This patch adds variant data and core support for V8 decoder. This patch also adds the register definition file for new firmware version v8 for MFC. Signed-off-by: Kiran AVND avnd.ki...@samsung.com Signed-off-by: Pawel Osciak posc...@chromium.org Signed-off-by: Arun Kumar K arun...@samsung.com --- .../devicetree/bindings/media/s5p-mfc.txt |3 +- drivers/media/platform/s5p-mfc/regs-mfc-v8.h | 94 drivers/media/platform/s5p-mfc/s5p_mfc.c | 30 +++ drivers/media/platform/s5p-mfc/s5p_mfc_common.h|4 +- drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |4 + drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c| 85 -- 6 files changed, 210 insertions(+), 10 deletions(-) create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v8.h diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt index f418168..3e3c5f3 100644 --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt @@ -10,7 +10,8 @@ Required properties: - compatible : value should be either one among the following (a) samsung,mfc-v5 for MFC v5 present in Exynos4 SoCs (b) samsung,mfc-v6 for MFC v6 present in Exynos5 SoCs - (b) samsung,mfc-v7 for MFC v7 present in Exynos5420 SoC + (c) samsung,mfc-v7 for MFC v7 present in Exynos5420 SoC + (d) samsung,mfc-v8 for MFC v8 present in Exynos5800 SoC - reg : Physical base address of the IP registers and length of memory mapped region. diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v8.h b/drivers/media/platform/s5p-mfc/regs-mfc-v8.h new file mode 100644 index 000..c84d120 --- /dev/null +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v8.h @@ -0,0 +1,94 @@ +/* + * Register definition file for Samsung MFC V8.x Interface (FIMV) driver + * + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * http://www.samsung.com/ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef _REGS_MFC_V8_H +#define _REGS_MFC_V8_H + +#include linux/sizes.h +#include regs-mfc-v7.h + +/* Additional registers for v8 */ +#define S5P_FIMV_D_MVC_NUM_VIEWS_V80xf104 +#define S5P_FIMV_D_FIRST_PLANE_DPB_SIZE_V8 0xf144 +#define S5P_FIMV_D_SECOND_PLANE_DPB_SIZE_V80xf148 +#define S5P_FIMV_D_MV_BUFFER_SIZE_V8 0xf150 + +#define S5P_FIMV_D_FIRST_PLANE_DPB_STRIDE_SIZE_V8 0xf138 +#define S5P_FIMV_D_SECOND_PLANE_DPB_STRIDE_SIZE_V8 0xf13c + +#define S5P_FIMV_D_FIRST_PLANE_DPB_V8 0xf160 +#define S5P_FIMV_D_SECOND_PLANE_DPB_V8 0xf260 +#define S5P_FIMV_D_MV_BUFFER_V80xf460 + +#define S5P_FIMV_D_NUM_MV_V8 0xf134 +#define S5P_FIMV_D_INIT_BUFFER_OPTIONS_V8 0xf154 + +#define S5P_FIMV_D_SCRATCH_BUFFER_ADDR_V8 0xf560 +#define S5P_FIMV_D_SCRATCH_BUFFER_SIZE_V8 0xf564 + +#define S5P_FIMV_D_CPB_BUFFER_ADDR_V8 0xf5b0 +#define S5P_FIMV_D_CPB_BUFFER_SIZE_V8 0xf5b4 +#define S5P_FIMV_D_AVAILABLE_DPB_FLAG_LOWER_V8 0xf5bc +#define S5P_FIMV_D_CPB_BUFFER_OFFSET_V80xf5c0 +#define S5P_FIMV_D_SLICE_IF_ENABLE_V8 0xf5c4 +#define S5P_FIMV_D_STREAM_DATA_SIZE_V8 0xf5d0 + +/* Display information register */ +#define S5P_FIMV_D_DISPLAY_FRAME_WIDTH_V8 0xf600 +#define S5P_FIMV_D_DISPLAY_FRAME_HEIGHT_V8 0xf604 + +/* Display status */ +#define S5P_FIMV_D_DISPLAY_STATUS_V8 0xf608 + +#define S5P_FIMV_D_DISPLAY_FIRST_PLANE_ADDR_V8 0xf60c +#define S5P_FIMV_D_DISPLAY_SECOND_PLANE_ADDR_V80xf610 + +#define S5P_FIMV_D_DISPLAY_FRAME_TYPE_V8 0xf618 +#define S5P_FIMV_D_DISPLAY_CROP_INFO1_V8 0xf61c +#define S5P_FIMV_D_DISPLAY_CROP_INFO2_V8 0xf620 +#define S5P_FIMV_D_DISPLAY_PICTURE_PROFILE_V8 0xf624 + +/* Decoded picture information register */ +#define S5P_FIMV_D_DECODED_STATUS_V8 0xf644 +#define S5P_FIMV_D_DECODED_FIRST_PLANE_ADDR_V8 0xf648 +#define S5P_FIMV_D_DECODED_SECOND_PLANE_ADDR_V80xf64c +#define S5P_FIMV_D_DECODED_THIRD_PLANE_ADDR_V8 0xf650 +#define S5P_FIMV_D_DECODED_FRAME_TYPE_V8 0xf654 +#define S5P_FIMV_D_DECODED_NAL_SIZE_V8 0xf664 + +/* Returned value register for specific setting */ +#define S5P_FIMV_D_RET_PICTURE_TAG_TOP_V8 0xf674 +#define S5P_FIMV_D_RET_PICTURE_TAG_BOT_V8 0xf678 +#define S5P_FIMV_D_MVC_VIEW_ID_V8 0xf6d8 + +/* SEI related information */ +#define S5P_FIMV_D_FRAME_PACK_SEI_AVAIL_V8 0xf6dc + +/* MFCv8 Context buffer sizes */ +#define MFC_CTX_BUF_SIZE_V8(30 * SZ_1K)/* 30KB */ +#define MFC_H264_DEC_CTX_BUF_SIZE_V8 (2 * SZ_1M) /* 2MB */ +#define MFC_OTHER_DEC_CTX_BUF_SIZE_V8 (20 * SZ_1K)/* 20KB */ + +/*
Re: [PATCHv4 5/7] clk: samsung: exynos3250: Add clocks using common clock framework
Hi Tomasz, On 05/14/2014 01:28 AM, Tomasz Figa wrote: Hi Chanwoo, On 13.05.2014 13:49, Chanwoo Choi wrote: Hi Tomasz, On 04/26/2014 09:39 AM, Tomasz Figa wrote: Hi Chanwoo, On 25.04.2014 03:16, Chanwoo Choi wrote: From: Tomasz Figa t.f...@samsung.com This patch add new the clock drvier of Exynos3250 SoC based on Cortex-A7 using common clock framework. The CMU (Clock Management Unit) of Exynos3250 control PLLs(Phase Locked Loops) and generate system clocks for CPU, buses, and function clocks for individual IPs. The CMU of Exynos3250 includes following clock doamins: - CPU block for Cortex-A7 MPCore processor - LEFTBUS/RIGHTBUS block - TOP block for G3D/MFC/LCD0/ISP/CAM/FSYS/MFC/PERIL/PERIR In original driver present in our internal tree I have separated several CMUs to account for certain factors caused by hardware design, which require such separation. Is there any reason why they were merged together into a single CMU again? This patch just include clocks in CMU clocks without CMU_DMC/CMU_ISP. I'll send a further patches to support CMU_DMC/CMU_ISP after verifying it. Cc: Mike Turquette mturque...@linaro.org Cc: Kukjin Kim kgene@samsung.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Signed-off-by: Hyunhee Kim hyunhee@samsung.com Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Inki Dae inki@samsung.com Signed-off-by: Seung-Woo Kim sw0312@samsung.com Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Signed-off-by: Karol Wrona k.wr...@samsung.com Signed-off-by: YoungJun Cho yj44@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/clk/samsung/Makefile | 1 + drivers/clk/samsung/clk-exynos3250.c | 785 + include/dt-bindings/clock/exynos3250.h | 256 +++ 3 files changed, 1042 insertions(+) create mode 100644 drivers/clk/samsung/clk-exynos3250.c create mode 100644 include/dt-bindings/clock/exynos3250.h diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile index 8eb4799..d120797 100644 --- a/drivers/clk/samsung/Makefile +++ b/drivers/clk/samsung/Makefile @@ -3,6 +3,7 @@ # obj-$(CONFIG_COMMON_CLK)+= clk.o clk-pll.o +obj-$(CONFIG_SOC_EXYNOS3250)+= clk-exynos3250.o obj-$(CONFIG_ARCH_EXYNOS4)+= clk-exynos4.o obj-$(CONFIG_SOC_EXYNOS5250)+= clk-exynos5250.o obj-$(CONFIG_SOC_EXYNOS5420)+= clk-exynos5420.o diff --git a/drivers/clk/samsung/clk-exynos3250.c b/drivers/clk/samsung/clk-exynos3250.c new file mode 100644 index 000..0574a76 --- /dev/null +++ b/drivers/clk/samsung/clk-exynos3250.c @@ -0,0 +1,785 @@ +/* + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * Common Clock Framework support for Exynos3250 SoC. + */ + +#include linux/clk.h +#include linux/clkdev.h +#include linux/clk-provider.h +#include linux/of.h +#include linux/of_address.h +#include linux/platform_device.h +#include linux/syscore_ops.h + +#include dt-bindings/clock/exynos3250.h + +#include clk.h +#include clk-pll.h + +#define SRC_LEFTBUS0x4200 +#define DIV_LEFTBUS0x4500 +#define GATE_IP_LEFTBUS0x4800 +#define SRC_RIGHTBUS0x8200 +#define DIV_RIGHTBUS0x8500 +#define GATE_IP_RIGHTBUS0x8800 +#define GATE_IP_PERIR0x8960 +#define MPLL_LOCK0xc010 +#define MPLL_CON00xc110 +#define VPLL_LOCK0xc020 +#define VPLL_CON00xc120 +#define UPLL_LOCK0xc030 +#define UPLL_CON00xc130 +#define SRC_TOP00xc210 +#define SRC_TOP10xc214 +#define SRC_CAM0xc220 +#define SRC_MFC0xc228 +#define SRC_G3D0xc22c +#define SRC_LCD0xc234 +#define SRC_ISP0xc238 +#define SRC_FSYS0xc240 +#define SRC_PERIL00xc250 +#define SRC_PERIL10xc254 +#define SRC_MASK_TOP0xc310 +#define SRC_MASK_CAM0xc320 +#define SRC_MASK_LCD0xc334 +#define SRC_MASK_ISP0xc338 +#define SRC_MASK_FSYS0xc340 +#define SRC_MASK_PERIL00xc350 +#define SRC_MASK_PERIL10xc354 +#define DIV_TOP0xc510 +#define DIV_CAM0xc520 +#define DIV_MFC0xc528 +#define DIV_G3D0xc52c +#define DIV_LCD0xc534 +#define DIV_ISP0xc538 +#define DIV_FSYS00xc540 +#define DIV_FSYS10xc544 +#define DIV_FSYS20xc548 +#define DIV_PERIL00xc550
[PATCH v5 0/2] Add resolution change event
This patchset adds a source_change event to the v4l2-events. This can be used for notifying the userspace about runtime format changes happening on video nodes / pads like resolution change in video decoder. Changes from v4 -- - Addressed comments from Hans https://patchwork.linuxtv.org/patch/23892/ https://patchwork.linuxtv.org/patch/23893/ Changes from v3 -- - Addressed comments from Laurent / Hans https://patchwork.kernel.org/patch/4135731/ Changes from v2 --- - Event can be subscribed on specific pad / port as suggested by Hans. Changes from v1 --- - Addressed review comments from Hans and Laurent https://patchwork.kernel.org/patch/4000951/ Arun Kumar K (1): [media] v4l: Add source change event Pawel Osciak (1): [media] s5p-mfc: Add support for resolution change event Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 33 ++ .../DocBook/media/v4l/vidioc-subscribe-event.xml | 20 +++ drivers/media/platform/s5p-mfc/s5p_mfc.c |8 + drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |2 ++ drivers/media/v4l2-core/v4l2-event.c | 36 include/media/v4l2-event.h |4 +++ include/uapi/linux/videodev2.h |8 + 7 files changed, 111 insertions(+) -- 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 v5 1/2] [media] v4l: Add source change event
This event indicates that the video device has encountered
a source parameter change during runtime. This can typically be a
resolution change detected by a video decoder OR a format change
detected by an input connector.
This needs to be nofified to the userspace and the application may
be expected to reallocate buffers before proceeding. The application
can subscribe to events on a specific pad or input port which
it is interested in.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 33 ++
.../DocBook/media/v4l/vidioc-subscribe-event.xml | 20 +++
drivers/media/v4l2-core/v4l2-event.c | 36
include/media/v4l2-event.h |4 +++
include/uapi/linux/videodev2.h |8 +
5 files changed, 101 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
index 89891ad..820f86e 100644
--- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
@@ -242,6 +242,22 @@
/tgroup
/table
+table frame=none pgwide=1 id=v4l2-event-src-change
+ titlestruct structnamev4l2_event_src_change/structname/title
+ tgroup cols=3
+ cs-str;
+ tbody valign=top
+ row
+ entry__u32/entry
+ entrystructfieldchanges/structfield/entry
+ entry
+ A bitmask that tells what has changed. See xref
linkend=src-changes-flags /.
+ /entry
+ /row
+ /tbody
+ /tgroup
+/table
+
table pgwide=1 frame=none id=changes-flags
titleChanges/title
tgroup cols=3
@@ -270,6 +286,23 @@
/tbody
/tgroup
/table
+
+table pgwide=1 frame=none id=src-changes-flags
+ titleSource Changes/title
+ tgroup cols=3
+ cs-def;
+ tbody valign=top
+ row
+ entryconstantV4L2_EVENT_SRC_CH_RESOLUTION/constant/entry
+ entry0x0001/entry
+ entryThis event gets triggered when a resolution change is
+ detected at an input. This can come from an input connector or
+ from a video decoder.
+ /entry
+ /row
+ /tbody
+ /tgroup
+/table
/refsect1
refsect1
return-value;
diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
index 5c70b61..f016254 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
@@ -155,6 +155,26 @@
/entry
/row
row
+ entryconstantV4L2_EVENT_SOURCE_CHANGE/constant/entry
+ entry5/entry
+ entry
+ paraThis event is triggered when a source parameter change is
+ detected during runtime by the video device. It can be a
+ runtime resolution change triggered by a video decoder or the
+ format change happening on an input connector.
+ This event requires that the structfieldid/structfield
+ matches the input index (when used with a video device node)
+ or the pad index (when used with a subdevice node) from which
+ you want to receive events./para
+
+ paraThis event has a v4l2-event-source-change; associated
+ with it. The structfieldchanges/structfield bitfield denotes
+ what has changed for the subscribed pad. If multiple events
+ occurred before application could dequeue them, then the changes
+ will have the ORed value of all the events generated./para
+ /entry
+ /row
+ row
entryconstantV4L2_EVENT_PRIVATE_START/constant/entry
entry0x0800/entry
entryBase event number for driver-private events./entry
diff --git a/drivers/media/v4l2-core/v4l2-event.c
b/drivers/media/v4l2-core/v4l2-event.c
index 86dcb54..8761aab 100644
--- a/drivers/media/v4l2-core/v4l2-event.c
+++ b/drivers/media/v4l2-core/v4l2-event.c
@@ -318,3 +318,39 @@ int v4l2_event_subdev_unsubscribe(struct v4l2_subdev *sd,
struct v4l2_fh *fh,
return v4l2_event_unsubscribe(fh, sub);
}
EXPORT_SYMBOL_GPL(v4l2_event_subdev_unsubscribe);
+
+static void v4l2_event_src_replace(struct v4l2_event *old,
+ const struct v4l2_event *new)
+{
+ u32 old_changes = old-u.src_change.changes;
+
+ old-u.src_change = new-u.src_change;
+ old-u.src_change.changes |= old_changes;
+}
+
+static void v4l2_event_src_merge(const struct v4l2_event *old,
+ struct v4l2_event *new)
+{
+ new-u.src_change.changes |= old-u.src_change.changes;
+}
+
+static const struct v4l2_subscribed_event_ops v4l2_event_src_ch_ops = {
+ .replace =
[PATCH v5 2/2] [media] s5p-mfc: Add support for resolution change event
From: Pawel Osciak posc...@chromium.org
When a resolution change point is reached, queue an event to signal the
userspace that a new set of buffers is required before decoding can
continue.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c |8
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 6b04f17..f3a4576 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -349,8 +349,16 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
/* All frames remaining in the buffer have been extracted */
if (dst_frame_status == S5P_FIMV_DEC_STATUS_DECODING_EMPTY) {
if (ctx-state == MFCINST_RES_CHANGE_FLUSH) {
+ static const struct v4l2_event ev_src_ch = {
+ .type = V4L2_EVENT_SOURCE_CHANGE,
+ .u.src_change.changes =
+ V4L2_EVENT_SRC_CH_RESOLUTION,
+ };
+
s5p_mfc_handle_frame_all_extracted(ctx);
ctx-state = MFCINST_RES_CHANGE_END;
+ v4l2_event_queue_fh(ctx-fh, ev_src_ch);
+
goto leave_handle_frame;
} else {
s5p_mfc_handle_frame_all_extracted(ctx);
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 4586186..326d8db 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -851,6 +851,8 @@ static int vidioc_subscribe_event(struct v4l2_fh *fh,
switch (sub-type) {
case V4L2_EVENT_EOS:
return v4l2_event_subscribe(fh, sub, 2, NULL);
+ case V4L2_EVENT_SOURCE_CHANGE:
+ return v4l2_src_change_event_subscribe(fh, sub);
default:
return -EINVAL;
}
--
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 v2] [media] s5p-mfc: Dequeue sequence header after STREAMON
On 05/14/2014 08:29 AM, Arun Kumar K wrote:
MFCv6 encoder needs specific minimum number of buffers to
be queued in the CAPTURE plane. This minimum number will
be known only when the sequence header is generated.
So we used to allow STREAMON on the CAPTURE plane only after
sequence header is generated and checked with the minimum
buffer requirement.
But this causes a problem that we call a vb2_buffer_done
for the sequence header buffer before doing a STREAON on the
CAPTURE plane.
How could this ever have worked? Buffers aren't queued to the driver until
STREAMON is called, and calling vb2_buffer_done for a buffer that is not queued
first to the driver will mess up internal data (q-queued_count for one).
This used to still work fine until this patch
was merged -
b3379c6 : vb2: only call start_streaming if sufficient buffers are queued
Are you testing with CONFIG_VIDEO_ADV_DEBUG set? If not, you should do so. That
will check whether all the vb2 calls are balanced.
BTW, that's a small typo in s5p_mfc_enc.c (search for 'inavlid').
This problem should also come in earlier MFC firmware versions
if the application calls STREAMON on CAPTURE with some delay
after doing STREAMON on OUTPUT.
You can also play around with the min_buffers_needed field. My rule-of-thumb is
that
when start_streaming is called everything should be ready to stream. It is
painful
for drivers to have to keep track of the 'do I have enough buffers' status.
For that reason I introduced the min_buffers_needed field. What I believe you
can
do here is to set it initially to a large value, preventing start_streaming from
being called, and once you really know the minimum number of buffers that you
need
it can be updated again to the actual value.
I don't know this driver well enough to tell whether that works here or not, but
it is worth looking at IMHO.
Regards,
Hans
So this patch keeps the header buffer until the other frame
buffers are ready and dequeues it just before the first frame
is ready.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Changes from v1
- Addressed review comments from Sachin
https://patchwork.linuxtv.org/patch/23839/
---
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 ++
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|6 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index f5404a6..cc2b96e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -523,6 +523,7 @@ struct s5p_mfc_codec_ops {
* @output_state:state of the output buffers queue
* @src_bufs:information on allocated source buffers
* @dst_bufs:information on allocated destination buffers
+ * @header_mb: buffer pointer of the encoded sequence header
* @sequence:counter for the sequence number for v4l2
* @dec_dst_flag:flags for buffers queued in the hardware
* @dec_src_buf_size:size of the buffer for source buffers in
decoding
@@ -607,6 +608,7 @@ struct s5p_mfc_ctx {
int src_bufs_cnt;
struct s5p_mfc_buf dst_bufs[MFC_MAX_BUFFERS];
int dst_bufs_cnt;
+ struct s5p_mfc_buf *header_mb;
unsigned int sequence;
unsigned long dec_dst_flag;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index f8c7053..0c8d593e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -787,7 +787,7 @@ static int enc_post_seq_start(struct s5p_mfc_ctx *ctx)
ctx-dst_queue_cnt--;
vb2_set_plane_payload(dst_mb-b, 0,
s5p_mfc_hw_call(dev-mfc_ops, get_enc_strm_size, dev));
- vb2_buffer_done(dst_mb-b, VB2_BUF_STATE_DONE);
+ ctx-header_mb = dst_mb;
spin_unlock_irqrestore(dev-irqlock, flags);
}
@@ -845,6 +845,10 @@ static int enc_post_frame_start(struct s5p_mfc_ctx *ctx)
unsigned int strm_size;
unsigned long flags;
+ if (ctx-header_mb) {
+ vb2_buffer_done(ctx-header_mb-b, VB2_BUF_STATE_DONE);
+ ctx-header_mb = NULL;
+ }
slice_type = s5p_mfc_hw_call(dev-mfc_ops, get_enc_slice_type, dev);
strm_size = s5p_mfc_hw_call(dev-mfc_ops, get_enc_strm_size, dev);
mfc_debug(2, Encoded slice type: %d\n, slice_type);
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/2] Add resolution change event
On 05/14/2014 08:59 AM, Arun Kumar K wrote: This patchset adds a source_change event to the v4l2-events. This can be used for notifying the userspace about runtime format changes happening on video nodes / pads like resolution change in video decoder. Looks good. I'll merge this after the weekend if there are no more comments. Regards, Hans Changes from v4 -- - Addressed comments from Hans https://patchwork.linuxtv.org/patch/23892/ https://patchwork.linuxtv.org/patch/23893/ Changes from v3 -- - Addressed comments from Laurent / Hans https://patchwork.kernel.org/patch/4135731/ Changes from v2 --- - Event can be subscribed on specific pad / port as suggested by Hans. Changes from v1 --- - Addressed review comments from Hans and Laurent https://patchwork.kernel.org/patch/4000951/ Arun Kumar K (1): [media] v4l: Add source change event Pawel Osciak (1): [media] s5p-mfc: Add support for resolution change event Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 33 ++ .../DocBook/media/v4l/vidioc-subscribe-event.xml | 20 +++ drivers/media/platform/s5p-mfc/s5p_mfc.c |8 + drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |2 ++ drivers/media/v4l2-core/v4l2-event.c | 36 include/media/v4l2-event.h |4 +++ include/uapi/linux/videodev2.h |8 + 7 files changed, 111 insertions(+) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 8/8] cpufreq: exynos: remove all exynos specific cpufreq driver support
Hi Thomas, -config ARM_EXYNOS_CPU_FREQ_BOOST_SW - bool EXYNOS Frequency Overclocking - Software - depends on ARM_EXYNOS_CPUFREQ - select CPU_FREQ_BOOST_SW - select EXYNOS_THERMAL - help - This driver supports software managed overclocking (BOOST). - It allows usage of special frequencies for Samsung Exynos - processors if thermal conditions are appropriate. - - It reguires, for safe operation, thermal framework with properly - defined trip points. - - If in doubt, say N. - If I might ask, where this switch,to enable BOOST, will be moved? All in all, I would like to be able to enable boost :-). In my opinion we should have the Kconfig option to enable/disable the CPU_FREQ_BOOST_SW and this may be used with cpufreq-cpu0 driver as I've pointed out in the other patch. -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line unsubscribe linux-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 v7 5/5] arm: exynos: Add MCPM call-back functions
Add machine-dependent MCPM call-backs for Exynos5420. These are used
to power up/down the secondary CPUs during boot, shutdown, s2r and
switching.
Signed-off-by: Thomas Abraham thomas...@samsung.com
Signed-off-by: Inderpal Singh inderpa...@samsung.com
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Reviewed-by: Nicolas Pitre nicolas.pi...@linaro.org
---
Changes since v6:
Addressed the following comments from Lorenzo Pieralisi:
- Added a comment for the power down function suggested by Lorenzo.
- Unmapped the non-secure sram region after use.
- Removed unnecessary variable initialization.
arch/arm/mach-exynos/Kconfig |8 +
arch/arm/mach-exynos/Makefile |2 +
arch/arm/mach-exynos/mcpm-exynos.c | 351
arch/arm/mach-exynos/regs-pmu.h|3 +
4 files changed, 364 insertions(+)
create mode 100644 arch/arm/mach-exynos/mcpm-exynos.c
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index fc8bf18..1602abc 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -110,4 +110,12 @@ config SOC_EXYNOS5440
endmenu
+config EXYNOS5420_MCPM
+ bool Exynos5420 Multi-Cluster PM support
+ depends on MCPM SOC_EXYNOS5420
+ select ARM_CCI
+ help
+ This is needed to provide CPU and cluster power management
+ on Exynos5420 implementing big.LITTLE.
+
endif
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index f6dcc25..2e0666d 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -24,3 +24,5 @@ obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
plus_sec := $(call as-instr,.arch_extension sec,+sec)
AFLAGS_exynos-smc.o:=-Wa,-march=armv7-a$(plus_sec)
+
+obj-$(CONFIG_EXYNOS5420_MCPM) += mcpm-exynos.o
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
new file mode 100644
index 000..7d271e7
--- /dev/null
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -0,0 +1,351 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * arch/arm/mach-exynos/mcpm-exynos.c
+ *
+ * Based on arch/arm/mach-vexpress/dcscb.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/arm-cci.h
+#include linux/delay.h
+#include linux/io.h
+#include linux/of_address.h
+
+#include asm/cputype.h
+#include asm/cp15.h
+#include asm/mcpm.h
+
+#include regs-pmu.h
+#include common.h
+
+#define EXYNOS5420_CPUS_PER_CLUSTER4
+#define EXYNOS5420_NR_CLUSTERS 2
+#define MCPM_BOOT_ADDR_OFFSET 0x1c
+
+/*
+ * The common v7_exit_coherency_flush API could not be used because of the
+ * Erratum 799270 workaround. This macro is the same as the common one (in
+ * arch/arm/include/asm/cacheflush.h) except for the erratum handling.
+ */
+#define exynos_v7_exit_coherency_flush(level) \
+ asm volatile( \
+ stmfd sp!, {fp, ip}\n\t\
+ mrcp15, 0, r0, c1, c0, 0 @ get SCTLR\n\t \
+ bicr0, r0, #__stringify(CR_C)\n\t \
+ mcrp15, 0, r0, c1, c0, 0 @ set SCTLR\n\t \
+ isb\n\t\
+ bl v7_flush_dcache___stringify(level)\n\t \
+ clrex\n\t\
+ mrcp15, 0, r0, c1, c0, 1 @ get ACTLR\n\t \
+ bicr0, r0, #(1 6) @ disable local coherency\n\t \
+ /* Dummy Load of a device register to avoid Erratum 799270 */ \
+ ldrr4, [%0]\n\t \
+ andr4, r4, #0\n\t \
+ orrr0, r0, r4\n\t \
+ mcrp15, 0, r0, c1, c0, 1 @ set ACTLR\n\t \
+ isb\n\t \
+ dsb\n\t \
+ ldmfd sp!, {fp, ip} \
+ : \
+ : Ir (S5P_INFORM0) \
+ : r0, r1, r2, r3, r4, r5, r6, r7, \
+ r9, r10, lr, memory)
+
+/*
+ * We can't use regular spinlocks. In the switcher case, it is possible
+ * for an outbound CPU to call power_down() after its inbound counterpart
+ * is already live using the same logical CPU number which trips lockdep
+ * debugging.
+ */
+static arch_spinlock_t exynos_mcpm_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+static int
+cpu_use_count[EXYNOS5420_CPUS_PER_CLUSTER][EXYNOS5420_NR_CLUSTERS];
+
+#define exynos_cluster_usecnt(cluster) \
+ (cpu_use_count[0][cluster] + \
+cpu_use_count[1][cluster] + \
+cpu_use_count[2][cluster] + \
+cpu_use_count[3][cluster])
+
+#define exynos_cluster_unused(cluster) !exynos_cluster_usecnt(cluster)
+
+static int exynos_cluster_power_control(unsigned int cluster, int enable)
+{
+ unsigned int tries = 100;
+ unsigned int val;
+
+ if (enable) {
+ exynos_cluster_power_up(cluster);
+ val = S5P_CORE_LOCAL_PWR_EN;
+ } else {
+ exynos_cluster_power_down(cluster);
+ val = 0;
+ }
+
+ /*
Re: [PATCH v6 0/5] MCPM backend for Exynos5420
Hi Nicolas, [...] 1) can't create /sys/devices/system/cpu/cpu//online: nonexistent directory What do you get if you do: $ ls -d /sys/devices/system/cpu/cpu?/online ls: /sys/devices/system/cpu/cpu//online: No such file or directory ? 2) sleep: invalid number '.0026736' A sufficiently recent coreutils package should have a sleep command that accepts fractional values. Alternatively you may replace it with usleep: usleep $RANDOM Looks like my cramfs needs an update, it seems to have old packages. For 1) the cpu number is not being appended. if I give a particular cpu in the script then hotplug in/out works fine. For 2) a constant msleep 10 works. If you have msleep but not usleep then try: msleep $(($RANDOM / 1000)) I have msleep present. Is it OK for me to modify the script to hotplug in/off a randomly chosed core ? No. They must *all* be hotplugged simultaneously with some random timing. OK. Regards, Abhilash -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: exynos: add generic function to calculate cpu number
On 9 May 2014 14:04, Chander Kashyap chander.kash...@linaro.org wrote:
On 9 May 2014 13:47, Tomasz Figa t.f...@samsung.com wrote:
Hi Chander,
On 09.05.2014 09:50, Chander Kashyap wrote:
On 5 May 2014 09:37, Chander Kashyap chander.kash...@linaro.org wrote:
On 25 April 2014 11:14, Chander Kashyap chander.kash...@linaro.org wrote:
The address of cpu power registers in pmu is based on cpu number
offsets. This function calculate the same. This is essentially
required in case of multicluster SoC's e.g Exynos5420.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
arch/arm/mach-exynos/regs-pmu.h |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/mach-exynos/regs-pmu.h
b/arch/arm/mach-exynos/regs-pmu.h
index 4f6a256..217da2e 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -313,4 +313,13 @@
#define EXYNOS5_OPTION_USE_RETENTION (1 4)
+#include asm/cputype.h
+#define MAX_CPUS_IN_CLUSTER4
+
+static inline unsigned int exynos_pmu_cpunr(unsigned int mpidr)
+{
+ return ((MPIDR_AFFINITY_LEVEL(mpidr, 1) * MAX_CPUS_IN_CLUSTER)
++ MPIDR_AFFINITY_LEVEL(mpidr, 0));
+}
+
#endif /* __ASM_ARCH_REGS_PMU_H */
--
1.7.9.5
Kukjin, Can you please have a look.
--
with warm regards,
Chander Kashyap
Hi Kgene,
Can you take this patch if no issues with it.
Is there any user for this function right now? Shouldn't this patch
rather be included as a part of some series that adds actual users of it?
Hi Tomasz,
Exynos5420 patches have dependency on this.
Those patches already posted.
Please ignore. Sending this with cpuidle patches
Best regards,
Tomasz
--
with warm regards,
Chander Kashyap
--
with warm regards,
Chander Kashyap
--
To unsubscribe from this list: send the line unsubscribe linux-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 v5 6/6] mcpm: exynos: populate suspend and powered_up callbacks
In order to support cpuidle through mcpm, suspend and powered-up
callbacks are required in mcpm platform code.
Hence populate the same callbacks.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
Changes in v5:
1. Add comment to address cache access while c-bit is cleared in SCLTR
2. Make exynos_powered_up static
Changes in v4: None
Changes in v3:
1. Removed coherency enablement after suspend failure.
2. Use generic function to poweron cpu.
changes in v2:
1. Fixed typo: enynos_pmu_cpunr to exynos_pmu_cpunr
arch/arm/mach-exynos/mcpm-exynos.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
index c6bb3a4..623dfa7 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -253,10 +253,46 @@ static int exynos_power_down_finish(unsigned int cpu,
unsigned int cluster)
return -ETIMEDOUT; /* timeout */
}
+static void exynos_powered_up(void)
+{
+ unsigned int mpidr, cpu, cluster;
+
+ mpidr = read_cpuid_mpidr();
+ cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+ arch_spin_lock(exynos_mcpm_lock);
+ if (cpu_use_count[cpu][cluster] == 0)
+ cpu_use_count[cpu][cluster] = 1;
+ arch_spin_unlock(exynos_mcpm_lock);
+}
+
+static void exynos_suspend(u64 residency)
+{
+ unsigned int mpidr, cpunr;
+
+ exynos_power_down();
+
+ /*
+* Execution reaches here only if cpu did not power down.
+* Hence roll back the changes done in exynos_power_down function.
+*
+* CAUTION: This function requires the stack data to be visible through
+* power down and can only be executed on processors like A15 and A7
+* that hit the cache with the C bit clear in the SCTLR register.
+ */
+ mpidr = read_cpuid_mpidr();
+ cpunr = exynos_pmu_cpunr(mpidr);
+
+ exynos_cpu_power_up(cpunr);
+}
+
static const struct mcpm_platform_ops exynos_power_ops = {
.power_up = exynos_power_up,
.power_down = exynos_power_down,
.power_down_finish = exynos_power_down_finish,
+ .suspend= exynos_suspend,
+ .powered_up = exynos_powered_up,
};
static void __init exynos_mcpm_usage_count_init(void)
--
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 v5 2/6] arm: exynos: add generic function to calculate cpu number
The address of cpu power registers in pmu is based on cpu number
offsets. This function calculate the same. This is essentially
required in case of multi-cluster SoC's e.g Exynos5420.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
arch/arm/mach-exynos/regs-pmu.h |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 4179f6a..485aefd 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -325,4 +325,13 @@
#define EXYNOS5420_SWRESET_KFC_SEL 0x3
+#include asm/cputype.h
+#define MAX_CPUS_IN_CLUSTER4
+
+static inline unsigned int exynos_pmu_cpunr(unsigned int mpidr)
+{
+ return ((MPIDR_AFFINITY_LEVEL(mpidr, 1) * MAX_CPUS_IN_CLUSTER)
++ MPIDR_AFFINITY_LEVEL(mpidr, 0));
+}
+
#endif /* __ASM_ARCH_REGS_PMU_H */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/6] add cpuidle support for Exynos5420
Exynos5420 is a big-little Soc from Samsung. It has 4 A15 and 4 A7 cores. This patchset adds cpuidle support for Exynos5420 SoC based on generic big.little cpuidle driver. Tested on SMDK5420. This patch set depends on: 1. [PATCH 0/5] MCPM backend for Exynos5420 http://www.spinics.net/lists/arm-kernel/msg331100.html Changelog is in respective patches. Chander Kashyap (5): driver: cpuidle-big-little: add of_device_id structure arm: exynos: add generic function to calculate cpu number cpuidle: config: Add ARCH_EXYNOS entry to select cpuidle-big-little driver driver: cpuidle: cpuidle-big-little: init driver for Exynos5420 exynos: cpuidle: do not allow cpuidle registration for Exynos5420 mcpm: exynos: populate suspend and powered_up callbacks arch/arm/mach-exynos/cpuidle.c |3 +++ arch/arm/mach-exynos/mcpm-exynos.c | 36 ++ arch/arm/mach-exynos/regs-pmu.h |9 + drivers/cpuidle/Kconfig.arm |2 +- drivers/cpuidle/cpuidle-big_little.c | 12 +++- 5 files changed, 60 insertions(+), 2 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 5/6] exynos: cpuidle: do not allow cpuidle registration for Exynos5420
Exynos5420 is big.Little Soc. It uses cpuidle-big-litle generic cpuidle driver. Hence do not allow exynos cpuidle driver registration for Exynos5420. Signed-off-by: Chander Kashyap chander.kash...@linaro.org Signed-off-by: Chander Kashyap k.chan...@samsung.com Acked-by: Daniel Lezcano daniel.lezc...@linaro.org --- arch/arm/mach-exynos/cpuidle.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c index 3dd385e..807a386 100644 --- a/arch/arm/mach-exynos/cpuidle.c +++ b/arch/arm/mach-exynos/cpuidle.c @@ -218,6 +218,9 @@ static int exynos_cpuidle_probe(struct platform_device *pdev) int cpu_id, ret; struct cpuidle_device *device; + if (soc_is_exynos5420()) + return -ENODEV; + if (soc_is_exynos5250()) exynos5_core_down_clk(); -- 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 v5 4/6] driver: cpuidle: cpuidle-big-little: init driver for Exynos5420
Add samsung,exynos5420 compatible string to initialize generic
big-little cpuidle driver for Exynos5420.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
Acked-by: Daniel Lezcano daniel.lezc...@linaro.org
---
Changes in v4: None
Changes in v3:
1. Add compatible string to of_device_id table insted comparing
directoly
Changes in v2: none
drivers/cpuidle/cpuidle-big_little.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpuidle/cpuidle-big_little.c
b/drivers/cpuidle/cpuidle-big_little.c
index 4cd02bd..344d79fa 100644
--- a/drivers/cpuidle/cpuidle-big_little.c
+++ b/drivers/cpuidle/cpuidle-big_little.c
@@ -165,6 +165,7 @@ static int __init bl_idle_driver_init(struct cpuidle_driver
*drv, int cpu_id)
static const struct of_device_id compatible_machine_match[] = {
{ .compatible = arm,vexpress,v2p-ca15_a7 },
+ { .compatible = samsung,exynos5420 },
{},
};
--
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 v5 1/6] driver: cpuidle-big-little: add of_device_id structure
This driver will be used by many big.Little Soc's. As of now it does
string matching of hardcoded compatible string to init the driver. This
comparison list will keep on growing with addition of new SoC's.
Hence add of_device_id structure to collect the compatible strings of
SoC's using this driver.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
drivers/cpuidle/cpuidle-big_little.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/cpuidle/cpuidle-big_little.c
b/drivers/cpuidle/cpuidle-big_little.c
index b45fc62..4cd02bd 100644
--- a/drivers/cpuidle/cpuidle-big_little.c
+++ b/drivers/cpuidle/cpuidle-big_little.c
@@ -163,14 +163,23 @@ static int __init bl_idle_driver_init(struct
cpuidle_driver *drv, int cpu_id)
return 0;
}
+static const struct of_device_id compatible_machine_match[] = {
+ { .compatible = arm,vexpress,v2p-ca15_a7 },
+ {},
+};
+
static int __init bl_idle_init(void)
{
int ret;
+ struct device_node *root = of_find_node_by_path(/);
+
+ if (!root)
+ return -ENODEV;
/*
* Initialize the driver just for a compliant set of machines
*/
- if (!of_machine_is_compatible(arm,vexpress,v2p-ca15_a7))
+ if (!of_match_node(compatible_machine_match, root))
return -ENODEV;
/*
* For now the differentiation between little and big cores
--
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 v5 3/6] cpuidle: config: Add ARCH_EXYNOS entry to select cpuidle-big-little driver
Add support to select generic big-little cpuidle driver for Samsung Exynos series SoC's. This is required for Exynos big-little SoC's eg, Exynos5420. Signed-off-by: Chander Kashyap chander.kash...@linaro.org Signed-off-by: Chander Kashyap k.chan...@samsung.com --- Changes in v4: 1. Typo fixed from SOC_EXYNOS5420 to ARCH_EXYNOS 2. Commit message updated Changes in v3: None Changes in v2: 1. Changed config macro from SOC_EXYNOS5420 to ARCH_EXYNOS drivers/cpuidle/Kconfig.arm |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm index 97ccc31..d9596e7 100644 --- a/drivers/cpuidle/Kconfig.arm +++ b/drivers/cpuidle/Kconfig.arm @@ -4,7 +4,7 @@ config ARM_BIG_LITTLE_CPUIDLE bool Support for ARM big.LITTLE processors - depends on ARCH_VEXPRESS_TC2_PM + depends on ARCH_VEXPRESS_TC2_PM || ARCH_EXYNOS select ARM_CPU_SUSPEND select CPU_IDLE_MULTIPLE_DRIVERS help -- 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 v2] [media] s5p-mfc: Dequeue sequence header after STREAMON
Hi Hans,
On 05/14/14 12:39, Hans Verkuil wrote:
On 05/14/2014 08:29 AM, Arun Kumar K wrote:
MFCv6 encoder needs specific minimum number of buffers to
be queued in the CAPTURE plane. This minimum number will
be known only when the sequence header is generated.
So we used to allow STREAMON on the CAPTURE plane only after
sequence header is generated and checked with the minimum
buffer requirement.
But this causes a problem that we call a vb2_buffer_done
for the sequence header buffer before doing a STREAON on the
CAPTURE plane.
How could this ever have worked? Buffers aren't queued to the driver until
STREAMON is called, and calling vb2_buffer_done for a buffer that is not
queued
first to the driver will mess up internal data (q-queued_count for one).
This worked till now because __enqueue_in_driver is called first and
then start_streaming qop is called. In MFCv6, the start_streaming driver
callback used to wait till sequence header interrupt is received and it
used to do vb2_buffer_done in that interrupt context. So it happened
after buffers are enqueued in driver and before completing the vb2_streamon.
This used to still work fine until this patch
was merged -
b3379c6 : vb2: only call start_streaming if sufficient buffers are queued
Are you testing with CONFIG_VIDEO_ADV_DEBUG set? If not, you should do so.
That
will check whether all the vb2 calls are balanced.
BTW, that's a small typo in s5p_mfc_enc.c (search for 'inavlid').
I got it. Will post a patch fixing them. Thanks for spotting this.
This problem should also come in earlier MFC firmware versions
if the application calls STREAMON on CAPTURE with some delay
after doing STREAMON on OUTPUT.
You can also play around with the min_buffers_needed field. My rule-of-thumb
is that
when start_streaming is called everything should be ready to stream. It is
painful
for drivers to have to keep track of the 'do I have enough buffers' status.
For that reason I introduced the min_buffers_needed field. What I believe you
can
do here is to set it initially to a large value, preventing start_streaming
from
being called, and once you really know the minimum number of buffers that you
need
it can be updated again to the actual value.
If a large value is kept in min_buffers_needed, there will be some
unnecessary memory initialization needed for say 16 full HD raw YUV
buffers when actual needed is only 4. And once the encoding is started,
updating the min_buffers_needed to actual value doesnt give any
advantage as nobody checks for it after that.
So the whole idea is to not enforce a worst case buffer allocation
requirement beforehand itself. I hope the current scheme of things works
well for the requirement.
Regards
Arun
I don't know this driver well enough to tell whether that works here or not,
but
it is worth looking at IMHO.
Regards,
Hans
So this patch keeps the header buffer until the other frame
buffers are ready and dequeues it just before the first frame
is ready.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Changes from v1
- Addressed review comments from Sachin
https://patchwork.linuxtv.org/patch/23839/
---
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 ++
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|6 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index f5404a6..cc2b96e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -523,6 +523,7 @@ struct s5p_mfc_codec_ops {
* @output_state: state of the output buffers queue
* @src_bufs: information on allocated source buffers
* @dst_bufs: information on allocated destination buffers
+ * @header_mb: buffer pointer of the encoded sequence header
* @sequence: counter for the sequence number for v4l2
* @dec_dst_flag: flags for buffers queued in the hardware
* @dec_src_buf_size: size of the buffer for source buffers in
decoding
@@ -607,6 +608,7 @@ struct s5p_mfc_ctx {
int src_bufs_cnt;
struct s5p_mfc_buf dst_bufs[MFC_MAX_BUFFERS];
int dst_bufs_cnt;
+struct s5p_mfc_buf *header_mb;
unsigned int sequence;
unsigned long dec_dst_flag;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index f8c7053..0c8d593e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -787,7 +787,7 @@ static int enc_post_seq_start(struct s5p_mfc_ctx *ctx)
ctx-dst_queue_cnt--;
vb2_set_plane_payload(dst_mb-b, 0,
s5p_mfc_hw_call(dev-mfc_ops, get_enc_strm_size, dev));
-vb2_buffer_done(dst_mb-b, VB2_BUF_STATE_DONE);
+
Re: [PATCH v5 1/2] [media] v4l: Add source change event
Hi Arun,
On 14/05/14 08:59, Arun Kumar K wrote:
This event indicates that the video device has encountered
a source parameter change during runtime. This can typically be a
resolution change detected by a video decoder OR a format change
detected by an input connector.
This needs to be nofified to the userspace and the application may
be expected to reallocate buffers before proceeding. The application
can subscribe to events on a specific pad or input port which
it is interested in.
Signed-off-by: Arun Kumar K arun...@samsung.com
This looks like a nice API enhancement.
Acked-by: Sylwester Nawrocki s.nawro...@samsung.com
---
Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 33 ++
.../DocBook/media/v4l/vidioc-subscribe-event.xml | 20 +++
drivers/media/v4l2-core/v4l2-event.c | 36
include/media/v4l2-event.h |4 +++
include/uapi/linux/videodev2.h |8 +
5 files changed, 101 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
index 89891ad..820f86e 100644
--- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
@@ -242,6 +242,22 @@
/tgroup
/table
+table frame=none pgwide=1 id=v4l2-event-src-change
+ titlestruct structnamev4l2_event_src_change/structname/title
+ tgroup cols=3
+ cs-str;
+ tbody valign=top
+ row
+ entry__u32/entry
+ entrystructfieldchanges/structfield/entry
+ entry
+ A bitmask that tells what has changed. See xref
linkend=src-changes-flags /.
+ /entry
+ /row
+ /tbody
+ /tgroup
+/table
+
table pgwide=1 frame=none id=changes-flags
titleChanges/title
tgroup cols=3
@@ -270,6 +286,23 @@
/tbody
/tgroup
/table
+
+table pgwide=1 frame=none id=src-changes-flags
+ titleSource Changes/title
+ tgroup cols=3
+ cs-def;
+ tbody valign=top
+ row
+ entryconstantV4L2_EVENT_SRC_CH_RESOLUTION/constant/entry
+ entry0x0001/entry
+ entryThis event gets triggered when a resolution change is
+ detected at an input. This can come from an input connector or
+ from a video decoder.
+ /entry
+ /row
+ /tbody
+ /tgroup
+/table
/refsect1
refsect1
return-value;
diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
index 5c70b61..f016254 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
@@ -155,6 +155,26 @@
/entry
/row
row
+ entryconstantV4L2_EVENT_SOURCE_CHANGE/constant/entry
+ entry5/entry
+ entry
+ paraThis event is triggered when a source parameter change is
+detected during runtime by the video device. It can be a
+runtime resolution change triggered by a video decoder or the
+format change happening on an input connector.
+This event requires that the structfieldid/structfield
+matches the input index (when used with a video device node)
+or the pad index (when used with a subdevice node) from which
+you want to receive events./para
+
+ paraThis event has a v4l2-event-source-change; associated
+ with it. The structfieldchanges/structfield bitfield denotes
+ what has changed for the subscribed pad. If multiple events
+ occurred before application could dequeue them, then the changes
+ will have the ORed value of all the events generated./para
+ /entry
+ /row
+ row
entryconstantV4L2_EVENT_PRIVATE_START/constant/entry
entry0x0800/entry
entryBase event number for driver-private events./entry
diff --git a/drivers/media/v4l2-core/v4l2-event.c
b/drivers/media/v4l2-core/v4l2-event.c
index 86dcb54..8761aab 100644
--- a/drivers/media/v4l2-core/v4l2-event.c
+++ b/drivers/media/v4l2-core/v4l2-event.c
@@ -318,3 +318,39 @@ int v4l2_event_subdev_unsubscribe(struct v4l2_subdev
*sd, struct v4l2_fh *fh,
return v4l2_event_unsubscribe(fh, sub);
}
EXPORT_SYMBOL_GPL(v4l2_event_subdev_unsubscribe);
+
+static void v4l2_event_src_replace(struct v4l2_event *old,
+ const struct v4l2_event *new)
+{
+ u32 old_changes = old-u.src_change.changes;
+
+ old-u.src_change = new-u.src_change;
+ old-u.src_change.changes |= old_changes;
+}
+
+static void v4l2_event_src_merge(const struct v4l2_event *old,
+ struct v4l2_event *new)
+{
+
Re: [PATCH v5 2/2] [media] s5p-mfc: Add support for resolution change event
On 14/05/14 08:59, Arun Kumar K wrote:
From: Pawel Osciak posc...@chromium.org
When a resolution change point is reached, queue an event to signal the
userspace that a new set of buffers is required before decoding can
continue.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
Acked-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c |8
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 6b04f17..f3a4576 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -349,8 +349,16 @@ static void s5p_mfc_handle_frame(struct s5p_mfc_ctx *ctx,
/* All frames remaining in the buffer have been extracted */
if (dst_frame_status == S5P_FIMV_DEC_STATUS_DECODING_EMPTY) {
if (ctx-state == MFCINST_RES_CHANGE_FLUSH) {
+ static const struct v4l2_event ev_src_ch = {
+ .type = V4L2_EVENT_SOURCE_CHANGE,
+ .u.src_change.changes =
+ V4L2_EVENT_SRC_CH_RESOLUTION,
+ };
+
s5p_mfc_handle_frame_all_extracted(ctx);
ctx-state = MFCINST_RES_CHANGE_END;
+ v4l2_event_queue_fh(ctx-fh, ev_src_ch);
+
goto leave_handle_frame;
} else {
s5p_mfc_handle_frame_all_extracted(ctx);
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 4586186..326d8db 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -851,6 +851,8 @@ static int vidioc_subscribe_event(struct v4l2_fh *fh,
switch (sub-type) {
case V4L2_EVENT_EOS:
return v4l2_event_subscribe(fh, sub, 2, NULL);
+ case V4L2_EVENT_SOURCE_CHANGE:
+ return v4l2_src_change_event_subscribe(fh, sub);
default:
return -EINVAL;
}
--
To unsubscribe from this list: send the line unsubscribe linux-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] documentation/iommu: Add note on existing DT binding status
On Wed, May 14, 2014 at 11:23:33AM +0530, Shaik Ameer Basha wrote: .../devicetree/bindings/iommu/samsung,sysmmu.txt |5 + 1 file changed, 5 insertions(+) Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 2/2] [media] s5p-mfc: Add support for resolution change event
Hi,
Thank you for this patch.
From: Arun Kumar K [mailto:arunkk.sams...@gmail.com] On Behalf Of Arun
Kumar K
Sent: Wednesday, May 14, 2014 9:00 AM
To: linux-me...@vger.kernel.org; linux-samsung-soc@vger.kernel.org
Cc: k.deb...@samsung.com; s.nawro...@samsung.com; hverk...@xs4all.nl;
laurent.pinch...@ideasonboard.com; posc...@chromium.org;
arunkk.sams...@gmail.com
Subject: [PATCH v5 2/2] [media] s5p-mfc: Add support for resolution
change event
From: Pawel Osciak posc...@chromium.org
When a resolution change point is reached, queue an event to signal the
userspace that a new set of buffers is required before decoding can
continue.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
Acked-by: Kamil Debski k.deb...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c |8
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 6b04f17..f3a4576 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -349,8 +349,16 @@ static void s5p_mfc_handle_frame(struct
s5p_mfc_ctx *ctx,
/* All frames remaining in the buffer have been extracted */
if (dst_frame_status == S5P_FIMV_DEC_STATUS_DECODING_EMPTY) {
if (ctx-state == MFCINST_RES_CHANGE_FLUSH) {
+ static const struct v4l2_event ev_src_ch = {
+ .type = V4L2_EVENT_SOURCE_CHANGE,
+ .u.src_change.changes =
+ V4L2_EVENT_SRC_CH_RESOLUTION,
+ };
+
s5p_mfc_handle_frame_all_extracted(ctx);
ctx-state = MFCINST_RES_CHANGE_END;
+ v4l2_event_queue_fh(ctx-fh, ev_src_ch);
+
goto leave_handle_frame;
} else {
s5p_mfc_handle_frame_all_extracted(ctx);
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 4586186..326d8db 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -851,6 +851,8 @@ static int vidioc_subscribe_event(struct v4l2_fh
*fh,
switch (sub-type) {
case V4L2_EVENT_EOS:
return v4l2_event_subscribe(fh, sub, 2, NULL);
+ case V4L2_EVENT_SOURCE_CHANGE:
+ return v4l2_src_change_event_subscribe(fh, sub);
default:
return -EINVAL;
}
--
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 v5 0/6] add cpuidle support for Exynos5420
On 05/14/2014 10:03 AM, Chander Kashyap wrote: Exynos5420 is a big-little Soc from Samsung. It has 4 A15 and 4 A7 cores. This patchset adds cpuidle support for Exynos5420 SoC based on generic big.little cpuidle driver. Hi Chander, just a side question. I am not succeeding to have both cluster A7/A15 with the upstream kernel. How can I test your driver ? Did I miss something ? Thanks -- Daniel Tested on SMDK5420. This patch set depends on: 1. [PATCH 0/5] MCPM backend for Exynos5420 http://www.spinics.net/lists/arm-kernel/msg331100.html Changelog is in respective patches. Chander Kashyap (5): driver: cpuidle-big-little: add of_device_id structure arm: exynos: add generic function to calculate cpu number cpuidle: config: Add ARCH_EXYNOS entry to select cpuidle-big-little driver driver: cpuidle: cpuidle-big-little: init driver for Exynos5420 exynos: cpuidle: do not allow cpuidle registration for Exynos5420 mcpm: exynos: populate suspend and powered_up callbacks arch/arm/mach-exynos/cpuidle.c |3 +++ arch/arm/mach-exynos/mcpm-exynos.c | 36 ++ arch/arm/mach-exynos/regs-pmu.h |9 + drivers/cpuidle/Kconfig.arm |2 +- drivers/cpuidle/cpuidle-big_little.c | 12 +++- 5 files changed, 60 insertions(+), 2 deletions(-) -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/6] add cpuidle support for Exynos5420
Hi Daniel, On 14 May 2014 15:26, Daniel Lezcano daniel.lezc...@linaro.org wrote: On 05/14/2014 10:03 AM, Chander Kashyap wrote: Exynos5420 is a big-little Soc from Samsung. It has 4 A15 and 4 A7 cores. This patchset adds cpuidle support for Exynos5420 SoC based on generic big.little cpuidle driver. Hi Chander, just a side question. I am not succeeding to have both cluster A7/A15 with the upstream kernel. How can I test your driver ? Hmm on octa can be tested only for 4 cores. as cci is disabled. Did I miss something ? Thanks -- Daniel Tested on SMDK5420. This patch set depends on: 1. [PATCH 0/5] MCPM backend for Exynos5420 http://www.spinics.net/lists/arm-kernel/msg331100.html Changelog is in respective patches. Chander Kashyap (5): driver: cpuidle-big-little: add of_device_id structure arm: exynos: add generic function to calculate cpu number cpuidle: config: Add ARCH_EXYNOS entry to select cpuidle-big-little driver driver: cpuidle: cpuidle-big-little: init driver for Exynos5420 exynos: cpuidle: do not allow cpuidle registration for Exynos5420 mcpm: exynos: populate suspend and powered_up callbacks arch/arm/mach-exynos/cpuidle.c |3 +++ arch/arm/mach-exynos/mcpm-exynos.c | 36 ++ arch/arm/mach-exynos/regs-pmu.h |9 + drivers/cpuidle/Kconfig.arm |2 +- drivers/cpuidle/cpuidle-big_little.c | 12 +++- 5 files changed, 60 insertions(+), 2 deletions(-) -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- with warm regards, Chander Kashyap -- To unsubscribe from this list: send the line unsubscribe linux-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] ASoC: samsung: Add missing pm ops for Snow sound card driver
On Wed, May 14, 2014 at 08:49:06AM +0530, Tushar Behera wrote: Adding missing pm ops so that audio playback works across suspend and resume cycle. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH] mmc: card: restrict access to RPMB partition
On 9 May 2014 15:39, Yuvaraj Kumar C D yuvaraj...@gmail.com wrote:
From: Andrew Bresticker abres...@chromium.org
The RPMB partition should only be accessed through the RPMB ioctls
and not through read()/write(). This patch makes mmc_blk_open()
reject open attempts to the RPMB partition in read or write mode.
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
---
drivers/mmc/card/block.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 452782b..fd59090 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -297,7 +297,15 @@ static int mmc_blk_open(struct block_device *bdev,
fmode_t mode)
check_disk_change(bdev);
ret = 0;
- if ((mode FMODE_WRITE) md-read_only) {
+ /*
+* Reject read/write access to the RPMB partition. It should
+* only be accessed through ioctls.
+*/
+ if ((mode (FMODE_READ | FMODE_WRITE))
+ md-area_type MMC_BLK_DATA_AREA_RPMB) {
+ mmc_blk_put(md);
+ ret = -EACCES;
How shall user space be able to receive a file descriptor, unless it's
allowed to open the device?
Kind regards
Ulf Hansson
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/exynos: Make exynos_drm_init() call late during the bootup
exynos_drm_init() does probing of various drivers like dp_panel, hdmi, fimd, mixer, etc in an order and finally binds them together. Some of the drm devices (Eg: dp_panel) try to do regulator_get() and enable few supplies during their probe. Chances are that, these devices may get probed before the respective supply/PMIC is hooked. In such cases, dp_panel would continue with dummy regulator. Which is not what the system wants. Lets give the core connectivity and regulators modules some time to hookup the supplies before Exynos DRM devices comes into picture. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com --- This change is proposed after 1. Discussing with I2C/SPI DMA subsystem maintainers and Others @ https://lkml.org/lkml/2014/5/9/333 Trying to change the I2C, SPI and DMA drivers as subsys_initcall() Which was strictly opposed, as a flaw was found in DRM subsystem. 2. -EPROBE_DEFER won't work well with the current sequency of platform_driver_register()s in exynos_drm_init() 3. bridge_panel mechanism is under RFC and no conclusions were drawn yet. We should be able to probe each DRM device independently and let PROBE_DEFER take care of dependencies. But, this could cause lot of bootup time. late_initcall() of DRM works well and fixes all the above issues for now. Kindly suggest, if an alternative/better mechanism is out there. Thanks, drivers/gpu/drm/exynos/exynos_drm_drv.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index 4cef88f..78c185a 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -692,7 +692,7 @@ static void exynos_drm_exit(void) platform_driver_unregister(exynos_drm_platform_driver); } -module_init(exynos_drm_init); +late_initcall(exynos_drm_init); module_exit(exynos_drm_exit); MODULE_AUTHOR(Inki Dae inki@samsung.com); -- 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] documentation/iommu: Add note on existing DT binding status
On Wednesday 14 May 2014 11:23:33 Shaik Ameer Basha wrote: The current dt binding for Exynos System MMU can be changed, if found incompatible with the support for Generic IOMMU Binding. This patch adds a note to the binding documentation stating the same. Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com Acked-by: Arnd Bergmann a...@arndb.de -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 7/8] ARM: Exynos: switch to using generic cpufreq-cpu0 driver
On Wednesday 14 May 2014 06:41:15 Thomas Abraham wrote:
From: Thomas Abraham thomas...@samsung.com
Remove the platform device instantiation for Exynos specific cpufreq
driver and add the platform device for cpufreq-cpu0 driver.
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
arch/arm/mach-exynos/exynos.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index b32a907..489a495 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -232,7 +232,9 @@ void __init exynos_cpuidle_init(void)
void __init exynos_cpufreq_init(void)
{
- platform_device_register_simple(exynos-cpufreq, -1, NULL, 0);
+ if (!(of_machine_is_compatible(samsung,exynos5420))
+ !(of_machine_is_compatible(samsung,exynos5440)))
+ platform_device_register_simple(cpufreq-cpu0, -1, NULL, 0);
}
Could we please come up with a way to probe this from DT in the cpufreq-cpu0
driver itself, so we don't have to add a device in every platform using it?
I realize you copied it from the other platforms using this driver, but
it still seems really wrong.
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 v4 0/8] cpufreq: use cpufreq-cpu0 driver for exynos based platforms
On Wednesday 14 May 2014 06:41:08 Thomas Abraham wrote: The patch series removes the use of Exynos specific cpufreq driver and enables the use of cpufreq-cpu0 driver for Exynos4210, Exynos4x12 and Exynos5250 based platforms. This is being done for few reasons. (a) The Exynos cpufreq driver reads/writes clock controller registers bypassing the Exynos CCF driver which is sort of problematic. (b) Removes the need for having clock controller register definitions in the cpufreq driver and also removes the need for statically io-remapping clock controller address space (helps in moving towards multiplatform kernel). Thanks a lot for your continued effort. Looks great overall, but I have one comment about the general way the cpu0 cpufreq driver works, not specific to the exynos implementation. See my reply to patch 4. 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 v5 4/6] driver: cpuidle: cpuidle-big-little: init driver for Exynos5420
On Wednesday 14 May 2014 13:33:55 Chander Kashyap wrote:
diff --git a/drivers/cpuidle/cpuidle-big_little.c
b/drivers/cpuidle/cpuidle-big_little.c
index 4cd02bd..344d79fa 100644
--- a/drivers/cpuidle/cpuidle-big_little.c
+++ b/drivers/cpuidle/cpuidle-big_little.c
@@ -165,6 +165,7 @@ static int __init bl_idle_driver_init(struct
cpuidle_driver *drv, int cpu_id)
static const struct of_device_id compatible_machine_match[] = {
{ .compatible = arm,vexpress,v2p-ca15_a7 },
+ { .compatible = samsung,exynos5420 },
{},
};
Does the cpuidle-big_little driver actually care about the platform?
If not, it would be good to add a generic string here as well, for
future platforms to match.
It still makes sense to list both the generic string and the platform
specific one though, in case we have to work around subtle differences.
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 v4 7/8] ARM: Exynos: switch to using generic cpufreq-cpu0 driver
On 14 May 2014 18:20, Arnd Bergmann a...@arndb.de wrote: Could we please come up with a way to probe this from DT in the cpufreq-cpu0 driver itself, so we don't have to add a device in every platform using it? Its followed that way because DT Maintainers had strong objections to creating virtual device nodes and haven't allowed creation of nodes for cpufreq drivers.. For which there is no physical device, as CPU already has a separate node.. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/8] cpufreq: use cpufreq-cpu0 driver for exynos based platforms
On 14 May 2014 18:21, Arnd Bergmann a...@arndb.de wrote: Thanks a lot for your continued effort. Looks great overall, but I have one comment about the general way the cpu0 cpufreq driver works, not specific to the exynos implementation. See my reply to patch 4. I hope you meant 7 here instead of 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 v4 7/8] ARM: Exynos: switch to using generic cpufreq-cpu0 driver
Am Mittwoch, 14. Mai 2014, 18:35:29 schrieb Viresh Kumar: On 14 May 2014 18:20, Arnd Bergmann a...@arndb.de wrote: Could we please come up with a way to probe this from DT in the cpufreq-cpu0 driver itself, so we don't have to add a device in every platform using it? Its followed that way because DT Maintainers had strong objections to creating virtual device nodes and haven't allowed creation of nodes for cpufreq drivers.. For which there is no physical device, as CPU already has a separate node.. as we already have the enable-method property for enabling/disabling cpus, would something like a scaling-method be feasible? -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 7/8] ARM: Exynos: switch to using generic cpufreq-cpu0 driver
On 14 May 2014 18:41, Heiko Stübner he...@sntech.de wrote: Am Mittwoch, 14. Mai 2014, 18:35:29 schrieb Viresh Kumar: On 14 May 2014 18:20, Arnd Bergmann a...@arndb.de wrote: Could we please come up with a way to probe this from DT in the cpufreq-cpu0 driver itself, so we don't have to add a device in every platform using it? Its followed that way because DT Maintainers had strong objections to creating virtual device nodes and haven't allowed creation of nodes for cpufreq drivers.. For which there is no physical device, as CPU already has a separate node.. as we already have the enable-method property for enabling/disabling cpus, would something like a scaling-method be feasible? Lets see what DT maintainers have to say on this, I would rather go for a more straight forward name: scaling-driver :) .. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/8] cpufreq: use cpufreq-cpu0 driver for exynos based platforms
On Wednesday 14 May 2014 18:37:13 Viresh Kumar wrote: On 14 May 2014 18:21, Arnd Bergmann a...@arndb.de wrote: Thanks a lot for your continued effort. Looks great overall, but I have one comment about the general way the cpu0 cpufreq driver works, not specific to the exynos implementation. See my reply to patch 4. I hope you meant 7 here instead of 4 ? Yes, that's right, sorry for the confusion. 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 v3 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
On Wed, May 14, 2014 at 7:32 AM, Nishanth Menon n...@ti.com wrote: On Tue, May 13, 2014 at 8:03 PM, Thomas Abraham ta.oma...@gmail.com wrote: From: Thomas Abraham thomas...@samsung.com Add a new optional boost-frequency binding for specifying the frequencies usable in boost mode. Cc: Nishanth Menon n...@ti.com Cc: Lukasz Majewski l.majew...@samsung.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Signed-off-by: Thomas Abraham thomas...@samsung.com --- .../devicetree/bindings/cpufreq/cpufreq-boost.txt | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt new file mode 100644 index 000..d925e38 --- /dev/null +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt @@ -0,0 +1,11 @@ +* Device tree binding for CPU boost frequency (aka over-clocking) + +Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as +overclocking) in which the CPU can operate in frequencies beyond the normal operate at? +operating conditions. normal operating conditions probably need a little bit of an expansion here perhaps? + +Optional Properties: +- boost-frequency: list of frequencies in KHz to be used only in boost mode. probably boost-frequencies? + This list should be a subset of frequencies listed in operating-points + property. Refer to Documentation/devicetree/bindings/power/opp.txt for + details about operating-points property. an example is expected here. personally, I think I understand the intent here, but as a hardware description, will let folks comment if it is acceptable. Thanks for your review Nishanth. I will do the changes you have suggested. Regards, Thomas. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 7/8] ARM: Exynos: switch to using generic cpufreq-cpu0 driver
On Wednesday 14 May 2014 18:44:46 Viresh Kumar wrote: On 14 May 2014 18:41, Heiko Stübner he...@sntech.de wrote: Am Mittwoch, 14. Mai 2014, 18:35:29 schrieb Viresh Kumar: On 14 May 2014 18:20, Arnd Bergmann a...@arndb.de wrote: Could we please come up with a way to probe this from DT in the cpufreq-cpu0 driver itself, so we don't have to add a device in every platform using it? Its followed that way because DT Maintainers had strong objections to creating virtual device nodes and haven't allowed creation of nodes for cpufreq drivers.. For which there is no physical device, as CPU already has a separate node.. as we already have the enable-method property for enabling/disabling cpus, would something like a scaling-method be feasible? Good idea to put it as a property into the CPU node. Lets see what DT maintainers have to say on this, I would rather go for a more straight forward name: scaling-driver .. Both sound fine to me. 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 v4 2/8] clk: samsung: change scope of samsung clock lock to global
On Wed, May 14, 2014 at 9:20 AM, Viresh Kumar viresh.ku...@linaro.org wrote: On 14 May 2014 06:41, Thomas Abraham ta.oma...@gmail.com wrote: From: Thomas Abraham thomas...@samsung.com Access to samsung clock lock is required to support newer samsung specific clock types. So change the scope of the samsung clock lock to global. And Maybe bit more detail on why exactly it should be available outside this file. Okay, will do in the next version. -- To unsubscribe from this list: send the line unsubscribe linux-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 v6 0/5] MCPM backend for Exynos5420
On Wed, 14 May 2014, Abhilash Kesavan wrote: Hi Nicolas, [...] 1) can't create /sys/devices/system/cpu/cpu//online: nonexistent directory What do you get if you do: $ ls -d /sys/devices/system/cpu/cpu?/online ls: /sys/devices/system/cpu/cpu//online: No such file or directory Somehow, you or your shell replaced the ? character into a / character. You could try with a * instead. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/5] MCPM backend for Exynos5420
Hi Nicolas, On Wed, May 14, 2014 at 7:03 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Wed, 14 May 2014, Abhilash Kesavan wrote: Hi Nicolas, [...] 1) can't create /sys/devices/system/cpu/cpu//online: nonexistent directory What do you get if you do: $ ls -d /sys/devices/system/cpu/cpu?/online ls: /sys/devices/system/cpu/cpu//online: No such file or directory Somehow, you or your shell replaced the ? character into a / character. You could try with a * instead. With a different RFS your script runs fine without any change. Will update with results once testing is done. Abhilash Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/8] cpufreq: cpufreq-cpu0: allow use of optional boost mode frequencies
Hi Lukasz, Viresh, On Wed, May 14, 2014 at 11:50 AM, Viresh Kumar viresh.ku...@linaro.org wrote: On 14 May 2014 11:47, Lukasz Majewski l.majew...@samsung.com wrote: I think that you can rely solely on the CPU_FREQ_BOOST_SW flag if the original author of cpufreq-cpu0.c don't mind. We don't have to. struct cpufreq_driver: boost_supported is always available. Just update it without any ugly #ifdefs .. Okay, so you are suggesting that Kconfig entry used to select cpufreq-cpu0 should also enable CPU_FREQ_BOOST_SW config as well. Considering that exynos4412 is the only user of this feature in mainline, should we do this? -- To unsubscribe from this list: send the line unsubscribe linux-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: [PATCHv4 5/7] clk: samsung: exynos3250: Add clocks using common clock framework
Hi Chanwoo
On 14.05.2014 08:57, Chanwoo Choi wrote:
On 05/14/2014 01:28 AM, Tomasz Figa wrote:
On 13.05.2014 13:49, Chanwoo Choi wrote:
On 04/26/2014 09:39 AM, Tomasz Figa wrote:
On 25.04.2014 03:16, Chanwoo Choi wrote:
+/* GATE_BLOCK */
+GATE(CLK_BLOCK_LCD, block_lcd, div_aclk_160, GATE_BLOCK, 4, 0,
0),
+GATE(CLK_BLOCK_G3D, block_g3d, div_aclk_200, GATE_BLOCK, 3, 0,
0),
Are there only 2 gate block clocks? By the way, how are they going to be
handled by respective drivers? There is no mainline support for them right
now, but you should be aware that adding them will cause common clock
framework to disable them if not claimed by any driver.
OK, I'll add remaing clock gate of GATE_BLOCK as following.
- CLK_BLOCK_MFC MFC_BLK
- CLK_BLOCK_CAM CAM_BLK
I agree that in the end the block gates will have to be added. However
currently drivers do not request block gates and enable them.
Considering that common clock framework disables all unused clocks by
default, this will lead to all the gate block clocks being disabled,
which is not desired.
You're right.
My opinion on this is that block gate clocks should be added in separate
patch along with patches adding code to get and enable them.
OK, I'll remove the clocks of GATE_BLOCK on next posting(v6)
OK, thanks.
By the way, if there are no other comments to v5 series than to this
patch, then you can simply send v6 of this single patch as a reply to v5.
+};
+
+/* APLL MPLL BPLL UPLL */
+static struct samsung_pll_rate_table exynos3250_pll_rates[] = {
+PLL_35XX_RATE(12, 400, 4, 1),
+PLL_35XX_RATE(11, 275, 3, 1),
+PLL_35XX_RATE(106600, 533, 6, 1),
+PLL_35XX_RATE(10, 250, 3, 1),
+PLL_35XX_RATE( 96000, 320, 4, 1),
+PLL_35XX_RATE( 9, 300, 4, 1),
+PLL_35XX_RATE( 85000, 425, 6, 1),
+PLL_35XX_RATE( 8, 200, 3, 1),
+PLL_35XX_RATE( 7, 175, 3, 1),
+PLL_35XX_RATE( 66700, 667, 12, 1),
+PLL_35XX_RATE( 6, 400, 4, 2),
+PLL_35XX_RATE( 53300, 533, 6, 2),
+PLL_35XX_RATE( 52000, 260, 3, 2),
+PLL_35XX_RATE( 5, 250, 3, 2),
+PLL_35XX_RATE( 4, 200, 3, 2),
+PLL_35XX_RATE( 2, 200, 3, 3),
+PLL_35XX_RATE( 1, 200, 3, 4),
+{ /* sentinel */ }
+};
+
+/* VPLL */
+static struct samsung_pll_rate_table exynos3250_vpll_rates[] = {
+PLL_36XX_RATE(6, 100, 2, 1, 0),
+PLL_36XX_RATE(53300, 267, 3, 2, 32668),
The TRM actually lists this as 267, 3, 2, 32768, and according to the
equation it will be 53515 Hz. Looks like a typo in the data sheet,
as 266, 3, 2, 32768 gives 53315, which is almost exactly 533 MHz.
+PLL_36XX_RATE(519231000, 173, 2, 2, 5046),
519230991
+PLL_36XX_RATE(5, 250, 3, 2, 0),
+PLL_36XX_RATE(44550, 149, 2, 2, 32768),
448500022
Also looks like a typo in the TRM, as 148, 2, 2, 32768 gives 445500022,
which is almost exactly 445.5 MHz.
+PLL_36XX_RATE(445055000, 148, 2, 2, 23047),
445055024
+PLL_36XX_RATE(4, 200, 3, 2, 0),
+PLL_36XX_RATE(37125, 124, 2, 2, 49512),
The TRM lists this as 124, 2, 2, 49152 and calculated frequency is
374250034. This one also looks like a typo. 123, 2, 2, 49512 would give
371250034.
When I calculated fout with following data:
- 124, 2, 2, 49512 would give 374266514.1
- 123, 2, 2, 49512 would give 371266514.1.
I think below value is proper.
- 123, 2, 2, 49512 would give 371266514.1.
Sorry, my bad, I made a typo as well ;). It should be 123, 2, 2, 49152.
The value I got was correct - 371250034.
+PLL_36XX_RATE(370879000, 185, 3, 2, 28803),
370879011
+PLL_36XX_RATE(34000, 170, 3, 2, 0),
+PLL_36XX_RATE(33500, 112, 2, 2, 43691),
33845
111, 2, 2, 43691 would give 33545. A typo in TRM?
+PLL_36XX_RATE(33300, 111, 2, 2, 0),
+PLL_36XX_RATE(33000, 110, 2, 2, 0),
+PLL_36XX_RATE(32000, 107, 2, 2, 43691),
32345
106, 2, 2, 43691 would give 32045.
+PLL_36XX_RATE(3, 100, 2, 2, 0),
+PLL_36XX_RATE(27500, 275, 3, 3, 0),
+PLL_36XX_RATE(22275, 149, 2, 3, 32768),
224250011
148, 2, 3, 32768 would give 222750011.
+PLL_36XX_RATE(222528000, 148, 2, 3, 23069),
222528015
+PLL_36XX_RATE(16000, 160, 3, 3, 0),
+PLL_36XX_RATE(14850, 99, 2, 3, 0),
+PLL_36XX_RATE(148352000, 99, 2, 3, 59070),
149852025
98, 2, 3, 59070 would give 148352025.
+PLL_36XX_RATE(10800, 144, 2, 4, 0),
+PLL_36XX_RATE( 7425, 99, 2, 4, 0),
+PLL_36XX_RATE( 74176000, 99, 3, 4, 59070),
The TRM seems to list this as 99, 2, 4 and calculated frequency will be
74926012, but 98, 2, 4, 59070 would give 74176012.
+PLL_36XX_RATE( 54054000, 216, 3, 5, 14156),
54054001
+PLL_36XX_RATE( 5400, 144, 2, 5, 0),
Are all
Re: [PATCH v4 7/8] ARM: Exynos: switch to using generic cpufreq-cpu0 driver
On Wed, May 14, 2014 at 8:18 AM, Arnd Bergmann a...@arndb.de wrote: On Wednesday 14 May 2014 18:44:46 Viresh Kumar wrote: On 14 May 2014 18:41, Heiko Stübner he...@sntech.de wrote: Am Mittwoch, 14. Mai 2014, 18:35:29 schrieb Viresh Kumar: On 14 May 2014 18:20, Arnd Bergmann a...@arndb.de wrote: Could we please come up with a way to probe this from DT in the cpufreq-cpu0 driver itself, so we don't have to add a device in every platform using it? Its followed that way because DT Maintainers had strong objections to creating virtual device nodes and haven't allowed creation of nodes for cpufreq drivers.. For which there is no physical device, as CPU already has a separate node.. as we already have the enable-method property for enabling/disabling cpus, would something like a scaling-method be feasible? Good idea to put it as a property into the CPU node. We already have properties which indicate this driver can be used by a platform: opp table and a clock for the cpu. If this information is not sufficient to determine whether you can use this driver or not, then you simply need to match against the platform. Perhaps the match list should be a blacklist rather than a whitelist, so new platforms work without a kernel change. Alternatively, create a new OPP binding that addresses this and all the other limitations in the current OPP binding. Lets see what DT maintainers have to say on this, I would rather go for a more straight forward name: scaling-driver .. Both sound fine to me. The fact that linux needs a way to create a platform device to enable a certain driver is not a DT problem. I proposed a solution for how to get this out of the platform code [1], but evidently we want people to open code the exceptions and adding boilerplate helpers will just encourage the exceptions. Rob [1] https://lkml.org/lkml/2013/10/30/30 -- To unsubscribe from this list: send the line unsubscribe linux-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 1/2] cpufreq / OPP: Allow boost frequency to be looked up from device tree
On Wed, May 14, 2014 at 9:10 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 14 May 2014 06:32, Thomas Abraham ta.oma...@gmail.com wrote:
From: Thomas Abraham thomas...@samsung.com
Commit 6f19efc0 (cpufreq: Add boost frequency support in core) adds
support for CPU boost mode. This patch adds support for finding available
boost frequencies from device tree and marking them as usable in boost mode.
Cc: Nishanth Menon n...@ti.com
Cc: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
drivers/cpufreq/cpufreq_opp.c | 39 +++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_opp.c b/drivers/cpufreq/cpufreq_opp.c
index c0c6f4a..e3c97f3 100644
--- a/drivers/cpufreq/cpufreq_opp.c
+++ b/drivers/cpufreq/cpufreq_opp.c
@@ -19,6 +19,7 @@
#include linux/pm_opp.h
#include linux/rcupdate.h
#include linux/slab.h
+#include linux/of.h
/**
* dev_pm_opp_init_cpufreq_table() - create a cpufreq table for a device
@@ -51,6 +52,10 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table *freq_table = NULL;
int i, max_opps, ret = 0;
unsigned long rate;
+#ifdef CONFIG_CPU_FREQ_BOOST_SW
+ int j, len;
+ u32 *boost_freqs = NULL;
+#endif
rcu_read_lock();
@@ -82,6 +87,40 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
*table = freq_table[0];
+#ifdef CONFIG_CPU_FREQ_BOOST_SW
+ if (of_find_property(dev-of_node, boost-frequency, len)) {
Does this mean another block inside the cpu node ? Like this: ?
cpu@0 {
compatible = arm,cortex-a9;
reg = 0;
next-level-cache = L2;
operating-points =
/* kHzuV */
792000 110
396000 95
198000 85
;
boost-frequency =
792000
198000
;
};
I think it we might better add another field in the opp block as these
OPPs are rather boost one..
@Rob/Rafael: Opinion please ..
+ if (len == 0 || (len (sizeof(u32) - 1)) != 0) {
+ dev_err(dev, %s: invalid boost frequency\n,
__func__);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ boost_freqs = kzalloc(len, GFP_KERNEL);
+ if (!boost_freqs) {
+ dev_warn(dev, %s: no memory for boost freq table\n,
+ __func__);
+ ret = -ENOMEM;
+ goto out;
+ }
+ of_property_read_u32_array(dev-of_node, boost-frequency,
+ boost_freqs, len / sizeof(u32));
+ }
+
+ for (j = 0; j len / sizeof(u32) boost_freqs; j++) {
Why is this present outside of above if {} ? as boost_freqs is guaranteed to
be NULL without that.
Just to reduce indentation by one tab. No technical reasons. The code
had to wrap at 80 column was becoming unreadable.
+ for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END;
i++) {
+ if (boost_freqs[j] == freq_table[i].frequency) {
Use cpufreq_frequency_table_get_index() instead.
Okay. Thanks for pointing out.
+ freq_table[i].flags |= CPUFREQ_BOOST_FREQ;
+ break;
+ }
+ }
+ if (freq_table[i].frequency == CPUFREQ_TABLE_END)
+ pr_err(%s: invalid boost frequency %d\n,
+ __func__, boost_freqs[j]);
+ }
+
+ kfree(boost_freqs);
+#endif
+
out:
rcu_read_unlock();
if (ret)
--
1.7.4.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 v3 1/2] cpufreq / OPP: Allow boost frequency to be looked up from device tree
On Wed, May 14, 2014 at 11:54 AM, Viresh Kumar viresh.ku...@linaro.org wrote: On 14 May 2014 11:39, Lukasz Majewski l.majew...@samsung.com wrote: I agree with Nishanth here, that point 1 (as described by Viresh at [*]) is a more scalable approach. The only reason why I wanted all that to be done at OPP level was to ensure if somebody else also needs it apart from cpufreq, they don't have to duplicate code and find it.. As it is present at a central place.. But if no other code is going to look for that, it may just be fine as is.. Yes, I agree with Nishanth and Lukasz for a separate binding. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/8] cpufreq: cpufreq-cpu0: allow use of optional boost mode frequencies
On 14 May 2014 19:13, Thomas Abraham ta.oma...@gmail.com wrote: Okay, so you are suggesting that Kconfig entry used to select cpufreq-cpu0 should also enable CPU_FREQ_BOOST_SW config as well. I never said that... That should be enabled by your defconfig instead. What I said was, don't put code within any #ifdefs in cpufreq-cpu0. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 8/8] cpufreq: exynos: remove all exynos specific cpufreq driver support
Hi Lukasz, On Wed, May 14, 2014 at 12:50 PM, Lukasz Majewski l.majew...@samsung.com wrote: Hi Thomas, -config ARM_EXYNOS_CPU_FREQ_BOOST_SW - bool EXYNOS Frequency Overclocking - Software - depends on ARM_EXYNOS_CPUFREQ - select CPU_FREQ_BOOST_SW - select EXYNOS_THERMAL - help - This driver supports software managed overclocking (BOOST). - It allows usage of special frequencies for Samsung Exynos - processors if thermal conditions are appropriate. - - It reguires, for safe operation, thermal framework with properly - defined trip points. - - If in doubt, say N. - If I might ask, where this switch,to enable BOOST, will be moved? All in all, I would like to be able to enable boost :-). The intent was to have a separate boost config option for cpufreq-cpu0 driver, only available if cpufreq-cpu0 driver is selected, as done in the other patch. In my opinion we should have the Kconfig option to enable/disable the CPU_FREQ_BOOST_SW and this may be used with cpufreq-cpu0 driver as I've pointed out in the other patch. Okay, this is how this patch series handles CPU_FREQ_BOOST_SW config option. Thanks, Thomas. -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line unsubscribe linux-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 1/2] cpufreq / OPP: Allow boost frequency to be looked up from device tree
On 14 May 2014 19:16, Thomas Abraham ta.oma...@gmail.com wrote:
On Wed, May 14, 2014 at 9:10 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
Why is this present outside of above if {} ? as boost_freqs is guaranteed to
be NULL without that.
Just to reduce indentation by one tab. No technical reasons. The code
had to wrap at 80 column was becoming unreadable.
That's bad :), you have added an extra comparison just for that :(
Instead kill the below indentation by doing a goto out with a ! of
below expression:
+ if (of_find_property(dev-of_node, boost-frequency, len)) {
--
To unsubscribe from this list: send the line unsubscribe linux-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 v6 6/8] ARM: dts: exynos5420-peach-pit: Add Vbus regulator for USB 3.0
Add required fixed-regulator for VBUS supply for USB 3.0
controller phy.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 46
1 file changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index fae33dd..8402ec3 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -58,6 +58,28 @@
pinctrl-0 = pwm0_out;
pinctrl-names = default;
};
+
+ usb300_vbus_reg: regulator-usb300 {
+ compatible = regulator-fixed;
+ regulator-name = P5.0V_USB3CON0;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gph0 0 0;
+ pinctrl-names = default;
+ pinctrl-0 = usb300_vbus_en;
+ enable-active-high;
+ };
+
+ usb301_vbus_reg: regulator-usb301 {
+ compatible = regulator-fixed;
+ regulator-name = P5.0V_USB3CON1;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gph0 1 0;
+ pinctrl-names = default;
+ pinctrl-0 = usb301_vbus_en;
+ enable-active-high;
+ };
};
pinctrl_0 {
@@ -76,6 +98,22 @@
};
};
+pinctrl_3 {
+ usb300_vbus_en: usb300-vbus-en {
+ samsung,pins = gph0-0;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ usb301_vbus_en: usb301-vbus-en {
+ samsung,pins = gph0-1;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+};
+
rtc {
status = okay;
};
@@ -137,6 +175,14 @@
};
};
+usbdrd3_0 {
+ vbus-supply = usb300_vbus_reg;
+};
+
+usbdrd3_1 {
+ vbus-supply = usb301_vbus_reg;
+};
+
/*
* Use longest HW watchdog in SoC (32 seconds) since the hardware
* watchdog provides no debugging information (compared to soft/hard
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 8/8] ARM: dts: exynos5800-peach-pi: Add Vbus regulator for USB 3.0
From: Vivek gautam gautam.vi...@samsung.com
Add required fixed-regulator for VBUS supply for USB 3.0
controller phy.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5800-peach-pi.dts | 46 +
1 file changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 4ed9ccc..8301bca 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -56,6 +56,28 @@
pinctrl-0 = pwm0_out;
pinctrl-names = default;
};
+
+ usb300_vbus_reg: regulator-usb300 {
+ compatible = regulator-fixed;
+ regulator-name = P5.0V_USB3CON0;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gph0 0 0;
+ pinctrl-names = default;
+ pinctrl-0 = usb300_vbus_en;
+ enable-active-high;
+ };
+
+ usb301_vbus_reg: regulator-usb301 {
+ compatible = regulator-fixed;
+ regulator-name = P5.0V_USB3CON1;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gph0 1 0;
+ pinctrl-names = default;
+ pinctrl-0 = usb301_vbus_en;
+ enable-active-high;
+ };
};
pinctrl_0 {
@@ -74,6 +96,22 @@
};
};
+pinctrl_3 {
+ usb300_vbus_en: usb300-vbus-en {
+ samsung,pins = gph0-0;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ usb301_vbus_en: usb301-vbus-en {
+ samsung,pins = gph0-1;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+};
+
rtc {
status = okay;
};
@@ -134,6 +172,14 @@
};
};
+usbdrd3_0 {
+ vbus-supply = usb300_vbus_reg;
+};
+
+usbdrd3_1 {
+ vbus-supply = usb301_vbus_reg;
+};
+
/*
* Use longest HW watchdog in SoC (32 seconds) since the hardware
* watchdog provides no debugging information (compared to soft/hard
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 7/8] ARM: dts: exynos5420-smdk5420: Add Vbus regulator for USB 3.0
Add required fixed-regulator for VBUS supply for USB 3.0
controller phy.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 46 +
1 file changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 6910485..6053c9f 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -140,6 +140,22 @@
};
};
+ pinctrl@1400 {
+ usb300_vbus_en: usb300-vbus-en {
+ samsung,pins = gpg0-5;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ usb301_vbus_en: usb301-vbus-en {
+ samsung,pins = gpg1-4;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+ };
+
hdmi@1453 {
status = okay;
hpd-gpio = gpx3 7 0;
@@ -147,6 +163,36 @@
pinctrl-0 = hdmi_hpd_irq;
};
+ usb300_vbus_reg: regulator-usb300 {
+ compatible = regulator-fixed;
+ regulator-name = VBUS0;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gpg0 5 0;
+ pinctrl-names = default;
+ pinctrl-0 = usb300_vbus_en;
+ enable-active-high;
+ };
+
+ usb301_vbus_reg: regulator-usb301 {
+ compatible = regulator-fixed;
+ regulator-name = VBUS1;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gpg1 4 0;
+ pinctrl-names = default;
+ pinctrl-0 = usb301_vbus_en;
+ enable-active-high;
+ };
+
+ phy@1210 {
+ vbus-supply = usb300_vbus_reg;
+ };
+
+ phy@1250 {
+ vbus-supply = usb301_vbus_reg;
+ };
+
i2c_2: i2c@12C8 {
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 66000;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 5/8] ARM: dts: exynos5250-snow: Add Vbus regulator for USB 3.0
Add required fixed-regulator for VBUS supply for USB 3.0
controller phy.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250-snow.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 1ce1088..fd9b3b3 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -37,6 +37,13 @@
sd3_bus4: sd3-bus-width4 {
samsung,pin-drv = 0;
};
+
+ usb3_vbus_en: usb3-vbus-en {
+ samsung,pins = gpx2-7;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
};
gpio-keys {
@@ -196,6 +203,21 @@
};
};
+ usb3_vbus_reg: regulator-usb3 {
+ compatible = regulator-fixed;
+ regulator-name = P5.0V_USB3CON;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gpx2 7 0;
+ pinctrl-names = default;
+ pinctrl-0 = usb3_vbus_en;
+ enable-active-high;
+ };
+
+ phy@1210 {
+ vbus-supply = usb3_vbus_reg;
+ };
+
usb@1211 {
samsung,vbus-gpio = gpx1 1 0;
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 3/8] ARM: dts: exynos5250: Enable support for generic USB DRD phy
Add device tree node for new usbdrd-phy driver, which
is based on generic phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 2fa6345..8303a42 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -574,6 +574,15 @@
};
};
+ usbdrd_phy: phy@1210 {
+ compatible = samsung,exynos5250-usbdrd-phy;
+ reg = 0x1210 0x100;
+ clocks = clock CLK_USB3, clock CLK_FIN_PLL;
+ clock-names = phy, ref;
+ samsung,pmu-syscon = pmu_system_controller;
+ #phy-cells = 1;
+ };
+
usb@1211 {
compatible = samsung,exynos4210-ehci;
reg = 0x1211 0x100;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 2/8] ARM: dts: exynos5420: Enable support for DWC3 controller
Add device tree nodes for DWC3 controller present on
Exynos 5420 SoC, to enable support for USB 3.0.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 8eebf7f..128829a 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -805,6 +805,23 @@
samsung,pmureg-phandle = pmu_system_controller;
};
+ usbdrd3_0: usb@1200 {
+ compatible = samsung,exynos5250-dwusb3;
+ clocks = clock CLK_USBD300;
+ clock-names = usbdrd30;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dwc3 {
+ compatible = snps,dwc3;
+ reg = 0x1200 0x1;
+ interrupts = 0 72 0;
+ phys = usbdrd_phy0 0, usbdrd_phy0 1;
+ phy-names = usb2-phy, usb3-phy;
+ };
+ };
+
usbdrd_phy0: phy@1210 {
compatible = samsung,exynos5420-usbdrd-phy;
reg = 0x1210 0x100;
@@ -814,6 +831,23 @@
#phy-cells = 1;
};
+ usbdrd3_1: usb@1240 {
+ compatible = samsung,exynos5250-dwusb3;
+ clocks = clock CLK_USBD301;
+ clock-names = usbdrd30;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dwc3 {
+ compatible = snps,dwc3;
+ reg = 0x1240 0x1;
+ interrupts = 0 73 0;
+ phys = usbdrd_phy1 0, usbdrd_phy1 1;
+ phy-names = usb2-phy, usb3-phy;
+ };
+ };
+
usbdrd_phy1: phy@1250 {
compatible = samsung,exynos5420-usbdrd-phy;
reg = 0x1250 0x100;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 4/8] ARM: dts: exynos5250: Update DWC3 usb controller to use new phy driver
Removing the dt node for older usb3 phy driver from Exynos5250
device tree and updating the dt node for DWC3 controller to
use new phy driver based on generic phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 8303a42..8deadc3 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -556,21 +556,8 @@
compatible = synopsys,dwc3;
reg = 0x1200 0x1;
interrupts = 0 72 0;
- usb-phy = usb2_phy usb3_phy;
- };
- };
-
- usb3_phy: usbphy@1210 {
- compatible = samsung,exynos5250-usb3phy;
- reg = 0x1210 0x100;
- clocks = clock CLK_FIN_PLL, clock CLK_USB3;
- clock-names = ext_xtal, usbdrd30;
- #address-cells = 1;
- #size-cells = 1;
- ranges;
-
- usbphy-sys {
- reg = 0x10040704 0x8;
+ phys = usbdrd_phy 0, usbdrd_phy 1;
+ phy-names = usb2-phy, usb3-phy;
};
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/8] ARM: dts: exynos5420: Enable support for USB 3.0 PHY controller
Add device tree nodes for USB 3.0 PHY present alongwith
USB 3.0 controller Exynos 5420 SoC. This phy driver is
based on generic phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 6fe321b..8eebf7f 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -47,6 +47,8 @@
spi0 = spi_0;
spi1 = spi_1;
spi2 = spi_2;
+ usbdrdphy0 = usbdrd_phy0;
+ usbdrdphy1 = usbdrd_phy1;
};
cpus {
@@ -802,4 +804,22 @@
samsung,sysreg-phandle = sysreg_system_controller;
samsung,pmureg-phandle = pmu_system_controller;
};
+
+ usbdrd_phy0: phy@1210 {
+ compatible = samsung,exynos5420-usbdrd-phy;
+ reg = 0x1210 0x100;
+ clocks = clock CLK_USBD300, clock CLK_SCLK_USBPHY300;
+ clock-names = phy, ref;
+ samsung,pmu-syscon = pmu_system_controller;
+ #phy-cells = 1;
+ };
+
+ usbdrd_phy1: phy@1250 {
+ compatible = samsung,exynos5420-usbdrd-phy;
+ reg = 0x1250 0x100;
+ clocks = clock CLK_USBD301, clock CLK_SCLK_USBPHY301;
+ clock-names = phy, ref;
+ samsung,pmu-syscon = pmu_system_controller;
+ #phy-cells = 1;
+ };
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 0/8] Enable USB 3.0 support on Exynos5 systems
From: Vivek gautam gautam.vi...@samsung.com Based on 'for-next' branch of Kgene's linux-samsung tree; along with dts patches for USB 2.0 phy[1], and Exynos5800 [2]. Also based on the latest USB 3.0 DRD phy driver patches posted [3]. Changes from v5: - Added node reference names for new boards. - Removed 'samsung,pmu-offset' porperty from nodes, since with latest driver bindings this is not required. - Added aliase nodes in Exynos5420 to facilitate latest driver bindings. - Added patch to add VBUS regulator for peach-pi board also. - Dropped patches removing older usb-phy driver: usb-phy: samsung-usb3: Remove older phy-samsung-usb3 driver ARM: exynos_defconfig: Remove SAMSUNG_USB3PHY config as appeared in V5 version of this series. Will post them separately after the new driver is merged. [1] http://www.spinics.net/lists/linux-samsung-soc/msg30494.html [2] http://comments.gmane.org/gmane.linux.kernel.samsung-soc/31133 [3] https://lkml.org/lkml/2014/5/13/285 Vivek Gautam (7): ARM: dts: exynos5420: Enable support for USB 3.0 PHY controller ARM: dts: exynos5420: Enable support for DWC3 controller ARM: dts: exynos5250: Enable support for generic USB DRD phy ARM: dts: exynos5250: Update DWC3 usb controller to use new phy driver ARM: dts: exynos5250-snow: Add Vbus regulator for USB 3.0 ARM: dts: exynos5420-peach-pit: Add Vbus regulator for USB 3.0 ARM: dts: exynos5420-smdk5420: Add Vbus regulator for USB 3.0 Vivek gautam (1): ARM: dts: exynos5800-peach-pi: Add Vbus regulator for USB 3.0 arch/arm/boot/dts/exynos5250-snow.dts | 22 arch/arm/boot/dts/exynos5250.dtsi | 20 +-- arch/arm/boot/dts/exynos5420-peach-pit.dts | 46 arch/arm/boot/dts/exynos5420-smdk5420.dts | 46 arch/arm/boot/dts/exynos5420.dtsi | 54 arch/arm/boot/dts/exynos5800-peach-pi.dts | 46 6 files changed, 222 insertions(+), 12 deletions(-) -- 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 v4 7/8] ARM: Exynos: switch to using generic cpufreq-cpu0 driver
On Wed, May 14, 2014 at 6:41 PM, Heiko Stübner he...@sntech.de wrote: Am Mittwoch, 14. Mai 2014, 18:35:29 schrieb Viresh Kumar: On 14 May 2014 18:20, Arnd Bergmann a...@arndb.de wrote: Could we please come up with a way to probe this from DT in the cpufreq-cpu0 driver itself, so we don't have to add a device in every platform using it? Its followed that way because DT Maintainers had strong objections to creating virtual device nodes and haven't allowed creation of nodes for cpufreq drivers.. For which there is no physical device, as CPU already has a separate node.. as we already have the enable-method property for enabling/disabling cpus, would something like a scaling-method be feasible? scaling-method also sounds like a software specific property. Would that be something that will be acceptable in dt? -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/6] driver: cpuidle: cpuidle-big-little: init driver for Exynos5420
On Wed, May 14, 2014 at 02:04:51PM +0100, Arnd Bergmann wrote:
On Wednesday 14 May 2014 13:33:55 Chander Kashyap wrote:
diff --git a/drivers/cpuidle/cpuidle-big_little.c
b/drivers/cpuidle/cpuidle-big_little.c
index 4cd02bd..344d79fa 100644
--- a/drivers/cpuidle/cpuidle-big_little.c
+++ b/drivers/cpuidle/cpuidle-big_little.c
@@ -165,6 +165,7 @@ static int __init bl_idle_driver_init(struct
cpuidle_driver *drv, int cpu_id)
static const struct of_device_id compatible_machine_match[] = {
{ .compatible = arm,vexpress,v2p-ca15_a7 },
+ { .compatible = samsung,exynos5420 },
{},
};
Does the cpuidle-big_little driver actually care about the platform?
No, platform specific bits are hidden behind MCPM. Apart from idle states
data, that will soon be initialized through DT too.
Actually, when idle for arm64 is merged we can even rework it and end up
with a single driver, DT based, that's the ultimate goal.
If not, it would be good to add a generic string here as well, for
future platforms to match.
Yes, you have a point.
It still makes sense to list both the generic string and the platform
specific one though, in case we have to work around subtle differences.
Agreed, but subtle differences do not belong in this driver, that's the
purpose of abstracting it the best we can. I have no problem in leaving
platform specific compatible there though.
Lorenzo
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-pm 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 v4 7/8] ARM: Exynos: switch to using generic cpufreq-cpu0 driver
On Wed, May 14, 2014 at 6:20 PM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 14 May 2014 06:41:15 Thomas Abraham wrote:
From: Thomas Abraham thomas...@samsung.com
Remove the platform device instantiation for Exynos specific cpufreq
driver and add the platform device for cpufreq-cpu0 driver.
Signed-off-by: Thomas Abraham thomas...@samsung.com
---
arch/arm/mach-exynos/exynos.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index b32a907..489a495 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -232,7 +232,9 @@ void __init exynos_cpuidle_init(void)
void __init exynos_cpufreq_init(void)
{
- platform_device_register_simple(exynos-cpufreq, -1, NULL, 0);
+ if (!(of_machine_is_compatible(samsung,exynos5420))
+ !(of_machine_is_compatible(samsung,exynos5440)))
+ platform_device_register_simple(cpufreq-cpu0, -1, NULL, 0);
}
Could we please come up with a way to probe this from DT in the cpufreq-cpu0
driver itself, so we don't have to add a device in every platform using it?
Okay, I don't have a solution for this as of now. Would this be
considered as a blocker for this series? I hope we could just live
with this for now.
Thanks,
Thomas.
I realize you copied it from the other platforms using this driver, but
it still seems really wrong.
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 v4 7/8] ARM: Exynos: switch to using generic cpufreq-cpu0 driver
On 14/05/14 15:03, Thomas Abraham wrote: On Wed, May 14, 2014 at 6:41 PM, Heiko Stübner he...@sntech.de wrote: Am Mittwoch, 14. Mai 2014, 18:35:29 schrieb Viresh Kumar: On 14 May 2014 18:20, Arnd Bergmann a...@arndb.de wrote: Could we please come up with a way to probe this from DT in the cpufreq-cpu0 driver itself, so we don't have to add a device in every platform using it? Its followed that way because DT Maintainers had strong objections to creating virtual device nodes and haven't allowed creation of nodes for cpufreq drivers.. For which there is no physical device, as CPU already has a separate node.. as we already have the enable-method property for enabling/disabling cpus, would something like a scaling-method be feasible? scaling-method also sounds like a software specific property. Would that be something that will be acceptable in dt? How about dvfs-method ? But the value should not be based on the driver they use, but something more generic. Regards, Sudeep -- To unsubscribe from this list: send the line unsubscribe linux-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] [media] s5p-mfc: Add a control for IVF format for VP8 encoder
Hi Pawel, Hans,
I think we talked some time ago on IRC about this patch.
If I remember correctly, the conclusion was that it would be better to use
a specific pixel formats for this kind of out codec output.
Akin to:
V4L2_PIX_FMT_H264 'H264' H264 video elementary stream
with start codes.
V4L2_PIX_FMT_H264_NO_SC 'AVC1' H264 video elementary stream without
start codes.
Could you confirm this?
Best wishes,
--
Kamil Debski
Samsung RD Institute Poland
-Original Message-
From: Arun Kumar K [mailto:arunkk.sams...@gmail.com] On Behalf Of Arun
Kumar K
Sent: Thursday, March 06, 2014 7:04 AM
To: linux-me...@vger.kernel.org; linux-samsung-soc@vger.kernel.org
Cc: k.deb...@samsung.com; s.nawro...@samsung.com; posc...@chromium.org;
arunkk.sams...@gmail.com
Subject: [PATCH] [media] s5p-mfc: Add a control for IVF format for VP8
encoder
From: Pawel Osciak posc...@chromium.org
Add a control to enable/disable IVF output stream format for VP8 encode.
Set the IVF format output to disabled as default.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Documentation/DocBook/media/v4l/controls.xml|8
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |1 +
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 11 +++
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |2 ++
drivers/media/v4l2-core/v4l2-ctrls.c|1 +
include/uapi/linux/v4l2-controls.h |1 +
6 files changed, 24 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 0e1770c..07fb64a 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -3222,6 +3222,14 @@ V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_REF_PERIOD
as a golden frame./entry Acceptable values are 0, 1, 2 and 3
corresponding to encoder profiles 0, 1, 2 and 3./entry
/row
+ rowentry/entry/row
+ row
+ entry
spanname=idconstantV4L2_CID_MPEG_VIDEO_VPX_IVF_FORMAT/constantn
bsp;/entry
+ entryboolean/entry
+ /row
+ rowentry spanname=descrOutputs the VP8 encoded stream
in IVF file format./entry
+ /row
+
rowentry/entry/row
/tbody
/tgroup
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 5c28cc3..4d17df9 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -418,6 +418,7 @@ struct s5p_mfc_vp8_enc_params {
u8 rc_frame_qp;
u8 rc_p_frame_qp;
u8 profile;
+ bool ivf;
};
/**
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index df83cd1..a67913e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -676,6 +676,14 @@ static struct mfc_control controls[] = {
.step = 1,
.default_value = 0,
},
+ {
+ .id = V4L2_CID_MPEG_VIDEO_VPX_IVF_FORMAT,
+ .type = V4L2_CTRL_TYPE_BOOLEAN,
+ .minimum = 0,
+ .maximum = 1,
+ .step = 1,
+ .default_value = 0,
+ },
};
#define NUM_CTRLS ARRAY_SIZE(controls)
@@ -1636,6 +1644,9 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl
*ctrl)
case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
p-codec.vp8.profile = ctrl-val;
break;
+ case V4L2_CID_MPEG_VIDEO_VPX_IVF_FORMAT:
+ p-codec.vp8.ivf = ctrl-val;
+ break;
default:
v4l2_err(dev-v4l2_dev, Invalid control, id=%d, val=%d\n,
ctrl-id,
ctrl-val);
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index f64621a..90edb19 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -1243,6 +1243,8 @@ static int s5p_mfc_set_enc_params_vp8(struct
s5p_mfc_ctx *ctx)
/* VP8 specific params */
reg = 0;
+ /* Bit set to 1 disables IVF stream format. */
+ reg |= p_vp8-ivf ? 0 : (0x1 12);
reg |= (p_vp8-imd_4x4 0x1) 10;
switch (p_vp8-num_partitions) {
case V4L2_CID_MPEG_VIDEO_VPX_1_PARTITION:
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-
core/v4l2-ctrls.c
index e9e12c4..19e78df 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -752,6 +752,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP:return VPX
I-
Frame QP Value;
case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:return VPX
P-
Re: [PATCH v4 1/8] cpufreq: cpufreq-cpu0: allow use of optional boost mode frequencies
On Wed, May 14, 2014 at 7:20 PM, Viresh Kumar viresh.ku...@linaro.org wrote: On 14 May 2014 19:13, Thomas Abraham ta.oma...@gmail.com wrote: Okay, so you are suggesting that Kconfig entry used to select cpufreq-cpu0 should also enable CPU_FREQ_BOOST_SW config as well. I never said that... That should be enabled by your defconfig instead. What I said was, don't put code within any #ifdefs in cpufreq-cpu0. Okay, I get the point about #ifdef in cpufreq-cpu0. What about your earlier comment about the new Kconfig entry (Get rid of this.. just not required.)? The new Kconfig entry would be needed in that case. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/8] cpufreq: cpufreq-cpu0: allow use of optional boost mode frequencies
On 14 May 2014 19:48, Thomas Abraham ta.oma...@gmail.com wrote: Okay, I get the point about #ifdef in cpufreq-cpu0. What about your earlier comment about the new Kconfig entry (Get rid of this.. just not required.)? The new Kconfig entry would be needed in that case. The only place you used that ifdef was in cpufreq-cpu0, which we already decided should stay without any ifdefs.. Now, you must enable CPU_FREQ_BOOST_SW from your defconfig. Did I make it clear this time ? -- viresh -- To unsubscribe from this list: send the line unsubscribe linux-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 1/2] cpufreq / OPP: Allow boost frequency to be looked up from device tree
On 05/14/2014 01:24 AM, Viresh Kumar wrote: On 14 May 2014 11:39, Lukasz Majewski l.majew...@samsung.com wrote: I agree with Nishanth here, that point 1 (as described by Viresh at [*]) is a more scalable approach. The only reason why I wanted all that to be done at OPP level was to ensure if somebody else also needs it apart from cpufreq, they don't have to duplicate code and find it.. As it is present at a central place.. But if no other code is going to look for that, it may just be fine as is.. If we eventually have a need beyond cpufreq (say devfreq) with similar instances, then it makes sense to move it out to a generic place. Either way, code implementation/duplication is a OS problem - and should be looked at independent of the description in dts. If we feel the description is valid hardware description (which, personally, I do), then lets go to the next discussion point of where to put it - generic or cpufreq specific (here, I have no preference), and finally decide the implementation as necessary as a result of the description. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 7/8] ARM: Exynos: switch to using generic cpufreq-cpu0 driver
On Wednesday 14 May 2014 08:45:23 Rob Herring wrote: On Wed, May 14, 2014 at 8:18 AM, Arnd Bergmann a...@arndb.de wrote: On Wednesday 14 May 2014 18:44:46 Viresh Kumar wrote: On 14 May 2014 18:41, Heiko Stübner he...@sntech.de wrote: Am Mittwoch, 14. Mai 2014, 18:35:29 schrieb Viresh Kumar: On 14 May 2014 18:20, Arnd Bergmann a...@arndb.de wrote: Could we please come up with a way to probe this from DT in the cpufreq-cpu0 driver itself, so we don't have to add a device in every platform using it? Its followed that way because DT Maintainers had strong objections to creating virtual device nodes and haven't allowed creation of nodes for cpufreq drivers.. For which there is no physical device, as CPU already has a separate node.. as we already have the enable-method property for enabling/disabling cpus, would something like a scaling-method be feasible? Good idea to put it as a property into the CPU node. We already have properties which indicate this driver can be used by a platform: opp table and a clock for the cpu. If this information is not sufficient to determine whether you can use this driver or not, then you simply need to match against the platform. Perhaps the match list should be a blacklist rather than a whitelist, so new platforms work without a kernel change. We'd not only need a blacklist, but also a way to tell whether we want to use the cpu0 or the big/little implementation, which currently have indistinguishable bindings. Alternatively, create a new OPP binding that addresses this and all the other limitations in the current OPP binding. Yes. Lets see what DT maintainers have to say on this, I would rather go for a more straight forward name: scaling-driver .. Both sound fine to me. The fact that linux needs a way to create a platform device to enable a certain driver is not a DT problem. I proposed a solution for how to get this out of the platform code [1], but evidently we want people to open code the exceptions and adding boilerplate helpers will just encourage the exceptions. I think the only benefit we have from using platform devices at all for cpufreq (not for cpuidle, which has a similar problem) is module autoloading. I think your patch doesn't actually help with that. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC V3 2/3] drm/bridge: add a dummy panel driver to support lvds bridges
On Tue, May 13, 2014 at 10:19:33PM +0530, Ajay kumar wrote: On Tue, May 13, 2014 at 1:35 PM, Thierry Reding thierry.red...@gmail.com wrote: On Fri, May 09, 2014 at 08:23:01PM +0530, Ajay Kumar wrote: implement basic panel controls as a drm_bridge so that the existing bridges can make use of it. The driver assumes that it is the last entity in the bridge chain. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com --- .../bindings/drm/bridge/bridge_panel.txt | 45 Can we please stop adding files to this directory? Device tree bindings are supposed to be OS agnostic, but DRM is specific to Linux and should not be used when describing hardware. One should not be adding a devicetree node if it is not describing the actual hardware? Correct. But my point is that even if you describe actual hardware, then the bindings don't belong in a drm subdirectory, because DRM does not make any sense in a hardware context. Something like video/bridge may be a better name for a directory. diff --git a/Documentation/devicetree/bindings/drm/bridge/bridge_panel.txt b/Documentation/devicetree/bindings/drm/bridge/bridge_panel.txt [...] + -led-en-gpio: + eDP panel LED enable GPIO. + Indicates which GPIO needs to be powered up as output + to enable the backlight. Since this is used to control a backlight, then this should really be a separate node to describe the backlight device (and use the corresponding backlight driver) rather than duplicating a subset of that functionality. I am stressing this point again! Backlight should ideally be enabled only after: 1) Panel is powered up (LCD_VDD) 2) HPD is thrown. 3) Valid data starts coming from the encoder(DP in our case) All the above 3 are controlled inside drm, but pwm-backlight is independent of drm. So, we let the pwm_config happen in pwm-backlight driver and enable backlight GPIO(BL_EN) inside drm, after valid video data starts coming out of the encoder. But that's completely the wrong way around. Why can't you simply control the backlight from within DRM and only enable it at the right time? As you said, we can get this GPIO from a backlight device node, but since this GPIO is related to panel also, I think conceptually its not wrong to have this GPIO binding defined in a panel node. It's not related to the panel. It's an enable for the backlight. Backlight could be considered part of the panel, therefore it makes sense to control the backlight from the panel driver. + -panel-pre-enable-delay: + delay value in ms required for panel_pre_enable process + Delay in ms needed for the eDP panel LCD unit to + powerup, and delay needed between panel_VCC and + video_enable. What are panel_VCC or video_enable? It is the time taken for the panel to throw a valid HPD from the point we enabled LCD_VCC. After HPD is thrown, we can start sending video data. What does throw a valid HPD mean? Is it an actual signal that can be captured via software (GPIO, interrupt, ...)? If so then it would be preferable to not use a delay at all but rather rely on that mechanism to determine when it's safe to send a video signal. + -panel-enable-delay: + delay value in ms required for panel_enable process + Delay in ms needed for the eDP panel backlight/LED unit + to powerup, and delay needed between video_enable and + BL_EN. Similarily, what does BL_EN stand for? Backlight Enable, same as enable-gpios in pwm-backlight driver. When writing a binding it's useful to describe these things without referring to signal names or abbreviations, since they may be something else for different people. diff --git a/drivers/gpu/drm/bridge/bridge_panel.c b/drivers/gpu/drm/bridge/bridge_panel.c [...] This duplicates much of the functionality that panels should provide. I think a better solution would be to properly integrate panels with bridges. True, ideally I should be calling drm_panel functions from a simple dummy bridge which sits at the end of the bridge chain. But, since you are not convinced with having pre_enable and post_disable calls for panels, I had no other way to do this, than stuffing these panel controls inside bridge! :( What makes you think that I would suddenly be any more convinced by this solution than by your prior proposal? I didn't say outright no to what you proposed earlier. What I said was that I didn't like it and that I thought we could come up with a better solution. Part of getting to a better solution is trying to understand the problems involved. You don't solve a problem by simply moving code into a different driver. Thierry pgpm5rLwCDxk5.pgp Description: PGP signature
Re: [PATCH v3 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
On 14/05/14 02:03, Thomas Abraham wrote: From: Thomas Abraham thomas...@samsung.com Add a new optional boost-frequency binding for specifying the frequencies usable in boost mode. Cc: Nishanth Menon n...@ti.com Cc: Lukasz Majewski l.majew...@samsung.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Signed-off-by: Thomas Abraham thomas...@samsung.com --- .../devicetree/bindings/cpufreq/cpufreq-boost.txt | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt new file mode 100644 index 000..d925e38 --- /dev/null +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt @@ -0,0 +1,11 @@ +* Device tree binding for CPU boost frequency (aka over-clocking) + +Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as +overclocking) in which the CPU can operate in frequencies beyond the normal +operating conditions. + +Optional Properties: +- boost-frequency: list of frequencies in KHz to be used only in boost mode. + This list should be a subset of frequencies listed in operating-points + property. Refer to Documentation/devicetree/bindings/power/opp.txt for + details about operating-points property. Though I understand the need of it, I think the binding is designed to suffice the need of the boost frequency support in cpufreq. Typically SoC would provide characteristics like under-drive(hits performance but most energy efficient), nominal(highest sustained performance w/o any external constraint like power, thermal) and over-drive(maximum performance but not sustainable for long periods) IMO the binding could represent these unique points on the curve instead. Regards, Sudeep -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
