Re: [PATCH V7 3/7] net: sxgbe: add TSO support for Samsung sxgbe
On Thu, Mar 20, 2014 at 7:56 AM, Byungho An wrote:
> From: Vipul Pandya
>
> Enable TSO during initialization for each DMA channels
>
> Signed-off-by: Vipul Pandya
> Neatening-by: Joe Perches
> Signed-off-by: Byungho An
> ---
> drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h |1 +
> drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h | 17 +++--
> drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c| 10 +++
> drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h|2 +
> drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c | 81
> +++--
> 5 files changed, 98 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
> b/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
> index 587b691..f8ba7e4 100644
> --- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
> +++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
> @@ -327,6 +327,7 @@ struct sxgbe_tx_queue {
> u32 tx_coal_frames;
> u32 tx_coal_timer;
> int hwts_tx_en;
> + u16 prev_mss;
> u8 queue_no;
> };
>
> diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h
> b/drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h
> index 41844d4..547edf3 100644
> --- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h
> +++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h
> @@ -167,8 +167,9 @@ struct sxgbe_desc_ops {
> void (*init_tx_desc)(struct sxgbe_tx_norm_desc *p);
>
> /* Invoked by the xmit function to prepare the tx descriptor */
> - void (*tx_enable_tse)(struct sxgbe_tx_norm_desc *p, u8 is_tse,
> - u32 hdr_len, u32 payload_len);
> + void (*tx_desc_enable_tse)(struct sxgbe_tx_norm_desc *p, u8 is_tse,
> + u32 total_hdr_len, u32 tcp_hdr_len,
> + u32 tcp_payload_len);
>
> /* Assign buffer lengths for descriptor */
> void (*prepare_tx_desc)(struct sxgbe_tx_norm_desc *p, u8 is_fd,
> @@ -207,20 +208,26 @@ struct sxgbe_desc_ops {
> int (*get_tx_timestamp_status)(struct sxgbe_tx_norm_desc *p);
>
> /* TX Context Descripto Specific */
> - void (*init_tx_ctxt_desc)(struct sxgbe_tx_ctxt_desc *p);
> + void (*tx_ctxt_desc_set_ctxt)(struct sxgbe_tx_ctxt_desc *p);
>
> /* Set the owner of the TX context descriptor */
> - void (*set_tx_ctxt_owner)(struct sxgbe_tx_ctxt_desc *p);
> + void (*tx_ctxt_desc_set_owner)(struct sxgbe_tx_ctxt_desc *p);
>
> /* Get the owner of the TX context descriptor */
> int (*get_tx_ctxt_owner)(struct sxgbe_tx_ctxt_desc *p);
>
> /* Set TX mss */
> - void (*tx_ctxt_desc_setmss)(struct sxgbe_tx_ctxt_desc *p, int mss);
> + void (*tx_ctxt_desc_set_mss)(struct sxgbe_tx_ctxt_desc *p, u16 mss);
>
> /* Set TX mss */
> int (*tx_ctxt_desc_get_mss)(struct sxgbe_tx_ctxt_desc *p);
>
> + /* Set TX tcmssv */
> + void (*tx_ctxt_desc_set_tcmssv)(struct sxgbe_tx_ctxt_desc *p);
> +
> + /* Reset TX ostc */
> + void (*tx_ctxt_desc_reset_ostc)(struct sxgbe_tx_ctxt_desc *p);
> +
> /* Set IVLAN information */
> void (*tx_ctxt_desc_set_ivlantag)(struct sxgbe_tx_ctxt_desc *p,
> int is_ivlanvalid, int ivlan_tag,
> diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c
> b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c
> index 1e68ef3..1edc451 100644
> --- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c
> +++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c
> @@ -354,6 +354,15 @@ static void sxgbe_dma_rx_watchdog(void __iomem *ioaddr,
> u32 riwt)
> }
> }
>
> +static void sxgbe_enable_tso(void __iomem *ioaddr, u8 chan_num)
> +{
> + u32 ctrl;
> +
> + ctrl = readl(ioaddr + SXGBE_DMA_CHA_TXCTL_REG(chan_num));
> + ctrl |= SXGBE_DMA_CHA_TXCTL_TSE_ENABLE;
> + writel(ctrl, ioaddr + SXGBE_DMA_CHA_TXCTL_REG(chan_num));
> +}
> +
> static const struct sxgbe_dma_ops sxgbe_dma_ops = {
> .init = sxgbe_dma_init,
> .cha_init = sxgbe_dma_channel_init,
> @@ -369,6 +378,7 @@ static const struct sxgbe_dma_ops sxgbe_dma_ops = {
> .tx_dma_int_status = sxgbe_tx_dma_int_status,
> .rx_dma_int_status = sxgbe_rx_dma_int_status,
> .rx_watchdog = sxgbe_dma_rx_watchdog,
> + .enable_tso = sxgbe_enable_tso,
> };
>
> const struct sxgbe_dma_ops *sxgbe_get_dma_ops(void)
> diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h
> b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h
> index 50c8054..6c070ac 100644
> --- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h
> +++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h
> @@ -42,6 +42,8 @@ struct sxgbe_dma_ops {
> struct sxgbe_extra_stats *x);
> /* Program the HW RX Watchdog */
> void (*rx_watchdog)(void __iomem *ioaddr, u32 riwt);
> + /* Enable TSO for each DMA channel */
> + void (*enable_ts
RE: [PATCH Resend 1/3] ARM: EXYNOS: Consolidate Kconfig entries
Kukjin Kim wrote: > > Sachin Kamat wrote: > > > > Instead of repeating the Kconfig entries for every SoC, move them under > > ARCH_EXYNOS4 and 5 and move the entries common to both 4 and 5 under > > ARCH_EXYNOS. Also, since the individual SoCs do not have any specific > > machine/platform code, keep them as boolean symbols instead of user > > selectable and select them from Exynos4 and 5 config symbols. Individual > > SoC symbols can be removed eventually once the driver Kconfig dependencies > > on these symbols are removed. > > > > Signed-off-by: Sachin Kamat > > Acked-by: Tomasz Figa > > --- > > This is a resend of the series rebased on top of latest linux-next and > > Tomasz Figa's PM consolidation series 1 and 2. > > --- > > arch/arm/Kconfig | 10 + > > arch/arm/mach-exynos/Kconfig | 89 > +++--- > > > > 2 files changed, 33 insertions(+), 66 deletions(-) > > > Hmm...I'm still thinking whether we don't need to select some specific > Exynos SoCs. Because actually we're implement/develop some features based on > mainline kernel and sometimes the features are not valid on all of Exynos4 > or Exynos5. Even though they are not in mainline, for mass product it's true > that Samsung needs to do it. It's another thing we have a plan for them or > not. Mainline upstreaming plan. > > So in my opinion, basically consolidation something is usually good but it's > not always good so we need to provide a way to use one of both. > - Kukjin -- 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 8/9] drm/exynos/fimd: use polarization flags provided by drm_display_mode
Thanks for your contributions,
2014-03-17 19:27 GMT+09:00 Andrzej Hajda :
> The patch replaces fimd private bindings for signal polarization by
> polarization flags provided by drm_display_mode.
>
This patch needs below patch not merged yet,
drm: drm_display_mode: add signal polarity flags
So let me pick up all of your path series except for patch 7 and 8.
And for these two patches, later.
Your opinion?
Thanks,
Inki Dae
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 15d6b37..dbfad4e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -115,7 +115,6 @@ struct fimd_context {
> unsigned intdefault_win;
> unsigned long irq_flags;
> u32 vidcon0;
> - u32 vidcon1;
> boolsuspended;
> int pipe;
> wait_queue_head_t wait_vsync_queue;
> @@ -232,7 +231,11 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
> return;
>
> /* setup polarity values */
> - vidcon1 = ctx->vidcon1;
> + vidcon1 = 0;
> + if (mode->pol_flags & DRM_MODE_FLAG_POL_DE_NEGEDGE)
> + vidcon1 |= VIDCON1_INV_VDEN;
> + if (mode->pol_flags & DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE)
> + vidcon1 |= VIDCON1_INV_VCLK;
> if (mode->flags & DRM_MODE_FLAG_NVSYNC)
> vidcon1 |= VIDCON1_INV_VSYNC;
> if (mode->flags & DRM_MODE_FLAG_NHSYNC)
> @@ -875,11 +878,6 @@ static int fimd_probe(struct platform_device *pdev)
> ctx->dev = dev;
> ctx->suspended = true;
>
> - if (of_property_read_bool(dev->of_node, "samsung,invert-vden"))
> - ctx->vidcon1 |= VIDCON1_INV_VDEN;
> - if (of_property_read_bool(dev->of_node, "samsung,invert-vclk"))
> - ctx->vidcon1 |= VIDCON1_INV_VCLK;
> -
> ctx->bus_clk = devm_clk_get(dev, "fimd");
> if (IS_ERR(ctx->bus_clk)) {
> dev_err(dev, "failed to get bus clock\n");
> --
> 1.8.3.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH Resend 1/3] ARM: EXYNOS: Consolidate Kconfig entries
Sachin Kamat wrote: > > Instead of repeating the Kconfig entries for every SoC, move them under > ARCH_EXYNOS4 and 5 and move the entries common to both 4 and 5 under > ARCH_EXYNOS. Also, since the individual SoCs do not have any specific > machine/platform code, keep them as boolean symbols instead of user > selectable and select them from Exynos4 and 5 config symbols. Individual > SoC symbols can be removed eventually once the driver Kconfig dependencies > on these symbols are removed. > > Signed-off-by: Sachin Kamat > Acked-by: Tomasz Figa > --- > This is a resend of the series rebased on top of latest linux-next and > Tomasz Figa's PM consolidation series 1 and 2. > --- > arch/arm/Kconfig | 10 + > arch/arm/mach-exynos/Kconfig | 89 +++--- > > 2 files changed, 33 insertions(+), 66 deletions(-) > Hmm...I'm still thinking whether we don't need to select some specific Exynos SoCs. Because actually we're implement/develop some features based on mainline kernel and sometimes the features are not valid on all of Exynos4 or Exynos5. Even though they are not in mainline, for mass product it's true that Samsung needs to do it. It's another thing we have a plan for them or not. So in my opinion, basically consolidation something is usually good but it's not always good so we need to provide a way to use one of both. Thanks, Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/4] clk: samsung: add new Kconfig for Samsung common clock option
This patch adds new Kconfig file for adding new COMMON_CLK_SAMSUNG option. Samsung platforms can select this for using common clock infrastructure. CC: Tomasz Figa CC: Mike Turquette Signed-off-by: Pankaj Dubey --- drivers/clk/Kconfig |2 ++ drivers/clk/samsung/Kconfig |3 +++ 2 files changed, 5 insertions(+) create mode 100644 drivers/clk/samsung/Kconfig diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 7641965..f2b6179 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -112,3 +112,5 @@ source "drivers/clk/qcom/Kconfig" endmenu source "drivers/clk/mvebu/Kconfig" + +source "drivers/clk/samsung/Kconfig" diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig new file mode 100644 index 000..fc8696b --- /dev/null +++ b/drivers/clk/samsung/Kconfig @@ -0,0 +1,3 @@ +config COMMON_CLK_SAMSUNG + bool + select COMMON_CLK -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/4] ARM: S3C24XX: move S3C24XX clock Kconfig options to Samsung clock Kconfig file
This patch moves S3C24XX specific clock Kconfig options into "clk/samsung/Kconfig" and also removes COMMON_CLK selection from "mach-s3c24xx/Kconfig" as S3C24XX_COMMON_CLK is selecting it's dependency. CC: Ben Dooks CC: Kukjin Kim CC: Russell King CC: Mike Turquette CC: Tomasz Figa Signed-off-by: Pankaj Dubey --- arch/arm/mach-s3c24xx/Kconfig | 14 -- drivers/clk/samsung/Kconfig |9 + 2 files changed, 9 insertions(+), 14 deletions(-) diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig index 80373da..2d1232e 100644 --- a/arch/arm/mach-s3c24xx/Kconfig +++ b/arch/arm/mach-s3c24xx/Kconfig @@ -39,7 +39,6 @@ config CPU_S3C2410 config CPU_S3C2412 bool "SAMSUNG S3C2412" - select COMMON_CLK select CPU_ARM926T select CPU_LLSERIAL_S3C2440 select S3C2412_COMMON_CLK @@ -50,7 +49,6 @@ config CPU_S3C2412 config CPU_S3C2416 bool "SAMSUNG S3C2416/S3C2450" - select COMMON_CLK select CPU_ARM926T select CPU_LLSERIAL_S3C2440 select S3C2416_PM if PM @@ -88,7 +86,6 @@ config CPU_S3C244X config CPU_S3C2443 bool "SAMSUNG S3C2443" - select COMMON_CLK select CPU_ARM920T select CPU_LLSERIAL_S3C2440 select S3C2443_COMMON_CLK @@ -364,11 +361,6 @@ config S3C2412_PM_SLEEP if CPU_S3C2412 -config S3C2412_COMMON_CLK - bool - help - Build the s3c2412 clock driver based on the common clock framework. - config CPU_S3C2412_ONLY bool depends on !CPU_S3C2410 && !CPU_S3C2416 && !CPU_S3C2440 && \ @@ -651,12 +643,6 @@ endif # CPU_S3C2442 if CPU_S3C2443 || CPU_S3C2416 -config S3C2443_COMMON_CLK - bool - help - Temporary symbol to build the clock driver based on the common clock - framework. - config S3C2443_DMA bool help diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig index fc8696b..baf28cb 100644 --- a/drivers/clk/samsung/Kconfig +++ b/drivers/clk/samsung/Kconfig @@ -1,3 +1,12 @@ config COMMON_CLK_SAMSUNG bool select COMMON_CLK + +config S3C2412_COMMON_CLK + bool + select COMMON_CLK_SAMSUNG + +config S3C2443_COMMON_CLK + bool + select COMMON_CLK_SAMSUNG + -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/4] drivers: clk: use COMMON_CLK_SAMSUNG for Samsung clock support
This patch replaces PLAT_SAMSUNG with COMMON_CLK_SAMSUNG for Samsung common clock support. Any Samsung SoC want to use Samsung common clock infrastructure can simply select COMMON_CLK_SAMSUNG. CC: Tomasz Figa Signed-off-by: Pankaj Dubey --- drivers/clk/Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index a367a98..f1da6ee 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -38,7 +38,7 @@ obj-$(CONFIG_PLAT_ORION) += mvebu/ obj-$(CONFIG_ARCH_MXS) += mxs/ obj-$(CONFIG_COMMON_CLK_QCOM) += qcom/ obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/ -obj-$(CONFIG_PLAT_SAMSUNG) += samsung/ +obj-$(CONFIG_COMMON_CLK_SAMSUNG) += samsung/ obj-$(CONFIG_ARCH_SHMOBILE_MULTI) += shmobile/ obj-$(CONFIG_ARCH_SIRF)+= sirf/ obj-$(CONFIG_ARCH_SOCFPGA) += socfpga/ -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/4] ARM: select COMMON_CLK_SAMSUNG for ARCH_EXYNOS and ARCH_S3C64XX
This patch selects COMMON_CLK_SAMSUNG for EXYNOS and S3C64XX SoC and removes COMMON_CLK selection as COMMON_CLK_SAMSUNG selects it's dependency. CC: Russell King Signed-off-by: Pankaj Dubey --- arch/arm/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e254198..0c15aa7 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -755,7 +755,7 @@ config ARCH_S3C64XX select ARM_VIC select CLKDEV_LOOKUP select CLKSRC_SAMSUNG_PWM - select COMMON_CLK + select COMMON_CLK_SAMSUNG select CPU_V6K select GENERIC_CLOCKEVENTS select GPIO_SAMSUNG @@ -834,7 +834,7 @@ config ARCH_EXYNOS select ARCH_REQUIRE_GPIOLIB select ARCH_SPARSEMEM_ENABLE select ARM_GIC - select COMMON_CLK + select COMMON_CLK_SAMSUNG select CPU_V7 select GENERIC_CLOCKEVENTS select HAVE_S3C2410_I2C if I2C -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/4] Introduce new Kconfig for Samsung common clock
Introduce a new Kconfig file for Samsung common clock infrastructure related config options. As current Samsung common clock gets compiled based on PLAT_SAMSUNG, but moving ahead with ARM64 we can not have any more such config options, so this patch introduce new COMMON_CLK_SAMSUNG invisible option. This option also select COMMON_CLK so ARCH Kconfig just need to select COMMON_CLK_SAMSUNG in case they want to use Samsung common clock. This series is based on Kukjin's for-next branch. V3: 1) Re-organized patches for preventing bisect issues. 2) Rebase on top of latest Kukjin's for-next branch. 3) Compile tested exynos_defconfig, s3c6400_defconfig and s3c2410_defconfig after each commit. V2: 1) Adding new Kconfig file for Samsung common clock. 2) Make COMMON_CLK_SAMSUNG option invisible. (as suggested by Tomasz Figa) 3) Let COMMON_CLK_SAMSUNG select COMMON_CLK. (as suggested by Tomasz Figa) 4) Move S3C24XX clock config option in new Kconfig file. Pankaj Dubey (4): clk: samsung: add new Kconfig for Samsung common clock option ARM: select COMMON_CLK_SAMSUNG for ARCH_EXYNOS and ARCH_S3C64XX ARM: S3C24XX: move S3C24XX clock Kconfig options to Samsung clock Kconfig file drivers: clk: use COMMON_CLK_SAMSUNG for Samsung clock support arch/arm/Kconfig |4 ++-- arch/arm/mach-s3c24xx/Kconfig | 14 -- drivers/clk/Kconfig |2 ++ drivers/clk/Makefile |2 +- drivers/clk/samsung/Kconfig | 12 5 files changed, 17 insertions(+), 17 deletions(-) create mode 100644 drivers/clk/samsung/Kconfig -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] clk: samsung: add new Kconfig for Samsung common clock options
On 03/19/2014 09:19 PM, Tomasz Figa wrote: Hi Pankaj, On 12.03.2014 05:32, Pankaj Dubey wrote: This patch adds new Kconfig file for adding new config option as COMMON_CLK_SAMSUNG for Samsung common clock. This patch also moves S3C24XX specific clock options here in this file. Signed-off-by: Pankaj Dubey --- drivers/clk/samsung/Kconfig | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 drivers/clk/samsung/Kconfig diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig new file mode 100644 index 000..26eb446 --- /dev/null +++ b/drivers/clk/samsung/Kconfig @@ -0,0 +1,11 @@ +config COMMON_CLK_SAMSUNG +bool +select COMMON_CLK + +config S3C2412_COMMON_CLK +bool +select COMMON_CLK_SAMSUNG + +config S3C2443_COMMON_CLK +bool +select COMMON_CLK_SAMSUNG This patch adds S3C2412_COMMON_CLK and S3C2443_COMMON_CLK to drivers/clk/samsung/Kconfig, but they are still present in arch/arm/mach-s3c24xx/Kconfig, so after this patch there are duplicate definitions. Best regards, Tomasz OK, In that case I will club change in arm/mach-s3c24xx/Kconfig and clk/samsung/Kconfig together and resubmit once again. -- Best Regards, Pankaj Dubey -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] drivers: clk: use CONFIG_COMMON_CLK_SAMSUNG for Samsung clock support
On 03/19/2014 09:18 PM, Tomasz Figa wrote: Hi Pankaj, On 12.03.2014 05:32, Pankaj Dubey wrote: This patch includes Samsung clock Kconfig file, and replaces PLAT_SAMSUNG with COMMON_CLK_SAMSUNG for Samsung common clock support. Any Samsung SoC want to use Samsung common clock infrastructure can simply select COMMON_CLK_SAMSUNG. Signed-off-by: Pankaj Dubey --- drivers/clk/Kconfig |2 ++ drivers/clk/Makefile |2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 7641965..f2b6179 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -112,3 +112,5 @@ source "drivers/clk/qcom/Kconfig" endmenu source "drivers/clk/mvebu/Kconfig" + +source "drivers/clk/samsung/Kconfig" diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index a367a98..f1da6ee 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -38,7 +38,7 @@ obj-$(CONFIG_PLAT_ORION)+= mvebu/ obj-$(CONFIG_ARCH_MXS)+= mxs/ obj-$(CONFIG_COMMON_CLK_QCOM)+= qcom/ obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/ -obj-$(CONFIG_PLAT_SAMSUNG)+= samsung/ +obj-$(CONFIG_COMMON_CLK_SAMSUNG)+= samsung/ obj-$(CONFIG_ARCH_SHMOBILE_MULTI)+= shmobile/ obj-$(CONFIG_ARCH_SIRF)+= sirf/ obj-$(CONFIG_ARCH_SOCFPGA)+= socfpga/ This patch makes samsung/ subdirectory compile depending on CONFIG_COMMON_CLK_SAMSUNG, but nothing selects it yet and thus breaking bisection. Best regards, Tomasz Thanks for review. OK, I will take care of this in next revision. -- Best Regards, Pankaj Dubey -- 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
[PATCHv4 1/5] devfreq: exynos4: Fix bug of resource leak and code clean on probe()
This patch fix bug about resource leak when happening probe fail and code clean
to add debug message.
Signed-off-by: Chanwoo Choi
---
drivers/devfreq/exynos/exynos4_bus.c | 35 +++
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/devfreq/exynos/exynos4_bus.c
b/drivers/devfreq/exynos/exynos4_bus.c
index e07b0c6..4c1bbd9 100644
--- a/drivers/devfreq/exynos/exynos4_bus.c
+++ b/drivers/devfreq/exynos/exynos4_bus.c
@@ -763,19 +763,11 @@ static int exynos4_bus_get_dev_status(struct device *dev,
return 0;
}
-static void exynos4_bus_exit(struct device *dev)
-{
- struct busfreq_data *data = dev_get_drvdata(dev);
-
- devfreq_unregister_opp_notifier(dev, data->devfreq);
-}
-
static struct devfreq_dev_profile exynos4_devfreq_profile = {
.initial_freq = 40,
.polling_ms = 50,
.target = exynos4_bus_target,
.get_dev_status = exynos4_bus_get_dev_status,
- .exit = exynos4_bus_exit,
};
static int exynos4210_init_tables(struct busfreq_data *data)
@@ -1048,8 +1040,11 @@ static int exynos4_busfreq_probe(struct platform_device
*pdev)
dev_err(dev, "Cannot determine the device id %d\n", data->type);
err = -EINVAL;
}
- if (err)
+ if (err) {
+ dev_err(dev, "Cannot initialize busfreq table %d\n",
+data->type);
return err;
+ }
data->vdd_int = devm_regulator_get(dev, "vdd_int");
if (IS_ERR(data->vdd_int)) {
@@ -1086,23 +1081,39 @@ static int exynos4_busfreq_probe(struct platform_device
*pdev)
if (IS_ERR(data->devfreq))
return PTR_ERR(data->devfreq);
- devfreq_register_opp_notifier(dev, data->devfreq);
+ /* Register opp_notifier for Exynos4 busfreq */
+ err = devfreq_register_opp_notifier(dev, data->devfreq);
+ if (err < 0) {
+ dev_err(dev, "Failed to register opp notifier\n");
+ goto err_notifier_opp;
+ }
+ /* Register pm_notifier for Exynos4 busfreq */
err = register_pm_notifier(&data->pm_notifier);
if (err) {
dev_err(dev, "Failed to setup pm notifier\n");
- devfreq_remove_device(data->devfreq);
- return err;
+ goto err_notifier_pm;
}
return 0;
+
+err_notifier_pm:
+ devfreq_unregister_opp_notifier(dev, data->devfreq);
+err_notifier_opp:
+ devfreq_remove_device(data->devfreq);
+
+ return err;
}
static int exynos4_busfreq_remove(struct platform_device *pdev)
{
struct busfreq_data *data = platform_get_drvdata(pdev);
+ /* Unregister all of notifier chain */
unregister_pm_notifier(&data->pm_notifier);
+ devfreq_unregister_opp_notifier(data->dev, data->devfreq);
+
+ /* Remove devfreq instance */
devfreq_remove_device(data->devfreq);
return 0;
--
1.8.0
--
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
[PATCHv4 5/5] devfreq: exynos5: Add CONFIG_PM_OPP dependency to fix probe fail
This patch add CONFIG_PM_OPP dependecy to exynos5_bus driver to fix probe fail. If CONFIG_PM_OPP is disabled, dev_pm_opp_find_freq_floor() will always return ERR_PTR(-EINVAL) error. Signed-off-by: Chanwoo Choi --- drivers/devfreq/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig index b2de2a1..c023c57 100644 --- a/drivers/devfreq/Kconfig +++ b/drivers/devfreq/Kconfig @@ -84,6 +84,7 @@ config ARM_EXYNOS5_BUS_DEVFREQ depends on SOC_EXYNOS5250 select ARCH_HAS_OPP select DEVFREQ_GOV_SIMPLE_ONDEMAND + select PM_OPP help This adds the DEVFREQ driver for Exynos5250 bus interface (vdd_int). It reads PPMU counters of memory controllers and adjusts the -- 1.8.0 -- 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
[PATCHv4 2/5] devfreq: exynos4: Use SIMPLE_DEV_PM_OPS macro
This patch use SIMPLE_DEV_PM_OPS macro instead of legacy method.
Signed-off-by: Chanwoo Choi
---
drivers/devfreq/exynos/exynos4_bus.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/devfreq/exynos/exynos4_bus.c
b/drivers/devfreq/exynos/exynos4_bus.c
index 4c1bbd9..5a48d16 100644
--- a/drivers/devfreq/exynos/exynos4_bus.c
+++ b/drivers/devfreq/exynos/exynos4_bus.c
@@ -1119,6 +1119,7 @@ static int exynos4_busfreq_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
static int exynos4_busfreq_resume(struct device *dev)
{
struct busfreq_data *data = dev_get_drvdata(dev);
@@ -1126,10 +1127,9 @@ static int exynos4_busfreq_resume(struct device *dev)
busfreq_mon_reset(data);
return 0;
}
+#endif
-static const struct dev_pm_ops exynos4_busfreq_pm = {
- .resume = exynos4_busfreq_resume,
-};
+static SIMPLE_DEV_PM_OPS(exynos4_busfreq_pm_ops, NULL, exynos4_busfreq_resume);
static const struct platform_device_id exynos4_busfreq_id[] = {
{ "exynos4210-busfreq", TYPE_BUSF_EXYNOS4210 },
@@ -1145,7 +1145,7 @@ static struct platform_driver exynos4_busfreq_driver = {
.driver = {
.name = "exynos4-busfreq",
.owner = THIS_MODULE,
- .pm = &exynos4_busfreq_pm,
+ .pm = &exynos4_busfreq_pm_ops,
},
};
--
1.8.0
--
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
[PATCHv4 4/5] devfreq: exynos5: Use SIMPLE_DEV_PM_OPS macro
This patch use SIMPLE_DEV_PM_OPS macro instead of legacy method.
Signed-off-by: Chanwoo Choi
---
drivers/devfreq/exynos/exynos5_bus.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/devfreq/exynos/exynos5_bus.c
b/drivers/devfreq/exynos/exynos5_bus.c
index 6eef1f7..af6213f 100644
--- a/drivers/devfreq/exynos/exynos5_bus.c
+++ b/drivers/devfreq/exynos/exynos5_bus.c
@@ -429,6 +429,7 @@ static int exynos5_busfreq_int_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
static int exynos5_busfreq_int_resume(struct device *dev)
{
struct platform_device *pdev = container_of(dev, struct platform_device,
@@ -438,10 +439,12 @@ static int exynos5_busfreq_int_resume(struct device *dev)
busfreq_mon_reset(data);
return 0;
}
-
static const struct dev_pm_ops exynos5_busfreq_int_pm = {
.resume = exynos5_busfreq_int_resume,
};
+#endif
+static SIMPLE_DEV_PM_OPS(exynos5_busfreq_int_pm_ops, NULL,
+exynos5_busfreq_int_resume);
/* platform device pointer for exynos5 devfreq device. */
static struct platform_device *exynos5_devfreq_pdev;
@@ -452,7 +455,7 @@ static struct platform_driver exynos5_busfreq_int_driver = {
.driver = {
.name = "exynos5-bus-int",
.owner = THIS_MODULE,
- .pm = &exynos5_busfreq_int_pm,
+ .pm = &exynos5_busfreq_int_pm_ops,
},
};
--
1.8.0
--
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
[PATCHv4 0/5] devfreq: exynos: Fix minor issue and code clean to remove legacy method
This patchset use SIMPLE_DEV_PM_OPS macro intead of legacy method and fix probe fail if CONFIG_PM_OPP is disabled. Also, this patchset fix minor issue. Changes from v3: - Discard patches related to DT support because DT support patch of patchset don't satisfy the basic of dt concept. So, I'm going to implement DT support patch regardless this patchset separately. - Use SIMPLE_DEV_PM_OPS macro instead of SET_SYSTEM_SLEEP_PM_OPS macro - Delete devfreq->profile->exit callback to improve readability when failure happen in probe(). - Add exynos5 patch to clean code Changes from v2: - Add detailed description to Documentation/devicetree/bindings/exynos4_bus.txt and change patch description of patch#8 - Change the sequence of patchset in patch #1 ~ #4 - Fix minor issue Changes from v1: - Add exynos4_bus.txt documentation for devicetree guide - Fix probe failure if CONFIG_PM_OPP is disabled - Fix typo and resource leak(regulator/clock/memory) when happening probe failure - Add additionally comment for PPMU usage instead of previous PPC - Split separate patch to remove ambiguous of patch Chanwoo Choi (5): devfreq: exynos4: Fix bug of resource leak and code clean on probe() devfreq: exynos4: Use SIMPLE_DEV_PM_OPS macro devfreq: exynos4: Add CONFIG_PM_OPP dependency to fix probe fail devfreq: exynos5: Use SIMPLE_DEV_PM_OPS macro devfreq: exynos5: Add CONFIG_PM_OPP dependency to fix probe fail drivers/devfreq/Kconfig | 2 ++ drivers/devfreq/exynos/exynos4_bus.c | 43 ++-- drivers/devfreq/exynos/exynos5_bus.c | 7 -- 3 files changed, 34 insertions(+), 18 deletions(-) -- 1.8.0 -- 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
[PATCHv4 3/5] devfreq: exynos4: Add CONFIG_PM_OPP dependency to fix probe fail
This patch add CONFIG_PM_OPP dependecy to exynos4_bus driver to fix probe fail as following log: [3.721389] exynos4-busfreq busfreq.3: Fail to add opp entries. [3.721697] exynos4-busfreq: probe of busfreq.3 failed with error -22 If CONFIG_PM_OPP is disabled, dev_pm_opp_find_freq_floor() in xxx_probe() will always return -EINVAL error. Signed-off-by: Chanwoo Choi --- drivers/devfreq/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig index 7d2f435..b2de2a1 100644 --- a/drivers/devfreq/Kconfig +++ b/drivers/devfreq/Kconfig @@ -70,6 +70,7 @@ config ARM_EXYNOS4_BUS_DEVFREQ depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) && !ARCH_MULTIPLATFORM select ARCH_HAS_OPP select DEVFREQ_GOV_SIMPLE_ONDEMAND + select PM_OPP help This adds the DEVFREQ driver for Exynos4210 memory bus (vdd_int) and Exynos4212/4412 memory interface and bus (vdd_mif + vdd_int). -- 1.8.0 -- 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 v11 0/4] thermal: samsung: Clean up and add support for Exynos5420
Hello Tomasz, On 20 March 2014 00:58, Tomasz Figa wrote: > Hi Leela, > > > On 19.03.2014 12:19, Leela Krishna Amudala wrote: >> >> Hi All, >> >> I didn't see this series in mainline, Any comments for this ? > > > Naveen had posted v12 of this series and I believe all the patches got my > Reviewed-by. > > Best regards, > Tomasz Thanks for your reply. These patches are posted to the mailing list quite some time now. Anything i can do to speed up the process. -- 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 0/9 v7] crypto:s5p-sss: Add DT and Exynos support
Hello Everyone, On 25 February 2014 15:16, Herbert Xu wrote: > On Mon, Feb 17, 2014 at 03:14:26PM +0530, Naveen Krishna Chatradhi wrote: >> SSS module on Exynos4210, Exynos5250 and Exynos5420 SoCs has added >> features to the one on S5PV210. However with minor changes the s5p-sss.c >> driver can be reused to support SSS modules on Exynos4 and 5 SoCs. >> >> This patch set >> 1. Adds device tree support to the s5p-sss.c driver and Documentation >> 2. Adds code to support SSS module on Exynos4 and 5 SoCs >> 3. Adds device tree node to Exynos5250 and Exynos5420 >> 4. Adds variant struct to handle the differences in SSS modules >> 5. Adds clk_prepare/clk_unprepare clocks to the s5p-sss.c driver >> >> Note: Compatible "exynos4210-secss" should work for Exynos4412 and >> Exynos5260 (Exynos5260, for which ARCH code is under review) >> I couldn't test on Exynos4412 and Exynos4210 boards, Should be able to >> test with addition of DT node and clocks support. >> >> Naveen Krishna Ch (7): [crypto-2.6.git] >> crypto:s5p-sss: Use platform_get_irq() instead of _byname() >> crypto:s5p-sss: Kconfig: Let Exynos SoCs select SSS driver >> crypto:s5p-sss: Look for the next request in the queue >> crypto:s5p-sss: Add device tree support >> crypto:s5p-sss: Add support for SSS module on Exynos >> crypto:s5p-sss: validate iv before memcpy >> crypto:s5p-sss: Use clk_prepare/clk_unprepare > > FWIW these patches are fine by me. > > Acked-by: Herbert Xu > > Thanks, Any update on this patchset. They are already reviewed by Tomasz and Acked by Herbert. Anything else to be done from my side. > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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
[PATCH V7 5/7] net: sxgbe: add Checksum offload support for Samsung sxgbe
From: Vipul Pandya
This patch adds TX and RX checksum offload support.
Signed-off-by: Vipul Pandya
Neatening-by: Joe Perches
Signed-off-by: Byungho An
---
drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h |5 +++
drivers/net/ethernet/samsung/sxgbe/sxgbe_core.c | 20 +
drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h |6 +--
drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c | 46 -
4 files changed, 63 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
index 5f1d02c..f06d439 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
@@ -337,6 +337,10 @@ struct sxgbe_core_ops {
void (*set_eee_timer)(void __iomem *ioaddr, const int ls,
const int tw);
void (*set_eee_pls)(void __iomem *ioaddr, const int link);
+
+ /* Enable disable checksum offload operations */
+ void (*enable_rx_csum)(void __iomem *ioaddr);
+ void (*disable_rx_csum)(void __iomem *ioaddr);
};
const struct sxgbe_core_ops *sxgbe_get_core_ops(void);
@@ -449,6 +453,7 @@ struct sxgbe_priv_data {
struct sxgbe_ops *hw; /* sxgbe specific ops */
int no_csum_insertion;
int irq;
+ int rxcsum_insertion;
spinlock_t stats_lock; /* lock for tx/rx statatics */
struct phy_device *phydev;
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_core.c
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_core.c
index bf93b16..5885fd6 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_core.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_core.c
@@ -217,6 +217,24 @@ static void sxgbe_set_eee_timer(void __iomem *ioaddr,
writel(value, ioaddr + SXGBE_CORE_LPI_TIMER_CTRL);
}
+static void sxgbe_enable_rx_csum(void __iomem *ioaddr)
+{
+ u32 ctrl;
+
+ ctrl = readl(ioaddr + SXGBE_CORE_RX_CONFIG_REG);
+ ctrl |= SXGBE_RX_CSUMOFFLOAD_ENABLE;
+ writel(ctrl, ioaddr + SXGBE_CORE_RX_CONFIG_REG);
+}
+
+static void sxgbe_disable_rx_csum(void __iomem *ioaddr)
+{
+ u32 ctrl;
+
+ ctrl = readl(ioaddr + SXGBE_CORE_RX_CONFIG_REG);
+ ctrl &= ~SXGBE_RX_CSUMOFFLOAD_ENABLE;
+ writel(ctrl, ioaddr + SXGBE_CORE_RX_CONFIG_REG);
+}
+
const struct sxgbe_core_ops core_ops = {
.core_init = sxgbe_core_init,
.dump_regs = sxgbe_core_dump_regs,
@@ -233,6 +251,8 @@ const struct sxgbe_core_ops core_ops = {
.reset_eee_mode = sxgbe_reset_eee_mode,
.set_eee_timer = sxgbe_set_eee_timer,
.set_eee_pls = sxgbe_set_eee_pls,
+ .enable_rx_csum = sxgbe_enable_rx_csum,
+ .disable_rx_csum = sxgbe_disable_rx_csum,
};
const struct sxgbe_core_ops *sxgbe_get_core_ops(void)
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h
index 547edf3..3c0b5a8 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h
@@ -113,7 +113,7 @@ struct sxgbe_rx_norm_desc {
/* WB RDES3 */
u32 pkt_len:14;
u32 rdes3_reserved:1;
- u32 err_summary:15;
+ u32 err_summary:1;
u32 err_l2_type:4;
u32 layer34_pkt_type:4;
u32 no_coagulation_pkt:1;
@@ -273,8 +273,8 @@ struct sxgbe_desc_ops {
int (*get_rx_ld_status)(struct sxgbe_rx_norm_desc *p);
/* Return the reception status looking at the RDES1 */
- void (*rx_wbstatus)(struct sxgbe_rx_norm_desc *p,
- struct sxgbe_extra_stats *x);
+ int (*rx_wbstatus)(struct sxgbe_rx_norm_desc *p,
+ struct sxgbe_extra_stats *x, int *checksum);
/* Get own bit */
int (*get_rx_ctxt_owner)(struct sxgbe_rx_ctxt_desc *p);
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
index 752b2c5..dbbb7ab 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
@@ -1255,6 +1255,7 @@ void sxgbe_tso_prepare(struct sxgbe_priv_data *priv,
static netdev_tx_t sxgbe_xmit(struct sk_buff *skb, struct net_device *dev)
{
unsigned int entry, frag_num;
+ int cksum_flag = 0;
struct netdev_queue *dev_txq;
unsigned txq_index = skb_get_queue_mapping(skb);
struct sxgbe_priv_data *priv = netdev_priv(dev);
@@ -1331,7 +1332,7 @@ static netdev_tx_t sxgbe_xmit(struct sk_buff *skb, struct
net_device *dev)
__func__);
priv->hw->desc->prepare_tx_desc(tx_desc, 1, no_pagedlen,
- no_pagedlen);
+ no_pagedlen,
cksu
[PATCH V7 6/7] net: sxgbe: add ethtool related functions support Samsung sxgbe
From: Vipul Pandya
This patch adds ethtool related functions.
Signed-off-by: Vipul Pandya
Neatening-by: Joe Perches
Signed-off-by: Byungho An
---
drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h | 25 +-
drivers/net/ethernet/samsung/sxgbe/sxgbe_ethtool.c | 509 +++-
drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c|8 +-
drivers/net/ethernet/samsung/sxgbe/sxgbe_reg.h |6 +
4 files changed, 537 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
index f06d439..ef7dc80 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
@@ -42,8 +42,12 @@ struct sxgbe_mtl_ops;
#define SXGBE_RX_QUEUES 16
/* Max/Min RI Watchdog Timer count value */
-#define SXGBE_MAX_DMA_RIWT 0xff
-#define SXGBE_MIN_DMA_RIWT 0x20
+/* Calculated based how much time does it take to fill 256KB Rx memory
+ * at 10Gb speed at 156MHz clock rate and considered little less then
+ * the actual value.
+ */
+#define SXGBE_MAX_DMA_RIWT 0x70
+#define SXGBE_MIN_DMA_RIWT 0x01
/* Tx coalesce parameters */
#define SXGBE_COAL_TX_TIMER4
@@ -194,6 +198,20 @@ enum dma_irq_status {
#define SXGBE_FOR_EACH_QUEUE(max_queues, queue_num)\
for (queue_num = 0; queue_num < max_queues; queue_num++)
+#define DRV_VERSION "1.0.0"
+
+#define SXGBE_MAX_RX_CHANNELS 16
+#define SXGBE_MAX_TX_CHANNELS 16
+
+#define START_MAC_REG_OFFSET 0x
+#define MAX_MAC_REG_OFFSET 0x0DFC
+#define START_MTL_REG_OFFSET 0x1000
+#define MAX_MTL_REG_OFFSET 0x18FC
+#define START_DMA_REG_OFFSET 0x3000
+#define MAX_DMA_REG_OFFSET 0x38FC
+
+#define REG_SPACE_SIZE 0x2000
+
/* sxgbe statistics counters */
struct sxgbe_extra_stats {
/* TX/RX IRQ events */
@@ -479,6 +497,7 @@ struct sxgbe_priv_data {
/* advanced time stamp support */
u32 adv_ts;
int use_riwt;
+ struct ptp_clock *ptp_clock;
/* tc control */
int tx_tc;
@@ -515,4 +534,6 @@ const struct sxgbe_mtl_ops *sxgbe_get_mtl_ops(void);
void sxgbe_disable_eee_mode(struct sxgbe_priv_data * const priv);
bool sxgbe_eee_init(struct sxgbe_priv_data * const priv);
+int sxgbe_set_flow_ctrl(struct sxgbe_priv_data *priv, int rx, int tx);
+
#endif /* __SXGBE_COMMON_H__ */
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_ethtool.c
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_ethtool.c
index 9083300..471bc89 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_ethtool.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_ethtool.c
@@ -12,11 +12,17 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include
+#include
#include
#include
+#include
#include
+#include
#include "sxgbe_common.h"
+#include "sxgbe_reg.h"
+#include "sxgbe_dma.h"
struct sxgbe_stats {
char stat_string[ETH_GSTRING_LEN];
@@ -32,16 +38,105 @@ struct sxgbe_stats {
}
static const struct sxgbe_stats sxgbe_gstrings_stats[] = {
+ /* TX/RX IRQ events */
+ SXGBE_STAT(tx_process_stopped_irq),
+ SXGBE_STAT(tx_ctxt_desc_err),
+ SXGBE_STAT(tx_threshold),
+ SXGBE_STAT(rx_threshold),
+ SXGBE_STAT(tx_pkt_n),
+ SXGBE_STAT(rx_pkt_n),
+ SXGBE_STAT(normal_irq_n),
+ SXGBE_STAT(tx_normal_irq_n),
+ SXGBE_STAT(rx_normal_irq_n),
+ SXGBE_STAT(napi_poll),
+ SXGBE_STAT(tx_clean),
+ SXGBE_STAT(tx_reset_ic_bit),
+ SXGBE_STAT(rx_process_stopped_irq),
+ SXGBE_STAT(rx_underflow_irq),
+
+ /* Bus access errors */
+ SXGBE_STAT(fatal_bus_error_irq),
+ SXGBE_STAT(tx_read_transfer_err),
+ SXGBE_STAT(tx_write_transfer_err),
+ SXGBE_STAT(tx_desc_access_err),
+ SXGBE_STAT(tx_buffer_access_err),
+ SXGBE_STAT(tx_data_transfer_err),
+ SXGBE_STAT(rx_read_transfer_err),
+ SXGBE_STAT(rx_write_transfer_err),
+ SXGBE_STAT(rx_desc_access_err),
+ SXGBE_STAT(rx_buffer_access_err),
+ SXGBE_STAT(rx_data_transfer_err),
+
+ /* EEE-LPI stats */
SXGBE_STAT(tx_lpi_entry_n),
SXGBE_STAT(tx_lpi_exit_n),
SXGBE_STAT(rx_lpi_entry_n),
SXGBE_STAT(rx_lpi_exit_n),
SXGBE_STAT(eee_wakeup_error_n),
+
+ /* RX specific */
+ /* L2 error */
+ SXGBE_STAT(rx_code_gmii_err),
+ SXGBE_STAT(rx_watchdog_err),
+ SXGBE_STAT(rx_crc_err),
+ SXGBE_STAT(rx_gaint_pkt_err),
+ SXGBE_STAT(ip_hdr_err),
+ SXGBE_STAT(ip_payload_err),
+ SXGBE_STAT(overflow_error),
+
+ /* L2 Pkt type */
+ SXGBE_STAT(len_pkt),
+ SXGBE_STAT(mac_ctl_pkt),
+ SXGBE_STAT(dcb_ctl_pkt),
+ SXGBE_STAT(arp_pkt),
+ SXGBE_STAT(oam_pkt),
+ SXGBE_STAT(untag_okt),
+ SXGBE_STAT(other_pkt),
+ SXGBE_STAT(svlan_tag_pkt),
+ SXGBE_STAT(cvlan_tag_pkt),
+ SXGBE_STAT(dvlan_ocvlan_icvlan_pkt),
+ SXGBE_STAT(dvlan_osvlan_isvla
[PATCH V7 4/7] net: sxgbe: add EEE(Energy Efficient Ethernet) for Samsung sxgbe
From: Girish K S
Added support for the EEE(Energy Efficient Ethernet) in 10G ethernet driver.
Signed-off-by: Girish K S
Neatening-by: Joe Perches
Signed-off-by: Byungho An
---
drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h | 53 +++
drivers/net/ethernet/samsung/sxgbe/sxgbe_core.c| 86 +-
drivers/net/ethernet/samsung/sxgbe/sxgbe_ethtool.c | 47 ++
drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c| 165 +++-
.../net/ethernet/samsung/sxgbe/sxgbe_platform.c|4 +
drivers/net/ethernet/samsung/sxgbe/sxgbe_reg.h |5 +
6 files changed, 358 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
index f8ba7e4..5f1d02c 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
@@ -115,6 +115,33 @@ struct sxgbe_mtl_ops;
#define RX_PTP_SIGNAL 0x0A
#define RX_PTP_RESV_MSG0x0F
+/* EEE-LPI mode flags*/
+#define TX_ENTRY_LPI_MODE 0x10
+#define TX_EXIT_LPI_MODE 0x20
+#define RX_ENTRY_LPI_MODE 0x40
+#define RX_EXIT_LPI_MODE 0x80
+
+/* EEE-LPI Interrupt status flag */
+#define LPI_INT_STATUS BIT(5)
+
+/* EEE-LPI Default timer values */
+#define LPI_LINK_STATUS_TIMER 0x3E8
+#define LPI_MAC_WAIT_TIMER 0x00
+
+/* EEE-LPI Control and status definitions */
+#define LPI_CTRL_STATUS_TXABIT(19)
+#define LPI_CTRL_STATUS_PLSDIS BIT(18)
+#define LPI_CTRL_STATUS_PLSBIT(17)
+#define LPI_CTRL_STATUS_LPIEN BIT(16)
+#define LPI_CTRL_STATUS_TXRSTP BIT(11)
+#define LPI_CTRL_STATUS_RXRSTP BIT(10)
+#define LPI_CTRL_STATUS_RLPIST BIT(9)
+#define LPI_CTRL_STATUS_TLPIST BIT(8)
+#define LPI_CTRL_STATUS_RLPIEX BIT(3)
+#define LPI_CTRL_STATUS_RLPIEN BIT(2)
+#define LPI_CTRL_STATUS_TLPIEX BIT(1)
+#define LPI_CTRL_STATUS_TLPIEN BIT(0)
+
enum dma_irq_status {
tx_hard_error = BIT(0),
tx_bump_tc = BIT(1),
@@ -199,6 +226,13 @@ struct sxgbe_extra_stats {
unsigned long rx_buffer_access_err;
unsigned long rx_data_transfer_err;
+ /* EEE-LPI stats */
+ unsigned long tx_lpi_entry_n;
+ unsigned long tx_lpi_exit_n;
+ unsigned long rx_lpi_entry_n;
+ unsigned long rx_lpi_exit_n;
+ unsigned long eee_wakeup_error_n;
+
/* RX specific */
/* L2 error */
unsigned long rx_code_gmii_err;
@@ -296,6 +330,13 @@ struct sxgbe_core_ops {
unsigned char feature_index);
/* adjust SXGBE speed */
void (*set_speed)(void __iomem *ioaddr, unsigned char speed);
+
+ /* EEE-LPI specific operations */
+ void (*set_eee_mode)(void __iomem *ioaddr);
+ void (*reset_eee_mode)(void __iomem *ioaddr);
+ void (*set_eee_timer)(void __iomem *ioaddr, const int ls,
+ const int tw);
+ void (*set_eee_pls)(void __iomem *ioaddr, const int link);
};
const struct sxgbe_core_ops *sxgbe_get_core_ops(void);
@@ -352,6 +393,8 @@ struct sxgbe_hw_features {
/* IEEE 1588-2008 */
unsigned int atime_stamp;
+ unsigned int eee;
+
unsigned int tx_csum_offload;
unsigned int rx_csum_offload;
unsigned int multi_macaddr;
@@ -435,6 +478,13 @@ struct sxgbe_priv_data {
/* tc control */
int tx_tc;
int rx_tc;
+ /* EEE-LPI specific members */
+ struct timer_list eee_ctrl_timer;
+ bool tx_path_in_lpi_mode;
+ int lpi_irq;
+ int eee_enabled;
+ int eee_active;
+ int tx_lpi_timer;
};
/* Function prototypes */
@@ -457,4 +507,7 @@ int sxgbe_restore(struct net_device *ndev);
const struct sxgbe_mtl_ops *sxgbe_get_mtl_ops(void);
+void sxgbe_disable_eee_mode(struct sxgbe_priv_data * const priv);
+bool sxgbe_eee_init(struct sxgbe_priv_data * const priv);
+
#endif /* __SXGBE_COMMON_H__ */
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_core.c
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_core.c
index 17eea58..bf93b16 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_core.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_core.c
@@ -47,11 +47,38 @@ static void sxgbe_core_dump_regs(void __iomem *ioaddr)
{
}
+static int sxgbe_get_lpi_status(void __iomem *ioaddr, const u32 irq_status)
+{
+ int status = 0;
+ int lpi_status;
+
+ /* Reading this register shall clear all the LPI status bits */
+ lpi_status = readl(ioaddr + SXGBE_CORE_LPI_CTRL_STATUS);
+
+ if (lpi_status & LPI_CTRL_STATUS_TLPIEN)
+ status |= TX_ENTRY_LPI_MODE;
+ if (lpi_status & LPI_CTRL_STATUS_TLPIEX)
+ status |= TX_EXIT_LPI_MODE;
+ if (lpi_status & LPI_CTRL_STATUS_RLPIEN)
+ status |= RX_ENTRY_LPI_MODE;
+ if (lpi_status & LPI_CTRL_STATUS_RLPIEX)
+ status |= RX_EXIT_LPI_MODE;
+
+ return status;
+}
+
/* Handle extra events on specific interrup
[PATCH V7 0/7] add new Samsung SXGBE driver
Hi all,
This is 7th posting for SAMSUNG SXGBE driver.
Changes since v1:
- changed name of driver to SXGbE as per Ben's comment
- squashed Joe's neatening for many stuff in original patches
Changes since v2:
- updated and split binding document as per Mark's comment
- clean up codes as per Joe's comment
- removed unused fields and clean up codes as per Francois's comment
- removed module parameters as per Dave's comment
- moved driver directory to samsung/sxgbe/
Changes since v3:
- fixed Missing a blank line after declarations as per Dave's comment
- clean up codes as per Joe's comment
- removed reference of net_device.{irq, base_addr} as per Francois's comment
Changes since v4:
- updated binding document and DT related function as per Mark's comment
Changes since v5:
- updated binding document and DT related function as per Florian's comment
- fixed typo and shortened code as per Joe's comment
Changes since v6:
- updated TSO related functions as per Rayagond's comment
- updated binding document as per Mark's comment
- removed WoL from this patch set
Byungho An (1):
MAINTAINERS: add maintainer for Samsung sxgbe driver
Girish K S (1):
net: sxgbe: add EEE(Energy Efficient Ethernet) for Samsung sxgbe
Siva Reddy (2):
sxgbe: Add device-tree binding support document
net: sxgbe: add basic framework for Samsung 10Gb ethernet driver
Vipul Pandya (3):
net: sxgbe: add TSO support for Samsung sxgbe
net: sxgbe: add Checksum offload support for Samsung sxgbe
net: sxgbe: add ethtool related functions support Samsung sxgbe
.../devicetree/bindings/net/samsung-sxgbe.txt | 60 +
MAINTAINERS|9 +
drivers/net/ethernet/Kconfig |1 +
drivers/net/ethernet/Makefile |1 +
drivers/net/ethernet/samsung/Kconfig | 20 +
drivers/net/ethernet/samsung/Makefile |5 +
drivers/net/ethernet/samsung/sxgbe/Kconfig |9 +
drivers/net/ethernet/samsung/sxgbe/Makefile|4 +
drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h | 539 +
drivers/net/ethernet/samsung/sxgbe/sxgbe_core.c| 261 +++
drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.c| 515 +
drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h| 298 +++
drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c | 387
drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h | 51 +
drivers/net/ethernet/samsung/sxgbe/sxgbe_ethtool.c | 588 +
drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c| 2313
drivers/net/ethernet/samsung/sxgbe/sxgbe_mdio.c| 271 +++
drivers/net/ethernet/samsung/sxgbe/sxgbe_mtl.c | 252 +++
drivers/net/ethernet/samsung/sxgbe/sxgbe_mtl.h | 104 +
.../net/ethernet/samsung/sxgbe/sxgbe_platform.c| 262 +++
drivers/net/ethernet/samsung/sxgbe/sxgbe_reg.h | 488 +
drivers/net/ethernet/samsung/sxgbe/sxgbe_xpcs.c| 92 +
drivers/net/ethernet/samsung/sxgbe/sxgbe_xpcs.h| 38 +
include/linux/sxgbe_platform.h | 54 +
24 files changed, 6622 insertions(+)
Thanks,
Byungho An
--
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 1/7] sxgbe: Add device-tree binding support document
From: Siva Reddy
This patch adds binding document for SXGBE ethernet driver via device-tree.
Signed-off-by: Siva Reddy Kallam
Signed-off-by: Byungho An
---
.../devicetree/bindings/net/samsung-sxgbe.txt | 60
1 file changed, 60 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/samsung-sxgbe.txt
diff --git a/Documentation/devicetree/bindings/net/samsung-sxgbe.txt
b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt
new file mode 100644
index 000..231acf8
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt
@@ -0,0 +1,60 @@
+* Samsung 10G Ethernet driver (SXGBE)
+
+Required properties:
+- compatible: Should be "samsung,sxgbe-v2.0a"
+- reg: Address and length of the register set for the device
+- interrupt-parent: Should be the phandle for the interrupt controller
+ that services interrupts for this device
+- interrupts: Should contain the SXGBE interrupts
+ These interrupts are ordered by fixed and follows variable
+ trasmit DMA interrupts, receive DMA interrupts and lpi interrupt.
+ index 0 - this is fixed common interrupt of SXGBE and it is always
+ available.
+ index 1 to 25 - 8 variable trasmit interrupts, variable 16 receive interrupts
+ and 1 optional lpi interrupt.
+- phy-mode: String, operation mode of the PHY interface.
+ Supported values are: "sgmii", "xgmii".
+- samsung,pbl: Integer, Programmable Burst Length.
+ Supported values are 1, 2, 4, 8, 16, or 32.
+- samsung,burst-map: Integer, Program the possible bursts supported by sxgbe
+ This is an interger and represents allowable DMA bursts when fixed burst.
+ Allowable range is 0x01-0x3F. When this field is set fixed burst is enabled.
+ When fixed length is needed for burst mode, it can be set within allowable
+ range.
+- samsung,adv-addr-mode: Boolean, Program the DMA to use Enhanced address mode.
+ When enhanced address mode is needed, it can be set.
+- samsung,force-thresh-dma-mode: Boolean, Force DMA to use the threshold mode
+ for both tx and rx.
+- samsung,force-sf-dma-mode: Boolean, Force DMA to use the Store and Forward
+ mode for both tx and rx. This flag is ignored if force-thresh-dma-mode is
set.
+
+Optional properties:
+- mac-address: 6 bytes, mac address
+- max-frame-size: Maximum Transfer Unit (IEEE defined MTU), rather
+ than the maximum frame size.
+
+Example:
+
+ aliases {
+ ethernet0 = <&sxgbe0>;
+ };
+
+ sxgbe0: ethernet@1a04 {
+ compatible = "samsung,sxgbe-v2.0a";
+ reg = <0 0x1a04 0 0x1>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 209 4>, <0 185 4>, <0 186 4>, <0 187 4>,
+<0 188 4>, <0 189 4>, <0 190 4>, <0 191 4>,
+<0 192 4>, <0 193 4>, <0 194 4>, <0 195 4>,
+<0 196 4>, <0 197 4>, <0 198 4>, <0 199 4>,
+<0 200 4>, <0 201 4>, <0 202 4>, <0 203 4>,
+<0 204 4>, <0 205 4>, <0 206 4>, <0 207 4>,
+<0 208 4>, <0 210 4>;
+ samsung,pbl = <0x08>
+ samsung,burst-map = <0x20>
+ samsung,adv-addr-mode = "true"
+ samsung,force-sf-dma-mode = "true"
+ mac-address = [ 00 11 22 33 44 55 ]; /* Filled in by U-Boot */
+ max-frame-size = <9000>;
+ phy-mode = "xgmii";
+ };
--
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 V7 3/7] net: sxgbe: add TSO support for Samsung sxgbe
From: Vipul Pandya
Enable TSO during initialization for each DMA channels
Signed-off-by: Vipul Pandya
Neatening-by: Joe Perches
Signed-off-by: Byungho An
---
drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h |1 +
drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h | 17 +++--
drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c| 10 +++
drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h|2 +
drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c | 81 +++--
5 files changed, 98 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
index 587b691..f8ba7e4 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_common.h
@@ -327,6 +327,7 @@ struct sxgbe_tx_queue {
u32 tx_coal_frames;
u32 tx_coal_timer;
int hwts_tx_en;
+ u16 prev_mss;
u8 queue_no;
};
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h
index 41844d4..547edf3 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_desc.h
@@ -167,8 +167,9 @@ struct sxgbe_desc_ops {
void (*init_tx_desc)(struct sxgbe_tx_norm_desc *p);
/* Invoked by the xmit function to prepare the tx descriptor */
- void (*tx_enable_tse)(struct sxgbe_tx_norm_desc *p, u8 is_tse,
- u32 hdr_len, u32 payload_len);
+ void (*tx_desc_enable_tse)(struct sxgbe_tx_norm_desc *p, u8 is_tse,
+ u32 total_hdr_len, u32 tcp_hdr_len,
+ u32 tcp_payload_len);
/* Assign buffer lengths for descriptor */
void (*prepare_tx_desc)(struct sxgbe_tx_norm_desc *p, u8 is_fd,
@@ -207,20 +208,26 @@ struct sxgbe_desc_ops {
int (*get_tx_timestamp_status)(struct sxgbe_tx_norm_desc *p);
/* TX Context Descripto Specific */
- void (*init_tx_ctxt_desc)(struct sxgbe_tx_ctxt_desc *p);
+ void (*tx_ctxt_desc_set_ctxt)(struct sxgbe_tx_ctxt_desc *p);
/* Set the owner of the TX context descriptor */
- void (*set_tx_ctxt_owner)(struct sxgbe_tx_ctxt_desc *p);
+ void (*tx_ctxt_desc_set_owner)(struct sxgbe_tx_ctxt_desc *p);
/* Get the owner of the TX context descriptor */
int (*get_tx_ctxt_owner)(struct sxgbe_tx_ctxt_desc *p);
/* Set TX mss */
- void (*tx_ctxt_desc_setmss)(struct sxgbe_tx_ctxt_desc *p, int mss);
+ void (*tx_ctxt_desc_set_mss)(struct sxgbe_tx_ctxt_desc *p, u16 mss);
/* Set TX mss */
int (*tx_ctxt_desc_get_mss)(struct sxgbe_tx_ctxt_desc *p);
+ /* Set TX tcmssv */
+ void (*tx_ctxt_desc_set_tcmssv)(struct sxgbe_tx_ctxt_desc *p);
+
+ /* Reset TX ostc */
+ void (*tx_ctxt_desc_reset_ostc)(struct sxgbe_tx_ctxt_desc *p);
+
/* Set IVLAN information */
void (*tx_ctxt_desc_set_ivlantag)(struct sxgbe_tx_ctxt_desc *p,
int is_ivlanvalid, int ivlan_tag,
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c
index 1e68ef3..1edc451 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.c
@@ -354,6 +354,15 @@ static void sxgbe_dma_rx_watchdog(void __iomem *ioaddr,
u32 riwt)
}
}
+static void sxgbe_enable_tso(void __iomem *ioaddr, u8 chan_num)
+{
+ u32 ctrl;
+
+ ctrl = readl(ioaddr + SXGBE_DMA_CHA_TXCTL_REG(chan_num));
+ ctrl |= SXGBE_DMA_CHA_TXCTL_TSE_ENABLE;
+ writel(ctrl, ioaddr + SXGBE_DMA_CHA_TXCTL_REG(chan_num));
+}
+
static const struct sxgbe_dma_ops sxgbe_dma_ops = {
.init = sxgbe_dma_init,
.cha_init = sxgbe_dma_channel_init,
@@ -369,6 +378,7 @@ static const struct sxgbe_dma_ops sxgbe_dma_ops = {
.tx_dma_int_status = sxgbe_tx_dma_int_status,
.rx_dma_int_status = sxgbe_rx_dma_int_status,
.rx_watchdog = sxgbe_dma_rx_watchdog,
+ .enable_tso = sxgbe_enable_tso,
};
const struct sxgbe_dma_ops *sxgbe_get_dma_ops(void)
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h
index 50c8054..6c070ac 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_dma.h
@@ -42,6 +42,8 @@ struct sxgbe_dma_ops {
struct sxgbe_extra_stats *x);
/* Program the HW RX Watchdog */
void (*rx_watchdog)(void __iomem *ioaddr, u32 riwt);
+ /* Enable TSO for each DMA channel */
+ void (*enable_tso)(void __iomem *ioaddr, u8 chan_num);
};
const struct sxgbe_dma_ops *sxgbe_get_dma_ops(void);
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
index 1714fd7..dc07ee6 100644
--- a/drivers/net/eth
[PATCH V7 7/7] MAINTAINERS: add maintainer for Samsung sxgbe driver
From: Byungho An Signed-off-by: Byungho An --- MAINTAINERS |9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index b7befe7..aeb81f2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7536,6 +7536,15 @@ S: Supported L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers) F: drivers/clk/samsung/ +SAMSUNG SXGBE DRIVERS +M: Byungho An +M: Girish K S +M: Siva Reddy Kallam +M: Vipul Pandya +S: Supported +L: net...@vger.kernel.org +F: drivers/net/ethernet/samsung/sxgbe/ + SERIAL DRIVERS M: Greg Kroah-Hartman L: linux-ser...@vger.kernel.org -- 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 1/1] ARM: EXYNOS: Add support to reserve memory for MFC-v7
Sachin Kamat wrote:
>
> Reserve memory for MFC-v7 IP.
>
> Signed-off-by: Sachin Kamat
> ---
> Based on top of Tushar's patch:
> [PATCH V2] ARM: SAMSUNG: Reorganize calls to reserve memory for MFC
> http://www.spinics.net/lists/linux-samsung-soc/msg25501.html
> ---
> arch/arm/mach-exynos/mach-exynos5-dt.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-
> exynos5-dt.c
> index 9586439b2d0e..9a8a798d2ad0 100644
> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
> @@ -59,7 +59,15 @@ static char const *exynos5_dt_compat[] __initdata = {
> static void __init exynos5_reserve(void)
> {
> #ifdef CONFIG_S5P_DEV_MFC
> - of_scan_flat_dt(s5p_fdt_alloc_mfc_mem, "samsung,mfc-v6");
> + int i;
> + char *mfc_mem[] = {
> + "samsung,mfc-v6",
> + "samsung,mfc-v7",
> + };
> +
> + for (i = 0; i < ARRAY_SIZE(mfc_mem); i++)
> + if (of_scan_flat_dt(s5p_fdt_alloc_mfc_mem, mfc_mem[i]))
> + break;
> #endif
> }
>
> --
> 1.7.9.5
Looks OK, will apply.
Thanks,
Kukjin
--
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] ARM: SAMSUNG: Reorganize calls to reserve memory for MFC
Tushar Behera wrote:
>
> On 31 December 2013 11:53, Tushar Behera wrote:
> > Reorganize code so that "plat/mfc.h" is no more referred from
> > mach-exynos folder.
> >
> > Signed-off-by: Tushar Behera
> > ---
> >
> > Changelog for V2:
> > * Added missing arch/arm/mach-exynos/mfc.h file
> >
> > arch/arm/mach-exynos/mach-exynos4-dt.c | 10 ++
> > arch/arm/mach-exynos/mach-exynos5-dt.c | 10 ++
> > arch/arm/mach-exynos/mfc.h | 16
> > arch/arm/plat-samsung/include/plat/mfc.h |3 ---
> > arch/arm/plat-samsung/s5p-dev-mfc.c | 17 ++---
> > 5 files changed, 30 insertions(+), 26 deletions(-)
> > create mode 100644 arch/arm/mach-exynos/mfc.h
> >
> > diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c
> > b/arch/arm/mach-exynos/mach-
> exynos4-dt.c
> > index 4603e6b..66b4a6e 100644
> > --- a/arch/arm/mach-exynos/mach-exynos4-dt.c
> > +++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
> > @@ -15,9 +15,9 @@
> > #include
> >
> > #include
> > -#include
> >
> > #include "common.h"
> > +#include "mfc.h"
> >
> > static void __init exynos4_dt_machine_init(void)
> > {
> > @@ -36,13 +36,7 @@ static char const *exynos4_dt_compat[] __initdata = {
> > static void __init exynos4_reserve(void)
> > {
> > #ifdef CONFIG_S5P_DEV_MFC
> > - struct s5p_mfc_dt_meminfo mfc_mem;
> > -
> > - /* Reserve memory for MFC only if it's available */
> > - mfc_mem.compatible = "samsung,mfc-v5";
> > - if (of_scan_flat_dt(s5p_fdt_find_mfc_mem, &mfc_mem))
> > - s5p_mfc_reserve_mem(mfc_mem.roff, mfc_mem.rsize,
> > mfc_mem.loff,
> > - mfc_mem.lsize);
> > + of_scan_flat_dt(s5p_fdt_alloc_mfc_mem, "samsung,mfc-v5");
> > #endif
> > }
> > DT_MACHINE_START(EXYNOS4210_DT, "Samsung Exynos4 (Flattened Device Tree)")
> > diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
> > b/arch/arm/mach-exynos/mach-
> exynos5-dt.c
> > index 9bb6eac..36b36f4 100644
> > --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> > +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
> > @@ -14,9 +14,9 @@
> > #include
> >
> > #include
> > -#include
> >
> > #include "common.h"
> > +#include "mfc.h"
> > #include "regs-pmu.h"
> >
> > static void __init exynos5_dt_machine_init(void)
> > @@ -59,13 +59,7 @@ static char const *exynos5_dt_compat[] __initdata = {
> > static void __init exynos5_reserve(void)
> > {
> > #ifdef CONFIG_S5P_DEV_MFC
> > - struct s5p_mfc_dt_meminfo mfc_mem;
> > -
> > - /* Reserve memory for MFC only if it's available */
> > - mfc_mem.compatible = "samsung,mfc-v6";
> > - if (of_scan_flat_dt(s5p_fdt_find_mfc_mem, &mfc_mem))
> > - s5p_mfc_reserve_mem(mfc_mem.roff, mfc_mem.rsize,
> > mfc_mem.loff,
> > - mfc_mem.lsize);
> > + of_scan_flat_dt(s5p_fdt_alloc_mfc_mem, "samsung,mfc-v6");
> > #endif
> > }
> >
> > diff --git a/arch/arm/mach-exynos/mfc.h b/arch/arm/mach-exynos/mfc.h
> > new file mode 100644
> > index 000..dec93cd
> > --- /dev/null
> > +++ b/arch/arm/mach-exynos/mfc.h
> > @@ -0,0 +1,16 @@
> > +/*
> > + * Copyright (C) 2013 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 as published by the
> > + * Free Software Foundation; either version 2 of the License, or (at your
> > + * option) any later version.
> > + */
> > +
> > +#ifndef __MACH_EXYNOS_MFC_H
> > +#define __MACH_EXYNOS_MFC_H __FILE__
> > +
> > +int __init s5p_fdt_alloc_mfc_mem(unsigned long node, const char *uname,
> > + int depth, void *data);
> > +
> > +#endif /* __MACH_EXYNOS_MFC_H */
> > diff --git a/arch/arm/plat-samsung/include/plat/mfc.h b/arch/arm/plat-
> samsung/include/plat/mfc.h
> > index e6d7c42..033654e 100644
> > --- a/arch/arm/plat-samsung/include/plat/mfc.h
> > +++ b/arch/arm/plat-samsung/include/plat/mfc.h
> > @@ -32,7 +32,4 @@ struct s5p_mfc_dt_meminfo {
> > void __init s5p_mfc_reserve_mem(phys_addr_t rbase, unsigned int rsize,
> > phys_addr_t lbase, unsigned int lsize);
> >
> > -int __init s5p_fdt_find_mfc_mem(unsigned long node, const char *uname,
> > - int depth, void *data);
> > -
> > #endif /* __PLAT_SAMSUNG_MFC_H */
> > diff --git a/arch/arm/plat-samsung/s5p-dev-mfc.c
> > b/arch/arm/plat-samsung/s5p-dev-
> mfc.c
> > index ad51f85..98087b6 100644
> > --- a/arch/arm/plat-samsung/s5p-dev-mfc.c
> > +++ b/arch/arm/plat-samsung/s5p-dev-mfc.c
> > @@ -122,32 +122,35 @@ device_initcall(s5p_mfc_memory_init);
> > #endif
> >
> > #ifdef CONFIG_OF
> > -int __init s5p_fdt_find_mfc_mem(unsigned long node, const char *uname,
> > +int __init s5p_fdt_alloc_mfc_mem(unsigned long node, const char *uname,
> > int depth, void *data)
> > {
> > __be32 *prop;
> > unsigned long len;
> > - str
RE: [PATCH 0/4] Consolidate Exynos machine code
Arnd Bergmann wrote: > > On Wednesday 19 March 2014, Sachin Kamat wrote: > > This patch series consolidates the Exynos machine code and common > > code into a single file to avoid code duplication and introduces > > generic compatible strings for Exynos4 and 5 SoC series. > > > > Complete discussion and motivation for this series is found here: > > http://comments.gmane.org/gmane.linux.kernel.samsung-soc/27268 > > > > This series is based on the latest linux-next and depends on > > 1. Tomasz Figa's PM consolidation series 1 and 2 > > 2. Patch: ARM: SAMSUNG: Reorganize calls to reserve memory for MFC > > http://www.spinics.net/lists/linux-samsung-soc/msg25501.html > > 3. Patch: ARM: EXYNOS: Add support to reserve memory for MFC-v7 > > http://www.spinics.net/lists/arm-kernel/msg315940.html > > 4. Kconfig and CPU init Consolidation series > > http://article.gmane.org/gmane.linux.kernel.samsung-soc/28216 > Hi Sachin, Looks good to me. > Acked-by: Arnd Bergmann Arnd, thanks. Let me sort this series out for v3.15 then I'll send pull-request to arm-soc with other dependencies tonight. Thanks, Kukjin -- 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/11] base: power: Add generic OF-based power domain look-up
Hi Sören,
On 20.03.2014 00:13, Sören Brinkmann wrote:
On Mon, 2014-03-03 at 05:02PM +0100, Tomasz Figa wrote:
This patch introduces generic code to perform power domain look-up using
device tree and automatically bind devices to their power domains.
Generic device tree binding is introduced to specify power domains of
devices in their device tree nodes.
Backwards compatibility with legacy Samsung-specific power domain
bindings is provided, but for now the new code is not compiled when
CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
will change as soon as Exynos power domain code gets converted to use
the generic framework in further patch.
Signed-off-by: Tomasz Figa
---
.../devicetree/bindings/power/power_domain.txt | 51
drivers/base/power/domain.c| 298 +
include/linux/pm_domain.h | 46
kernel/power/Kconfig | 4 +
4 files changed, 399 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
b/Documentation/devicetree/bindings/power/power_domain.txt
new file mode 100644
index 000..93be5d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -0,0 +1,51 @@
+* Generic power domains
+
+System on chip designs are often divided into multiple power domains that
+can be used for power gating of selected IP blocks for power saving by
+reduced leakage current.
+
+This device tree binding can be used to bind power domain consumer devices
+with their power domains provided by power domain providers. A power domain
+provider can be represented by any node in the device tree and can provide
+one or more power domains. A consumer node can refer to the provider by
+a phandle and a set of phandle arguments (so called power domain specifier)
+of length specified by #power-domain-cells property in the power domain
+provider node.
+
+==Power domain providers==
+
+Required properties:
+ - #power-domain-cells : Number of cells in a power domain specifier;
+ Typically 0 for nodes representing a single power domain and 1 for nodes
+ providing multiple power domains (e.g. power controllers), but can be
+ any value as specified by device tree binding documentation of particular
+ provider.
+
+Example:
+
+ power: power-controller@1234 {
+ compatible = "foo,power-controller";
+ reg = <0x1234 0x1000>;
+ #power-domain-cells = <1>;
+ };
+
+The node above defines a power controller that is a power domain provider
+and expects one cell as its phandle argument.
+
+==Power domain consumers==
+
+Required properties:
+ - power-domain : A phandle and power domain specifier as defined by bindings
+ of power controller specified by phandle.
+
+Example:
+
+ leaky-device@1235 {
+ compatible = "foo,i-leak-current";
+ reg = <0x1235 0x1000>;
+ power-domain = <&power 0>;
+ };
+
+The node above defines a typical power domain consumer device, which is located
+inside power domain with index 0 of power controller represented by node with
+label "power".
Does this allow nesting of power domains? E.g. you have a PD which is
represented by some programmable power supply, and within this domain
smaller islands/domains that can be gated independently.
These are client-side bindings only, i.e. power domain providers and
consumers. Registering power domains and relations between them are up
to platform-specific code, e.g. power controller 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 v2 01/11] base: power: Add generic OF-based power domain look-up
On Mon, 2014-03-03 at 05:02PM +0100, Tomasz Figa wrote:
> This patch introduces generic code to perform power domain look-up using
> device tree and automatically bind devices to their power domains.
> Generic device tree binding is introduced to specify power domains of
> devices in their device tree nodes.
>
> Backwards compatibility with legacy Samsung-specific power domain
> bindings is provided, but for now the new code is not compiled when
> CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
> will change as soon as Exynos power domain code gets converted to use
> the generic framework in further patch.
>
> Signed-off-by: Tomasz Figa
> ---
> .../devicetree/bindings/power/power_domain.txt | 51
> drivers/base/power/domain.c| 298
> +
> include/linux/pm_domain.h | 46
> kernel/power/Kconfig | 4 +
> 4 files changed, 399 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
>
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
> b/Documentation/devicetree/bindings/power/power_domain.txt
> new file mode 100644
> index 000..93be5d9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -0,0 +1,51 @@
> +* Generic power domains
> +
> +System on chip designs are often divided into multiple power domains that
> +can be used for power gating of selected IP blocks for power saving by
> +reduced leakage current.
> +
> +This device tree binding can be used to bind power domain consumer devices
> +with their power domains provided by power domain providers. A power domain
> +provider can be represented by any node in the device tree and can provide
> +one or more power domains. A consumer node can refer to the provider by
> +a phandle and a set of phandle arguments (so called power domain specifier)
> +of length specified by #power-domain-cells property in the power domain
> +provider node.
> +
> +==Power domain providers==
> +
> +Required properties:
> + - #power-domain-cells : Number of cells in a power domain specifier;
> + Typically 0 for nodes representing a single power domain and 1 for nodes
> + providing multiple power domains (e.g. power controllers), but can be
> + any value as specified by device tree binding documentation of particular
> + provider.
> +
> +Example:
> +
> + power: power-controller@1234 {
> + compatible = "foo,power-controller";
> + reg = <0x1234 0x1000>;
> + #power-domain-cells = <1>;
> + };
> +
> +The node above defines a power controller that is a power domain provider
> +and expects one cell as its phandle argument.
> +
> +==Power domain consumers==
> +
> +Required properties:
> + - power-domain : A phandle and power domain specifier as defined by bindings
> + of power controller specified by phandle.
> +
> +Example:
> +
> + leaky-device@1235 {
> + compatible = "foo,i-leak-current";
> + reg = <0x1235 0x1000>;
> + power-domain = <&power 0>;
> + };
> +
> +The node above defines a typical power domain consumer device, which is
> located
> +inside power domain with index 0 of power controller represented by node with
> +label "power".
Does this allow nesting of power domains? E.g. you have a PD which is
represented by some programmable power supply, and within this domain
smaller islands/domains that can be gated independently.
Thanks,
Sören
--
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] sxgbe: Add device-tree binding support document
Mark Rutland : > On Tue, Mar 18, 2014 at 04:27:46PM +, Byungho An wrote: > > Mark Rutland : > > > Hi, > > > > > > As a general note it's helpful for devicetree to be Cc'd on the > > > entire > > series > > > (though the binding document should be a separate patch) as it > > > provides > > useful > > > context for reviewing the binding. > > OK. > > > > > > > > On Tue, Mar 18, 2014 at 06:47:13AM +, Byungho An wrote: > > > > From: Siva Reddy > > > > > > > > This patch adds binding document for SXGBE ethernet driver via > > device-tree. > > > > > > > > Signed-off-by: Siva Reddy Kallam > > > > Signed-off-by: Byungho An > > > > --- > > > > .../devicetree/bindings/net/samsung-sxgbe.txt | 53 > > > > > > > > 1 file changed, 53 insertions(+) > > > > create mode 100644 > > > > Documentation/devicetree/bindings/net/samsung-sxgbe.txt > > > > > > > > diff --git > > > > a/Documentation/devicetree/bindings/net/samsung-sxgbe.txt > > > > b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt > > > > new file mode 100644 > > > > index 000..ca27947 > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt > > > > @@ -0,0 +1,53 @@ > > > > +* Samsung 10G Ethernet driver (SXGBE) > > > > + > > > > +Required properties: > > > > +- compatible: Should be "samsung,sxgbe-v2.0a" > > > > +- reg: Address and length of the register set for the device > > > > +- interrupt-parent: Should be the phandle for the interrupt > > > > +controller > > > > + that services interrupts for this device > > > > +- interrupts: Should contain the SXGBE interrupts > > > > + These interrupts are ordered by fixed and follows variable > > > > + trasmit DMA interrupts, receive DMA interrupts and lpi interrupt. > > > > + index 0 - this is fixed common interrupt of SXGBE and it is > > > > +always > > > > + available. > > > > + index 1 to 25 - 8 variable trasmit interrupts, variable 16 > > > > +receive > > > > interrupts > > > > + and 1 optional lpi interrupt. > > > > +- phy-mode: String, operation mode of the PHY interface. > > > > + Supported values are: "xaui", "gmii". > > > > +- samsung,pbl: Integer, Programmable Burst Length. > > > > + Supported values are 1, 2, 4, 8, 16, or 32. > > > > > > There's no need to abbreviate to "pbl". > > > > > > Is this a property of the hardware, or configuration that the kernel > > > will > > program > > > in? If the latter, why can the kernel not choose? > > Yes, this is hardware property > > Ok. > > > > > > > > > > +- samsung,fixed-burst: Boolean, Program the DMA to use the fixed > > > > +burst mode > > > > +- samsung,burst-map: Integer, Program the possible bursts > > > > +supported by sxgbe > > > > + This is an interger and represents allowable DMA bursts when > > > > +fixed > > burst. > > > > + Allowable range is 0x00-0x3F. This field is valid only when > > > > +fixed burst is > > > > + enabled, otherwise ignored. > > > > > > If that's the case, why not have just this property and have it > > > imply the > > use of > > > fixed burst mode? > > OK. It will be implemented in next patch set. > > > > > > > > When is it necessary to use fixed burst mode? > > This is the configurable mode of DMA an used internally by hardware to > > fetch data from platform bus > > Sure, but that doesn't describe when it is necessary. Is this the way the DMA > was configured at integration time, or the way the kernel should configure it? It is needed when fixed length of burst is needed. if it is not configured, the length of burst will be variable(not fixed). Anyway, I'll add description more for it. > > If the latter, is it absolutely necessary for correctness to use fixed-burst mode? > Or is it just always sensible to use it if available? It is not absolutely necessary, as I mentioned above. > > What does the driver do if fixed burst mode is not available? Would this work in > the presence of fixed-burt mode? Fixed burst mode is always available so driver doesn't need to care about it. > > I'm not arguing to remove these properties. I'd just like to understand if all > you're describing is the presence of a feature or that the use of the feature is > absolutely necessary for correctness. OK > > I'm perfectly happy for Linux to always decide to use these features if available. > > > > > > > > > > +- samsung,adv-addr-mode: Boolean, Program the DMA to use Enhanced > > > > +address > > > > mode. > > > > > > When would this be selected, and why can the kernel not choose? > > Kernel doesn't have the provision to find out a way to select this. > > So, need to pass from DT > > Likewise, it is always absolutely necessary, or just always sensible to use > enhanced address mode if present? Not always necessary. When extended address mode is needed, it can be set in the DT. > > > > > > > > > > +- samsung,force_thresh_dma_mode: Boolean, Force DMA to use the > > > > +threshold mode > > > > + for both tx and rx > > > > > > s/_/-/ in property nam
Re: [PATCH v11 17/27] iommu/exynos: remove calls to Runtime PM API functions
On 19.03.2014 19:37, Grant Grundler wrote: On Wed, Mar 19, 2014 at 10:30 AM, Tomasz Figa wrote: ... As I said, AFAIK the trend is to get rid of ordering by initcalls and make sure that drivers can handle missing dependencies properly, even for "services" such as DMA, GPIO, clocks and so on, which after all are provided by normal drivers like other. Ok - I'm not following the general kernel dev trends. initcall() levels are easy to understand and implement. So I would not be in a hurry to replace them. Well, initcall level is still a way to satisfy most of dependencies, i.e. all client devices with higher initcall levels will probe successfully. However the other case needs to be handled as well - in this case the IOMMU binding code needs to defer probe of client driver if respective IOMMU is not yet available. ps. I've written IOMMU support for four different IOMMUs on three operating systems (See drivers/parisc for two linux examples). But I still feel like I at best have 80% understanding of how this one is organized/works. Abstract descriptions and convoluted code have been handicapping me (and lack of time to dig further). Well, this is one of my concerns with this driver. It isn't easy to read (and so review, maintain, extend and debug found issues). My postscript comment was more to explain why I'm not confident in my opinion - not a reason to reject the patch series. I still consider the whole series as a step forward. But I'm not the expert here. I fully agree with you. Other than the issues mentioned in review, the patches are definitely a step forward. I'd even say that all the patches that have nothing to do with device tree could be merged in their current form and the code refined later. It doesn't mean that patches shouldn't be reviewed now and issues spotted reported, even if they could be fixed later - this is for the IOMMU subsystem maintainer to decide. As for patches related to DT support, more care needs to be taken, as bindings should be designed with stability in mind, so the refining process should happen at review stage. Right now, with ~30 patches posted by the exynos iommu (official?) maintainer, no one else who has a clue will attempt to fix or clean up those kinds of problems. i.e. it's useful to enable others to fix what are essentially unspecified "design pattern" issues. Agreed. 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 v11 17/27] iommu/exynos: remove calls to Runtime PM API functions
On Wed, Mar 19, 2014 at 10:30 AM, Tomasz Figa wrote: ... > As I said, AFAIK the trend is to get rid of ordering by initcalls and make > sure that drivers can handle missing dependencies properly, even for > "services" such as DMA, GPIO, clocks and so on, which after all are provided > by normal drivers like other. Ok - I'm not following the general kernel dev trends. initcall() levels are easy to understand and implement. So I would not be in a hurry to replace them. >> ps. I've written IOMMU support for four different IOMMUs on three >> operating systems (See drivers/parisc for two linux examples). But I >> still feel like I at best have 80% understanding of how this one is >> organized/works. Abstract descriptions and convoluted code have been >> handicapping me (and lack of time to dig further). > > > Well, this is one of my concerns with this driver. It isn't easy to read > (and so review, maintain, extend and debug found issues). My postscript comment was more to explain why I'm not confident in my opinion - not a reason to reject the patch series. I still consider the whole series as a step forward. But I'm not the expert here. Right now, with ~30 patches posted by the exynos iommu (official?) maintainer, no one else who has a clue will attempt to fix or clean up those kinds of problems. i.e. it's useful to enable others to fix what are essentially unspecified "design pattern" issues. cheers, grant -- 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 3/8] net: sxgbe: add TSO support for Samsung sxgbe
Rayagond Kokatanur wrote:
> On Wed, Mar 19, 2014 at 11:02 AM, Byungho An wrote:
[snip]
> >
> > /* save the skb address */
> > tqueue->tx_skbuff[entry] = skb;
> >
> > if (!is_jumbo) {
> > - tx_desc->tdes01 = dma_map_single(priv->device, skb->data,
> > - no_pagedlen,
DMA_TO_DEVICE);
> > - if (dma_mapping_error(priv->device, tx_desc->tdes01))
> > - pr_err("%s: TX dma mapping failed!!\n", __func__);
> > -
> > - priv->hw->desc->prepare_tx_desc(tx_desc, 1, no_pagedlen,
> > - no_pagedlen);
> > + if (likely(skb_is_gso(skb))) {
> > + /* TSO support */
> > + mss = skb_shinfo(skb)->gso_size;
> > +
> > + priv->hw->desc->tx_ctxt_desc_set_mss(ctxt_desc, mss);
>
> No need to issue context descriptor for every TSO packets. Program context
descriptor only if MSS value is value is changed compared
> to previous TSO packet MSS value. By this way we can reduce the one extra
descriptor fetch by device and improve the performance.
OK. This will be applied in the next post.
[snip]
> > @@ -1893,7 +1943,9 @@ struct sxgbe_priv_data *sxgbe_dvr_probe(struct
> > device *device,
> >
> > ndev->netdev_ops = &sxgbe_netdev_ops;
> >
> > - ndev->hw_features = NETIF_F_SG | NETIF_F_RXCSUM;
> > + ndev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM |
NETIF_F_IPV6_CSUM |
> > + NETIF_F_RXCSUM | NETIF_F_TSO | NETIF_F_TSO6 |
> > + NETIF_F_GRO;
>
> Enable TSO only if HW supports, hence we have to check for HW
feature/capability registers here also.
OK. Thanks
>
> > ndev->features |= ndev->hw_features | NETIF_F_HIGHDMA;
> > ndev->watchdog_timeo = msecs_to_jiffies(TX_TIMEO);
> >
> > @@ -1905,6 +1957,13 @@ struct sxgbe_priv_data *sxgbe_dvr_probe(struct
device *device,
> > if (flow_ctrl)
> > priv->flow_ctrl = SXGBE_FLOW_AUTO; /* RX/TX pause on
*/
> >
> > + /* Enable TCP segmentation offload for all DMA channels */
> > + if (priv->hw_cap.tcpseg_offload) {
> > + SXGBE_FOR_EACH_QUEUE(SXGBE_TX_QUEUES, queue_num) {
> > + priv->hw->dma->enable_tso(priv->ioaddr,
queue_num);
> > + }
> > + }
> > +
> > /* Rx Watchdog is available, enable depend on platform data */
> > if (!priv->plat->riwt_off) {
> > priv->use_riwt = 1;
> > --
> > 1.7.10.4
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majord...@vger.kernel.org More majordomo info
> > at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in the
body of a message to majord...@vger.kernel.org More
> majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 v11 17/27] iommu/exynos: remove calls to Runtime PM API functions
Hi Grant, On 19.03.2014 18:03, Grant Grundler wrote: On Wed, Mar 19, 2014 at 6:12 AM, Tomasz Figa wrote: ... No. Proper Linux drivers must support deferred probing mechanism and there should be no assumptions about probing orders. Using other initcall level than module_initcall for particular drivers is strongly discouraged. That's true for "end-point" devices. It's not true for "infrastructure": Memory, CPU, DMA, Interrupt handling, etc. Those need to be in place before "normal" drivers get called. This SysMMU driver provides DMA services for "normal" device drivers. Or do I see that wrong? Of course using an early initcall level would give you some kind of guarantees, but it wouldn't guarantee that someone couldn't lower initcall level for some MMU client driver and break the ordering anyway. As I said, AFAIK the trend is to get rid of ordering by initcalls and make sure that drivers can handle missing dependencies properly, even for "services" such as DMA, GPIO, clocks and so on, which after all are provided by normal drivers like other. thanks, grant ps. I've written IOMMU support for four different IOMMUs on three operating systems (See drivers/parisc for two linux examples). But I still feel like I at best have 80% understanding of how this one is organized/works. Abstract descriptions and convoluted code have been handicapping me (and lack of time to dig further). Well, this is one of my concerns with this driver. It isn't easy to read (and so review, maintain, extend and debug found issues). Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/4] drm: exynos: add MDNIE post processor
Hi Ajay,
On 19 March 2014 19:52, Ajay Kumar wrote:
> Add post processor ops for MDNIE and their support functions.
> Expose an interface for the FIMD to register MDNIE PP.
>
> Signed-off-by: Ajay Kumar
> Signed-off-by: Shirish S
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/Makefile| 2 +-
> drivers/gpu/drm/exynos/exynos_mdnie.c | 707
> +
> drivers/gpu/drm/exynos/exynos_mdnie_regs.h | 154 +++
> 3 files changed, 862 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/exynos/exynos_mdnie.c
> create mode 100644 drivers/gpu/drm/exynos/exynos_mdnie_regs.h
>
> diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
> index 02dde22..653eab5 100644
> --- a/drivers/gpu/drm/exynos/Makefile
> +++ b/drivers/gpu/drm/exynos/Makefile
> @@ -10,7 +10,7 @@ exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o \
>
> exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
> exynosdrm-$(CONFIG_DRM_EXYNOS_DMABUF) += exynos_drm_dmabuf.o
> -exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o
> +exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o exynos_mdnie.o
> exynosdrm-$(CONFIG_DRM_EXYNOS_DSI) += exynos_drm_dsi.o
> exynosdrm-$(CONFIG_DRM_EXYNOS_DP) += exynos_dp_core.o exynos_dp_reg.o
> exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o
> diff --git a/drivers/gpu/drm/exynos/exynos_mdnie.c
> b/drivers/gpu/drm/exynos/exynos_mdnie.c
> new file mode 100644
> index 000..a043853
> --- /dev/null
> +++ b/drivers/gpu/drm/exynos/exynos_mdnie.c
> @@ -0,0 +1,707 @@
> +/* drivers/gpu/drm/exynos/exynos_mdnie.c
> + *
> + * Samsung mDNIe driver
> + *
> + * 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 as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> +*/
> +
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +
> +#include "exynos_drm_drv.h"
> +#include "exynos_fimd_pp.h"
> +#include "exynos_mdnie_regs.h"
> +
> +#define GAMMA_RAMP_LENGTH 17
> +#define COLOR_COMPONENTS 3
> +
> +#define MDNIE_ON 1
> +#define MDNIE_OFF 0
> +
> +#define PARAM_IN_RANGE(r, p, l, u) \
> + do {\
> + r = ((p >= l) && (p <= u)) ? 0 : 1; \
> + if (r) \
> + DRM_ERROR("Wrong param: %s:%llu\n", #p, (u64)p); \
> + } while (0)
> +
[snip]
> +static int mdnie_set_color_saturation_params(
> + struct mdnie_context *mdnie,
> + const struct drm_mode_color_saturation *params)
> +{
> + int ret;
> +
> + PARAM_IN_RANGE(ret, params->hue_gain_red, HG_MIN, HG_MAX);
> + PARAM_IN_RANGE(ret, params->hue_gain_green, HG_MIN, HG_MAX);
> + PARAM_IN_RANGE(ret, params->hue_gain_blue, HG_MIN, HG_MAX);
> + PARAM_IN_RANGE(ret, params->hue_gain_cyan, HG_MIN, HG_MAX);
> + PARAM_IN_RANGE(ret, params->hue_gain_magenta, HG_MIN, HG_MAX);
> + PARAM_IN_RANGE(ret, params->hue_gain_yellow, HG_MIN, HG_MAX);
> + PARAM_IN_RANGE(ret, params->hue_gain_overall, HG_MIN, HG_MAX);
> +
> + if (ret)
> + return -EINVAL;
This would be applicable only for the last macro call as ret would get
overwritten after
each call.
> + memcpy(&mdnie->params.cs_params, params, sizeof(*params));
> +
> + return 0;
> +}
> +
> +static int mdnie_set_color_reproduction_params(
> + struct mdnie_context *mdnie,
> + const struct drm_mode_color_reproduction *params)
> +{
> + int ret;
> +
> + PARAM_IN_RANGE(ret, params->red_rgb[0], CC_MIN, CC_MAX);
> + PARAM_IN_RANGE(ret, params->red_rgb[1], CC_MIN, CC_MAX);
> + PARAM_IN_RANGE(ret, params->red_rgb[2], CC_MIN, CC_MAX);
> + PARAM_IN_RANGE(ret, params->green_rgb[0], CC_MIN, CC_MAX);
> + PARAM_IN_RANGE(ret, params->green_rgb[1], CC_MIN, CC_MAX);
> + PARAM_IN_RANGE(ret, params->green_rgb[2], CC_MIN, CC_MAX);
> + PARAM_IN_RANGE(ret, params->blue_rgb[0], CC_MIN, CC_MAX);
> + PARAM_IN_RANGE(ret, params->blue_rgb[1], CC_MIN, CC_MAX);
> + PARAM_IN_RANGE(ret, params->blue_rgb[2], CC_MIN, CC_MAX);
> + PARAM_IN_RANGE(ret, params->cyan_rgb[0], CC_MIN, CC_MAX);
> + PARAM_IN_RANGE(ret, params->cyan_rgb[1], CC_MIN, CC_MAX);
> + PARAM_IN_RANGE(ret, params->cyan_rgb[2], CC_MIN, CC_MAX);
> + PARAM_IN_RANGE(ret, params->magenta_rgb[0], CC_MIN, CC_MAX);
> + PARAM_IN_RANGE(ret, params->magenta_rgb[1], CC_MIN, CC_MAX);
> + PARAM_IN_RANGE(ret, params->magenta_rgb[2], CC_MIN, CC_MAX);
> + PARAM_IN_RANGE(ret, params->yellow_rgb[0], CC_MIN, CC_MAX);
> + PARAM_IN_RANGE(ret, params->yellow_r
Re: [PATCH v11 17/27] iommu/exynos: remove calls to Runtime PM API functions
On Wed, Mar 19, 2014 at 6:12 AM, Tomasz Figa wrote: ... > No. Proper Linux drivers must support deferred probing mechanism and there > should be no assumptions about probing orders. Using other initcall level > than module_initcall for particular drivers is strongly discouraged. That's true for "end-point" devices. It's not true for "infrastructure": Memory, CPU, DMA, Interrupt handling, etc. Those need to be in place before "normal" drivers get called. This SysMMU driver provides DMA services for "normal" device drivers. Or do I see that wrong? thanks, grant ps. I've written IOMMU support for four different IOMMUs on three operating systems (See drivers/parisc for two linux examples). But I still feel like I at best have 80% understanding of how this one is organized/works. Abstract descriptions and convoluted code have been handicapping me (and lack of time to dig further). -- 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 v11 17/27] iommu/exynos: remove calls to Runtime PM API functions
On Wed, Mar 19, 2014 at 6:12 AM, Tomasz Figa wrote: ... >> Device driver is not only for the scholarship but also for the real use. > > Huh? I'm not sure what kind of comment is this. I'm guessing Cho meant: "This isn't an academic exercise - I have a real use case that requires reference counting." Cho needs to be more specific about his "Some driver needs enabling sysmmu" example. Then others would understand why/when the reference counting is needed. Ie walk through a real driver that exists today that depends on reference counting. cheers, grant -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] ARM: EXYNOS: Map PMU address through DT
On 17.03.2014 15:23, Sachin Kamat wrote:
Hi Vikas,
On 17 March 2014 18:39, Vikas Sajjan wrote:
Instead of hardcoding the PMU details for each SoC, pass this information
through device tree (DT).
Signed-off-by: Vikas Sajjan
---
.../devicetree/bindings/arm/samsung/pmu.txt|5 +-
arch/arm/boot/dts/exynos4.dtsi |5 ++
arch/arm/boot/dts/exynos5260.dtsi |5 ++
arch/arm/mach-exynos/common.c | 51 +---
arch/arm/mach-exynos/include/mach/map.h|3 --
5 files changed, 47 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
index f1f1552..667a7f0 100644
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -2,14 +2,15 @@ SAMSUNG Exynos SoC series PMU Registers
Properties:
- compatible : should contain two values. First value must be one from
following list:
+ - "samsung,exynos4210-pmu" - for Exynos4210 and Exynos4x12
SoC,
- "samsung,exynos5250-pmu" - for Exynos5250 SoC,
- - "samsung,exynos5420-pmu" - for Exynos5420 SoC.
+ - "samsung,exynos5420-pmu" - for Exynos5420 and Exynos5260
SoC.
second value must be always "syscon".
- reg : offset and length of the register set.
Example :
pmu_system_controller: system-controller@1004 {
- compatible = "samsung,exynos5250-pmu", "syscon";
+ compatible = "samsung,exynos5250-pmu";
If you have removed "syscon" deliberately above, then you should also
remove the same in the
binding description which says "second value must be always "syscon".".
I believe that "syscon" should be still present as I don't see any code
providing access to PMU registers to other drivers, that could replace
the standard syscon interface, being added by this series.
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 v11 0/4] thermal: samsung: Clean up and add support for Exynos5420
Hi Leela, On 19.03.2014 12:19, Leela Krishna Amudala wrote: Hi All, I didn't see this series in mainline, Any comments for this ? Naveen had posted v12 of this series and I believe all the patches got my Reviewed-by. 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 v11 20/27] iommu/exynos: allow having multiple System MMUs for a master H/W
On 19.03.2014 14:20, Tomasz Figa wrote:
On 19.03.2014 01:39, Cho KyongHo wrote:
On Tue, 18 Mar 2014 15:26:48 +0100, Tomasz Figa wrote:
On 18.03.2014 14:01, Cho KyongHo wrote:
On Fri, 14 Mar 2014 17:12:03 +0100, Tomasz Figa wrote:
Hi KyongHo,
On 14.03.2014 06:10, Cho KyongHo wrote:
Some master device descriptor like fimc-is which is an abstraction
of very complex H/W may have multiple System MMUs. For those devices,
the design of the link between System MMU and its master H/W is
needed
to be reconsidered.
A link structure, sysmmu_list_data is introduced that provides a link
to master H/W and that has a pointer to the device descriptor of a
System MMU. Given a device descriptor of a master H/W, it is possible
to traverse all System MMUs that must be controlled along with the
master H/W.
NAK.
A device driver should handle particular hardware instances
separately,
without abstracting a virtual hardware instance consisting of multiple
physical ones.
If such abstraction is needed, it should be done above the
exynos-iommu
driver, e.g. by something like iommu-composite driver that would
aggregate several IOMMUs. Keep in mind that such IOMMUs in a group
could
be different, e.g. different Exynos SysMMU versions or even completely
different IPs handled by different drivers.
Still, I don't think there is a real need for such abstraction.
Instead,
related drivers shall be fixed to properly handle multiple memory
masters and their IOMMUs.
G2D, Scalers and FIMD of Exynos5420 has 2 System MMUs while aother
SoC like
Exynos5250 does not.
I don't understand why you are negative to this approach.
This is the simplest than the others.
Let me show you an example.
FIMC-IS driver just controls MCU in FIMC-IS subsystem and the
firmware of
the MCU controls all other peripherals in the subsystem. Each
peripherals
have their own System MMU. Moreover, the configuration of the
peripherals
varies according to the SoCs.
If System MMU driver accepts multiple masters, everything is done in
DT.
But I worry that it is not easy if System MMU driver does not support
multiple masters.
I believe I have stated enough reasons why this kind of implementation
is bad. I'm not going to waste time repeating myself.
Your concerns presented above are valid, however they are not related to
what is wrong with this patch. I have given you two proper ways to
handle this, none should be forced upon particular IOMMU master drivers
- their authors should have the chance to select the method that works
best for them.
I don't still understand why you think this patch is wrong.
I think this is the best way not to think for all the driver developers
about other things than their business logic.
I agree, but one of the ways I proposed (an iommu-composite layer above
the IOMMU low level drivers) doesn't add any extra responsibility of
driver developers.
Moreover, it's this kind of business logic in low level drivers that is
adding more responsibility, because it introduces additional complexity
and makes the driver harder to read, maintain and extend in future.
This does not hurt anyone and I think this is good enough.
Well, it is barely good enough. It is a good practice to make a low
level driver handle a single device instance and this is how Linux
driver model is designed.
Moreover, a single device tree node _must_ represent a single hardware
block, so you can't group multiple SysMMUs into a single device tree node.
OK, you add nodes for single SysMMUs devices which is fine, sorry. I was
under impression that one kernel device (struct device) corresponds to
multiple SysMMUs, but this was before your patches, sorry. So one issue
less, but it's still not good.
Furthermore, if you force grouping of SysMMUs into a single virtual one,
you enforce using the same address space for all masters of some
particular hardware blocks, while potentially driver developers would
like to separate them.
Probably some clarification is needed. Your other patch adds:
sysmmu_fimd0w04: sysmmu@1464 {
compatible = "samsung,sysmmu-v3.3";
reg = <0x1464 0x1000>;
interrupt-parent = <&combiner>;
interrupts = <3 2>;
clock-names = "sysmmu", "master";
clocks = <&clock 422>, <&clock 421>;
samsung,power-domain = <&disp_pd>;
mmu-masters = <&fimd>;
};
sysmmu_fimd0w123: sysmmu@1468 {
compatible = "samsung,sysmmu-v3.3";
reg = <0x1468 0x1000>;
interrupt-parent = <&combiner>;
interrupts = <3 0>;
clock-names = "sysmmu", "master";
clocks = <&clock 423>, <&clock 421>;
samsung,power-domain = <&disp_pd>;
mmu-masters = <&fimd>;
};
From such description, in future FIMD driver won't be able to determine
which SysMMU is used for windows 0 and 4 and which for wind
Re: [PATCH V4 1/8] sxgbe: Add device-tree binding support document
On Tue, Mar 18, 2014 at 04:27:46PM +, Byungho An wrote: > Mark Rutland : > > Hi, > > > > As a general note it's helpful for devicetree to be Cc'd on the entire > series > > (though the binding document should be a separate patch) as it provides > useful > > context for reviewing the binding. > OK. > > > > > On Tue, Mar 18, 2014 at 06:47:13AM +, Byungho An wrote: > > > From: Siva Reddy > > > > > > This patch adds binding document for SXGBE ethernet driver via > device-tree. > > > > > > Signed-off-by: Siva Reddy Kallam > > > Signed-off-by: Byungho An > > > --- > > > .../devicetree/bindings/net/samsung-sxgbe.txt | 53 > > > > > > 1 file changed, 53 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/net/samsung-sxgbe.txt > > > > > > diff --git a/Documentation/devicetree/bindings/net/samsung-sxgbe.txt > > > b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt > > > new file mode 100644 > > > index 000..ca27947 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt > > > @@ -0,0 +1,53 @@ > > > +* Samsung 10G Ethernet driver (SXGBE) > > > + > > > +Required properties: > > > +- compatible: Should be "samsung,sxgbe-v2.0a" > > > +- reg: Address and length of the register set for the device > > > +- interrupt-parent: Should be the phandle for the interrupt > > > +controller > > > + that services interrupts for this device > > > +- interrupts: Should contain the SXGBE interrupts > > > + These interrupts are ordered by fixed and follows variable > > > + trasmit DMA interrupts, receive DMA interrupts and lpi interrupt. > > > + index 0 - this is fixed common interrupt of SXGBE and it is always > > > + available. > > > + index 1 to 25 - 8 variable trasmit interrupts, variable 16 receive > > > interrupts > > > + and 1 optional lpi interrupt. > > > +- phy-mode: String, operation mode of the PHY interface. > > > + Supported values are: "xaui", "gmii". > > > +- samsung,pbl: Integer, Programmable Burst Length. > > > + Supported values are 1, 2, 4, 8, 16, or 32. > > > > There's no need to abbreviate to "pbl". > > > > Is this a property of the hardware, or configuration that the kernel will > program > > in? If the latter, why can the kernel not choose? > Yes, this is hardware property Ok. > > > > > > +- samsung,fixed-burst: Boolean, Program the DMA to use the fixed > > > +burst mode > > > +- samsung,burst-map: Integer, Program the possible bursts supported > > > +by sxgbe > > > + This is an interger and represents allowable DMA bursts when fixed > burst. > > > + Allowable range is 0x00-0x3F. This field is valid only when fixed > > > +burst is > > > + enabled, otherwise ignored. > > > > If that's the case, why not have just this property and have it imply the > use of > > fixed burst mode? > OK. It will be implemented in next patch set. > > > > > When is it necessary to use fixed burst mode? > This is the configurable mode of DMA an used internally by hardware to fetch > data from platform bus Sure, but that doesn't describe when it is necessary. Is this the way the DMA was configured at integration time, or the way the kernel should configure it? If the latter, is it absolutely necessary for correctness to use fixed-burst mode? Or is it just always sensible to use it if available? What does the driver do if fixed burst mode is not available? Would this work in the presence of fixed-burt mode? I'm not arguing to remove these properties. I'd just like to understand if all you're describing is the presence of a feature or that the use of the feature is absolutely necessary for correctness. I'm perfectly happy for Linux to always decide to use these features if available. > > > > > > +- samsung,adv-addr-mode: Boolean, Program the DMA to use Enhanced > > > +address > > > mode. > > > > When would this be selected, and why can the kernel not choose? > Kernel doesn't have the provision to find out a way to select this. So, need > to pass from DT Likewise, it is always absolutely necessary, or just always sensible to use enhanced address mode if present? > > > > > > +- samsung,force_thresh_dma_mode: Boolean, Force DMA to use the > > > +threshold mode > > > + for both tx and rx > > > > s/_/-/ in property names. > OK. > > > > > Likewise, why can the kernel not choose. > SXGBE h/w registers can't provide information to select this. So, need to pass > from DT depend on Platform Similarly. > > > > > > +- samsung,force_sf_dma_mode: Boolean, Force DMA to use the Store and > > > +Forward > > > + mode for both tx and rx. This flag is ignored if > > > +force_thresh_dma_mode is > > > set. > > > > Likewise for both points. > Same above. And again. Cheers, 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 v3 2/3] mfd: sec-core: Add of_compatible strings for clock MFD cells
> > > Add of_compatible strings for S5M8767 and S2MPS14 clock MFD cells. > > > > > > Signed-off-by: Krzysztof Kozlowski > > > --- > > > drivers/mfd/sec-core.c |3 +++ > > > 1 file changed, 3 insertions(+) > > > > Applied with Tomasz' Reviewed-by. > > Thanks! One minor thing - I see that Tomasz' Review-by got lost when the > patch was applied to your tree: > https://git.kernel.org/cgit/linux/kernel/git/lee/mfd.git/commit/?h=for-mfd-next&id=09f8c0a07044bb8ac5085fcbcf82468173a1666d. Thanks for the prod, but I do have it applied locally. I'll push the branch later today. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | 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
[RFC 3/4] drm: exynos: add IELCD post processor
Add post processor ops for IELCD and their support functions.
Expose an interface for the FIMD to register IELCD PP.
Signed-off-by: Ajay Kumar
Signed-off-by: Shirish S
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/Makefile | 3 +-
drivers/gpu/drm/exynos/exynos_ielcd.c | 295 ++
include/video/samsung_fimd.h | 43 +
3 files changed, 340 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/exynos/exynos_ielcd.c
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 653eab5..f3d7314 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -10,7 +10,8 @@ exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o \
exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
exynosdrm-$(CONFIG_DRM_EXYNOS_DMABUF) += exynos_drm_dmabuf.o
-exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o exynos_mdnie.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o exynos_mdnie.o \
+ exynos_ielcd.o
exynosdrm-$(CONFIG_DRM_EXYNOS_DSI) += exynos_drm_dsi.o
exynosdrm-$(CONFIG_DRM_EXYNOS_DP) += exynos_dp_core.o exynos_dp_reg.o
exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o
diff --git a/drivers/gpu/drm/exynos/exynos_ielcd.c
b/drivers/gpu/drm/exynos/exynos_ielcd.c
new file mode 100644
index 000..33d0d34
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_ielcd.c
@@ -0,0 +1,295 @@
+/* drivers/gpu/drm/exynos/exynos_ielcd.c
+ *
+ * Samsung IELCD driver
+ *
+ * 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 as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+*/
+
+#include
+#include
+#include
+
+#include
+
+#include
+
+#include "exynos_drm_drv.h"
+#include "exynos_fimd_pp.h"
+
+#define exynos_ielcd_readl(addr) readl(ielcd->exynos_ielcd_base + addr)
+#define exynos_ielcd_writel(addr, val) \
+ writel(val, ielcd->exynos_ielcd_base + addr)
+#define IELCD_TIMEOUT_CNT 1000
+
+struct ielcd_context {
+ void __iomem*exynos_ielcd_base;
+ unsignedvdisplay;
+ unsignedvsync_len;
+ unsignedvbpd;
+ unsignedvfpd;
+ unsignedhdisplay;
+ unsignedhsync_len;
+ unsignedhbpd;
+ unsignedhfpd;
+ unsignedvidcon0;
+ unsignedvidcon1;
+};
+
+static int ielcd_logic_start(struct ielcd_context *ielcd)
+{
+ exynos_ielcd_writel(IELCD_AUXCON, IELCD_MAGIC_KEY);
+
+ return 0;
+}
+
+static void ielcd_set_polarity(struct ielcd_context *ielcd)
+{
+ unsigned int cfg;
+
+ cfg = exynos_ielcd_readl(IELCD_VIDCON1);
+
+ cfg &= ~(VIDCON1_INV_VCLK | VIDCON1_INV_HSYNC
+ | VIDCON1_INV_VSYNC | VIDCON1_INV_VDEN);
+ cfg |= ielcd->vidcon1;
+ exynos_ielcd_writel(IELCD_VIDCON1, cfg);
+}
+
+static void ielcd_set_timing(struct ielcd_context *ielcd)
+{
+ unsigned int cfg;
+
+ /*LCD verical porch setting*/
+ cfg = VIDTCON0_VBPD(ielcd->vbpd - 1) |
+ VIDTCON0_VFPD(ielcd->vfpd - 1) |
+ VIDTCON0_VSPW(ielcd->vsync_len - 1);
+
+ exynos_ielcd_writel(IELCD_VIDTCON0, cfg);
+ /*LCD horizontal porch setting*/
+ cfg = VIDTCON1_HBPD(ielcd->hbpd - 1) |
+ VIDTCON1_HFPD(ielcd->hfpd - 1) |
+ VIDTCON1_HSPW(ielcd->hsync_len - 1);
+
+ exynos_ielcd_writel(IELCD_VIDTCON1, cfg);
+}
+
+static void ielcd_set_lcd_size(struct ielcd_context *ielcd)
+{
+ unsigned int cfg;
+
+ cfg = (IELCD_VIDTCON2_LINEVAL(ielcd->vdisplay - 1) |
+ IELCD_VIDTCON2_HOZVAL(ielcd->hdisplay - 1));
+ exynos_ielcd_writel(IELCD_VIDTCON2, cfg);
+
+ /* window0 position setting */
+ exynos_ielcd_writel(IELCD_VIDOSD0A, 0);
+ cfg = (IELCD_VIDOSDB_XPOS_END(ielcd->hdisplay - 1)) |
+ (IELCD_VIDOSDB_YPOS_END(ielcd->vdisplay - 1));
+ exynos_ielcd_writel(IELCD_VIDOSD0B, cfg);
+
+ /* window0 osd size setting */
+ exynos_ielcd_writel(IELCD_VIDOSD0C, ielcd->hdisplay *
+ ielcd->vdisplay);
+
+ /* window0 page size(bytes) */
+ exynos_ielcd_writel(IELCD_VIDW00ADD2, ielcd->hdisplay * 4);
+}
+
+static int exynos_ielcd_hw_trigger_check(struct ielcd_context *ielcd)
+{
+ unsigned int cfg;
+ unsigned int count = 0;
+
+ cfg = exynos_ielcd_readl(IELCD_TRIGCON);
+ cfg &= ~(SWTRGCMD_W0BUF | TRGMODE_W0BUF);
+ cfg |= (SWTRGCMD_W0BUF | TRGMODE_W0BUF);
+ exynos_ielcd_writel(IELCD_TRIG
[RFC 2/4] drm: exynos: add MDNIE post processor
Add post processor ops for MDNIE and their support functions.
Expose an interface for the FIMD to register MDNIE PP.
Signed-off-by: Ajay Kumar
Signed-off-by: Shirish S
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/Makefile| 2 +-
drivers/gpu/drm/exynos/exynos_mdnie.c | 707 +
drivers/gpu/drm/exynos/exynos_mdnie_regs.h | 154 +++
3 files changed, 862 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/exynos/exynos_mdnie.c
create mode 100644 drivers/gpu/drm/exynos/exynos_mdnie_regs.h
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 02dde22..653eab5 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -10,7 +10,7 @@ exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o \
exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
exynosdrm-$(CONFIG_DRM_EXYNOS_DMABUF) += exynos_drm_dmabuf.o
-exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o exynos_mdnie.o
exynosdrm-$(CONFIG_DRM_EXYNOS_DSI) += exynos_drm_dsi.o
exynosdrm-$(CONFIG_DRM_EXYNOS_DP) += exynos_dp_core.o exynos_dp_reg.o
exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o
diff --git a/drivers/gpu/drm/exynos/exynos_mdnie.c
b/drivers/gpu/drm/exynos/exynos_mdnie.c
new file mode 100644
index 000..a043853
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_mdnie.c
@@ -0,0 +1,707 @@
+/* drivers/gpu/drm/exynos/exynos_mdnie.c
+ *
+ * Samsung mDNIe driver
+ *
+ * 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 as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+*/
+
+#include
+#include
+#include
+
+#include
+
+#include
+
+#include "exynos_drm_drv.h"
+#include "exynos_fimd_pp.h"
+#include "exynos_mdnie_regs.h"
+
+#define GAMMA_RAMP_LENGTH 17
+#define COLOR_COMPONENTS 3
+
+#define MDNIE_ON 1
+#define MDNIE_OFF 0
+
+#define PARAM_IN_RANGE(r, p, l, u) \
+ do {\
+ r = ((p >= l) && (p <= u)) ? 0 : 1; \
+ if (r) \
+ DRM_ERROR("Wrong param: %s:%llu\n", #p, (u64)p); \
+ } while (0)
+
+struct exynos_mdnie_drm_gamma {
+ u8 gamma_r[GAMMA_RAMP_LENGTH];
+ u8 gamma_g[GAMMA_RAMP_LENGTH];
+ u8 gamma_b[GAMMA_RAMP_LENGTH];
+};
+
+struct mdnie_conf_params {
+ u32 modules_enabled;
+ struct exynos_mdnie_drm_gamma gamma_params;
+ struct drm_exynos_mdnie_window win;
+ struct drm_mode_color_reproduction cr_params;
+ struct drm_mode_color_saturationcs_params;
+ struct drm_mode_edge_enhancementde_params;
+};
+
+struct mdnie_context {
+ struct mdnie_conf_paramsparams;
+ struct clk *mdnie_mux_clk;
+ struct clk *mdnie_bus_clk;
+ struct clk *mdnie_src_clk;
+ struct clk *sclk_mout_fimd;
+ void __iomem*exynos_mdnie_base;
+ void __iomem*sysreg_disp1blk;
+ struct drm_display_mode mode;
+};
+
+static void exynos_mdnie_unmask(struct mdnie_context *mdnie)
+{
+ writel(!MDNIE_RELEASE_RFF_MASK_REGISTERS,
+ mdnie->exynos_mdnie_base +
+ MDNIE_RELEASE_RFF * sizeof(u32));
+}
+
+static u32 mdnie_read(struct mdnie_context *mdnie, u32 reg)
+{
+ return readl(mdnie->exynos_mdnie_base + reg * sizeof(u32)) &
+ MDNIE_REG_WIDTH;
+}
+
+static void mdnie_write(struct mdnie_context *mdnie, u32 reg, u32 val)
+{
+ writel(val & MDNIE_REG_WIDTH, mdnie->exynos_mdnie_base +
+ (reg & MDNIE_REG_OFFSET_LIMIT) * sizeof(u32));
+
+ exynos_mdnie_unmask(mdnie);
+}
+
+static void exynos_mdnie_bank_sel(struct mdnie_context *mdnie, int bank)
+{
+ if (bank)
+ writel(MDNIE_TOP_R0_BANK1_SEL |
+ MDNIE_TOP_R0_SHADOW_SEL ,
+ mdnie->exynos_mdnie_base);
+ else
+ writel(MDNIE_TOP_R0_BANK0_SEL |
+ MDNIE_TOP_R0_SHADOW_SEL ,
+ mdnie->exynos_mdnie_base);
+
+ exynos_mdnie_unmask(mdnie);
+}
+
+static int exynos_mdnie_set_size(struct mdnie_context *mdnie)
+{
+ unsigned int cfg;
+
+ if ((mdnie->mode.crtc_hdisplay > MDNIE_TOP_RSIZE_MAX) ||
+ (mdnie->mode.crtc_vdisplay > MDNIE_TOP_RSIZE_MAX))
+ return -EINVAL;
+
+ exynos_mdnie_bank_sel(mdnie
[RFC 4/4] drm: exynos: add MDNIE and IELCD to FIMD pp list
This patch adds code to add MDNIE and IELCD onto the
list of FIMD PP.
Signed-off-by: Ajay Kumar
Signed-off-by: Shirish S
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 +
drivers/gpu/drm/exynos/exynos_fimd_pp.h | 2 ++
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index a584d8e..d5a32fb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -160,8 +160,25 @@ static int fimd_mgr_initialize(struct exynos_drm_manager
*mgr,
{
struct fimd_context *ctx = mgr->ctx;
struct exynos_drm_private *priv;
+ struct exynos_fimd_pp *mdnie_pp = NULL, *ielcd_pp = NULL;
+ int ret;
+
priv = drm_dev->dev_private;
+ ret = exynos_mdnie_init(ctx->dev, &mdnie_pp);
+ if (!ret && mdnie_pp) {
+ ret = exynos_ielcd_init(ctx->dev, &ielcd_pp);
+ if (!ret && ielcd_pp) {
+ fimd_add_pp_to_list(ctx, mdnie_pp);
+ fimd_add_pp_to_list(ctx, ielcd_pp);
+ ctx->enable_pp = true;
+ ctx->pp_running = false;
+ } else {
+ DRM_INFO("No ielcd node present, "
+ "MDNIE feature will be disabled\n");
+ }
+ }
+
mgr->drm_dev = ctx->drm_dev = drm_dev;
mgr->pipe = ctx->pipe = priv->pipe++;
diff --git a/drivers/gpu/drm/exynos/exynos_fimd_pp.h
b/drivers/gpu/drm/exynos/exynos_fimd_pp.h
index 528d3cb..b980742 100644
--- a/drivers/gpu/drm/exynos/exynos_fimd_pp.h
+++ b/drivers/gpu/drm/exynos/exynos_fimd_pp.h
@@ -49,4 +49,6 @@ struct exynos_fimd_pp {
void *ctx;
};
+extern int exynos_mdnie_init(struct device *dev, struct exynos_fimd_pp **pp);
+extern int exynos_ielcd_init(struct device *dev, struct exynos_fimd_pp **pp);
#endif
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/4] drm: exynos: Add drivers for MDNIE and IELCD
This series is based on exynos-drm-next-todo branch of Inki Dae's tree at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git On Exynos SOC, FIMD supports various post processors like MIE, MDNIE and IELCD for image enhancement purposes. This patchset adds an infrastructure in exynos FIMD to support such post procerssors and also adds support routines for MDNIE, and IELCD. (1) For basic display output, -- MDNIE and IELCD should have same video timings as FIMD (mode_set) -- strict power_up/down sequence need to be followed between FIMD, MDNIE, and IELCD (power_on, power_off) (2) For enhanced display output, -- MDNIE needs image enhancement data from userspace (set_property and set_gamma) Rahul Sharma's patchset at: http://comments.gmane.org/gmane.linux.kernel.samsung-soc/27642 The above patchset is needed to support the enhanced display output. MDNIE and IELCD DT nodes are given as phandles to FIMD DT node. SOC specific information like base address, clocks and other configuration information are extracted via FIMD DT node. Ajay Kumar, Shirish, Rahul Sharma (4): drm: exynos: Add infrastructure to support FIMD post processors drm: exynos: add MDNIE post processor drm: exynos: add IELCD post processor drm: exynos: add MDNIE and IELCD to FIMD pp list drivers/gpu/drm/exynos/Makefile| 3 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 179 drivers/gpu/drm/exynos/exynos_fimd_pp.h| 54 +++ drivers/gpu/drm/exynos/exynos_ielcd.c | 295 drivers/gpu/drm/exynos/exynos_mdnie.c | 707 + drivers/gpu/drm/exynos/exynos_mdnie_regs.h | 154 +++ include/video/samsung_fimd.h | 49 +- 7 files changed, 1439 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/exynos/exynos_fimd_pp.h create mode 100644 drivers/gpu/drm/exynos/exynos_ielcd.c create mode 100644 drivers/gpu/drm/exynos/exynos_mdnie.c create mode 100644 drivers/gpu/drm/exynos/exynos_mdnie_regs.h -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/4] drm: exynos: Add infrastructure to support FIMD post processors
Exynos variants support post pocessors(PP) for FIMD (MDNIE and IELCD)
which work closely with fimd. These post processors have strict
dependency on FIMD for poweron/poweroff. This patch adds an
infrastructure in FIMD driver to accomodate such devices.
Added structure definition for FIMD PP and interfaces from FIMD
driver to control FIMD PP.
Signed-off-by: Ajay Kumar
Signed-off-by: Shirish S
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 162 +++
drivers/gpu/drm/exynos/exynos_fimd_pp.h | 52 ++
include/video/samsung_fimd.h | 6 +-
3 files changed, 219 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/exynos/exynos_fimd_pp.h
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index a5511be..a584d8e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -30,6 +30,7 @@
#include "exynos_drm_fbdev.h"
#include "exynos_drm_crtc.h"
#include "exynos_drm_iommu.h"
+#include "exynos_fimd_pp.h"
/*
* FIMD stands for Fully Interactive Mobile Display and
@@ -113,11 +114,14 @@ struct fimd_context {
void __iomem*regs;
struct drm_display_mode mode;
struct fimd_win_datawin_data[WINDOWS_NR];
+ struct list_headfimd_pp_list;
unsigned intdefault_win;
unsigned long irq_flags;
u32 vidcon0;
u32 vidcon1;
boolsuspended;
+ boolenable_pp;
+ boolpp_running;
int pipe;
wait_queue_head_t wait_vsync_queue;
atomic_twait_vsync_event;
@@ -145,6 +149,12 @@ static inline struct fimd_driver_data
*drm_fimd_get_driver_data(
return (struct fimd_driver_data *)of_id->data;
}
+void fimd_add_pp_to_list(struct fimd_context *ctx,
+ struct exynos_fimd_pp *pp)
+{
+ list_add_tail(&pp->list, &ctx->fimd_pp_list);
+}
+
static int fimd_mgr_initialize(struct exynos_drm_manager *mgr,
struct drm_device *drm_dev)
{
@@ -214,17 +224,49 @@ static void fimd_mode_set(struct exynos_drm_manager *mgr,
const struct drm_display_mode *in_mode)
{
struct fimd_context *ctx = mgr->ctx;
+ struct exynos_fimd_pp *pp_display;
drm_mode_copy(&ctx->mode, in_mode);
+
+ /* mode_set for the post processors*/
+ list_for_each_entry(pp_display, &ctx->fimd_pp_list, list)
+ if (pp_display->ops->mode_set)
+ pp_display->ops->mode_set(pp_display->ctx, in_mode);
+}
+
+static int fimd_wait_till_per_frame_off(struct fimd_context *ctx)
+{
+ unsigned int val = readl(ctx->regs + VIDCON0);
+ int count = 10;
+
+ val &= ~(VIDCON0_ENVID_F);
+ writel(val, ctx->regs + VIDCON0);
+
+ while (count) {
+ val = readl(ctx->regs + VIDCON0);
+ if ((val & VIDCON0_ENVID_F) == 0)
+ break;
+ mdelay(17);
+ count--;
+ }
+
+ if (count == 0) {
+ DRM_ERROR("FIMD per frame switch off TIMEDOUT\n");
+ return -ETIMEDOUT;
+ }
+
+ return 0;
}
static void fimd_commit(struct exynos_drm_manager *mgr)
{
struct fimd_context *ctx = mgr->ctx;
struct drm_display_mode *mode = &ctx->mode;
+ struct exynos_fimd_pp *pp_display;
struct fimd_driver_data *driver_data;
u32 val, clkdiv, vidcon1;
int hblank, vblank, vsync_len, vbpd, vfpd, hsync_len, hbpd, hfpd;
+ int ret = 0;
driver_data = ctx->driver_data;
if (ctx->suspended)
@@ -234,6 +276,30 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
if (mode->htotal == 0 || mode->vtotal == 0)
return;
+ /* The FIMD and the post processor(PP) poweroff calls below are needed
+* here to make sure that fimd_commit doesn't switch on the PPs twice
+* in a row. For proper working we need to keep fimd, and the PPs
+* off, before we start again. This flag "pp_running" will also help
+* in syncing any of the clock enable/disable calls in PP routines.
+*/
+ if (ctx->enable_pp && ctx->pp_running) {
+ if (fimd_wait_till_per_frame_off(ctx))
+ DRM_ERROR("failed to switch off fimd per frame\n");
+ list_for_each_entry_reverse(pp_display, &ctx->fimd_pp_list,
+ list) {
+ if (pp_display->ops->power_off) {
+ ret = pp_display->ops->
+ power_off(pp_disp
Re: [PATCH 0/4] Consolidate Exynos machine code
On Wednesday 19 March 2014, Sachin Kamat wrote: > This patch series consolidates the Exynos machine code and common > code into a single file to avoid code duplication and introduces > generic compatible strings for Exynos4 and 5 SoC series. > > Complete discussion and motivation for this series is found here: > http://comments.gmane.org/gmane.linux.kernel.samsung-soc/27268 > > This series is based on the latest linux-next and depends on > 1. Tomasz Figa's PM consolidation series 1 and 2 > 2. Patch: ARM: SAMSUNG: Reorganize calls to reserve memory for MFC > http://www.spinics.net/lists/linux-samsung-soc/msg25501.html > 3. Patch: ARM: EXYNOS: Add support to reserve memory for MFC-v7 > http://www.spinics.net/lists/arm-kernel/msg315940.html > 4. Kconfig and CPU init Consolidation series > http://article.gmane.org/gmane.linux.kernel.samsung-soc/28216 Acked-by: Arnd Bergmann -- 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 0/3] regulator: s2mps11: Add support for S2MPS14 regulators
On Fri, Mar 07, 2014 at 11:10:49AM +0100, Krzysztof Kozlowski wrote: > Hi, > > This patchset adds support for the S2MPS14 device to the s2mps11 regulator > driver. It's a subset of previously sent patches for S2MPS14 device: > http://thread.gmane.org/gmane.linux.kernel.samsung-soc/27194/focus=1649217 > along with one new patch: Applied all, thanks. signature.asc Description: Digital signature
Re: [PATCH v11 20/27] iommu/exynos: allow having multiple System MMUs for a master H/W
On 19.03.2014 01:39, Cho KyongHo wrote: On Tue, 18 Mar 2014 15:26:48 +0100, Tomasz Figa wrote: On 18.03.2014 14:01, Cho KyongHo wrote: On Fri, 14 Mar 2014 17:12:03 +0100, Tomasz Figa wrote: Hi KyongHo, On 14.03.2014 06:10, Cho KyongHo wrote: Some master device descriptor like fimc-is which is an abstraction of very complex H/W may have multiple System MMUs. For those devices, the design of the link between System MMU and its master H/W is needed to be reconsidered. A link structure, sysmmu_list_data is introduced that provides a link to master H/W and that has a pointer to the device descriptor of a System MMU. Given a device descriptor of a master H/W, it is possible to traverse all System MMUs that must be controlled along with the master H/W. NAK. A device driver should handle particular hardware instances separately, without abstracting a virtual hardware instance consisting of multiple physical ones. If such abstraction is needed, it should be done above the exynos-iommu driver, e.g. by something like iommu-composite driver that would aggregate several IOMMUs. Keep in mind that such IOMMUs in a group could be different, e.g. different Exynos SysMMU versions or even completely different IPs handled by different drivers. Still, I don't think there is a real need for such abstraction. Instead, related drivers shall be fixed to properly handle multiple memory masters and their IOMMUs. G2D, Scalers and FIMD of Exynos5420 has 2 System MMUs while aother SoC like Exynos5250 does not. I don't understand why you are negative to this approach. This is the simplest than the others. Let me show you an example. FIMC-IS driver just controls MCU in FIMC-IS subsystem and the firmware of the MCU controls all other peripherals in the subsystem. Each peripherals have their own System MMU. Moreover, the configuration of the peripherals varies according to the SoCs. If System MMU driver accepts multiple masters, everything is done in DT. But I worry that it is not easy if System MMU driver does not support multiple masters. I believe I have stated enough reasons why this kind of implementation is bad. I'm not going to waste time repeating myself. Your concerns presented above are valid, however they are not related to what is wrong with this patch. I have given you two proper ways to handle this, none should be forced upon particular IOMMU master drivers - their authors should have the chance to select the method that works best for them. I don't still understand why you think this patch is wrong. I think this is the best way not to think for all the driver developers about other things than their business logic. I agree, but one of the ways I proposed (an iommu-composite layer above the IOMMU low level drivers) doesn't add any extra responsibility of driver developers. Moreover, it's this kind of business logic in low level drivers that is adding more responsibility, because it introduces additional complexity and makes the driver harder to read, maintain and extend in future. This does not hurt anyone and I think this is good enough. Well, it is barely good enough. It is a good practice to make a low level driver handle a single device instance and this is how Linux driver model is designed. Moreover, a single device tree node _must_ represent a single hardware block, so you can't group multiple SysMMUs into a single device tree node. Furthermore, if you force grouping of SysMMUs into a single virtual one, you enforce using the same address space for all masters of some particular hardware blocks, while potentially driver developers would like to separate them. A good interface design should not enforce any particular implementation and this is what we should stick to in this case as well. If you want to provide another layer between master device and system mmu as you mentioned, you do that. This patch does not restrict it. It does, as mentioned above. With a device tree listing multiple SysMMUs as one, you can't separate them. 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 v3 2/3] mfd: sec-core: Add of_compatible strings for clock MFD cells
On Tue, 2014-03-18 at 20:31 +, Lee Jones wrote: > > Add of_compatible strings for S5M8767 and S2MPS14 clock MFD cells. > > > > Signed-off-by: Krzysztof Kozlowski > > --- > > drivers/mfd/sec-core.c |3 +++ > > 1 file changed, 3 insertions(+) > > Applied with Tomasz' Reviewed-by. Thanks! One minor thing - I see that Tomasz' Review-by got lost when the patch was applied to your tree: https://git.kernel.org/cgit/linux/kernel/git/lee/mfd.git/commit/?h=for-mfd-next&id=09f8c0a07044bb8ac5085fcbcf82468173a1666d. Best regards, Krzysztof -- 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 v11 17/27] iommu/exynos: remove calls to Runtime PM API functions
On 19.03.2014 02:03, Cho KyongHo wrote:
On Tue, 18 Mar 2014 16:09:50 +0100, Tomasz Figa wrote:
On 18.03.2014 10:56, Cho KyongHo wrote:
On Fri, 14 Mar 2014 13:59:00 +0100, Tomasz Figa wrote:
Hi KyongHo,
On 14.03.2014 06:08, Cho KyongHo wrote:
[snip]
@@ -637,11 +708,14 @@ static void exynos_iommu_domain_destroy(struct
iommu_domain *domain)
spin_lock_irqsave(&priv->lock, flags);
- list_for_each_entry(data, &priv->clients, node) {
- while (!exynos_sysmmu_disable(data->dev))
+ list_for_each_entry(owner, &priv->clients, client) {
+ while (!exynos_sysmmu_disable(owner->dev))
; /* until System MMU is actually disabled */
What about using list_for_each_entry_safe() and calling list_del_init()
here directly?
That require another variable to be defined.
Is it a problem?
That is not a problem.
But I think using list_for_each_entry() is not a problem likewise.
I just wanted to avoid that because I think it is prettier.
Moreover, list_del_init() below the empty while() clause may make
the source code readers misunderstood..
This raises another question, why the loop above is even needed.
exynos_sysmmu_disable() should make sure that SYSMMU is actually
disabled, without any need for looping like this.
Some driver needs enabling sysmmu to be counted due to its complex structure.
It can be also removed by the driver with an extra effort
but the reality is important.
My comment was not about the need to have reference counting, as this is
a common design pattern, but rather that there should be a low level
power control function, which simply disables the IOMMU, without the
need to loop through existing references.
Actually there is already such function - __sysmmu_disable_nocount() -
so the code could look like:
list_for_each_entry_safe(owner, n, &priv->clients, client) {
__sysmmu_disable_nocount(owner->dev);
list_del_init(&owner->client);
}
As for reference counting in this use case in general, as far as I'm
looking through the whole driver code, there is no other usage of this
reference counting than exynos_iommu_attach_device() and
exynos_iommu_detach_device(). Assuming that there is just a single
master for each SYSMMU, I don't see why reference counting is even
needed, as you can't bind a device to IOMMU multiple times.
Device driver is not only for the scholarship but also for the real use.
Huh? I'm not sure what kind of comment is this.
}
+ while (!list_empty(&priv->clients))
+ list_del_init(priv->clients.next);
+
spin_unlock_irqrestore(&priv->lock, flags);
for (i = 0; i < NUM_LV1ENTRIES; i++)
[snip]
+static int sysmmu_hook_driver_register(struct notifier_block *nb,
+ unsigned long val,
+ void *p)
+{
+ struct device *dev = p;
+
+ switch (val) {
+ case BUS_NOTIFY_BIND_DRIVER:
+ {
+ struct exynos_iommu_owner *owner;
Please move this variable to the top of the function and drop the braces
around case blocks.
I don't think it is required because this function is modified
by the following patches.
OK, if so, and similar issue is not present after further patches.
+
+ /* No System MMU assigned. See exynos_sysmmu_probe(). */
+ if (dev->archdata.iommu == NULL)
+ break;
This looks strange... (see below)
Also this looks racy. There are no guarantees about device probing
order, so you may end up with master devices being probed before the
IOMMUs. Deferred probing should be used to handle this correctly.
System MMU driver must be probed earlier than the drivers of master devices
because the drivers may want to use System MMU for their initial task.
As I said, there are no guarantees about platform device probe order in
Linux kernel. Code must be designed to check whether required
dependencies are met and if not, deferred probing must be used.
I told that System MMU driver must be probed earlier.
That's why exynos_iommu_init() is called by subsys_initcall level.
I also noticed that it must be promoted to arch_initcall for some driver.
No. Proper Linux drivers must support deferred probing mechanism and
there should be no assumptions about probing orders. Using other
initcall level than module_initcall for particular drivers is strongly
discouraged.
+
+ owner = devm_kzalloc(dev, sizeof(*owner), GFP_KERNEL);
+ if (!owner) {
+ dev_err(dev, "No Memory for exynos_iommu_owner\n");
+ return -ENOMEM;
+ }
+
+ owner->dev = dev;
+ INIT_LIST_HEAD(&owner->client);
+ owner->sysmmu = dev->archdata.iommu;
+
+ dev->archdata.iommu = owner;
I don't understand what is happening here in this case
Re: [GIT PULL] Samsung clock changes for v3.15
On Wednesday 19 March 2014 13:12:43 Tomasz Figa wrote: > On 19.03.2014 05:07, Mike Turquette wrote: > > Quoting Tomasz Figa (2014-03-18 18:19:25) > >> Hi Mike, > >> > >> On 19.03.2014 02:06, Mike Turquette wrote: > >>> Quoting Tomasz Figa (2014-03-17 10:59:57) > The following changes since commit > 38dbfb59d1175ef458d006556061adeaa8751b72: > > Linus 3.14-rc1 (2014-02-02 16:42:13 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tfiga/samsung-clk.git > tags/for_3.15/samsung-clk > > for you to fetch changes up to 70d1cf1c85486753fec0c60a9a093bdfe42b89b4: > > Merge branch 'for_3.15/misc' into samsung-next (2014-03-17 13:00:01 > +0100) > > > > Samsung clock patches for v3.15. > > Due to dependencies, most of the patches already went through > linux-samsung > tree, so this pull request is rather small. > >>> > >>> I'm a bit confused. This PR is not really small (32 patches) and it > >>> covers more stuff from arch/arm that I usually take. > >>> > It contains various patches > collected since the last merge window: > > 1) non-critical fixes (without need to push to stable): > > 220b0cc clk: samsung: Initialize clock table with error pointers > 58d83cb clk: exynos-5420: Fix VPLL lock offset > 3299bc3 clk: samsung: fixed compiler warning [-Wpointer-to-int-cast] > > 2) clock driver extensions: > > db40d0c clk: samsung exynos5250/5420: Add gate clock for SSS module > d8b9731 clk/samsung: add support for multiple clock providers > 45af130 clk/samsung: add support for pll2550xx > adec437 clk/samsung: add support for pll2650xx > >>> > >>> Right, these 7 patches would constitute a small PR. Was there a mistake > >>> when generating this pull request? > >> > >> The problem with this pull request is that it contains patches that > >> require quite a lot of dependencies that have been already applied into > >> Samsung SoC tree. I'm not sure how else such situation could be handled, > >> other than pulling respective commits into my tree as well. > > > > There are already a fair number of clk patches going through the samsung > > tree. So in the name of consistency for this upcoming merge window it > > might be best to take these patches through there as well. Let me know > > if that creates any undo burden on you. Otherwise please add: > > > > Acked-by: Mike Turquette > > From my perspective, as long as the patches flow upstream, it's one and > the same. I wonder whether ARM SoC tree is still open for merges, > though. Arnd, Olof? > We can probably still take the bug fixes, but I'd have to take a closer look at other ones. Probably one of us would say no to those. 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 v6 1/4] [media] exynos-scaler: Add DT bindings for SCALER driver
Hi Laurent, On 19/03/14 12:59, Laurent Pinchart wrote: > On Wednesday 19 March 2014 12:55:21 Sylwester Nawrocki wrote: >> > On 19/03/14 12:31, Laurent Pinchart wrote: > >> +++ b/Documentation/devicetree/bindings/media/exynos5-scaler.txt > >> > > >> > @@ -0,0 +1,24 @@ > > >> > +* Samsung Exynos5 SCALER device > > >> > + > > >> > +SCALER is used for scaling, blending, color fill and color space > > >> > +conversion on EXYNOS[5420/5410] SoCs. > > >> > + > > >> > +Required properties: > > >> > +- compatible: should be "samsung,exynos5420-scaler" or > > >> > + "samsung,exynos5410-scaler" > > >> > +- reg: should contain SCALER physical address location and length > > >> > +- interrupts: should contain SCALER interrupt specifier > > >> > +- clocks: should contain the SCALER clock phandle and specifier > > >> > pair > > >> > for > > >> > + each clock listed in clock-names property, according to > > >> > + the common clock bindings > > >> > +- clock-names: should contain exactly one entry > > >> > + - "scaler" - IP bus clock >>> > > >>> > > I'm not too familiar with the Exynos platform, but wouldn't it make >>> > > sense >>> > > to use a common name across IP cores for interface and function clocks ? >> > Certainly it would, I proposed that when the exynos clock controller >> > driver was posted, quite long time ago. Unfortunately it wasn't followed >> > up. One of serious reasons was that there are common drivers for >> > multiple Samsung platforms (also the ones not reworked to support dt) and >> > thus changing the clock names would be problematic - driver would still >> > need to handle multiple clock names. >> > But for this driver a common name like "gate" could be better IMHO. > > OMAP uses "ick" for the interface clock and "fck" for the function clock. Do > you think it would make sense to standardize on "fck" across SoC families ? Not sure if it could be future proof, I guess where it isn't bound to other issues and the names could be chosen freely - we could try to use standard names. OTOH it could obfuscate things a bit. As far as Samsung platforms are concerned, the function clock names are usually in form of SCLK_[IP_NAME], "sclk" seems to be an abbreviation of "special clock". It is also not always clear which clock is the interface clock and which is the function clock. The "special clocks" are generally referred to as the IP block clocks. -- Regards, 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
[PATCH 1/4] ARM: SAMSUNG: Introduce generic Exynos4 and 5 helpers
Add helpers to check for Exynos4 and 5 family of SoCs.
This will eliminate comparing long list of SoCs and make
code simpler.
Signed-off-by: Sachin Kamat
---
arch/arm/plat-samsung/include/plat/cpu.h |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h
b/arch/arm/plat-samsung/include/plat/cpu.h
index d762533b856f..b9ae39ca1b7f 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -166,6 +166,10 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID,
EXYNOS5_SOC_MASK)
# define soc_is_exynos5440() 0
#endif
+#define soc_is_exynos4() (soc_is_exynos4210() || soc_is_exynos4212() || \
+ soc_is_exynos4412())
+#define soc_is_exynos5() (soc_is_exynos5250() || soc_is_exynos5420())
+
#define IODESC_ENT(x) { (unsigned long)S3C24XX_VA_##x,
__phys_to_pfn(S3C24XX_PA_##x), S3C24XX_SZ_##x, MT_DEVICE }
#ifndef KHZ
--
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 3/4] ARM: EXYNOS: Add generic compatible strings
Add generic compatible strings for Exynos4 and 5 platforms so that
future SoCs can use them if there is nothing extra/specific to be
differentiated.
Signed-off-by: Sachin Kamat
---
arch/arm/mach-exynos/exynos.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index b6fd40e76936..07884efd3a48 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -343,9 +343,11 @@ static void __init exynos_dt_machine_init(void)
}
static char const *exynos_dt_compat[] __initconst = {
+ "samsung,exynos4",
"samsung,exynos4210",
"samsung,exynos4212",
"samsung,exynos4412",
+ "samsung,exynos5",
"samsung,exynos5250",
"samsung,exynos5420",
"samsung,exynos5440",
--
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 2/4] ARM: EXYNOS: Consolidate Exynos4 and 5 machine files
Since there is very little difference between these two files,
they can be easily combined into one with necessary SoC checks.
While at it also merge the common.c file into this as it does
not have any other users.
Signed-off-by: Sachin Kamat
---
arch/arm/mach-exynos/Makefile |7 +-
arch/arm/mach-exynos/common.h |3 +-
arch/arm/mach-exynos/{common.c => exynos.c} | 133 ++-
arch/arm/mach-exynos/mach-exynos4-dt.c | 53 ---
arch/arm/mach-exynos/mach-exynos5-dt.c | 83 -
arch/arm/mach-exynos/regs-pmu.h |1 -
6 files changed, 93 insertions(+), 187 deletions(-)
rename arch/arm/mach-exynos/{common.c => exynos.c} (75%)
delete mode 100644 arch/arm/mach-exynos/mach-exynos4-dt.c
delete mode 100644 arch/arm/mach-exynos/mach-exynos5-dt.c
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 58fe9e6f542f..a656dbe3b78c 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -12,7 +12,7 @@ obj- :=
# Core
-obj-$(CONFIG_ARCH_EXYNOS) += common.o
+obj-$(CONFIG_ARCH_EXYNOS) += exynos.o
obj-$(CONFIG_PM_SLEEP) += pm.o sleep.o
obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o
@@ -29,8 +29,3 @@ obj-$(CONFIG_ARCH_EXYNOS) += firmware.o
plus_sec := $(call as-instr,.arch_extension sec,+sec)
AFLAGS_exynos-smc.o:=-Wa,-march=armv7-a$(plus_sec)
-
-# machine support
-
-obj-$(CONFIG_ARCH_EXYNOS4) += mach-exynos4-dt.o
-obj-$(CONFIG_ARCH_EXYNOS5) += mach-exynos5-dt.o
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index aba6a2ad7d1b..9ef3f83efaff 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -19,8 +19,7 @@ void mct_init(void __iomem *base, int irq_g0, int irq_l0, int
irq_l1);
struct map_desc;
void exynos_init_io(void);
-void exynos4_restart(enum reboot_mode mode, const char *cmd);
-void exynos5_restart(enum reboot_mode mode, const char *cmd);
+void exynos_restart(enum reboot_mode mode, const char *cmd);
void exynos_cpuidle_init(void);
void exynos_cpufreq_init(void);
void exynos_init_late(void);
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/exynos.c
similarity index 75%
rename from arch/arm/mach-exynos/common.c
rename to arch/arm/mach-exynos/exynos.c
index d9ae5cd49194..b6fd40e76936 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -1,55 +1,39 @@
/*
- * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
+ * SAMSUNG EXYNOS Flattened Device Tree enabled machine
*
- * Common Codes for EXYNOS
+ * Copyright (c) 2010-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.
- */
+*/
-#include
-#include
-#include
-#include
-#include
+#include
#include
-#include
-#include
-#include
-#include
-#include
-#include
+#include
#include
-#include
-#include
-#include
-#include
-#include
#include
-#include
-#include
+#include
+#include
#include
+#include
-#include
-#include
+#include
#include
+#include
#include
-#include
-#include
+#include
#include
-#include
#include "common.h"
+#include "mfc.h"
#include "regs-pmu.h"
#define L2_AUX_VAL 0x7C470001
#define L2_AUX_MASK 0xC200
-/* Initial IO mappings */
-
static struct map_desc exynos4_iodesc[] __initdata = {
{
.virtual= (unsigned long)S3C_VA_SYS,
@@ -163,19 +147,11 @@ static struct map_desc exynos5_iodesc[] __initdata = {
},
};
-void exynos4_restart(enum reboot_mode mode, const char *cmd)
-{
- __raw_writel(0x1, S5P_SWRESET);
-}
-
-void exynos5_restart(enum reboot_mode mode, const char *cmd)
+void exynos_restart(enum reboot_mode mode, const char *cmd)
{
struct device_node *np;
- u32 val;
- void __iomem *addr;
-
- val = 0x1;
- addr = EXYNOS_SWRESET;
+ u32 val = 0x1;
+ void __iomem *addr = EXYNOS_SWRESET;
if (of_machine_is_compatible("samsung,exynos5440")) {
u32 status;
@@ -286,10 +262,10 @@ static int __init exynos_fdt_map_sysram(unsigned long
node, const char *uname,
*/
static void __init exynos_map_io(void)
{
- if (soc_is_exynos4210() || soc_is_exynos4212() || soc_is_exynos4412())
+ if (soc_is_exynos4())
iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
- if (soc_is_exynos5250() || soc_is_exynos5420())
+ if (soc_is_exynos5())
iotable_init(exynos5_iodesc, ARRAY_SIZE(exynos5_iodesc));
}
@@ -331,3 +307,76 @@ static int __init exynos4_l2x0_cache_init(void)
return 0;
}
early_initcall(exynos4_l2x0_cache_init);
+
+static void __init e
[PATCH 4/4] ARM: dts: Update Exynos DT files with generic compatible strings
Add generic compatible strings to the respective board DT files.
Signed-off-by: Sachin Kamat
---
arch/arm/boot/dts/exynos4210-origen.dts |2 +-
arch/arm/boot/dts/exynos4210-smdkv310.dts |2 +-
arch/arm/boot/dts/exynos4210-trats.dts |2 +-
arch/arm/boot/dts/exynos4210-universal_c210.dts |2 +-
arch/arm/boot/dts/exynos4210.dtsi |2 +-
arch/arm/boot/dts/exynos4212.dtsi |2 +-
arch/arm/boot/dts/exynos4412-odroidx.dts|2 +-
arch/arm/boot/dts/exynos4412-origen.dts |2 +-
arch/arm/boot/dts/exynos4412-smdk4412.dts |2 +-
arch/arm/boot/dts/exynos4412-tiny4412.dts |2 +-
arch/arm/boot/dts/exynos4412-trats2.dts |2 +-
arch/arm/boot/dts/exynos4412.dtsi |2 +-
arch/arm/boot/dts/exynos5250-arndale.dts|2 +-
arch/arm/boot/dts/exynos5250-smdk5250.dts |2 +-
arch/arm/boot/dts/exynos5250-snow.dts |2 +-
arch/arm/boot/dts/exynos5250.dtsi |2 +-
arch/arm/boot/dts/exynos5420-arndale-octa.dts |2 +-
arch/arm/boot/dts/exynos5420-smdk5420.dts |2 +-
arch/arm/boot/dts/exynos5420.dtsi |2 +-
arch/arm/boot/dts/exynos5440-sd5v1.dts |2 +-
arch/arm/boot/dts/exynos5440-ssdk5440.dts |2 +-
arch/arm/boot/dts/exynos5440.dtsi |2 +-
22 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index 2aa13cb3bbed..72fb11f7ea21 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -19,7 +19,7 @@
/ {
model = "Insignal Origen evaluation board based on Exynos4210";
- compatible = "insignal,origen", "samsung,exynos4210";
+ compatible = "insignal,origen", "samsung,exynos4210", "samsung,exynos4";
memory {
reg = <0x4000 0x1000
diff --git a/arch/arm/boot/dts/exynos4210-smdkv310.dts
b/arch/arm/boot/dts/exynos4210-smdkv310.dts
index 9c01b718d29d..636d16684750 100644
--- a/arch/arm/boot/dts/exynos4210-smdkv310.dts
+++ b/arch/arm/boot/dts/exynos4210-smdkv310.dts
@@ -19,7 +19,7 @@
/ {
model = "Samsung smdkv310 evaluation board based on Exynos4210";
- compatible = "samsung,smdkv310", "samsung,exynos4210";
+ compatible = "samsung,smdkv310", "samsung,exynos4210",
"samsung,exynos4";
memory {
reg = <0x4000 0x8000>;
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 63cc571ca307..361cb58052bf 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -17,7 +17,7 @@
/ {
model = "Samsung Trats based on Exynos4210";
- compatible = "samsung,trats", "samsung,exynos4210";
+ compatible = "samsung,trats", "samsung,exynos4210", "samsung,exynos4";
memory {
reg = <0x4000 0x1000
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index b893a042e3f7..02f9a05790bc 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -17,7 +17,7 @@
/ {
model = "Samsung Universal C210 based on Exynos4210 rev0";
- compatible = "samsung,universal_c210", "samsung,exynos4210";
+ compatible = "samsung,universal_c210", "samsung,exynos4210",
"samsung,exynos4";
memory {
reg = <0x4000 0x1000
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index b92982b9607e..a3f4bba099e6 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -23,7 +23,7 @@
#include "exynos4210-pinctrl.dtsi"
/ {
- compatible = "samsung,exynos4210";
+ compatible = "samsung,exynos4210", "samsung,exynos4";
aliases {
pinctrl0 = &pinctrl_0;
diff --git a/arch/arm/boot/dts/exynos4212.dtsi
b/arch/arm/boot/dts/exynos4212.dtsi
index ceefc711793c..3c00e6ec9302 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -20,7 +20,7 @@
#include "exynos4x12.dtsi"
/ {
- compatible = "samsung,exynos4212";
+ compatible = "samsung,exynos4212", "samsung,exynos4";
combiner: interrupt-controller@1044 {
samsung,combiner-nr = <18>;
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts
b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 12459b01cca3..31db28a4bb33 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -16,7 +16,7 @@
/ {
model = "Hardkernel ODROID-X board based on Exynos4412";
- compatible = "hardkernel,odroid-x", "samsung,exynos4412";
+ compatible = "hardkernel,odroid-x", "samsung,exynos4412",
"samsung,exynos4";
memory {
[PATCH 0/4] Consolidate Exynos machine code
This patch series consolidates the Exynos machine code and common
code into a single file to avoid code duplication and introduces
generic compatible strings for Exynos4 and 5 SoC series.
Complete discussion and motivation for this series is found here:
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/27268
This series is based on the latest linux-next and depends on
1. Tomasz Figa's PM consolidation series 1 and 2
2. Patch: ARM: SAMSUNG: Reorganize calls to reserve memory for MFC
http://www.spinics.net/lists/linux-samsung-soc/msg25501.html
3. Patch: ARM: EXYNOS: Add support to reserve memory for MFC-v7
http://www.spinics.net/lists/arm-kernel/msg315940.html
4. Kconfig and CPU init Consolidation series
http://article.gmane.org/gmane.linux.kernel.samsung-soc/28216
Sachin Kamat (4):
ARM: SAMSUNG: Introduce generic Exynos4 and 5 helpers
ARM: EXYNOS: Consolidate Exynos4 and 5 machine files
ARM: EXYNOS: Add generic compatible strings
ARM: dts: Update Exynos DT files with generic compatible strings
arch/arm/boot/dts/exynos4210-origen.dts |2 +-
arch/arm/boot/dts/exynos4210-smdkv310.dts |2 +-
arch/arm/boot/dts/exynos4210-trats.dts |2 +-
arch/arm/boot/dts/exynos4210-universal_c210.dts |2 +-
arch/arm/boot/dts/exynos4210.dtsi |2 +-
arch/arm/boot/dts/exynos4212.dtsi |2 +-
arch/arm/boot/dts/exynos4412-odroidx.dts|2 +-
arch/arm/boot/dts/exynos4412-origen.dts |2 +-
arch/arm/boot/dts/exynos4412-smdk4412.dts |2 +-
arch/arm/boot/dts/exynos4412-tiny4412.dts |2 +-
arch/arm/boot/dts/exynos4412-trats2.dts |2 +-
arch/arm/boot/dts/exynos4412.dtsi |2 +-
arch/arm/boot/dts/exynos5250-arndale.dts|2 +-
arch/arm/boot/dts/exynos5250-smdk5250.dts |2 +-
arch/arm/boot/dts/exynos5250-snow.dts |2 +-
arch/arm/boot/dts/exynos5250.dtsi |2 +-
arch/arm/boot/dts/exynos5420-arndale-octa.dts |2 +-
arch/arm/boot/dts/exynos5420-smdk5420.dts |2 +-
arch/arm/boot/dts/exynos5420.dtsi |2 +-
arch/arm/boot/dts/exynos5440-sd5v1.dts |2 +-
arch/arm/boot/dts/exynos5440-ssdk5440.dts |2 +-
arch/arm/boot/dts/exynos5440.dtsi |2 +-
arch/arm/mach-exynos/Makefile |7 +-
arch/arm/mach-exynos/common.h |3 +-
arch/arm/mach-exynos/{common.c => exynos.c} | 135 ---
arch/arm/mach-exynos/mach-exynos4-dt.c | 53 -
arch/arm/mach-exynos/mach-exynos5-dt.c | 83 --
arch/arm/mach-exynos/regs-pmu.h |1 -
arch/arm/plat-samsung/include/plat/cpu.h|4 +
29 files changed, 121 insertions(+), 209 deletions(-)
rename arch/arm/mach-exynos/{common.c => exynos.c} (75%)
delete mode 100644 arch/arm/mach-exynos/mach-exynos4-dt.c
delete mode 100644 arch/arm/mach-exynos/mach-exynos5-dt.c
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] clk: samsung: add new Kconfig for Samsung common clock options
Hi Pankaj, On 12.03.2014 05:32, Pankaj Dubey wrote: This patch adds new Kconfig file for adding new config option as COMMON_CLK_SAMSUNG for Samsung common clock. This patch also moves S3C24XX specific clock options here in this file. Signed-off-by: Pankaj Dubey --- drivers/clk/samsung/Kconfig | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 drivers/clk/samsung/Kconfig diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig new file mode 100644 index 000..26eb446 --- /dev/null +++ b/drivers/clk/samsung/Kconfig @@ -0,0 +1,11 @@ +config COMMON_CLK_SAMSUNG + bool + select COMMON_CLK + +config S3C2412_COMMON_CLK + bool + select COMMON_CLK_SAMSUNG + +config S3C2443_COMMON_CLK + bool + select COMMON_CLK_SAMSUNG This patch adds S3C2412_COMMON_CLK and S3C2443_COMMON_CLK to drivers/clk/samsung/Kconfig, but they are still present in arch/arm/mach-s3c24xx/Kconfig, so after this patch there are duplicate definitions. 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 2/4] drivers: clk: use CONFIG_COMMON_CLK_SAMSUNG for Samsung clock support
Hi Pankaj, On 12.03.2014 05:32, Pankaj Dubey wrote: This patch includes Samsung clock Kconfig file, and replaces PLAT_SAMSUNG with COMMON_CLK_SAMSUNG for Samsung common clock support. Any Samsung SoC want to use Samsung common clock infrastructure can simply select COMMON_CLK_SAMSUNG. Signed-off-by: Pankaj Dubey --- drivers/clk/Kconfig |2 ++ drivers/clk/Makefile |2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 7641965..f2b6179 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -112,3 +112,5 @@ source "drivers/clk/qcom/Kconfig" endmenu source "drivers/clk/mvebu/Kconfig" + +source "drivers/clk/samsung/Kconfig" diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index a367a98..f1da6ee 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -38,7 +38,7 @@ obj-$(CONFIG_PLAT_ORION) += mvebu/ obj-$(CONFIG_ARCH_MXS)+= mxs/ obj-$(CONFIG_COMMON_CLK_QCOM) += qcom/ obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/ -obj-$(CONFIG_PLAT_SAMSUNG) += samsung/ +obj-$(CONFIG_COMMON_CLK_SAMSUNG) += samsung/ obj-$(CONFIG_ARCH_SHMOBILE_MULTI) += shmobile/ obj-$(CONFIG_ARCH_SIRF) += sirf/ obj-$(CONFIG_ARCH_SOCFPGA)+= socfpga/ This patch makes samsung/ subdirectory compile depending on CONFIG_COMMON_CLK_SAMSUNG, but nothing selects it yet and thus breaking bisection. 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: [GIT PULL] Samsung clock changes for v3.15
On 19.03.2014 05:07, Mike Turquette wrote: Quoting Tomasz Figa (2014-03-18 18:19:25) Hi Mike, On 19.03.2014 02:06, Mike Turquette wrote: Quoting Tomasz Figa (2014-03-17 10:59:57) The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72: Linus 3.14-rc1 (2014-02-02 16:42:13 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tfiga/samsung-clk.git tags/for_3.15/samsung-clk for you to fetch changes up to 70d1cf1c85486753fec0c60a9a093bdfe42b89b4: Merge branch 'for_3.15/misc' into samsung-next (2014-03-17 13:00:01 +0100) Samsung clock patches for v3.15. Due to dependencies, most of the patches already went through linux-samsung tree, so this pull request is rather small. I'm a bit confused. This PR is not really small (32 patches) and it covers more stuff from arch/arm that I usually take. It contains various patches collected since the last merge window: 1) non-critical fixes (without need to push to stable): 220b0cc clk: samsung: Initialize clock table with error pointers 58d83cb clk: exynos-5420: Fix VPLL lock offset 3299bc3 clk: samsung: fixed compiler warning [-Wpointer-to-int-cast] 2) clock driver extensions: db40d0c clk: samsung exynos5250/5420: Add gate clock for SSS module d8b9731 clk/samsung: add support for multiple clock providers 45af130 clk/samsung: add support for pll2550xx adec437 clk/samsung: add support for pll2650xx Right, these 7 patches would constitute a small PR. Was there a mistake when generating this pull request? The problem with this pull request is that it contains patches that require quite a lot of dependencies that have been already applied into Samsung SoC tree. I'm not sure how else such situation could be handled, other than pulling respective commits into my tree as well. There are already a fair number of clk patches going through the samsung tree. So in the name of consistency for this upcoming merge window it might be best to take these patches through there as well. Let me know if that creates any undo burden on you. Otherwise please add: Acked-by: Mike Turquette From my perspective, as long as the patches flow upstream, it's one and the same. I wonder whether ARM SoC tree is still open for merges, though. Arnd, Olof? 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 v11 10/27] iommu/exynos: use managed device helper functions
On 19.03.2014 10:01, Sachin Kamat wrote:
On 19 March 2014 14:29, Cho KyongHo wrote:
On Tue, 18 Mar 2014 16:14:53 +0100, Tomasz Figa wrote:
On 18.03.2014 12:09, Cho KyongHo wrote:
On Fri, 14 Mar 2014 20:52:43 +0530, Sachin Kamat wrote:
Hi KyongHo,
On 14 March 2014 10:35, Cho KyongHo wrote:
This patch uses managed device helper functions in the probe().
Signed-off-by: Cho KyongHo
---
[snip]
+ data->clk = devm_clk_get(dev, "sysmmu");
+ if (IS_ERR(data->clk)) {
+ dev_info(dev, "No gate clock found!\n");
+ data->clk = NULL;
+ }
Why aren't you returning from here upon error?
It is for the case of a System MMU which does not need clock gating.
Are there really such cases?
Yes.
Especially in the case of initial stage of new SoC development.
I have experianced some software workaround for H/W restriction
needs prevention of clock gating for some devices.
So aren't these basically some exceptions/hacks rather than the usual way
of functioning of the device?
This actually raises a good question, whether we really need to support
such early development SoC versions in mainline.
Another thing is that if you need to assure that a clock is ungated, you
must acquire it and prepare_enable explicitly, so I don't think this
kind of handling is correct.
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 v6 1/4] [media] exynos-scaler: Add DT bindings for SCALER driver
Hi Laurent, On 19.03.2014 12:31, Laurent Pinchart wrote: Hi Shaik, Thank you for the patch. On Wednesday 19 March 2014 12:43:13 Shaik Ameer Basha wrote: This patch adds the DT binding documentation for the Exynos5420/5410 based SCALER device driver. Signed-off-by: Shaik Ameer Basha Reviewed-by: Sylwester Nawrocki --- .../devicetree/bindings/media/exynos5-scaler.txt | 24 + 1 file changed, 24 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/exynos5-scaler.txt diff --git a/Documentation/devicetree/bindings/media/exynos5-scaler.txt b/Documentation/devicetree/bindings/media/exynos5-scaler.txt new file mode 100644 index 000..e1dd465 --- /dev/null +++ b/Documentation/devicetree/bindings/media/exynos5-scaler.txt @@ -0,0 +1,24 @@ +* Samsung Exynos5 SCALER device + +SCALER is used for scaling, blending, color fill and color space +conversion on EXYNOS[5420/5410] SoCs. + +Required properties: +- compatible: should be "samsung,exynos5420-scaler" or + "samsung,exynos5410-scaler" +- reg: should contain SCALER physical address location and length +- interrupts: should contain SCALER interrupt specifier +- clocks: should contain the SCALER clock phandle and specifier pair for + each clock listed in clock-names property, according to + the common clock bindings +- clock-names: should contain exactly one entry + - "scaler" - IP bus clock I'm not too familiar with the Exynos platform, but wouldn't it make sense to use a common name across IP cores for interface and function clocks ? Yes, it would definitely make sense, provided we are starting from scratch, but due to the lack of listed IP clock inputs in documentation, we ended with a custom of naming the inputs after SoC clocks of first SoC used with such driver. This showed up long before adoption of DT and common clocks on Samsung platform and I'd say it would be hard to get rid of it now. Anyway, as long as clock names are well specified in binding documentation, it should be fine. So, from me it's a Reviewed-by: Tomasz Figa 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 v6 1/4] [media] exynos-scaler: Add DT bindings for SCALER driver
Hi Sylwester, On Wednesday 19 March 2014 12:55:21 Sylwester Nawrocki wrote: > On 19/03/14 12:31, Laurent Pinchart wrote: > >> +++ b/Documentation/devicetree/bindings/media/exynos5-scaler.txt > >> > >> > @@ -0,0 +1,24 @@ > >> > +* Samsung Exynos5 SCALER device > >> > + > >> > +SCALER is used for scaling, blending, color fill and color space > >> > +conversion on EXYNOS[5420/5410] SoCs. > >> > + > >> > +Required properties: > >> > +- compatible: should be "samsung,exynos5420-scaler" or > >> > +"samsung,exynos5410-scaler" > >> > +- reg: should contain SCALER physical address location and length > >> > +- interrupts: should contain SCALER interrupt specifier > >> > +- clocks: should contain the SCALER clock phandle and specifier pair > >> > for > >> > +each clock listed in clock-names property, according to > >> > +the common clock bindings > >> > +- clock-names: should contain exactly one entry > >> > +- "scaler" - IP bus clock > > > > I'm not too familiar with the Exynos platform, but wouldn't it make sense > > to use a common name across IP cores for interface and function clocks ? > Certainly it would, I proposed that when the exynos clock controller > driver was posted, quite long time ago. Unfortunately it wasn't followed > up. One of serious reasons was that there are common drivers for > multiple Samsung platforms (also the ones not reworked to support dt) and > thus changing the clock names would be problematic - driver would still > need to handle multiple clock names. > But for this driver a common name like "gate" could be better IMHO. OMAP uses "ick" for the interface clock and "fck" for the function clock. Do you think it would make sense to standardize on "fck" across SoC families ? -- Regards, Laurent Pinchart -- 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 1/4] [media] exynos-scaler: Add DT bindings for SCALER driver
Hi, On 19/03/14 12:31, Laurent Pinchart wrote: >> +++ b/Documentation/devicetree/bindings/media/exynos5-scaler.txt >> > @@ -0,0 +1,24 @@ >> > +* Samsung Exynos5 SCALER device >> > + >> > +SCALER is used for scaling, blending, color fill and color space >> > +conversion on EXYNOS[5420/5410] SoCs. >> > + >> > +Required properties: >> > +- compatible: should be "samsung,exynos5420-scaler" or >> > + "samsung,exynos5410-scaler" >> > +- reg: should contain SCALER physical address location and length >> > +- interrupts: should contain SCALER interrupt specifier >> > +- clocks: should contain the SCALER clock phandle and specifier pair for >> > + each clock listed in clock-names property, according to >> > + the common clock bindings >> > +- clock-names: should contain exactly one entry >> > + - "scaler" - IP bus clock > > I'm not too familiar with the Exynos platform, but wouldn't it make sense to > use a common name across IP cores for interface and function clocks ? Certainly it would, I proposed that when the exynos clock controller driver was posted, quite long time ago. Unfortunately it wasn't followed up. One of serious reasons was that there are common drivers for multiple Samsung platforms (also the ones not reworked to support dt) and thus changing the clock names would be problematic - driver would still need to handle multiple clock names. But for this driver a common name like "gate" could be better IMHO. Regards, 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 v6 1/4] [media] exynos-scaler: Add DT bindings for SCALER driver
Hi Shaik,
Thank you for the patch.
On Wednesday 19 March 2014 12:43:13 Shaik Ameer Basha wrote:
> This patch adds the DT binding documentation for the Exynos5420/5410
> based SCALER device driver.
>
> Signed-off-by: Shaik Ameer Basha
> Reviewed-by: Sylwester Nawrocki
> ---
> .../devicetree/bindings/media/exynos5-scaler.txt | 24 +
> 1 file changed, 24 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/media/exynos5-scaler.txt
>
> diff --git a/Documentation/devicetree/bindings/media/exynos5-scaler.txt
> b/Documentation/devicetree/bindings/media/exynos5-scaler.txt new file mode
> 100644
> index 000..e1dd465
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/exynos5-scaler.txt
> @@ -0,0 +1,24 @@
> +* Samsung Exynos5 SCALER device
> +
> +SCALER is used for scaling, blending, color fill and color space
> +conversion on EXYNOS[5420/5410] SoCs.
> +
> +Required properties:
> +- compatible: should be "samsung,exynos5420-scaler" or
> + "samsung,exynos5410-scaler"
> +- reg: should contain SCALER physical address location and length
> +- interrupts: should contain SCALER interrupt specifier
> +- clocks: should contain the SCALER clock phandle and specifier pair for
> + each clock listed in clock-names property, according to
> + the common clock bindings
> +- clock-names: should contain exactly one entry
> + - "scaler" - IP bus clock
I'm not too familiar with the Exynos platform, but wouldn't it make sense to
use a common name across IP cores for interface and function clocks ?
> +Example:
> + scaler_0: scaler@1280 {
> + compatible = "samsung,exynos5420-scaler";
> + reg = <0x1280 0x1000>;
> + interrupts = <0 220 0>;
> + clocks = <&clock 381>;
> + clock-names = "scaler";
> + };
--
Regards,
Laurent Pinchart
--
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 v11 0/4] thermal: samsung: Clean up and add support for Exynos5420
Hi All, I didn't see this series in mainline, Any comments for this ? Thanks, Leela Krishna Amudala. On Tue, Dec 10, 2013 at 12:10 PM, Naveen Krishna Chatradhi wrote: > This patchset does a little clean up of the existing code (linux-soc-thermal) > 1. [v11] thermal: samsung: replace inten_ bit fields with intclr_ > 2. [v11] thermal: samsung: change base_common to more meaningful base_second > > adds support for Exynos5420 in the driver and (linux-soc-thermal) > 3. [v11] thermal: samsung: Add TMU support for Exynos5420 SoCs > also adds the device tree nodes for the same to exynos5420.dtsi > (linux-samsung.git) > 4. [v11] ARM: dts: Exynos5420: Add device nodes for TMU blocks > > (linux-soc-thermal) > Naveen Krishna Chatradhi (3): > thermal: samsung: replace inten_ bit fields with intclr_ > thermal: samsung: change base_common to more meaningful base_second > thermal: samsung: Add TMU support for Exynos5420 SoCs > > .../devicetree/bindings/thermal/exynos-thermal.txt | 42 ++- > drivers/thermal/samsung/exynos_tmu.c | 72 +--- > drivers/thermal/samsung/exynos_tmu.h | 21 ++-- > drivers/thermal/samsung/exynos_tmu_data.c | 119 > ++-- > drivers/thermal/samsung/exynos_tmu_data.h | 12 +- > 5 files changed, 228 insertions(+), 38 deletions(-) > > (linux-samsung.git) > Naveen Krishna Chatradhi (1): > ARM: dts: Exynos5420: Add device nodes for TMU blocks > > arch/arm/boot/dts/exynos5420.dtsi | 40 > + > 1 file changed, 40 insertions(+) > -- > 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 -- 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 Resend 3/3] ARM: EXYNOS: Map SYSRAM address through DT
Instead of hardcoding the SYSRAM details for each SoC,
pass this information through device tree (DT) and make
the code SoC agnostic.
Signed-off-by: Sachin Kamat
---
.../devicetree/bindings/arm/samsung-boards.txt | 11 +++
arch/arm/boot/dts/exynos4210-universal_c210.dts|9 ++
arch/arm/boot/dts/exynos4210.dtsi | 10 ++
arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
arch/arm/boot/dts/exynos5.dtsi |5 +
arch/arm/boot/dts/exynos5250.dtsi |5 +
arch/arm/boot/dts/exynos5420.dtsi |5 +
arch/arm/mach-exynos/common.c | 104
arch/arm/mach-exynos/include/mach/map.h|7 --
9 files changed, 95 insertions(+), 71 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt
b/Documentation/devicetree/bindings/arm/samsung-boards.txt
index 2168ed31e1b0..f79710eb7e79 100644
--- a/Documentation/devicetree/bindings/arm/samsung-boards.txt
+++ b/Documentation/devicetree/bindings/arm/samsung-boards.txt
@@ -7,6 +7,17 @@ Required root node properties:
(a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
(b) "samsung,exynos4210" - for boards based on Exynos4210 SoC.
+- sysram node, specifying the type (secure or non-secure) of SYSRAM
+ - compatible: following types are supported
+ "samsung,exynos4210-sysram" : Secure SYSRAM
+ "samsung,exynos4210-sysram-ns" : Non-secure SYSRAM
+ - reg: address of SYSRAM bank
+
+ sysram@0202 {
+ compatible = "samsung,exynos4210-sysram";
+ reg = <0x0202 0x1000>;
+ };
+
Optional:
- firmware node, specifying presence and type of secure firmware:
- compatible: only "samsung,secure-firmware" is currently supported
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index d2e3f5f5916d..b893a042e3f7 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -28,6 +28,15 @@
bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5 rw
rootwait earlyprintk panic=5 maxcpus=1";
};
+ sysram@0202 {
+ status = "disabled";
+ };
+
+ sysram@02025000 {
+ compatible = "samsung,exynos4210-sysram";
+ reg = <0x02025000 0x1000>;
+ };
+
mct@1005 {
compatible = "none";
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index cb0e768dc6d4..b92982b9607e 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -31,6 +31,16 @@
pinctrl2 = &pinctrl_2;
};
+ sysram@0202 {
+ compatible = "samsung,exynos4210-sysram";
+ reg = <0x0202 0x1000>;
+ };
+
+ sysram-ns@0203F000 {
+ compatible = "samsung,exynos4210-sysram-ns";
+ reg = <0x0203F000 0x1000>;
+ };
+
pd_lcd1: lcd1-power-domain@10023CA0 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023CA0 0x20>;
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index c4a9306f8529..d57e3120223f 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -37,6 +37,16 @@
interrupts = <2 2>, <3 2>, <18 2>, <19 2>;
};
+ sysram@0202 {
+ compatible = "samsung,exynos4210-sysram";
+ reg = <0x0202 0x1000>;
+ };
+
+ sysram-ns@0204F000 {
+ compatible = "samsung,exynos4210-sysram-ns";
+ reg = <0x0204F000 0x1000>;
+ };
+
pd_isp: isp-power-domain@10023CA0 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023CA0 0x20>;
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 79d0608d6dcc..c03bd09ec37d 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -18,6 +18,11 @@
/ {
interrupt-parent = <&gic>;
+ sysram@0202 {
+ compatible = "samsung,exynos4210-sysram";
+ reg = <0x0202 0x1000>;
+ };
+
chipid@1000 {
compatible = "samsung,exynos4210-chipid";
reg = <0x1000 0x100>;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index fdeed7c29ac9..abfceadbb1ea 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -72,6 +72,11 @@
};
};
+ sysram-ns@0204F000 {
+ compatible = "samsung,exynos4210-sysram-ns";
+ reg = <0x0204F000 0x1000>;
+ };
+
pd_gsc: gsc-power-domain@10044000 {
compatible = "samsung,exyno
[PATCH Resend 1/3] ARM: EXYNOS: Consolidate Kconfig entries
Instead of repeating the Kconfig entries for every SoC, move them under ARCH_EXYNOS4 and 5 and move the entries common to both 4 and 5 under ARCH_EXYNOS. Also, since the individual SoCs do not have any specific machine/platform code, keep them as boolean symbols instead of user selectable and select them from Exynos4 and 5 config symbols. Individual SoC symbols can be removed eventually once the driver Kconfig dependencies on these symbols are removed. Signed-off-by: Sachin Kamat Acked-by: Tomasz Figa --- This is a resend of the series rebased on top of latest linux-next and Tomasz Figa's PM consolidation series 1 and 2. --- arch/arm/Kconfig | 10 + arch/arm/mach-exynos/Kconfig | 89 +++--- 2 files changed, 33 insertions(+), 66 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index afc751f750b9..e2428a18f2a6 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -821,18 +821,28 @@ config ARCH_S5PV210 config ARCH_EXYNOS bool "Samsung EXYNOS" + select ARCH_HAS_BANDGAP select ARCH_HAS_CPUFREQ select ARCH_HAS_HOLES_MEMORYMODEL select ARCH_REQUIRE_GPIOLIB select ARCH_SPARSEMEM_ENABLE + select ARM_AMBA select ARM_GIC + select CLKSRC_OF select COMMON_CLK select CPU_V7 select GENERIC_CLOCKEVENTS + select HAVE_ARM_SCU if SMP select HAVE_S3C2410_I2C if I2C select HAVE_S3C2410_WATCHDOG if WATCHDOG select HAVE_S3C_RTC if RTC_CLASS + select HAVE_SMP select NEED_MACH_MEMORY_H + select PINCTRL + select PINCTRL_EXYNOS + select PM_GENERIC_DOMAINS if PM_RUNTIME + select S5P_DEV_MFC + select SAMSUNG_DMADEV select SPARSE_IRQ select USE_OF help diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index fc8bf18e222d..9398bab87a76 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -14,90 +14,32 @@ menu "SAMSUNG EXYNOS SoCs Support" config ARCH_EXYNOS4 bool "SAMSUNG EXYNOS4" default y - select ARM_AMBA - select CLKSRC_OF + select ARM_CPU_SUSPEND if PM_SLEEP select CLKSRC_SAMSUNG_PWM if CPU_EXYNOS4210 select CPU_EXYNOS4210 select GIC_NON_BANKED select KEYBOARD_SAMSUNG if INPUT_KEYBOARD - select HAVE_ARM_SCU if SMP - select HAVE_SMP select MIGHT_HAVE_CACHE_L2X0 - select PINCTRL - select PM_GENERIC_DOMAINS if PM_RUNTIME - select S5P_DEV_MFC + select SOC_EXYNOS4212 + select SOC_EXYNOS4412 help - Samsung EXYNOS4 SoCs based systems + Samsung EXYNOS4 (Cortex-A9) SoC based systems config ARCH_EXYNOS5 bool "SAMSUNG EXYNOS5" - select ARM_AMBA - select CLKSRC_OF - select HAVE_ARM_SCU if SMP - select HAVE_SMP - select PINCTRL - help - Samsung EXYNOS5 (Cortex-A15) SoC based systems - -comment "EXYNOS SoCs" - -config CPU_EXYNOS4210 - bool "SAMSUNG EXYNOS4210" - default y - depends on ARCH_EXYNOS4 - select ARCH_HAS_BANDGAP - select ARM_CPU_SUSPEND if PM_SLEEP - select PINCTRL_EXYNOS - select SAMSUNG_DMADEV - help - Enable EXYNOS4210 CPU support - -config SOC_EXYNOS4212 - bool "SAMSUNG EXYNOS4212" default y - depends on ARCH_EXYNOS4 - select ARCH_HAS_BANDGAP - select PINCTRL_EXYNOS - select SAMSUNG_DMADEV + select SOC_EXYNOS5250 + select SOC_EXYNOS5420 help - Enable EXYNOS4212 SoC support + Samsung EXYNOS5 (Cortex-A15/A7) SoC based systems -config SOC_EXYNOS4412 - bool "SAMSUNG EXYNOS4412" - default y - depends on ARCH_EXYNOS4 - select ARCH_HAS_BANDGAP - select PINCTRL_EXYNOS - select SAMSUNG_DMADEV - help - Enable EXYNOS4412 SoC support - -config SOC_EXYNOS5250 - bool "SAMSUNG EXYNOS5250" - default y - depends on ARCH_EXYNOS5 - select ARCH_HAS_BANDGAP - select PINCTRL_EXYNOS - select PM_GENERIC_DOMAINS if PM_RUNTIME - select S5P_DEV_MFC - select SAMSUNG_DMADEV - help - Enable EXYNOS5250 SoC support - -config SOC_EXYNOS5420 - bool "SAMSUNG EXYNOS5420" - default y - depends on ARCH_EXYNOS5 - select PM_GENERIC_DOMAINS if PM_RUNTIME - help - Enable EXYNOS5420 SoC support +comment "EXYNOS SoCs" config SOC_EXYNOS5440 bool "SAMSUNG EXYNOS5440" default y depends on ARCH_EXYNOS5 select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE - select ARCH_HAS_BANDGAP select ARCH_HAS_OPP select HAVE_ARM_ARCH_TIMER select AUTO_ZRELADDR @@ -110,4 +52,19 @@ config SOC_EXYNOS5440 endmenu +config CPU_EXYNOS4210 + bool + +config SOC_EXYNOS4212 + bool + +config SOC_EXYNOS4412 + bool + +config SOC_EXYNOS5250 + bool
[PATCH Resend 2/3] ARM: EXYNOS: Consolidate CPU init code
cpu_table was used to distinguish between different Exynos4 and 5
SoCs and based on the type do the initialization and io mapping.
exynos_init is dummy and no longer needed as we do a DT based booting.
By having a common io mapping function we can get rid of the whole
table and avoid populating it for every SoC.
Tested on Exynos4210, 5250 and 5420 based boards.
Signed-off-by: Sachin Kamat
Tested-by: Tomasz Figa
---
arch/arm/mach-exynos/common.c | 108 +
1 file changed, 23 insertions(+), 85 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index e98ddadc5f74..10ed374c0744 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -48,56 +48,6 @@
#define L2_AUX_VAL 0x7C470001
#define L2_AUX_MASK 0xC200
-static const char name_exynos4210[] = "EXYNOS4210";
-static const char name_exynos4212[] = "EXYNOS4212";
-static const char name_exynos4412[] = "EXYNOS4412";
-static const char name_exynos5250[] = "EXYNOS5250";
-static const char name_exynos5420[] = "EXYNOS5420";
-static const char name_exynos5440[] = "EXYNOS5440";
-
-static void exynos4_map_io(void);
-static void exynos5_map_io(void);
-static int exynos_init(void);
-
-static struct cpu_table cpu_ids[] __initdata = {
- {
- .idcode = EXYNOS4210_CPU_ID,
- .idmask = EXYNOS4_CPU_MASK,
- .map_io = exynos4_map_io,
- .init = exynos_init,
- .name = name_exynos4210,
- }, {
- .idcode = EXYNOS4212_CPU_ID,
- .idmask = EXYNOS4_CPU_MASK,
- .map_io = exynos4_map_io,
- .init = exynos_init,
- .name = name_exynos4212,
- }, {
- .idcode = EXYNOS4412_CPU_ID,
- .idmask = EXYNOS4_CPU_MASK,
- .map_io = exynos4_map_io,
- .init = exynos_init,
- .name = name_exynos4412,
- }, {
- .idcode = EXYNOS5250_SOC_ID,
- .idmask = EXYNOS5_SOC_MASK,
- .map_io = exynos5_map_io,
- .init = exynos_init,
- .name = name_exynos5250,
- }, {
- .idcode = EXYNOS5420_SOC_ID,
- .idmask = EXYNOS5_SOC_MASK,
- .map_io = exynos5_map_io,
- .init = exynos_init,
- .name = name_exynos5420,
- }, {
- .idcode = EXYNOS5440_SOC_ID,
- .idmask = EXYNOS5_SOC_MASK,
- .init = exynos_init,
- .name = name_exynos5440,
- },
-};
-
/* Initial IO mappings */
static struct map_desc exynos4_iodesc[] __initdata = {
@@ -346,6 +296,28 @@ static int __init exynos_fdt_map_chipid(unsigned long
node, const char *uname,
*
* register the standard cpu IO areas
*/
+static void __init exynos_map_io(void)
+{
+ if (soc_is_exynos4210() || soc_is_exynos4212() || soc_is_exynos4412())
+ iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
+
+ if (soc_is_exynos5250() || soc_is_exynos5420())
+ iotable_init(exynos5_iodesc, ARRAY_SIZE(exynos5_iodesc));
+
+ if (soc_is_exynos4210()) {
+ if (samsung_rev() == EXYNOS4210_REV_0)
+ iotable_init(exynos4_iodesc0,
+ ARRAY_SIZE(exynos4_iodesc0));
+ else
+ iotable_init(exynos4_iodesc1,
+ ARRAY_SIZE(exynos4_iodesc1));
+ iotable_init(exynos4210_iodesc, ARRAY_SIZE(exynos4210_iodesc));
+ }
+ if (soc_is_exynos4212() || soc_is_exynos4412())
+ iotable_init(exynos4x12_iodesc, ARRAY_SIZE(exynos4x12_iodesc));
+ if (soc_is_exynos5250())
+ iotable_init(exynos5250_iodesc, ARRAY_SIZE(exynos5250_iodesc));
+}
void __init exynos_init_io(void)
{
@@ -356,30 +328,7 @@ void __init exynos_init_io(void)
/* detect cpu id and rev. */
s5p_init_cpu(S5P_VA_CHIPID);
- s3c_init_cpu(samsung_cpu_id, cpu_ids, ARRAY_SIZE(cpu_ids));
-}
-
-static void __init exynos4_map_io(void)
-{
- iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
-
- if (soc_is_exynos4210() && samsung_rev() == EXYNOS4210_REV_0)
- iotable_init(exynos4_iodesc0, ARRAY_SIZE(exynos4_iodesc0));
- else
- iotable_init(exynos4_iodesc1, ARRAY_SIZE(exynos4_iodesc1));
-
- if (soc_is_exynos4210())
- iotable_init(exynos4210_iodesc, ARRAY_SIZE(exynos4210_iodesc));
- if (soc_is_exynos4212() || soc_is_exynos4412())
- iotable_init(exynos4x12_iodesc, ARRAY_SIZE(exynos4x12_iodesc));
-}
-
-static void _
Re: [PATCHv2 8/8] devfreq: exynos4: Add busfreq driver for exynos4210/exynos4x12
Hi Chanwoo, On 19.03.2014 10:47, Chanwoo Choi wrote: Hi Tomasz, On 03/19/2014 12:46 AM, Tomasz Figa wrote: On 17.03.2014 06:19, Chanwoo Choi wrote: Hi Tomasz, On 03/15/2014 02:35 AM, Tomasz Figa wrote: Hi Chanwoo, Mark, On 14.03.2014 11:56, Chanwoo Choi wrote: Hi Mark, On 03/14/2014 07:35 PM, Mark Rutland wrote: On Fri, Mar 14, 2014 at 07:14:37AM +, Chanwoo Choi wrote: Hi Mark, On 03/14/2014 02:53 AM, Mark Rutland wrote: On Thu, Mar 13, 2014 at 08:17:29AM +, Chanwoo Choi wrote: This patch add busfreq driver for Exynos4210/Exynos4x12 memory interface and bus to support DVFS(Dynamic Voltage Frequency Scaling) according to PPMU counters. PPMU (Performance Profiling Monitorings Units) of Exynos4 SoC provides PPMU counters for DMC(Dynamic Memory Controller) to check memory bus utilization and then busfreq driver adjusts dynamically the operating frequency/voltage by using DEVFREQ Subsystem. Signed-off-by: Chanwoo Choi --- .../devicetree/bindings/devfreq/exynos4_bus.txt| 49 ++ 1 file changed, 49 insertions(+) create mode 100644 Documentation/devicetree/bindings/devfreq/exynos4_bus.txt diff --git a/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt b/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt new file mode 100644 index 000..2a83fcc --- /dev/null +++ b/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt @@ -0,0 +1,49 @@ + +Exynos4210/4x12 busfreq driver +- + +Exynos4210/4x12 Soc busfreq driver with devfreq for Memory bus frequency/voltage +scaling according to PPMU counters of memory controllers + +Required properties: +- compatible: should contain Exynos4 SoC type as follwoing: + - "samsung,exynos4x12-busfreq" for Exynos4x12 + - "samsung,exynos4210-busfreq" for Exynos4210 Is there a device called "busfreq"? What device does this binding describe? I'll add detailed description of busfreq as following: "busfreq(bus frequendcy)" driver means that busfreq driver control dynamically memory bus frequency/voltage by checking memory bus utilization to optimize power-consumption. When checking memeory bus utilization, exynos4_busfreq driver would use PPMU(Performance Profiling Monitoring Units). This still sounds like a description of the _driver_, not the _device_. The binding should describe the hardware, now the high level abstraction that software is going to build atop of it. It sounds like this is a binding for the DMC PPMU? Is the PPMU a component of the DMC, or is it bolted on the side? PPMU(Performance Profiling Monitoring Unit) is to profile performance event of various IP on Exynos4. Each PPMU provide perforamnce event for each IP. We can check various PPMU as following: PPMU_3D PPMU_ACP PPMU_CAMIF PPMU_CPU PPMU_DMC0 PPMU_DMC1 PPMU_FSYS PPMU_IMAGE PPMU_LCD0 PPMU_LCD1 PPMU_MFC_L PPMU_MFC_R PPMU_TV PPMU_LEFT_BUS PPMU_RIGHT_BUS DMC (Dynamic Memory Controller) control the operation of DRAM in Exynos4 SoC. If we need to get memory bust utilization of DMC, we can get memory bus utilization from PPMU_DMC0/PPMU_DMC1. So, Exynos4's busfreq used two(PPMU_DMC0/PPMU_DMC1) among upper various PPMU list. Well, PPMUs and DMCs are separate hardware blocks found inside Exynos SoCs. Busfreq/devfreq is just a Linux-specific abstraction responsible for collecting data using PPMUs and controlling frequencies and voltages of appropriate power planes, vdd_int responsible for powering DMC0 and DMC1 blocks in this case. I knew already. I'm afraid that the binding you're proposing is unfortunately incorrect, because it represents the software abstraction, not the real hardware. What is exactly incorrect part of this patch? Device tree contains information about hardware, not about OS-specific drivers or subsystems. Busfreq/devfreq is not a hardware block, but a Linux-specific driver, so it's not suitable to be described by DT directly, especially considering the fact that in future it might be replaced by or merged with another subsystem. Only PPMUs are real hardware blocks present in the SoC. In addition, a SoC-level aspect of hardware description may be added, such as a list of power planes. See below for explanation. You means that PPMU must need separate framework from devfreq subsystem? If PPMU framework will be implemented, PPMU framework provides API to external device driver as common clk framework, regulator framework. And then,exynos4 busfreq with devfreq have to use PPMU framework to monitor memory utilization. Is this right? Not exactly. I'm just saying that in device tree, particular hardware blocks (such as PPMU) must be represented by their own nodes. This doesn't imply any particular implementation in code. DT bindings should be considered without any particular driver code in mind. The principle here is that with device tree describing all the information needed for Exynos bus frequency and power plane voltage scaling, y
Re: [PATCH v2 0/4] Introduce new Kconfig for Samsung common clock
On 03/12/2014 01:32 PM, Pankaj Dubey wrote: Introduce a new Kconfig file for Samsung common clock infrastructure related config options. As current Samsung common clock gets compiled based on PLAT_SAMSUNG, but moving ahead with ARM64 we can not have any more such config options, so this patch introduce new COMMON_CLK_SAMSUNG invisible option. This option also select COMMON_CLK so ARCH Kconfig just need to select COMMON_CLK_SAMSUNG in case they want to use Samsung common clock. This series is based on Kukjin's for-next branch. V2: 1) Adding new Kconfig file for Samsung common clock. 2) Make COMMON_CLK_SAMSUNG option invisible. (as suggested by Tomasz Figa) 3) Let COMMON_CLK_SAMSUNG select COMMON_CLK. (as suggested by Tomasz Figa) 4) Move S3C24XX clock config option in new Kconfig file. Pankaj Dubey (4): clk: samsung: add new Kconfig for Samsung common clock options drivers: clk: use CONFIG_COMMON_CLK_SAMSUNG for Samsung clock support ARM: select COMMON_CLK_SAMSUNG for ARCH_EXYNOS and ARCH_S3C64XX ARM: S3C24XX: remove S3C24XX specific clock Kconfig options arch/arm/Kconfig |4 ++-- arch/arm/mach-s3c24xx/Kconfig | 14 -- drivers/clk/Kconfig |2 ++ drivers/clk/Makefile |2 +- drivers/clk/samsung/Kconfig | 11 +++ 5 files changed, 16 insertions(+), 17 deletions(-) create mode 100644 drivers/clk/samsung/Kconfig +CC: Mike and Tomasz Figa Sorry, during posting second version I forgot to CC Clock maintainer's, so CC'ing now. Link for this series: http://lkml.org/lkml/2014/3/12/10 -- Best Regards, Pankaj Dubey -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 8/8] devfreq: exynos4: Add busfreq driver for exynos4210/exynos4x12
Hi Tomasz, On 03/19/2014 12:46 AM, Tomasz Figa wrote: > On 17.03.2014 06:19, Chanwoo Choi wrote: >> Hi Tomasz, >> >> On 03/15/2014 02:35 AM, Tomasz Figa wrote: >>> Hi Chanwoo, Mark, >>> >>> On 14.03.2014 11:56, Chanwoo Choi wrote: Hi Mark, On 03/14/2014 07:35 PM, Mark Rutland wrote: > On Fri, Mar 14, 2014 at 07:14:37AM +, Chanwoo Choi wrote: >> Hi Mark, >> >> On 03/14/2014 02:53 AM, Mark Rutland wrote: >>> On Thu, Mar 13, 2014 at 08:17:29AM +, Chanwoo Choi wrote: This patch add busfreq driver for Exynos4210/Exynos4x12 memory interface and bus to support DVFS(Dynamic Voltage Frequency Scaling) according to PPMU counters. PPMU (Performance Profiling Monitorings Units) of Exynos4 SoC provides PPMU counters for DMC(Dynamic Memory Controller) to check memory bus utilization and then busfreq driver adjusts dynamically the operating frequency/voltage by using DEVFREQ Subsystem. Signed-off-by: Chanwoo Choi --- .../devicetree/bindings/devfreq/exynos4_bus.txt| 49 ++ 1 file changed, 49 insertions(+) create mode 100644 Documentation/devicetree/bindings/devfreq/exynos4_bus.txt diff --git a/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt b/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt new file mode 100644 index 000..2a83fcc --- /dev/null +++ b/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt @@ -0,0 +1,49 @@ + +Exynos4210/4x12 busfreq driver +- + +Exynos4210/4x12 Soc busfreq driver with devfreq for Memory bus frequency/voltage +scaling according to PPMU counters of memory controllers + +Required properties: +- compatible: should contain Exynos4 SoC type as follwoing: + - "samsung,exynos4x12-busfreq" for Exynos4x12 + - "samsung,exynos4210-busfreq" for Exynos4210 >>> >>> Is there a device called "busfreq"? What device does this binding >>> describe? >> >> I'll add detailed description of busfreq as following: >> >> "busfreq(bus frequendcy)" driver means that busfreq driver control >> dynamically >> memory bus frequency/voltage by checking memory bus utilization to >> optimize >> power-consumption. When checking memeory bus utilization, >> exynos4_busfreq driver >> would use PPMU(Performance Profiling Monitoring Units). > > This still sounds like a description of the _driver_, not the _device_. > The binding should describe the hardware, now the high level abstraction > that software is going to build atop of it. > > It sounds like this is a binding for the DMC PPMU? > > Is the PPMU a component of the DMC, or is it bolted on the side? PPMU(Performance Profiling Monitoring Unit) is to profile performance event of various IP on Exynos4. Each PPMU provide perforamnce event for each IP. We can check various PPMU as following: PPMU_3D PPMU_ACP PPMU_CAMIF PPMU_CPU PPMU_DMC0 PPMU_DMC1 PPMU_FSYS PPMU_IMAGE PPMU_LCD0 PPMU_LCD1 PPMU_MFC_L PPMU_MFC_R PPMU_TV PPMU_LEFT_BUS PPMU_RIGHT_BUS DMC (Dynamic Memory Controller) control the operation of DRAM in Exynos4 SoC. If we need to get memory bust utilization of DMC, we can get memory bus utilization from PPMU_DMC0/PPMU_DMC1. So, Exynos4's busfreq used two(PPMU_DMC0/PPMU_DMC1) among upper various PPMU list. >>> >>> Well, PPMUs and DMCs are separate hardware blocks found inside Exynos SoCs. >>> Busfreq/devfreq is just a Linux-specific abstraction responsible for >>> collecting data using PPMUs and controlling frequencies and voltages of >>> appropriate power planes, vdd_int responsible for powering DMC0 and DMC1 >>> blocks in this case. >>> >> >> I knew already. >> >>> I'm afraid that the binding you're proposing is unfortunately incorrect, >>> because it represents the software abstraction, not the real hardware. >> >> What is exactly incorrect part of this patch? >> > > Device tree contains information about hardware, not about OS-specific > drivers or subsystems. Busfreq/devfreq is not a hardware block, but a > Linux-specific driver, so it's not suitable to be described by DT directly, > especially considering the fact that in future it might be replaced by or > merged with another subsystem. > > Only PPMUs are real hardware blocks present in the SoC. In addition, a > SoC-level aspect of hardware description may be added, such as a list of > power planes. See below for explanation. > You means that PPMU must need separate
Re: [PATCH v11 19/27] iommu/exynos: add support for power management subsystems.
On Tue, 18 Mar 2014 16:33:04 +0100, Tomasz Figa wrote: > On 18.03.2014 12:23, Cho KyongHo wrote: > > On Fri, 14 Mar 2014 17:07:53 +0100, Tomasz Figa wrote: > >> Hi KyongHo, > >> > >> On 14.03.2014 06:10, Cho KyongHo wrote: > > [snip] > > >>> @@ -677,11 +679,40 @@ static int __init exynos_sysmmu_probe(struct > >>> platform_device *pdev) > >>> platform_set_drvdata(pdev, data); > >>> > >>> pm_runtime_enable(dev); > >>> + data->runtime_active = !pm_runtime_enabled(dev); > >> > >> Hmm, this seems to be a bit misleading. The field is named > >> runtime_active, but the assignment makes it true if PM runtime is _not_ > >> enabled (i.e. inactive). Is this correct? > >> > > > > I agree that it may lead misunderstood. > > data->runtime_active actually indicates if electric power is asserted > > to the System MMU. pm_runtime_enable() call must enable runtime pm > > for the given device. If runtime pm is not enabled although > > pm_runtime_enable() > > is called, CONFIG_PM_RUNTIME is not configured. > > > > Actually, it is replacible with > > if (IS_ENABLED(CONFIG_PM_RUNTIME)) > > data->runtime_active = true; > > I would keep it as !pm_runtime_enabled(dev), but rename the field to > something more meaningful, like data->is_powered_on. > That is good idea. thanks for advice. KyongHo. -- 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 v11 13/27] iommu/exynos: support for device tree
On Tue, 18 Mar 2014 16:25:11 +0100, Tomasz Figa wrote:
> On 18.03.2014 11:52, Cho KyongHo wrote:
> > On Fri, 14 Mar 2014 14:39:33 +0100, Tomasz Figa wrote:
> >>> @@ -557,11 +558,23 @@ static int exynos_sysmmu_probe(struct
> >>> platform_device *pdev)
> >>> return 0;
> >>>}
> >>>
> >>> -static struct platform_driver exynos_sysmmu_driver = {
> >>> - .probe = exynos_sysmmu_probe,
> >>> - .driver = {
> >>> +#ifdef CONFIG_OF
> >>> +static struct of_device_id sysmmu_of_match[] __initconst = {
> >>> + { .compatible = "samsung,sysmmu-v1", },
> >>> + { .compatible = "samsung,sysmmu-v2", },
> >>> + { .compatible = "samsung,sysmmu-v3.1", },
> >>> + { .compatible = "samsung,sysmmu-v3.2", },
> >>> + { .compatible = "samsung,sysmmu-v3.3", },
> >>
> >> Do you need all these compatible strings? I mean, are there any
> >> implementation differences that can't be identified by reading IP
> >> registers, such as REG_MMU_VERSION?
> >>
> >
> > Unfortunately, there is a SoC which overrides REG_MMU_VERSION with
> > a value for RTL designers and it is not related to System MMU
> > versions.
>
> OK.
>
> What about having a generic compatible string for Samsung SysMMU then,
> but an additional property that can override the version to account for
> such brokenness? If not provided, the version would be read from
> REG_MMU_VERSION.
>
Yes it is one of possible idea.
Let me think what better way is.
Thank you.
KyongHo
--
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 v11 10/27] iommu/exynos: use managed device helper functions
On 19 March 2014 14:29, Cho KyongHo wrote:
> On Tue, 18 Mar 2014 16:14:53 +0100, Tomasz Figa wrote:
>> On 18.03.2014 12:09, Cho KyongHo wrote:
>> > On Fri, 14 Mar 2014 20:52:43 +0530, Sachin Kamat wrote:
>> >> Hi KyongHo,
>> >>
>> >> On 14 March 2014 10:35, Cho KyongHo wrote:
>> >>> This patch uses managed device helper functions in the probe().
>> >>>
>> >>> Signed-off-by: Cho KyongHo
>> >>> ---
>> >> [snip]
>> >>
>> >>> + data->clk = devm_clk_get(dev, "sysmmu");
>> >>> + if (IS_ERR(data->clk)) {
>> >>> + dev_info(dev, "No gate clock found!\n");
>> >>> + data->clk = NULL;
>> >>> + }
>> >>
>> >> Why aren't you returning from here upon error?
>> >
>> > It is for the case of a System MMU which does not need clock gating.
>> >
>>
>> Are there really such cases?
>>
>
> Yes.
> Especially in the case of initial stage of new SoC development.
>
> I have experianced some software workaround for H/W restriction
> needs prevention of clock gating for some devices.
So aren't these basically some exceptions/hacks rather than the usual way
of functioning of the device?
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 10/27] iommu/exynos: use managed device helper functions
On Tue, 18 Mar 2014 16:14:53 +0100, Tomasz Figa wrote:
> On 18.03.2014 12:09, Cho KyongHo wrote:
> > On Fri, 14 Mar 2014 20:52:43 +0530, Sachin Kamat wrote:
> >> Hi KyongHo,
> >>
> >> On 14 March 2014 10:35, Cho KyongHo wrote:
> >>> This patch uses managed device helper functions in the probe().
> >>>
> >>> Signed-off-by: Cho KyongHo
> >>> ---
> >> [snip]
> >>
> >>> + data->clk = devm_clk_get(dev, "sysmmu");
> >>> + if (IS_ERR(data->clk)) {
> >>> + dev_info(dev, "No gate clock found!\n");
> >>> + data->clk = NULL;
> >>> + }
> >>
> >> Why aren't you returning from here upon error?
> >
> > It is for the case of a System MMU which does not need clock gating.
> >
>
> Are there really such cases?
>
Yes.
Especially in the case of initial stage of new SoC development.
I have experianced some software workaround for H/W restriction
needs prevention of clock gating for some devices.
Regards,
KyongHo
--
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 v11 10/27] iommu/exynos: use managed device helper functions
On Wed, 19 Mar 2014 08:59:09 +0900, Jingoo Han wrote:
> On Wednesday, March 19, 2014 12:12 AM, Tomasz Figa wrote:
> > On 18.03.2014 11:38, Cho KyongHo wrote:
> > > On Fri, 14 Mar 2014 14:28:36 +0100, Tomasz Figa wrote:
> > >> On 14.03.2014 06:05, Cho KyongHo wrote:
> > >>> This patch uses managed device helper functions in the probe().
> > >>>
> > >>> Signed-off-by: Cho KyongHo
> > >>> ---
> > >>>drivers/iommu/exynos-iommu.c | 64
> > >>> +-
> > >>>1 file changed, 26 insertions(+), 38 deletions(-)
> > >>>
> > >>> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> > >>> index 36e6b73..33b424d 100644
> > >>> --- a/drivers/iommu/exynos-iommu.c
> > >>> +++ b/drivers/iommu/exynos-iommu.c
>
> [.]
>
> > >>> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > >>> if (!res) {
> > >>> - dev_dbg(dev, "Unable to find IOMEM region\n");
> > >>> - ret = -ENOENT;
> > >>> - goto err_init;
> > >>> + dev_err(dev, "Unable to find IOMEM region\n");
> > >>> + return -ENOENT;
> > >>> }
> > >>
> > >> No need to check for error and print message, because
> > >> devm_ioremap_resource() already checks the passed resource and handles
> > >> error cases.
> > >>
> > >
> > > Yes but devm_ioremap_resource() just tells that the given 'res' is not
> > > correct. I think the message in the driver is more informative.
> >
> > The common practice used in Linux kernel is to not duplicate such
> > messages. It is obvious that devm_ioremap_resource() printing such
> > message is related to an IOMEM resource anyway, as you can't used it
> > with other types of resources.
>
> +1
>
> I agree with Tomasz Figa's opinion.
> These messages have been being removed from Linux kernel.
> Thank you.
>
Ok.
Thank you for the advice.
Kyong Ho
--
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 v11 13/27] iommu/exynos: support for device tree
On Tue, 18 Mar 2014 16:46:24 +0530, Sachin Kamat wrote:
> On 18 March 2014 16:44, Cho KyongHo wrote:
> > On Fri, 14 Mar 2014 20:57:42 +0530, Sachin Kamat wrote:
> >> Hi KyongHo,
> >>
> >> On 14 March 2014 10:39, Cho KyongHo wrote:
> >> >
> >> > -static struct platform_driver exynos_sysmmu_driver = {
> >> > - .probe = exynos_sysmmu_probe,
> >> > - .driver = {
> >> > +#ifdef CONFIG_OF
> >>
> >> This is not needed as Exynos is DT only platform.
> >>
> > Yes, but I hesitate to remove that.
>
> What is the reason for your hesitation? :)
>
Actually, no reason because you mentioned that Exynos is DT only platofrm.
I will remove that.
Thank you.
KyongHo
--
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] ARM: SAMSUNG: Reorganize calls to reserve memory for MFC
On 31 December 2013 11:53, Tushar Behera wrote:
> Reorganize code so that "plat/mfc.h" is no more referred from
> mach-exynos folder.
>
> Signed-off-by: Tushar Behera
> ---
>
> Changelog for V2:
> * Added missing arch/arm/mach-exynos/mfc.h file
>
> arch/arm/mach-exynos/mach-exynos4-dt.c | 10 ++
> arch/arm/mach-exynos/mach-exynos5-dt.c | 10 ++
> arch/arm/mach-exynos/mfc.h | 16
> arch/arm/plat-samsung/include/plat/mfc.h |3 ---
> arch/arm/plat-samsung/s5p-dev-mfc.c | 17 ++---
> 5 files changed, 30 insertions(+), 26 deletions(-)
> create mode 100644 arch/arm/mach-exynos/mfc.h
>
> diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c
> b/arch/arm/mach-exynos/mach-exynos4-dt.c
> index 4603e6b..66b4a6e 100644
> --- a/arch/arm/mach-exynos/mach-exynos4-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
> @@ -15,9 +15,9 @@
> #include
>
> #include
> -#include
>
> #include "common.h"
> +#include "mfc.h"
>
> static void __init exynos4_dt_machine_init(void)
> {
> @@ -36,13 +36,7 @@ static char const *exynos4_dt_compat[] __initdata = {
> static void __init exynos4_reserve(void)
> {
> #ifdef CONFIG_S5P_DEV_MFC
> - struct s5p_mfc_dt_meminfo mfc_mem;
> -
> - /* Reserve memory for MFC only if it's available */
> - mfc_mem.compatible = "samsung,mfc-v5";
> - if (of_scan_flat_dt(s5p_fdt_find_mfc_mem, &mfc_mem))
> - s5p_mfc_reserve_mem(mfc_mem.roff, mfc_mem.rsize, mfc_mem.loff,
> - mfc_mem.lsize);
> + of_scan_flat_dt(s5p_fdt_alloc_mfc_mem, "samsung,mfc-v5");
> #endif
> }
> DT_MACHINE_START(EXYNOS4210_DT, "Samsung Exynos4 (Flattened Device Tree)")
> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
> b/arch/arm/mach-exynos/mach-exynos5-dt.c
> index 9bb6eac..36b36f4 100644
> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
> @@ -14,9 +14,9 @@
> #include
>
> #include
> -#include
>
> #include "common.h"
> +#include "mfc.h"
> #include "regs-pmu.h"
>
> static void __init exynos5_dt_machine_init(void)
> @@ -59,13 +59,7 @@ static char const *exynos5_dt_compat[] __initdata = {
> static void __init exynos5_reserve(void)
> {
> #ifdef CONFIG_S5P_DEV_MFC
> - struct s5p_mfc_dt_meminfo mfc_mem;
> -
> - /* Reserve memory for MFC only if it's available */
> - mfc_mem.compatible = "samsung,mfc-v6";
> - if (of_scan_flat_dt(s5p_fdt_find_mfc_mem, &mfc_mem))
> - s5p_mfc_reserve_mem(mfc_mem.roff, mfc_mem.rsize, mfc_mem.loff,
> - mfc_mem.lsize);
> + of_scan_flat_dt(s5p_fdt_alloc_mfc_mem, "samsung,mfc-v6");
> #endif
> }
>
> diff --git a/arch/arm/mach-exynos/mfc.h b/arch/arm/mach-exynos/mfc.h
> new file mode 100644
> index 000..dec93cd
> --- /dev/null
> +++ b/arch/arm/mach-exynos/mfc.h
> @@ -0,0 +1,16 @@
> +/*
> + * Copyright (C) 2013 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 as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#ifndef __MACH_EXYNOS_MFC_H
> +#define __MACH_EXYNOS_MFC_H __FILE__
> +
> +int __init s5p_fdt_alloc_mfc_mem(unsigned long node, const char *uname,
> + int depth, void *data);
> +
> +#endif /* __MACH_EXYNOS_MFC_H */
> diff --git a/arch/arm/plat-samsung/include/plat/mfc.h
> b/arch/arm/plat-samsung/include/plat/mfc.h
> index e6d7c42..033654e 100644
> --- a/arch/arm/plat-samsung/include/plat/mfc.h
> +++ b/arch/arm/plat-samsung/include/plat/mfc.h
> @@ -32,7 +32,4 @@ struct s5p_mfc_dt_meminfo {
> void __init s5p_mfc_reserve_mem(phys_addr_t rbase, unsigned int rsize,
> phys_addr_t lbase, unsigned int lsize);
>
> -int __init s5p_fdt_find_mfc_mem(unsigned long node, const char *uname,
> - int depth, void *data);
> -
> #endif /* __PLAT_SAMSUNG_MFC_H */
> diff --git a/arch/arm/plat-samsung/s5p-dev-mfc.c
> b/arch/arm/plat-samsung/s5p-dev-mfc.c
> index ad51f85..98087b6 100644
> --- a/arch/arm/plat-samsung/s5p-dev-mfc.c
> +++ b/arch/arm/plat-samsung/s5p-dev-mfc.c
> @@ -122,32 +122,35 @@ device_initcall(s5p_mfc_memory_init);
> #endif
>
> #ifdef CONFIG_OF
> -int __init s5p_fdt_find_mfc_mem(unsigned long node, const char *uname,
> +int __init s5p_fdt_alloc_mfc_mem(unsigned long node, const char *uname,
> int depth, void *data)
> {
> __be32 *prop;
> unsigned long len;
> - struct s5p_mfc_dt_meminfo *mfc_mem = data;
> + struct s5p_mfc_dt_meminfo mfc_mem;
>
> if (!data)
> return 0;
>
> - if (!of_flat_dt_is_compatible(node, mfc_mem->compatible))
> + if (!of_flat_dt_is_compatible(node, data))
> return 0;
>
> prop
Re: [PATCH 2/2] ARM: dts: Keep some essential LDOs enabled for Arndale-Octa
On 5 March 2014 13:39, Tushar Behera wrote:
> LDO3 and LDO23 need to be enabled in order for soft-reset to work.
>
> Additionally LDO9 needs to be enabled for USB operations.
>
> Signed-off-by: Tushar Behera
> ---
> arch/arm/boot/dts/exynos5420-arndale-octa.dts |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> index 810ec73..df975b5 100644
> --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> @@ -113,6 +113,7 @@
> regulator-name =
> "PVDD_APIO_MMCON_1V8";
> regulator-min-microvolt = <180>;
> regulator-max-microvolt = <180>;
> + regulator-always-on;
> };
>
> ldo4_reg: LDO4 {
> @@ -150,6 +151,7 @@
> regulator-name = "PVDD_USB_3V3";
> regulator-min-microvolt = <300>;
> regulator-max-microvolt = <300>;
> + regulator-always-on;
> };
>
> ldo10_reg: LDO10 {
> @@ -218,6 +220,7 @@
> regulator-name = "PVDD_MIFS_1V1";
> regulator-min-microvolt = <120>;
> regulator-max-microvolt = <120>;
> + regulator-always-on;
> };
>
> ldo24_reg: LDO24 {
> --
> 1.7.9.5
>
Kukjin,
Would you please apply this?
--
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
Re: [PATCH 1/2] ARM: dts: Disable MDMA1 node for Arndale-octa board
On 5 March 2014 13:39, Tushar Behera wrote:
> MDMA1 can support both secure and non-secure AXI transactions. When this
> is enabled in the kernel for boards that run in secure mode, we get
> imprecise external aborts causing the kernel to oops.
>
> Unhandled fault: imprecise external abort (0x1406) at 0x
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0007
>
> Suggested-by: Javi Merino
> Signed-off-by: Tushar Behera
> ---
> arch/arm/boot/dts/exynos5420-arndale-octa.dts | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> index f509e8f..810ec73 100644
> --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> @@ -361,4 +361,16 @@
> gpio-key,wakeup;
> };
> };
> +
> + amba {
> + mdma1: mdma@11C1 {
> + /*
> +* MDMA1 can support both secure and non-secure
> +* AXI transactions. When this is enabled in the
> kernel
> +* for boards that run in secure mode, we are getting
> +* imprecise external aborts causing the kernel to
> oops.
> +*/
> + status = "disabled";
> + };
> + };
> };
> --
> 1.7.9.5
>
Kukjin,
Can you please apply this with Javi's "Tested-by"?
--
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
RE: [PATCH v2 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board
Mark Rutland wrote:
>
> On Fri, Mar 14, 2014 at 01:26:31AM +, Kukjin Kim wrote:
> > > > > > + cpu@000 {
> > > > > > + device_type = "cpu";
> > > > > > + compatible = "arm,armv8";
> > > > >
> > > > > The "arm,armv8" should be a fallback rather than the only entry. The
> > > > > precise core should be first (see arch/arm64/boot/dts/apm-storm.dtsi
> > > > > for
> > > > > an example).
> > > > >
> > > > Well, do I really need another name if GH7 has just 'ARMv8 core'
> > > > exactly?
> > >
> > > Yes please. You presumably don't have "just 'ARMv8 core'", but rather a
> > > specific ARMv8 implementation.
> > >
> > OK, so in my understanding if it is really _just_ 'ARMv8 core' from S/W
> > point
> > of view, "arm,armv8" should be fine. I will make sure.
>
> It will work, sure. But the compatible list should also list the
> specific CPU. From the S/W point of view there are likely
> implementation-defined registers which mean that no real CPU will be
> "just" an ARMv8 core.
>
Well, IMHO, SoC is just SoC and we don't think each CPU(core) from SoC and I'm
still wondering why the specific compatible string for CPU is needed in kernel.
And I don't see any custom handling for GH7 SoC. Note sorry, I don't get about
implementation-defined registers.
> We have enough trouble with DTBs for 32-bit SoCs not listing things they
> should. I see no reason to be lax here.
>
Could you please let me know what was the problem?
If it could be on exynos, would be helpful to me.
> > > > > > + gic: interrupt-controller@1C00 {
> > > > > > + compatible = "arm,cortex-a15-gic";
> > > > >
> > > > > We should have a more specific compatible string early in the list
> > > > > here
> > > > > too.
> > > > >
> > > > Well, I think more specific compatible string is not required for gic,
> > > > there
> > > > were discussion about using another compatible string for gic-v2. And
> > > > cortex-a15-gic should be fine at this moment and if another name is
> > > > required
> > > > as per previous discussion, we will then.
> > >
> > > While it's probably ok to have "arm,cortex-a15-gic" in the compatible
> > > list, it would be good to also have a more specific string, so we can
> > > identify the GIC implementation precisely in future (in case we need to
> > > perform any workarounds, or there's some kind of optimisation we could
> > > perform for some implementations).
> > >
> > Hmm... let's use just it for now then add another specific string later ;-)
>
> Why not do this from the start? Then we can actually rely on the DTB
> rather than it being useless.
>
I mean, we need to use current GIC implementation for GH7 SoC at this moment.
> > > > > > + pmu {
> > > > > > + compatible = "arm,armv8-pmuv3";
> > > > >
> > > > > This is missing a specific compatible string.
> > > > >
> > > > I don't know why I need another specific compatible string here because
> > > > I
> > > > thought the 'armv8-pmuv3' is enough.
> > >
> > > Each CPU microarchitecture has different PMU events and quirks. While
> > > the CPU PMU might be compatible with ARMv8's PMUv3, it will also have
> > > implementation-specific events, and may have quirks we need to work
> > > around in future.
> > >
> > > As with 32-bit, we'd expect these to be of the form
> > > "${implementor},${cpu}-pmu".
> > >
> > OK.
> >
> > + compatible = "samsung,gh7-pmu", "armv8-pmuv3";
>
> Is GH7 an SoC or a CPU?
>
SoC. Similar as above. AFAIK, ARM SoC vendors usually didn't name for each CPU
not SoC if there is no change in core hardware implementation, at least Samsung
didn't name.
OK, if you still have strong objection on this, I will remove PMU support here
until agreement about that.
> > > > > > + serial@12c2 {
> > > > > > + compatible = "arm,pl011", "arm,primecell";
> > > > > > + reg = <0 0x12c2 0 0x1>;
> > > > > > + interrupts = <0 420 0>;
> > > > > > + };
> > > > >
> > > > > These are both missing required clocks.
> > > > >
> > > > Yes right.
> > >
> > > So you'll add these?
> > >
> > To be honest, still I'm not sure how it should be handled because regarding
> > clocks do not need to handle in the kernel for GH7. And for it, I needed to
> > use some HACKs to change clock handling in the kernel. I will provide proper
> > solution soon.
>
> Are the clocks always-on, fixed-rate clocks, or does some firmware
> manage them dynamically? We have bindings for the former.
>
Actually, some firmware handles them and basically and kernel doesn't need.
> There's not much point having a DTS upstream that relies on hacks which
> are not.
>
At the end, we are going to use just upstream kernel for GH7 without any HACKs
but as a preliminary, this is a good start point even there is HACK for a while.
Thanks,
Kukjin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger
Re: [PATCH v3 1/3] clk: s2mps11: Add support for S2MPS14 clocks
On Tue, 2014-03-18 at 17:16 -0700, Mike Turquette wrote: > Quoting Krzysztof Kozlowski (2014-03-17 02:19:16) > > This patch adds support for S2MPS14 PMIC clocks (BT and AP) to the > > s2mps11 clock driver. > > > > Signed-off-by: Krzysztof Kozlowski > > Reviewed-by: Yadwinder Singh Brar > > Reviewed-by: Tomasz Figa > > This does not apply cleanly to to clk tree trip, nor does it compile > after manually merging due to changes introducing > linux/mfd/samsung/s2mps14.h. > > The changes look OK to me so maybe Lee can take it with my Ack? > > Acked-by: Mike Turquette > Hi, Thanks for the Ack. The patch depends on Tushar Behera's patches: - [PATCH V2 0/2] Add support for clocks in S5M8767 http://thread.gmane.org/gmane.linux.kernel.samsung-soc/27264 which are waiting for some time. Both patchsets should be pulled together. Best regards, Krzysztof -- 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 3/4] [media] exynos-scaler: Add m2m functionality for the SCALER driver
Thanks for this patch series!
I've got some comments below...
Regards,
Hans
On 03/19/2014 08:13 AM, Shaik Ameer Basha wrote:
> This patch adds memory to memory (m2m) interface functionality
> for the SCALER driver.
>
> [arun...@samsung.com: fix compilation issues]
>
> Signed-off-by: Shaik Ameer Basha
> Signed-off-by: Arun Kumar K
> Reviewed-by: Sylwester Nawrocki
> ---
> drivers/media/platform/exynos-scaler/scaler-m2m.c | 788
> +
> 1 file changed, 788 insertions(+)
> create mode 100644 drivers/media/platform/exynos-scaler/scaler-m2m.c
>
> diff --git a/drivers/media/platform/exynos-scaler/scaler-m2m.c
> b/drivers/media/platform/exynos-scaler/scaler-m2m.c
> new file mode 100644
> index 000..7b21a17
> --- /dev/null
> +++ b/drivers/media/platform/exynos-scaler/scaler-m2m.c
> @@ -0,0 +1,788 @@
> +/*
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Samsung EXYNOS5 SoC series SCALER driver
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include "scaler-regs.h"
> +
> +#define SCALER_DEF_PIX_FMT V4L2_PIX_FMT_RGB32
> +#define SCALER_DEF_WIDTH 1280
> +#define SCALER_DEF_HEIGHT720
> +
> +static int scaler_m2m_ctx_stop_req(struct scaler_ctx *ctx)
> +{
> + struct scaler_ctx *curr_ctx;
> + struct scaler_dev *scaler = ctx->scaler_dev;
> + int ret;
> +
> + curr_ctx = v4l2_m2m_get_curr_priv(scaler->m2m.m2m_dev);
> + if (!scaler_m2m_pending(scaler) || (curr_ctx != ctx))
> + return 0;
> +
> + scaler_ctx_state_lock_set(SCALER_CTX_STOP_REQ, ctx);
> + ret = wait_event_timeout(scaler->irq_queue,
> + !scaler_ctx_state_is_set(SCALER_CTX_STOP_REQ, ctx),
> + SCALER_SHUTDOWN_TIMEOUT);
> +
> + return ret == 0 ? -ETIMEDOUT : ret;
> +}
> +
> +static int scaler_m2m_start_streaming(struct vb2_queue *q, unsigned int
> count)
> +{
> + struct scaler_ctx *ctx = q->drv_priv;
> + int ret;
> +
> + ret = pm_runtime_get_sync(&ctx->scaler_dev->pdev->dev);
> +
> + return ret > 0 ? 0 : ret;
> +}
If an error occurs, then all queued buffers must be returned to the vb2
core with vb2_buffer_done with state VB2_BUF_STATE_QUEUED. A lot of vb2
instrumentation has been added in recent weeks to check for correct
buffer handling, and this was one of the corner cases that was never
handled correctly. If you compile with the VIDEO_ADV_DEBUG config option
you'll see warnings appearing if this function returns an error and the
buffers aren't requeued. It's a good test to do.
> +
> +static int scaler_m2m_stop_streaming(struct vb2_queue *q)
> +{
> + struct scaler_ctx *ctx = q->drv_priv;
> + int ret;
> +
> + ret = scaler_m2m_ctx_stop_req(ctx);
> + if (ret < 0)
> + scaler_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
> +
> + pm_runtime_put(&ctx->scaler_dev->pdev->dev);
> +
> + return 0;
> +}
> +
> +void scaler_m2m_job_finish(struct scaler_ctx *ctx, int vb_state)
> +{
> + struct vb2_buffer *src_vb, *dst_vb;
> +
> + if (!ctx || !ctx->m2m_ctx)
> + return;
> +
> + src_vb = v4l2_m2m_src_buf_remove(ctx->m2m_ctx);
> + dst_vb = v4l2_m2m_dst_buf_remove(ctx->m2m_ctx);
> +
> + if (src_vb && dst_vb) {
> + v4l2_m2m_buf_done(src_vb, vb_state);
> + v4l2_m2m_buf_done(dst_vb, vb_state);
> +
> + v4l2_m2m_job_finish(ctx->scaler_dev->m2m.m2m_dev,
> + ctx->m2m_ctx);
> + }
> +}
> +
> +static void scaler_m2m_job_abort(void *priv)
> +{
> + struct scaler_ctx *ctx = priv;
> + int ret;
> +
> + ret = scaler_m2m_ctx_stop_req(ctx);
> + if (ret < 0)
> + scaler_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
> +}
> +
> +static int scaler_get_bufs(struct scaler_ctx *ctx)
> +{
> + struct scaler_frame *s_frame, *d_frame;
> + struct vb2_buffer *src_vb, *dst_vb;
> + int ret;
> +
> + s_frame = &ctx->s_frame;
> + d_frame = &ctx->d_frame;
> +
> + src_vb = v4l2_m2m_next_src_buf(ctx->m2m_ctx);
> + ret = scaler_prepare_addr(ctx, src_vb, s_frame, &s_frame->addr);
> + if (ret < 0)
> + return ret;
> +
> + dst_vb = v4l2_m2m_next_dst_buf(ctx->m2m_ctx);
> + ret = scaler_prepare_addr(ctx, dst_vb, d_frame, &d_frame->addr);
> + if (ret < 0)
> + return ret;
> +
> + dst_vb->v4l2_buf.timestamp = src_vb->v4l2_buf.timestamp;
> +
> + return 0;
> +}
> +
> +static void scaler_m2m_device_run(void *priv)
> +{
> + struct scaler_ctx *ctx = priv;
> + struct scaler_dev *scaler;
> + unsigned long flags;
> + int ret;
> + bool is_stopped;
> +
> + if (WARN(!ctx, "Null hardware context\n"))
> + return;
> +
> + s
[PATCH v6 2/4] [media] exynos-scaler: Add new driver for Exynos5 SCALER
This patch adds support for SCALER device which is a new device
for scaling, blending, color fill and color space conversion
on EXYNOS5410 and EXYNOS5420 SoCs.
This device supports the followings as key feature.
input image format
- YCbCr420 2P(UV/VU), 3P
- YCbCr422 1P(YUYV/UYVY/YVYU), 2P(UV,VU), 3P
- YCbCr444 2P(UV,VU), 3P
- RGB565, ARGB1555, ARGB, ARGB, RGBA
- Pre-multiplexed ARGB, L8A8 and L8
output image format
- YCbCr420 2P(UV/VU), 3P
- YCbCr422 1P(YUYV/UYVY/YVYU), 2P(UV,VU), 3P
- YCbCr444 2P(UV,VU), 3P
- RGB565, ARGB1555, ARGB, ARGB, RGBA
- Pre-multiplexed ARGB
input rotation
- 0/90/180/270 degree, X/Y/XY Flip
scale ratio
- 1/4 scale down to 16 scale up
color space conversion
- RGB to YUV / YUV to RGB
Size - Exynos5420
- Input : 16x16 to 8192x8192
- Output: 4x4 to 8192x8192
Size - Exynos5410
- Input/Output: 4x4 to 4096x4096
alpha blending, color fill
Signed-off-by: Shaik Ameer Basha
Reviewed-by: Sylwester Nawrocki
---
drivers/media/platform/exynos-scaler/scaler-regs.c | 337
drivers/media/platform/exynos-scaler/scaler-regs.h | 331 +++
2 files changed, 668 insertions(+)
create mode 100644 drivers/media/platform/exynos-scaler/scaler-regs.c
create mode 100644 drivers/media/platform/exynos-scaler/scaler-regs.h
diff --git a/drivers/media/platform/exynos-scaler/scaler-regs.c
b/drivers/media/platform/exynos-scaler/scaler-regs.c
new file mode 100644
index 000..e9e8a60
--- /dev/null
+++ b/drivers/media/platform/exynos-scaler/scaler-regs.c
@@ -0,0 +1,337 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series SCALER driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+
+#include "scaler-regs.h"
+
+/* Scaler reset timeout in milliseconds */
+#define SCALER_RESET_TIMEOUT 5
+
+void scaler_hw_set_sw_reset(struct scaler_dev *dev)
+{
+ u32 cfg;
+
+ cfg = scaler_read(dev, SCALER_CFG);
+ cfg |= SCALER_CFG_SOFT_RESET;
+
+ scaler_write(dev, SCALER_CFG, cfg);
+}
+
+int scaler_wait_reset(struct scaler_dev *dev)
+{
+ unsigned long end = jiffies + msecs_to_jiffies(SCALER_RESET_TIMEOUT);
+ u32 cfg, reset_done = 0;
+
+ while (time_is_after_jiffies(end)) {
+ cfg = scaler_read(dev, SCALER_CFG);
+ if (!(cfg & SCALER_CFG_SOFT_RESET)) {
+ reset_done = 1;
+ break;
+ }
+ usleep_range(100, 200);
+ }
+
+ if (!reset_done)
+ return -EBUSY;
+
+ /*
+* Write any value to read/write register and read it back.
+* If the write and read value matches, then the reset process is
+* succeeded.
+*/
+ end = jiffies + msecs_to_jiffies(SCALER_RESET_TIMEOUT);
+ while (time_is_after_jiffies(end)) {
+ scaler_write(dev, SCALER_CFG_SOFT_RESET_CHECK_REG,
+ SCALER_CFG_SOFT_RESET_CHECK_VAL);
+ if (SCALER_CFG_SOFT_RESET_CHECK_VAL ==
+ scaler_read(dev, SCALER_CFG_SOFT_RESET_CHECK_REG))
+ return 0;
+ usleep_range(9000, 1);
+ }
+
+ return -EBUSY;
+}
+
+void scaler_hw_set_irq(struct scaler_dev *dev, int irq_num, bool enable)
+{
+ u32 cfg;
+
+ if ((irq_num < SCALER_INT_FRAME_END) ||
+ (irq_num > SCALER_INT_TIMEOUT))
+ return;
+
+ cfg = scaler_read(dev, SCALER_INT_EN);
+ if (enable)
+ cfg |= 1 << irq_num;
+ else
+ cfg &= ~(1 << irq_num);
+ scaler_write(dev, SCALER_INT_EN, cfg);
+}
+
+void scaler_hw_set_input_addr(struct scaler_dev *dev, struct scaler_addr *addr)
+{
+ scaler_dbg(dev, "src_buf: 0x%x, cb: 0x%x, cr: 0x%x",
+ addr->y, addr->cb, addr->cr);
+ scaler_write(dev, SCALER_SRC_Y_BASE, addr->y);
+ scaler_write(dev, SCALER_SRC_CB_BASE, addr->cb);
+ scaler_write(dev, SCALER_SRC_CR_BASE, addr->cr);
+}
+
+void scaler_hw_set_output_addr(struct scaler_dev *dev,
+struct scaler_addr *addr)
+{
+ scaler_dbg(dev, "dst_buf: 0x%x, cb: 0x%x, cr: 0x%x",
+ addr->y, addr->cb, addr->cr);
+ scaler_write(dev, SCALER_DST_Y_BASE, addr->y);
+ scaler_write(dev, SCALER_DST_CB_BASE, addr->cb);
+ scaler_write(dev, SCALER_DST_CR_BASE, addr->cr);
+}
+
+void scaler_hw_set_in_size(struct scaler_ctx *ctx)
+{
+ struct scaler_dev *dev = ctx->scaler_dev;
+ struct scaler_frame *frame = &ctx->s_frame;
+ u32 cfg;
+
+ /* set
[PATCH v6 3/4] [media] exynos-scaler: Add m2m functionality for the SCALER driver
This patch adds memory to memory (m2m) interface functionality
for the SCALER driver.
[arun...@samsung.com: fix compilation issues]
Signed-off-by: Shaik Ameer Basha
Signed-off-by: Arun Kumar K
Reviewed-by: Sylwester Nawrocki
---
drivers/media/platform/exynos-scaler/scaler-m2m.c | 788 +
1 file changed, 788 insertions(+)
create mode 100644 drivers/media/platform/exynos-scaler/scaler-m2m.c
diff --git a/drivers/media/platform/exynos-scaler/scaler-m2m.c
b/drivers/media/platform/exynos-scaler/scaler-m2m.c
new file mode 100644
index 000..7b21a17
--- /dev/null
+++ b/drivers/media/platform/exynos-scaler/scaler-m2m.c
@@ -0,0 +1,788 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series SCALER driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+
+#include
+
+#include "scaler-regs.h"
+
+#define SCALER_DEF_PIX_FMT V4L2_PIX_FMT_RGB32
+#define SCALER_DEF_WIDTH 1280
+#define SCALER_DEF_HEIGHT 720
+
+static int scaler_m2m_ctx_stop_req(struct scaler_ctx *ctx)
+{
+ struct scaler_ctx *curr_ctx;
+ struct scaler_dev *scaler = ctx->scaler_dev;
+ int ret;
+
+ curr_ctx = v4l2_m2m_get_curr_priv(scaler->m2m.m2m_dev);
+ if (!scaler_m2m_pending(scaler) || (curr_ctx != ctx))
+ return 0;
+
+ scaler_ctx_state_lock_set(SCALER_CTX_STOP_REQ, ctx);
+ ret = wait_event_timeout(scaler->irq_queue,
+ !scaler_ctx_state_is_set(SCALER_CTX_STOP_REQ, ctx),
+ SCALER_SHUTDOWN_TIMEOUT);
+
+ return ret == 0 ? -ETIMEDOUT : ret;
+}
+
+static int scaler_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
+{
+ struct scaler_ctx *ctx = q->drv_priv;
+ int ret;
+
+ ret = pm_runtime_get_sync(&ctx->scaler_dev->pdev->dev);
+
+ return ret > 0 ? 0 : ret;
+}
+
+static int scaler_m2m_stop_streaming(struct vb2_queue *q)
+{
+ struct scaler_ctx *ctx = q->drv_priv;
+ int ret;
+
+ ret = scaler_m2m_ctx_stop_req(ctx);
+ if (ret < 0)
+ scaler_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+
+ pm_runtime_put(&ctx->scaler_dev->pdev->dev);
+
+ return 0;
+}
+
+void scaler_m2m_job_finish(struct scaler_ctx *ctx, int vb_state)
+{
+ struct vb2_buffer *src_vb, *dst_vb;
+
+ if (!ctx || !ctx->m2m_ctx)
+ return;
+
+ src_vb = v4l2_m2m_src_buf_remove(ctx->m2m_ctx);
+ dst_vb = v4l2_m2m_dst_buf_remove(ctx->m2m_ctx);
+
+ if (src_vb && dst_vb) {
+ v4l2_m2m_buf_done(src_vb, vb_state);
+ v4l2_m2m_buf_done(dst_vb, vb_state);
+
+ v4l2_m2m_job_finish(ctx->scaler_dev->m2m.m2m_dev,
+ ctx->m2m_ctx);
+ }
+}
+
+static void scaler_m2m_job_abort(void *priv)
+{
+ struct scaler_ctx *ctx = priv;
+ int ret;
+
+ ret = scaler_m2m_ctx_stop_req(ctx);
+ if (ret < 0)
+ scaler_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+}
+
+static int scaler_get_bufs(struct scaler_ctx *ctx)
+{
+ struct scaler_frame *s_frame, *d_frame;
+ struct vb2_buffer *src_vb, *dst_vb;
+ int ret;
+
+ s_frame = &ctx->s_frame;
+ d_frame = &ctx->d_frame;
+
+ src_vb = v4l2_m2m_next_src_buf(ctx->m2m_ctx);
+ ret = scaler_prepare_addr(ctx, src_vb, s_frame, &s_frame->addr);
+ if (ret < 0)
+ return ret;
+
+ dst_vb = v4l2_m2m_next_dst_buf(ctx->m2m_ctx);
+ ret = scaler_prepare_addr(ctx, dst_vb, d_frame, &d_frame->addr);
+ if (ret < 0)
+ return ret;
+
+ dst_vb->v4l2_buf.timestamp = src_vb->v4l2_buf.timestamp;
+
+ return 0;
+}
+
+static void scaler_m2m_device_run(void *priv)
+{
+ struct scaler_ctx *ctx = priv;
+ struct scaler_dev *scaler;
+ unsigned long flags;
+ int ret;
+ bool is_stopped;
+
+ if (WARN(!ctx, "Null hardware context\n"))
+ return;
+
+ scaler = ctx->scaler_dev;
+ spin_lock_irqsave(&scaler->slock, flags);
+
+ set_bit(ST_M2M_PEND, &scaler->state);
+
+ /* Reconfigure hardware if the context has changed. */
+ if (scaler->m2m.ctx != ctx) {
+ scaler_dbg(scaler, "scaler->m2m.ctx = 0x%p, current_ctx = 0x%p",
+ scaler->m2m.ctx, ctx);
+ ctx->state |= SCALER_PARAMS;
+ scaler->m2m.ctx = ctx;
+ }
+
+ is_stopped = ctx->state & SCALER_CTX_STOP_REQ;
+ ctx->state &= ~SCALER_CTX_STOP_REQ;
+ if (is_stopped) {
+ wake_up(&scaler->irq_queue);
+ goto unlock;
+ }
+
+ ret = scaler_get_bufs(ctx);
+ if (ret < 0) {
+ scaler_dbg(scaler, "Wrong address\n");
+
[PATCH v6 4/4] [media] exynos-scaler: Add core functionality for the SCALER driver
This patch adds the Makefile and core functionality for the SCALER driver.
Signed-off-by: Shaik Ameer Basha
Reviewed-by: Sylwester Nawrocki
---
drivers/media/platform/Kconfig|8 +
drivers/media/platform/Makefile |1 +
drivers/media/platform/exynos-scaler/Makefile |3 +
drivers/media/platform/exynos-scaler/scaler.c | 1235 +
drivers/media/platform/exynos-scaler/scaler.h | 376
5 files changed, 1623 insertions(+)
create mode 100644 drivers/media/platform/exynos-scaler/Makefile
create mode 100644 drivers/media/platform/exynos-scaler/scaler.c
create mode 100644 drivers/media/platform/exynos-scaler/scaler.h
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c137abf..7cdec24 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -196,6 +196,14 @@ config VIDEO_SAMSUNG_EXYNOS_GSC
help
This is a v4l2 driver for Samsung EXYNOS5 SoC G-Scaler.
+config VIDEO_SAMSUNG_EXYNOS_SCALER
+ tristate "Samsung Exynos SCALER driver"
+ depends on VIDEO_DEV && VIDEO_V4L2 && (SOC_EXYNOS5410 || SOC_EXYNOS5420)
+ select VIDEOBUF2_DMA_CONTIG
+ select V4L2_MEM2MEM_DEV
+ help
+ This is a v4l2 driver for Samsung EXYNOS5410/5420 SoC SCALER.
+
config VIDEO_SH_VEU
tristate "SuperH VEU mem2mem video processing driver"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index e5269da..0f774ba 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV)+= s5p-tv/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)+= s5p-g2d/
obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/
+obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_SCALER) += exynos-scaler/
obj-$(CONFIG_BLACKFIN) += blackfin/
diff --git a/drivers/media/platform/exynos-scaler/Makefile
b/drivers/media/platform/exynos-scaler/Makefile
new file mode 100644
index 000..6c8a25b
--- /dev/null
+++ b/drivers/media/platform/exynos-scaler/Makefile
@@ -0,0 +1,3 @@
+exynos-scaler-objs := scaler.o scaler-m2m.o scaler-regs.o
+
+obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_SCALER) += exynos-scaler.o
diff --git a/drivers/media/platform/exynos-scaler/scaler.c
b/drivers/media/platform/exynos-scaler/scaler.c
new file mode 100644
index 000..6005651
--- /dev/null
+++ b/drivers/media/platform/exynos-scaler/scaler.c
@@ -0,0 +1,1235 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series SCALER driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "scaler-regs.h"
+
+#define SCALER_CLOCK_GATE_NAME "scaler"
+
+static const struct scaler_fmt scaler_formats[] = {
+ {
+ .name = "YUV 4:2:0 non-contig. 2p, Y/CbCr",
+ .pixelformat= V4L2_PIX_FMT_NV12M,
+ .depth = { 8, 4 },
+ .color = SCALER_YUV420,
+ .color_order= SCALER_CBCR,
+ .num_planes = 2,
+ .num_comp = 2,
+ .scaler_color = SCALER_YUV420_2P_Y_UV,
+ .flags = SCALER_FMT_SRC | SCALER_FMT_DST,
+
+ }, {
+ .name = "YUV 4:2:0 contig. 2p, Y/CbCr",
+ .pixelformat= V4L2_PIX_FMT_NV12,
+ .depth = { 12 },
+ .color = SCALER_YUV420,
+ .color_order= SCALER_CBCR,
+ .num_planes = 1,
+ .num_comp = 2,
+ .scaler_color = SCALER_YUV420_2P_Y_UV,
+ .flags = SCALER_FMT_SRC | SCALER_FMT_DST,
+ }, {
+ .name = "YUV 4:2:0 n.c. 2p, Y/CbCr tiled",
+ .pixelformat= V4L2_PIX_FMT_NV12MT_16X16,
+ .depth = { 8, 4 },
+ .color = SCALER_YUV420,
+ .color_order= SCALER_CBCR,
+ .num_planes = 2,
+ .num_comp = 2,
+ .scaler_color = SCALER_YUV420_2P_Y_UV,
+ .flags = SCALER_FMT_SRC | SCALER_FMT_TILED,
+ }, {
+ .name = "YUV 4:2:2 contig. 2p, Y/CbCr",
+ .pixelformat= V4L2_PIX_FMT_NV16,
+ .depth = { 16 },
+ .color = SCALER_YUV422,
+ .color_order= SCALER_CBCR,
+ .num_planes = 1,
+ .num_comp = 2,
+ .scaler_color = SCALER_YUV422_2P_Y_UV,
+ .flags = SCALER_FMT_SRC | SCALER_FMT_DST,
+ }, {
+
[PATCH v6 1/4] [media] exynos-scaler: Add DT bindings for SCALER driver
This patch adds the DT binding documentation for the Exynos5420/5410
based SCALER device driver.
Signed-off-by: Shaik Ameer Basha
Reviewed-by: Sylwester Nawrocki
---
.../devicetree/bindings/media/exynos5-scaler.txt | 24
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/exynos5-scaler.txt
diff --git a/Documentation/devicetree/bindings/media/exynos5-scaler.txt
b/Documentation/devicetree/bindings/media/exynos5-scaler.txt
new file mode 100644
index 000..e1dd465
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/exynos5-scaler.txt
@@ -0,0 +1,24 @@
+* Samsung Exynos5 SCALER device
+
+SCALER is used for scaling, blending, color fill and color space
+conversion on EXYNOS[5420/5410] SoCs.
+
+Required properties:
+- compatible: should be "samsung,exynos5420-scaler" or
+ "samsung,exynos5410-scaler"
+- reg: should contain SCALER physical address location and length
+- interrupts: should contain SCALER interrupt specifier
+- clocks: should contain the SCALER clock phandle and specifier pair for
+ each clock listed in clock-names property, according to
+ the common clock bindings
+- clock-names: should contain exactly one entry
+ - "scaler" - IP bus clock
+
+Example:
+ scaler_0: scaler@1280 {
+ compatible = "samsung,exynos5420-scaler";
+ reg = <0x1280 0x1000>;
+ interrupts = <0 220 0>;
+ clocks = <&clock 381>;
+ clock-names = "scaler";
+ };
--
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 v6 0/4] Exynos5 Series SCALER Driver
This patch adds support for SCALER device which is a new device for scaling, blending, color fill and color space conversion on EXYNOS5410/5420 SoCs. This device supports the following as key features. input image format - YCbCr420 2P(UV/VU), 3P - YCbCr422 1P(YUYV/UYVY/YVYU), 2P(UV,VU), 3P - YCbCr444 2P(UV,VU), 3P - RGB565, ARGB1555, ARGB, ARGB, RGBA - Pre-multiplexed ARGB, L8A8 and L8 output image format - YCbCr420 2P(UV/VU), 3P - YCbCr422 1P(YUYV/UYVY/YVYU), 2P(UV,VU), 3P - YCbCr444 2P(UV,VU), 3P - RGB565, ARGB1555, ARGB, ARGB, RGBA - Pre-multiplexed ARGB input rotation - 0/90/180/270 degree, X/Y/XY Flip scale ratio - 1/4 scale down to 16 scale up color space conversion - RGB to YUV / YUV to RGB Size - Exynos5420 - Input : 16x16 to 8192x8192 - Output: 4x4 to 8192x8192 Size - Exynos5410 - Input/Output: 4x4 to 4096x4096 alpha blending, color fill Rebased on: --- git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git:master Changes from v5: --- Addressed review comments from, Bartlomiej Zolnierkiewicz and Tomasz Figa Links to the review comments: 1] https://linuxtv.org/patch/21512/ 2] https://linuxtv.org/patch/21513/ 3] https://linuxtv.org/patch/21514/ Changes from v4: --- Addressed review comments from, Sylwester Nawrocki and Mauro Carvalho Chehab Links to the review comments: 1] https://linuxtv.org/patch/20307/ 2] https://linuxtv.org/patch/20308/ 3] https://linuxtv.org/patch/20451/ Changes from v3: --- Addressed review comments from, Sylwester Nawrocki and Hans Verkuil. Links to the review comments: 1] https://linuxtv.org/patch/20072/ 2] https://linuxtv.org/patch/20073/ Changes from v2: --- Addressed review comments from, Inki Dae, Hans Verkuil and Sylwester Nawrocki. Links to the review comments: 1] https://linuxtv.org/patch/19783/ 2] https://linuxtv.org/patch/19784/ 3] https://linuxtv.org/patch/19785/ 4] https://linuxtv.org/patch/19786/ 5] https://linuxtv.org/patch/19787/ Changes from v1: --- 1] Split the previous single patch into multiple patches. 2] Added DT binding documentation. 3] Removed the unnecessary header file inclusions. 4] Fix the condition check in mscl_prepare_address for swapping cb/cr addresses. Shaik Ameer Basha (4): [media] exynos-scaler: Add DT bindings for SCALER driver [media] exynos-scaler: Add new driver for Exynos5 SCALER [media] exynos-scaler: Add m2m functionality for the SCALER driver [media] exynos-scaler: Add core functionality for the SCALER driver .../devicetree/bindings/media/exynos5-scaler.txt | 24 + drivers/media/platform/Kconfig |8 + drivers/media/platform/Makefile|1 + drivers/media/platform/exynos-scaler/Makefile |3 + drivers/media/platform/exynos-scaler/scaler-m2m.c | 788 + drivers/media/platform/exynos-scaler/scaler-regs.c | 337 ++ drivers/media/platform/exynos-scaler/scaler-regs.h | 331 ++ drivers/media/platform/exynos-scaler/scaler.c | 1235 drivers/media/platform/exynos-scaler/scaler.h | 376 ++ 9 files changed, 3103 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/exynos5-scaler.txt create mode 100644 drivers/media/platform/exynos-scaler/Makefile create mode 100644 drivers/media/platform/exynos-scaler/scaler-m2m.c create mode 100644 drivers/media/platform/exynos-scaler/scaler-regs.c create mode 100644 drivers/media/platform/exynos-scaler/scaler-regs.h create mode 100644 drivers/media/platform/exynos-scaler/scaler.c create mode 100644 drivers/media/platform/exynos-scaler/scaler.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
