RE: [PATCH] [media] s5p-mfc: Add Horizontal and Vertical search range for Video Macro Blocks
Hi Amit,
From: Amit Grover [mailto:amit.gro...@samsung.com]
Sent: Monday, December 30, 2013 11:43 AM
This patch adds Controls to set Horizontal and Vertical search range
for Motion Estimation block for Samsung MFC video Encoders.
Signed-off-by: Swami Nathan swaminat...@samsung.com
Signed-off-by: Amit Grover amit.gro...@samsung.com
---
Documentation/DocBook/media/v4l/controls.xml| 14 +
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 ++
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 24
+++
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |8 ++--
drivers/media/v4l2-core/v4l2-ctrls.c| 14 +
include/uapi/linux/v4l2-controls.h |2 ++
6 files changed, 58 insertions(+), 6 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 7a3b49b..70a0f6f 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -2258,6 +2258,20 @@ Applicable to the MPEG1, MPEG2, MPEG4
encoders./entry
VBV buffer control./entry
/row
+ rowentry/entry/row
+ row id=v4l2-mpeg-video-horz-search-range
+ entry
spanname=idconstantV4L2_CID_MPEG_VIDEO_HORZ_SEARCH_RANGE/constant
HORZ is nowhere used. HOR is more commonly used in control names.
V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE seems better.
nbsp;/entry
+ entryinteger/entry
+ /rowrowentry spanname=descrSets the Horizontal
search range for Video Macro blocks./entry
+ /row
It's expressed in pixels? If so then it should be mentioned here. Also I
think this lacks the mention that it is used for motion estimation.
Please add a more detailed description.
+
+ rowentry/entry/row
+ row id=v4l2-mpeg-video-vert-search-range
+ entry
spanname=idconstantV4L2_CID_MPEG_VIDEO_VERT_SEARCH_RANGE/constant
nbsp;/entry
V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE seems better.
+ entryinteger/entry
+ /rowrowentry spanname=descrSets the Vertical search
range for Video Macro blocks./entry
+ /row
+
This description is too vague as well.
rowentry/entry/row
row
entry
spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_CPB_SIZE/constantnb
sp;/entry
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 6920b54..f2c13c3 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -430,6 +430,8 @@ struct s5p_mfc_vp8_enc_params {
struct s5p_mfc_enc_params {
u16 width;
u16 height;
+ u32 horz_range;
+ u32 vert_range;
mv_h_range ?
mv_v_range ?
u16 gop_size;
enum v4l2_mpeg_video_multi_slice_mode slice_mode;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 4ff3b6c..a02e7b8 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -208,6 +208,24 @@ static struct mfc_control controls[] = {
.default_value = 0,
},
{
+ .id = V4L2_CID_MPEG_VIDEO_HORZ_SEARCH_RANGE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = horizontal search range of video macro block,
This too should be property capitalised. Please mention the motion vectors
too.
+ .minimum = 16,
+ .maximum = 128,
+ .step = 16,
+ .default_value = 32,
+ },
+ {
+ .id = V4L2_CID_MPEG_VIDEO_VERT_SEARCH_RANGE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = vertical search range of video macro block,
This too should be property capitalised. Please mention the motion vectors
too.
+ .minimum = 16,
+ .maximum = 128,
+ .step = 16,
+ .default_value = 32,
+ },
+ {
.id = V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE,
.type = V4L2_CTRL_TYPE_INTEGER,
.minimum = 0,
@@ -1377,6 +1395,12 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl
*ctrl)
case V4L2_CID_MPEG_VIDEO_VBV_SIZE:
p-vbv_size = ctrl-val;
break;
+ case V4L2_CID_MPEG_VIDEO_HORZ_SEARCH_RANGE:
+ p-horz_range = ctrl-val;
+ break;
+ case V4L2_CID_MPEG_VIDEO_VERT_SEARCH_RANGE:
+ p-vert_range = ctrl-val;
+ break;
case V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE:
p-codec.h264.cpb_size = ctrl-val;
break;
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 461358c..47e1807 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++
Re: [PATCH 8/8 v4] crypto:s5p-sss: Use clk_prepare/clk_unprepare
Hello All, On 15 January 2014 14:47, Naveen Krishna Chatradhi ch.nav...@samsung.com wrote: This patch set adds use of clk_prepare/clk_unprepare as required by generic clock framework. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com --- Changes since v3: None drivers/crypto/s5p-sss.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c index f7c66c7..870e794 100644 --- a/drivers/crypto/s5p-sss.c +++ b/drivers/crypto/s5p-sss.c @@ -648,7 +648,7 @@ static int s5p_aes_probe(struct platform_device *pdev) return -ENOENT; } - clk_enable(pdata-clk); + clk_prepare_enable(pdata-clk); spin_lock_init(pdata-lock); pdata-ioaddr = devm_ioremap(dev, res-start, @@ -711,7 +711,7 @@ static int s5p_aes_probe(struct platform_device *pdev) tasklet_kill(pdata-tasklet); err_irq: - clk_disable(pdata-clk); + clk_disable_unprepare(pdata-clk); s5p_dev = NULL; @@ -731,7 +731,7 @@ static int s5p_aes_remove(struct platform_device *pdev) tasklet_kill(pdata-tasklet); - clk_disable(pdata-clk); + clk_disable_unprepare(pdata-clk); s5p_dev = NULL; -- 1.7.9.5 Any update on this patch, Please -- Shine bright, (: Nav :) -- To unsubscribe from this list: send the line unsubscribe linux-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 6/8 v4] ARM: dts: exynos5250/5420: add dt node for sss module
Hello All,
On 15 January 2014 14:46, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
This patch adds the device tree node for SSS module
found on Exynos5420 and Exynos5250
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
TO: linux-samsung-soc@vger.kernel.org
CC: Kukjin Kim kgene@samsung.com
CC: linux-cry...@vger.kernel.org
---
Changes since v3:
1. Modified the SSS clock ID as per dt-bindings for Exynos5250 in
samsung-clk.git tree.
arch/arm/boot/dts/exynos5250.dtsi |8
arch/arm/boot/dts/exynos5420.dtsi | 10 ++
2 files changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index c341e55..1d249df 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -704,4 +704,12 @@
io-channel-ranges;
status = disabled;
};
+
+ sss@1083 {
+ compatible = samsung,exynos4210-secss;
+ reg = 0x1083 0x1;
+ interrupts = 0 112 0;
+ clocks = clock 348;
+ clock-names = secss;
+ };
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 11dd202..56a3f3e 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -652,4 +652,14 @@
clocks = clock 319, clock 318;
clock-names = tmu_apbif, tmu_triminfo_apbif;
};
+
+ sss@1083 {
+ compatible = samsung,exynos4210-secss;
+ reg = 0x1083 0x1;
+ interrupts = 0 112 0;
+ clocks = clock 471;
+ clock-names = secss;
+ samsung,power-domain = g2d_pd;
+ };
+
};
--
1.7.9.5
Any update on this patch, Please
--
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8 v4] crypto:s5p-sss: validate iv before memcpy
Hello All,
On 15 January 2014 14:47, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
This patch adds code to validate iv buffer before trying to
memcpy the contents
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
Changes since v3:
None
drivers/crypto/s5p-sss.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 69130b2..f7c66c7 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -380,7 +380,8 @@ static void s5p_set_aes(struct s5p_aes_dev *dev,
{
void __iomem *keystart;
- memcpy(dev-aes_ioaddr + SSS_REG_AES_IV_DATA (0), iv, 0x10);
+ if (iv)
+ memcpy(dev-aes_ioaddr + SSS_REG_AES_IV_DATA (0), iv, 0x10);
if (keylen == AES_KEYSIZE_256)
keystart = dev-aes_ioaddr + SSS_REG_AES_KEY_DATA(0);
--
1.7.9.5
Any update on this patch, Please
--
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8 v4] crypto:s5p-sss: Use platform_get_irq() instead of _byname()
Hello All,
On 15 January 2014 14:44, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
From: Naveen Krishna Ch ch.nav...@samsung.com
This patch uses the platform_get_irq() instead of the
platform_get_irq_byname(). Making feeder control interrupt
as resource 0 and hash interrupt as 1.
reasons for this change.
1. Cannot find any Arch which is currently using this driver
2. Samsung Exynos4 and 5 SoCs only use the feeder control interrupt
3. Patches adding support for DT and H/W version are in pipeline
Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
CC: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-cry...@vger.kernel.org
CC: linux-samsung-soc@vger.kernel.org
---
Changes since v3:
None
drivers/crypto/s5p-sss.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index cf149b1..93cddeb 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -592,29 +592,29 @@ static int s5p_aes_probe(struct platform_device *pdev)
pdata-ioaddr = devm_ioremap(dev, res-start,
resource_size(res));
- pdata-irq_hash = platform_get_irq_byname(pdev, hash);
- if (pdata-irq_hash 0) {
- err = pdata-irq_hash;
- dev_warn(dev, hash interrupt is not available.\n);
+ pdata-irq_fc = platform_get_irq(pdev, 0);
+ if (pdata-irq_fc 0) {
+ err = pdata-irq_fc;
+ dev_warn(dev, feed control interrupt is not available.\n);
goto err_irq;
}
- err = devm_request_irq(dev, pdata-irq_hash, s5p_aes_interrupt,
+ err = devm_request_irq(dev, pdata-irq_fc, s5p_aes_interrupt,
IRQF_SHARED, pdev-name, pdev);
if (err 0) {
- dev_warn(dev, hash interrupt is not available.\n);
+ dev_warn(dev, feed control interrupt is not available.\n);
goto err_irq;
}
- pdata-irq_fc = platform_get_irq_byname(pdev, feed control);
- if (pdata-irq_fc 0) {
- err = pdata-irq_fc;
- dev_warn(dev, feed control interrupt is not available.\n);
+ pdata-irq_hash = platform_get_irq(pdev, 1);
+ if (pdata-irq_hash 0) {
+ err = pdata-irq_hash;
+ dev_warn(dev, hash interrupt is not available.\n);
goto err_irq;
}
- err = devm_request_irq(dev, pdata-irq_fc, s5p_aes_interrupt,
+ err = devm_request_irq(dev, pdata-irq_hash, s5p_aes_interrupt,
IRQF_SHARED, pdev-name, pdev);
if (err 0) {
- dev_warn(dev, feed control interrupt is not available.\n);
+ dev_warn(dev, hash interrupt is not available.\n);
goto err_irq;
}
--
1.7.9.5
Any update on this patch, Please
--
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8 v4] clk: samsung: exynos5250/5420: Add gate clock for SSS module
Hello All,
On 15 January 2014 14:46, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
This patch adds gating clock for SSS(Security SubSystem)
module on Exynos5250/5420.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
TO: linux-samsung-soc@vger.kernel.org
TO: Tomasz Figa t.f...@samsung.com
CC: Kukjin Kim kgene@samsung.com
CC: linux-cry...@vger.kernel.org
---
Changes since v3:
1. Rebased on to
https://git.kernel.org/pub/scm/linux/kernel/git/tfiga/samsung-clk.git
2. Added new ID for SSS clock on Exynos5250, with Documentation and
3. Added gate clocks definitions for SSS on Exynos5420 and Exynos5250
.../devicetree/bindings/clock/exynos5250-clock.txt |1 +
drivers/clk/samsung/clk-exynos5250.c |1 +
drivers/clk/samsung/clk-exynos5420.c |4
include/dt-bindings/clock/exynos5250.h |1 +
4 files changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 492ed09..a845fc6 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -162,6 +162,7 @@ clock which they consume.
g2d 345
mdma0346
smmu_mdma0 347
+ sss 348
[Clock Muxes]
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c
index ff4beeb..2c52fe1 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -387,6 +387,7 @@ static struct samsung_gate_clock exynos5250_gate_clks[]
__initdata = {
* CMU_ACP
*/
GATE(CLK_MDMA0, mdma0, div_aclk266, GATE_IP_ACP, 1, 0, 0),
+ GATE(CLK_SSS, sss, div_aclk266, GATE_IP_ACP, 2, 0, 0),
GATE(CLK_G2D, g2d, div_aclk200, GATE_IP_ACP, 3, 0, 0),
GATE(CLK_SMMU_MDMA0, smmu_mdma0, div_aclk266, GATE_IP_ACP, 5, 0,
0),
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index ab4f2f7..94915bb 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -26,6 +26,7 @@
#define DIV_CPU1 0x504
#define GATE_BUS_CPU 0x700
#define GATE_SCLK_CPU 0x800
+#define GATE_BUS_G2D 0x8700
#define CPLL_LOCK 0x10020
#define DPLL_LOCK 0x10030
#define EPLL_LOCK 0x10040
@@ -702,6 +703,9 @@ static struct samsung_gate_clock exynos5420_gate_clks[]
__initdata = {
0),
GATE(CLK_SMMU_MIXER, smmu_mixer, aclk200_disp1, GATE_IP_DISP1, 9,
0,
0),
+
+ /* SSS */
+ GATE(CLK_SSS, sss, aclk266_g2d, GATE_BUS_G2D, 2, 0, 0),
};
static struct samsung_pll_clock exynos5420_plls[nr_plls] __initdata = {
diff --git a/include/dt-bindings/clock/exynos5250.h
b/include/dt-bindings/clock/exynos5250.h
index 922f2dc..f9b452b 100644
--- a/include/dt-bindings/clock/exynos5250.h
+++ b/include/dt-bindings/clock/exynos5250.h
@@ -150,6 +150,7 @@
#define CLK_G2D345
#define CLK_MDMA0 346
#define CLK_SMMU_MDMA0 347
+#define CLK_SSS348
/* mux clocks */
#define CLK_MOUT_HDMI 1024
--
1.7.9.5
Any update on this patch, Please
--
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8 v4] crypto:s5p-sss: Add device tree support
Hello All,
On 15 January 2014 14:44, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
This patch adds device tree support to the s5p-sss.c crypto driver.
Also, Documentation under devicetree/bindings added.
Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com
CC: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-cry...@vger.kernel.org
CC: linux-samsung-soc@vger.kernel.org
---
Changes since v3:
None
.../devicetree/bindings/crypto/samsung-sss.txt | 20
drivers/crypto/s5p-sss.c | 10 +-
2 files changed, 29 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt
diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
new file mode 100644
index 000..2f9d7e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
@@ -0,0 +1,20 @@
+Samsung SoC SSS (Security SubSystem) module
+
+The SSS module in S5PV210 SoC supports the following:
+-- Feeder (FeedCtrl)
+-- Advanced Encryption Standard (AES)
+-- Data Encryption Standard (DES)/3DES
+-- Public Key Accelerator (PKA)
+-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
+-- PRNG: Pseudo Random Number Generator
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+ SSS versions:
+ - samsung,s5pv210-secss for S5PV210 SoC.
+- reg : Offset and length of the register set for the module
+- interrupts : the interrupt-specifier for the SSS module.
+ Two interrupts feed control and hash in case of S5PV210
+- clocks : the required gating clock for the SSS module.
+- clock-names : the gating clock name to be requested in the SSS driver.
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 93cddeb..2da5617 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -22,6 +22,7 @@
#include linux/scatterlist.h
#include linux/dma-mapping.h
#include linux/io.h
+#include linux/of.h
#include linux/crypto.h
#include linux/interrupt.h
@@ -177,6 +178,12 @@ struct s5p_aes_dev {
static struct s5p_aes_dev *s5p_dev;
+static const struct of_device_id s5p_sss_dt_match[] = {
+ { .compatible = samsung,s5pv210-secss, },
+ { },
+};
+MODULE_DEVICE_TABLE(of, s5p_sss_dt_match);
+
static void s5p_set_dma_indata(struct s5p_aes_dev *dev, struct scatterlist
*sg)
{
SSS_WRITE(dev, FCBRDMAS, sg_dma_address(sg));
@@ -676,7 +683,8 @@ static struct platform_driver s5p_aes_crypto = {
.remove = s5p_aes_remove,
.driver = {
.owner = THIS_MODULE,
- .name = s5p-secss,
+ .name = s5pv210-secss,
+ .of_match_table = s5p_sss_dt_match,
},
};
--
1.7.9.5
Any update on this patch, Please
--
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line unsubscribe linux-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 Horizontal and Vertical search range for Video Macro Blocks
Hi,
On 23/01/14 11:11, Kamil Debski wrote:
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 4ff3b6c..a02e7b8 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -208,6 +208,24 @@ static struct mfc_control controls[] = {
.default_value = 0,
},
{
+ .id = V4L2_CID_MPEG_VIDEO_HORZ_SEARCH_RANGE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = horizontal search range of video macro block,
This too should be property capitalised. Please mention the motion vectors
too.
And additionally length of the name string should not exceed 31 characters.
--
Thanks,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8 v4] crypto:s5p-sss: Add device tree support
Hi,
(Adding missing devicetre ML list at CC.)
On 15/01/14 10:14, Naveen Krishna Chatradhi wrote:
This patch adds device tree support to the s5p-sss.c crypto driver.
Also, Documentation under devicetree/bindings added.
Signed-off-by: Naveen Krishna Ch ch.nav...@samsung.com
CC: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Vladimir Zapolskiy vzapols...@gmail.com
TO: linux-cry...@vger.kernel.org
CC: linux-samsung-soc@vger.kernel.org
---
Changes since v3:
None
.../devicetree/bindings/crypto/samsung-sss.txt | 20
drivers/crypto/s5p-sss.c | 10 +-
2 files changed, 29 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt
diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
new file mode 100644
index 000..2f9d7e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
@@ -0,0 +1,20 @@
+Samsung SoC SSS (Security SubSystem) module
+
+The SSS module in S5PV210 SoC supports the following:
+-- Feeder (FeedCtrl)
+-- Advanced Encryption Standard (AES)
+-- Data Encryption Standard (DES)/3DES
+-- Public Key Accelerator (PKA)
+-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
+-- PRNG: Pseudo Random Number Generator
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+ SSS versions:
+ - samsung,s5pv210-secss for S5PV210 SoC.
+- reg : Offset and length of the register set for the module
+- interrupts : the interrupt-specifier for the SSS module.
+ Two interrupts feed control and hash in case of S5PV210
It should be described in what order both interrupts are supposed to be
specified.
+- clocks : the required gating clock for the SSS module.
+- clock-names : the gating clock name to be requested in the SSS driver.
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 93cddeb..2da5617 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -22,6 +22,7 @@
#include linux/scatterlist.h
#include linux/dma-mapping.h
#include linux/io.h
+#include linux/of.h
#include linux/crypto.h
#include linux/interrupt.h
@@ -177,6 +178,12 @@ struct s5p_aes_dev {
static struct s5p_aes_dev *s5p_dev;
+static const struct of_device_id s5p_sss_dt_match[] = {
+ { .compatible = samsung,s5pv210-secss, },
nit: the first semicolon could be omitted.
+ { },
+};
+MODULE_DEVICE_TABLE(of, s5p_sss_dt_match);
+
static void s5p_set_dma_indata(struct s5p_aes_dev *dev, struct scatterlist
*sg)
{
SSS_WRITE(dev, FCBRDMAS, sg_dma_address(sg));
@@ -676,7 +683,8 @@ static struct platform_driver s5p_aes_crypto = {
.remove = s5p_aes_remove,
.driver = {
.owner = THIS_MODULE,
- .name = s5p-secss,
+ .name = s5pv210-secss,
Why you're changing the driver name ? It's not related and not needed AFAICT.
+ .of_match_table = s5p_sss_dt_match,
},
};
--
Thanks,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8 v4] crypto:s5p-sss: Add device tree support
On Thu, Jan 23, 2014 at 05:47:25PM +, Sylwester Nawrocki wrote:
On 23/01/14 18:41, Mark Rutland wrote:
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 93cddeb..2da5617 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -22,6 +22,7 @@
#include linux/scatterlist.h
#include linux/dma-mapping.h
#include linux/io.h
+#include linux/of.h
#include linux/crypto.h
#include linux/interrupt.h
@@ -177,6 +178,12 @@ struct s5p_aes_dev {
static struct s5p_aes_dev *s5p_dev;
+static const struct of_device_id s5p_sss_dt_match[] = {
+ { .compatible = samsung,s5pv210-secss, },
nit: the first semicolon could be omitted.
I assume you mean comma ratehr than semicolon?
Indeed...and it's actually the second one :-/
Also, I meant rather rather than ratehr. At least we figured it out
in the end. :)
Thanks,
Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] serial: samsung: Move uart_register_driver call to device probe
I had earlier submitted a patch [1] to remove the hard coded major/minor number for Samsung UART driver, but that was rejected because of userspace breakage. Without this patch, Samsung UART driver can't bind to the hard-coded device node. Changing the default major/minor will also not help to fix the objections raised in [1]. Would you please suggest a way forward? [1] https://lkml.org/lkml/2013/12/27/2 So to go and try and put this to bed properly I would suggest the following way forward. We add CONFIG_LEGACY_STATIC_TTY Some platforms historically used static device nodes for the console devices. Select this if you are building a kernel for an old system which has a static /dev. Note that because some devices historically used incorrect clashing numbering this may prevent you building a single kernel which can be booted on multiple platforms. And then we do .nr = CONFIG_SERIAL_SAMSUNG_UARTS, .cons = S3C24XX_SERIAL_CONSOLE, .dev_name = S3C24XX_SERIAL_NAME, #ifdef CONFIG_LEGACY_STATIC_TTY .major = S3C24XX_SERIAL_MAJOR, .minor = S3C24XX_SERIAL_MINOR, #endif for the afflicted ports (and anyone else who wants to migrate) We can then enable that config option for ARM (and in time for any other architecture that turns out to need/want it). Eventually it can go away (not that its exactly doing any harm if it doesnt). Does that sound a valid way forward for everyone ? Alan -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] dt-bindings: document the s3c24xx software-reset register
Hi Heiko, On 06.01.2014 19:37, Heiko Stübner wrote: The S3C2412/S3C2413 as well as the S3C2443 and following contain a special register that restarts the system when written to. This adds a simple binding, so that it gets accessible on dt systems too. We distinguish between the two types (s3c2412, s3c2443) because the handling of the swrst register on the s3c2412 also needs to take care of a hardware glitch at reset time. Signed-off-by: Heiko Stuebner he...@sntech.de --- .../devicetree/bindings/arm/samsung/s3c24xx-swrst.txt | 16 1 file changed, 16 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/samsung/s3c24xx-swrst.txt Is there really a need to have separate bindings for this? As far as I can see, the swreset register is a part of the clock controller, so restart function could be provided by clock driver and there would be no need to change anything in DT. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] ARM: S3C24XX: convert boards to use common restart function
Hi Heiko,
On 06.01.2014 19:40, Heiko Stübner wrote:
This converts all boards to use the new common restart function instead
of SoC specific ones.
The mach-s3c2416-dt board now tries to setup either a swrst- or watchdog-
reset so that it will be able to handle more s3c24xx-SoCs later on.
[snip]
diff --git a/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
b/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
index 0a86953..88716fa4 100644
--- a/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
+++ b/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
@@ -24,6 +24,7 @@
#include plat/cpu.h
#include plat/pm.h
+#include plat/watchdog-reset.h
#include common.h
@@ -34,6 +35,14 @@ static void __init s3c2416_dt_map_io(void)
static void __init s3c2416_dt_machine_init(void)
{
+ s3c24xx_swrst_reset_of_init();
+
+#ifdef CONFIG_SAMSUNG_WDT_RESET
+ /* if no special swrst-device exists try to find a watchdog */
+ if (!s3c24xx_swrst_reset_available())
+ samsung_wdt_reset_of_init();
+#endif
Hmm... I think it would be safe to assume availability of soft reset,
especially if you could move the restart code to the clock driver.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Add l2x0 device node for Exynos4-based boards
Hi, On 07.01.2014 09:53, Tushar Behera wrote: For Exynos4 platform, L2 cache initialization is done only if a device node for l2x0 device exists. L2 cache initialization path is different when a board boots with secure firmware. Since there are many Exynos4 based SoCs that boot in secure mode, enabling this only for boards that don't boot with secure firmware. Signed-off-by: Tushar Behera tushar.beh...@linaro.org --- Tested on Exynos4210-Origen board. arch/arm/boot/dts/exynos4.dtsi |8 arch/arm/boot/dts/exynos4210-origen.dts |4 arch/arm/boot/dts/exynos4210-smdkv310.dts |4 arch/arm/boot/dts/exynos4210-trats.dts |4 arch/arm/boot/dts/exynos4210-universal_c210.dts |4 arch/arm/boot/dts/exynos4412-odroidx.dts|4 arch/arm/boot/dts/exynos4412-smdk4412.dts |4 arch/arm/boot/dts/exynos4412-tiny4412.dts |4 8 files changed, 36 insertions(+) Looks good. Unfortunately this is still going to break secure firmware enabled boards, because l2x0_of_init() does not check if the node is enabled. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 01/10] clk/exynos5410: move suspend/resume handling to SoC driver
On 07.01.2014 13:58, Rahul Sharma wrote: Suspend/resume handling is already moved for all other Exynos SoCs other than Exynos5420 which is addressed in this patch. Signed-off-by: Rahul Sharma rahul.sha...@samsung.com --- drivers/clk/samsung/clk-exynos5410.c | 49 ++ 1 file changed, 44 insertions(+), 5 deletions(-) Acked-by: Tomasz Figa t.f...@samsung.com Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 04/10] clk/samsung: add support for multiple clock providers
Hi Rahul,
The patch looks mostly fine now, but I still have one inline comment.
On 07.01.2014 13:59, Rahul Sharma wrote:
Samsung CCF helper functions do not provide support to
register multiple Clock Providers for a given SoC. Due to
this limitation SoC platforms are not able to use these
helpers for registering multiple clock providers and are
forced to bypass this layer.
This layer is modified accordingly to enable the support.
Clock file for exynos4, exynos5250, exynos5420, exynos5440
[snip]
/* setup the essentials required to support clock lookup using ccf */
-void __init samsung_clk_init(struct device_node *np, void __iomem *base,
-unsigned long nr_clks)
+struct samsung_clk_provider *__init samsung_clk_init(struct device_node *np,
+ void __iomem *base, unsigned long nr_clks)
{
- reg_base = base;
+ struct samsung_clk_provider *ctx;
+ struct clk **clk_table;
+ int ret;
+
+ ctx = kzalloc(sizeof(struct samsung_clk_provider), GFP_KERNEL);
+ if (!ctx)
+ panic(could not allocate clock provider context.\n);
clk_table = kzalloc(sizeof(struct clk *) * nr_clks, GFP_KERNEL);
if (!clk_table)
panic(could not allocate clock lookup table\n);
+ ctx-reg_base = base;
+ ctx-clk_data.clks = clk_table;
+ ctx-clk_data.clk_num = nr_clks;
+ ctx-lock = __SPIN_LOCK_UNLOCKED(lock);
spin_lock_init(ctx-lock);
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] serial: samsung: Move uart_register_driver call to device probe
On Thu, Jan 23, 2014 at 07:47:56PM +0100, Tomasz Figa wrote: On 23.01.2014 19:40, Mark Brown wrote: We'd need to leave it user selectable rather than enabling it for ARM, the whole reason this got noticed is that people are trying to build kernels that support a wider range of devices for ARM. What about making it depend on !MULTIPLATFORM and enabled by default? That'd work, but if we're doing that then substituting in the dynamic assignment only when we hit a collision seems smoother and more general. Or we could just make the core ignore all hard coded numbers if this is set rather than putting ifdefs in the drivers. signature.asc Description: Digital signature
Re: [PATCH 1/2] serial: samsung: Move uart_register_driver call to device probe
On Thu, 23 Jan 2014 19:36:33 + Mark Brown broo...@kernel.org wrote: On Thu, Jan 23, 2014 at 07:47:56PM +0100, Tomasz Figa wrote: On 23.01.2014 19:40, Mark Brown wrote: We'd need to leave it user selectable rather than enabling it for ARM, the whole reason this got noticed is that people are trying to build kernels that support a wider range of devices for ARM. What about making it depend on !MULTIPLATFORM and enabled by default? That'd work, but if we're doing that then substituting in the dynamic assignment only when we hit a collision seems smoother and more general. Or we could just make the core ignore all hard coded numbers if this is set rather than putting ifdefs in the drivers. That strikes me as rather more risky. We can propogate it through the drivers as we are sure it is safe to do so on that platform and encourage driver authors to migrate. Better than a big bang and the inevitable fallout. We do want it user selectable, because we want people to leave it off unless they have a need for it - that then becomes a path towards eventually getting rid of them static identifiers for good. Alan -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] serial: samsung: Move uart_register_driver call to device probe
On Thu, Jan 23, 2014 at 07:51:44PM +, Alan Cox wrote: That strikes me as rather more risky. We can propogate it through the drivers as we are sure it is safe to do so on that platform and encourage driver authors to migrate. Better than a big bang and the inevitable fallout. I don't see how we can meaningfully test this on a platform - the kernel would have to be pretty demented to care, it's userspace that cares and that's not really tied to individual serial drivers but is where we mainly need coverage. We do want it user selectable, because we want people to leave it off unless they have a need for it - that then becomes a path towards eventually getting rid of them static identifiers for good. Yup. signature.asc Description: Digital signature
Re: [PATCH 1/2] serial: samsung: Move uart_register_driver call to device probe
On Thu, 23 Jan 2014 20:05:09 + Mark Brown broo...@kernel.org wrote: On Thu, Jan 23, 2014 at 07:51:44PM +, Alan Cox wrote: That strikes me as rather more risky. We can propogate it through the drivers as we are sure it is safe to do so on that platform and encourage driver authors to migrate. Better than a big bang and the inevitable fallout. I don't see how we can meaningfully test this on a platform - the kernel would have to be pretty demented to care, it's userspace that cares and that's not really tied to individual serial drivers but is where we mainly need coverage. Which is why I think we want to enable it gradually and platform by platform as that platform or arch maintainer judges it appropriate given their knowledge of their platform(s). Alan -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] ARM: S3C24XX: convert boards to use common restart function
On 23.01.2014 20:02, Heiko Stübner wrote:
Am Donnerstag, 23. Januar 2014, 19:51:34 schrieb Tomasz Figa:
On 23.01.2014 19:36, Heiko Stübner wrote:
Am Donnerstag, 23. Januar 2014, 19:12:04 schrieb Tomasz Figa:
Hi Heiko,
On 06.01.2014 19:40, Heiko Stübner wrote:
This converts all boards to use the new common restart function instead
of SoC specific ones.
The mach-s3c2416-dt board now tries to setup either a swrst- or
watchdog-
reset so that it will be able to handle more s3c24xx-SoCs later on.
[snip]
diff --git a/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
b/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c index 0a86953..88716fa4 100644
--- a/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
+++ b/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
@@ -24,6 +24,7 @@
#include plat/cpu.h
#include plat/pm.h
+#include plat/watchdog-reset.h
#include common.h
@@ -34,6 +35,14 @@ static void __init s3c2416_dt_map_io(void)
static void __init s3c2416_dt_machine_init(void)
{
+ s3c24xx_swrst_reset_of_init();
+
+#ifdef CONFIG_SAMSUNG_WDT_RESET
+ /* if no special swrst-device exists try to find a watchdog */
+ if (!s3c24xx_swrst_reset_available())
+ samsung_wdt_reset_of_init();
+#endif
Hmm... I think it would be safe to assume availability of soft reset,
especially if you could move the restart code to the clock driver.
ok, so something like the following:
the boards would simply use samsung_watchdog_reset, which should according
to the manuals be available on all architectures. And the ccf-driver on
appropriate architectures would simple replace the arm_pm_restart
callback with its own SoC specific one?
For the s3c2412 this also means that the clock-logic would get simplified.
Like this, or do I overlook something?
Hmm, this would mean a dependency on CONFIG_SAMSUNG_WDT_RESET then. Is
there a need to fall back to it on platforms which support soft reset
(assuming that CCF driver would always install its restart handler on
applicable platforms)?
s3c2410, s3c2440 and s3c2442 do not have the swrst facility. They always use
samsung_wdt_reset.
In general, I want to try establishing some sort of general restart way, as in
the future one dt-board should hopefully be enough to cover all s3c24xx soc
variants.
If you make SAMSUNG_WDT_RESET always selected on S3C24XX then I guess
it's fine.
Note that you can make the restart field NULL in mach_desc in board files.
As I said above, this is mainly meant for the dt-case. The legacy-board files
are more or less only secondary, and the affected boards can of course then
have a NULL restart handle :-) .
So for this the dt-board could simply use the wdt-reset, which then gets
replaced by the ccf-based reset if appropriate.
OK. By the way, are there any benefits of using this software reset over
watchdog reset? Maybe all S3C24xx could simply use watchdog reset and no
special handling of those with swrst would be needed.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Add l2x0 device node for Exynos4-based boards
On 23 January 2014 23:45, Tomasz Figa t.f...@samsung.com wrote: Hi, On 07.01.2014 09:53, Tushar Behera wrote: For Exynos4 platform, L2 cache initialization is done only if a device node for l2x0 device exists. L2 cache initialization path is different when a board boots with secure firmware. Since there are many Exynos4 based SoCs that boot in secure mode, enabling this only for boards that don't boot with secure firmware. Signed-off-by: Tushar Behera tushar.beh...@linaro.org --- Tested on Exynos4210-Origen board. arch/arm/boot/dts/exynos4.dtsi |8 arch/arm/boot/dts/exynos4210-origen.dts |4 arch/arm/boot/dts/exynos4210-smdkv310.dts |4 arch/arm/boot/dts/exynos4210-trats.dts |4 arch/arm/boot/dts/exynos4210-universal_c210.dts |4 arch/arm/boot/dts/exynos4412-odroidx.dts|4 arch/arm/boot/dts/exynos4412-smdk4412.dts |4 arch/arm/boot/dts/exynos4412-tiny4412.dts |4 8 files changed, 36 insertions(+) Looks good. Unfortunately this is still going to break secure firmware enabled boards, because l2x0_of_init() does not check if the node is enabled. Is the following check in l2x0_of_init() not enough? 1002 |---np = of_find_matching_node(NULL, l2x0_ids); 1003 |---if (!np) 1004 |---|---return -ENODEV; Best regards, Tomasz -- Tushar Behera -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
