Re: [PATCH v3 08/19] s5p-fimc: Add the media device driver
Hi Sylwester,
On 07/04/2011 11:24 PM, Sylwester Nawrocki wrote:
The fimc media device driver is hooked onto "s5p-fimc-md" platform device.
Such a platform device need to be added in a board initialization code
and then camera sensors need to be specified as it's platform data.
The "s5p-fimc-md" device is a top level entity for all FIMC, mipi-csis
and sensor devices.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/Kconfig |2 +-
drivers/media/video/s5p-fimc/Makefile |2 +-
...
/* -*/
/* fimc-capture.c */
diff --git a/drivers/media/video/s5p-fimc/fimc-mdevice.c
b/drivers/media/video/s5p-fimc/fimc-mdevice.c
new file mode 100644
index 000..10c8d5d
--- /dev/null
+++ b/drivers/media/video/s5p-fimc/fimc-mdevice.c
@@ -0,0 +1,804 @@
...
+
+static int fimc_md_register_sensor_entities(struct fimc_md *fmd)
+{
+ struct s5p_platform_fimc *pdata = fmd->pdev->dev.platform_data;
+ struct fimc_dev *fd = NULL;
+ int num_clients, ret, i;
+
+ /*
+* Runtime resume one of the FIMC entities to make sure
+* the sclk_cam clocks are not globally disabled.
+*/
+ for (i = 0; !fd&& i< ARRAY_SIZE(fmd->fimc); i++)
+ if (fmd->fimc[i])
+ fd = fmd->fimc[i];
+ if (!fd)
+ return -ENXIO;
+ ret = pm_runtime_get_sync(&fd->pdev->dev);
+ if (ret< 0)
+ return ret;
+
+ WARN_ON(pdata->num_clients> ARRAY_SIZE(fmd->sensor));
+ num_clients = min_t(u32, pdata->num_clients, ARRAY_SIZE(fmd->sensor));
+
+ fmd->num_sensors = num_clients;
+ for (i = 0; i< num_clients; i++) {
+ fmd->sensor[i].pdata =&pdata->isp_info[i];
+ ret = __fimc_md_set_camclk(fmd,&fmd->sensor[i], true);
+ if (ret)
+ break;
+ fmd->sensor[i].subdev =
+ fimc_md_register_sensor(fmd,&fmd->sensor[i]);
There is an issue here. Function fimc_md_register_sensor(), can return
subdev, as also error codes when i2c_get_adapter() or NULL when
v4l2_i2c_new_subdev_board() fail. But we do not invalidate, and assume
the return value is valid subdev. It will cause kernel NULL pointer
exception later in fimc_md_create_links().
+ ret = __fimc_md_set_camclk(fmd,&fmd->sensor[i], false);
+ if (ret)
+ break;
+ }
+ pm_runtime_put(&fd->pdev->dev);
+ return ret;
+}
+
+/*
+ * MIPI CSIS and FIMC platform devices registration.
+ */
Regards,
Subash
SISO-SLG
--
To unsubscribe from this list: send the line "unsubscribe linux-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 03-1/13] DMA: PL330: Support DMA_SLAVE_CONFIG command
On Wed, Jul 20, 2011 at 4:16 PM, Boojin Kim wrote:
> Signed-off-by: Boojin Kim
> Signed-off-by: Kukjin Kim
> ---
> drivers/dma/pl330.c | 53 +-
> 1 files changed, 39 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 586ab39..880f010 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -256,25 +256,50 @@ static int pl330_alloc_chan_resources(struct dma_chan
> *chan)
> static int pl330_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
> unsigned long arg)
> {
> struct dma_pl330_chan *pch = to_pchan(chan);
> - struct dma_pl330_desc *desc;
> + struct dma_pl330_desc *desc, *_dt;
> unsigned long flags;
> + struct dma_pl330_dmac *pdmac = pch->dmac;
> + struct dma_slave_config *slave_config;
> + struct dma_pl330_peri *peri;
> + LIST_HEAD(list);
>
> - /* Only supports DMA_TERMINATE_ALL */
> - if (cmd != DMA_TERMINATE_ALL)
> - return -ENXIO;
> -
> - spin_lock_irqsave(&pch->lock, flags);
> -
> - /* FLUSH the PL330 Channel thread */
> - pl330_chan_ctrl(pch->pl330_chid, PL330_OP_FLUSH);
> + switch (cmd) {
> + case DMA_TERMINATE_ALL:
> + spin_lock_irqsave(&pch->lock, flags);
>
> - /* Mark all desc done */
> - list_for_each_entry(desc, &pch->work_list, node)
> - desc->status = DONE;
> + /* FLUSH the PL330 Channel thread */
> + pl330_chan_ctrl(pch->pl330_chid, PL330_OP_FLUSH);
>
> - spin_unlock_irqrestore(&pch->lock, flags);
> + /* Mark all desc done */
> + list_for_each_entry_safe(desc, _dt, &pch->work_list , node) {
> + desc->status = DONE;
> + pch->completed = desc->txd.cookie;
> + list_move_tail(&desc->node, &list);
> + }
>
> - pl330_tasklet((unsigned long) pch);
> + list_splice_tail_init(&list, &pdmac->desc_pool);
> + spin_unlock_irqrestore(&pch->lock, flags);
> + break;
> + case DMA_SLAVE_CONFIG:
> + slave_config = (struct dma_slave_config *)arg;
> + peri = pch->chan.private;
> +
> + if (slave_config->direction == DMA_TO_DEVICE) {
> + if (slave_config->dst_addr)
> + peri->fifo_addr = slave_config->dst_addr;
> + if (slave_config->dst_addr_width)
> + peri->burst_sz =
> __ffs(slave_config->dst_addr_width);
> + } else if (slave_config->direction == DMA_FROM_DEVICE) {
> + if (slave_config->src_addr)
> + peri->fifo_addr = slave_config->src_addr;
> + if (slave_config->src_addr_width)
> + peri->burst_sz =
> __ffs(slave_config->src_addr_width);
> + }
> + break;
As discussed yesterday, DMA_SLAVE_CONFIG is assumed to be madatory,
so please dismantle the 'struct dma_pl330_peri', move fifo_addr,
burst_sz and rqtype
to 'struct dma_pl330_chan' and poison them - that will force clients
to do DMA_SLAVE_CONFIG. Move 'peri_id' to 'struct dma_pl330_platdata'
And protect the changes to channel parameters with lock.
--
To unsubscribe from this list: send the line "unsubscribe linux-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] I2C: Samsung: Add support for PM_runtime in the I2C driver.
On Mon, Mar 28, 2011 at 4:41 AM, Ben Dooks wrote:
> On Sun, Mar 27, 2011 at 04:32:43PM -0400, Amit Daniel Kachhap wrote:
>> This patch adds PM runtime management support in the I2C driver.
>> The functionality of the driver is not modified much but some extra I2C
>> states are added for PM runtime. The runtime suspend keeps the interrupt
>> for the I2C interface disabled.
>
> ok, whilst this looks ok, it's too late for the current merge window,
> so will go into the -next for the next kernel
>
Hi Ben,
I do not see this patch in your i2c-next branch. Could you please
merge this patch in the next merge window.
Thanks,
Amit Daniel
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> drivers/i2c/busses/i2c-s3c2410.c | 61
>> +-
>> 1 files changed, 53 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-s3c2410.c
>> b/drivers/i2c/busses/i2c-s3c2410.c
>> index 6c00c10..8ebe621 100644
>> --- a/drivers/i2c/busses/i2c-s3c2410.c
>> +++ b/drivers/i2c/busses/i2c-s3c2410.c
>> @@ -35,6 +35,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> @@ -48,7 +49,9 @@ enum s3c24xx_i2c_state {
>> STATE_START,
>> STATE_READ,
>> STATE_WRITE,
>> - STATE_STOP
>> + STATE_STOP,
>> + STATE_STANDBY,
>> + STATE_SUSPEND
>> };
>>
>> enum s3c24xx_i2c_type {
>> @@ -59,7 +62,6 @@ enum s3c24xx_i2c_type {
>> struct s3c24xx_i2c {
>> spinlock_t lock;
>> wait_queue_head_t wait;
>> - unsigned int suspended:1;
>>
>> struct i2c_msg *msg;
>> unsigned int msg_num;
>> @@ -400,8 +402,13 @@ static int i2s_s3c_irq_nextbyte(struct s3c24xx_i2c
>> *i2c, unsigned long iicstat)
>> i2c->msg++;
>> }
>> }
>> + break;
>>
>> + default:
>> + dev_err(i2c->dev, "%s: called with invalid state\n", __func__);
>> + goto out;
>> break;
>> +
>> }
>>
>> /* acknowlegde the IRQ and get back on with the work */
>> @@ -485,7 +492,7 @@ static int s3c24xx_i2c_doxfer(struct s3c24xx_i2c *i2c,
>> int spins = 20;
>> int ret;
>>
>> - if (i2c->suspended)
>> + if (i2c->state == STATE_SUSPEND)
>> return -EIO;
>>
>> ret = s3c24xx_i2c_set_master(i2c);
>> @@ -555,12 +562,14 @@ static int s3c24xx_i2c_xfer(struct i2c_adapter *adap,
>> int ret;
>>
>> clk_enable(i2c->clk);
>> + pm_runtime_get_sync(i2c->dev);
>>
>> for (retry = 0; retry < adap->retries; retry++) {
>>
>> ret = s3c24xx_i2c_doxfer(i2c, msgs, num);
>>
>> if (ret != -EAGAIN) {
>> + pm_runtime_put_sync(i2c->dev);
>> clk_disable(i2c->clk);
>> return ret;
>> }
>> @@ -570,6 +579,7 @@ static int s3c24xx_i2c_xfer(struct i2c_adapter *adap,
>> udelay(100);
>> }
>>
>> + pm_runtime_put_sync(i2c->dev);
>> clk_disable(i2c->clk);
>> return -EREMOTEIO;
>> }
>> @@ -912,10 +922,14 @@ static int s3c24xx_i2c_probe(struct platform_device
>> *pdev)
>> goto err_cpufreq;
>> }
>>
>> + /*Set Initial I2C state*/
>> + i2c->state = STATE_STANDBY;
>> +
>> platform_set_drvdata(pdev, i2c);
>>
>> dev_info(&pdev->dev, "%s: S3C I2C adapter\n",
>> dev_name(&i2c->adap.dev));
>> clk_disable(i2c->clk);
>> + pm_runtime_enable(&pdev->dev);
>> return 0;
>>
>> err_cpufreq:
>> @@ -956,6 +970,7 @@ static int s3c24xx_i2c_remove(struct platform_device
>> *pdev)
>>
>> clk_disable(i2c->clk);
>> clk_put(i2c->clk);
>> + pm_runtime_disable(&pdev->dev);
>>
>> iounmap(i2c->regs);
>>
>> @@ -972,9 +987,9 @@ static int s3c24xx_i2c_suspend_noirq(struct device *dev)
>> struct platform_device *pdev = to_platform_device(dev);
>> struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev);
>>
>> - i2c->suspended = 1;
>> -
>> + i2c->state = STATE_SUSPEND;
>> return 0;
>> +
>> }
>>
>> static int s3c24xx_i2c_resume(struct device *dev)
>> @@ -982,17 +997,47 @@ static int s3c24xx_i2c_resume(struct device *dev)
>> struct platform_device *pdev = to_platform_device(dev);
>> struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev);
>>
>> - i2c->suspended = 0;
>> clk_enable(i2c->clk);
>> s3c24xx_i2c_init(i2c);
>> + i2c->state = STATE_STANDBY;
>> clk_disable(i2c->clk);
>>
>> return 0;
>> }
>>
>> +static int s3c_i2c_runtime_suspend(struct device *dev)
>> +{
>> + struct platform_device *pdev = to_platform_device(dev);
>> + struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev);
>> +
>> + i2c->state = STATE_STANDBY;
>> + s3c24xx_i2c_disable_irq(i2c);
>> + s3c24xx_i2c_disable_ack(i2c);
>> +
>> + return 0;
>> +}
>> +
>> +static int s3c_i2c_runtime_resume(struct device *dev)
>> +{
>> + struct platform_device
RE: [PATCH V8 4/5] video: s3c-fb: Add support EXYNOS4 FIMD
Hi Paul,
Other patches were commited to 'linux-arm-soc.git'.
Please, commit this patch '[PATCH V8 4/5] video: s3c-fb: Add support EXYNOS4
FIMD' to 'fbdev-2.6'.
Thanks,
Jingoo Han
Jingoo Han wrote:
> -Original Message-
> Subject: [PATCH V8 4/5] video: s3c-fb: Add support EXYNOS4 FIMD
>
> This patch adds struct s3c_fb_driverdata s3c_fb_data_exynos4 for EXYNOS4
> and adds lcd clock gating support.
>
> FIMD driver needs two clocks for FIMD IP and LCD pixel clock. Previously,
> both clocks are provided by using bus clock such as HCLK. However, EXYNOS4
> can not select HCLK for LCD pixel clock because the EXYNOS4 FIMD IP does
> not
> have the CLKSEL bit of VIDCON0. So, FIMD driver should provide the lcd
> clock
> using SCLK_FIMD as LCD pixel clock for EXYNOS4.
>
> The driver selects enabling lcd clock according to has_clksel which means
> the CLKSEL bit of VIDCON0. If there is has_clksel, the driver will not
> enable the lcd clock using SCLK_FIMD because bus clock using HCLK is used
> a LCD pixel clock.
>
> Signed-off-by: Jingoo Han
> ---
> drivers/video/Kconfig |2 +-
> drivers/video/s3c-fb.c | 88
> +--
> 2 files changed, 85 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 549b960..963b8b7 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2027,7 +2027,7 @@ config FB_TMIO_ACCELL
>
> config FB_S3C
> tristate "Samsung S3C framebuffer support"
> - depends on FB && S3C_DEV_FB
> + depends on FB && (S3C_DEV_FB || S5P_DEV_FIMD0)
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 4aecf21..cb0d3ea 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -81,6 +81,7 @@ struct s3c_fb;
> * @palette: Address of palette memory, or 0 if none.
> * @has_prtcon: Set if has PRTCON register.
> * @has_shadowcon: Set if has SHADOWCON register.
> + * @has_clksel: Set if VIDCON0 register has CLKSEL bit.
> */
> struct s3c_fb_variant {
> unsigned intis_2443:1;
> @@ -98,6 +99,7 @@ struct s3c_fb_variant {
>
> unsigned inthas_prtcon:1;
> unsigned inthas_shadowcon:1;
> + unsigned inthas_clksel:1;
> };
>
> /**
> @@ -186,6 +188,7 @@ struct s3c_fb_vsync {
> * @dev: The device that we bound to, for printing, etc.
> * @regs_res: The resource we claimed for the IO registers.
> * @bus_clk: The clk (hclk) feeding our interface and possibly pixclk.
> + * @lcd_clk: The clk (sclk) feeding pixclk.
> * @regs: The mapped hardware registers.
> * @variant: Variant information for this hardware.
> * @enabled: A bitmask of enabled hardware windows.
> @@ -200,6 +203,7 @@ struct s3c_fb {
> struct device *dev;
> struct resource *regs_res;
> struct clk *bus_clk;
> + struct clk *lcd_clk;
> void __iomem*regs;
> struct s3c_fb_variantvariant;
>
> @@ -336,10 +340,15 @@ static int s3c_fb_check_var(struct fb_var_screeninfo
> *var,
> */
> static int s3c_fb_calc_pixclk(struct s3c_fb *sfb, unsigned int pixclk)
> {
> - unsigned long clk = clk_get_rate(sfb->bus_clk);
> + unsigned long clk;
> unsigned long long tmp;
> unsigned int result;
>
> + if (sfb->variant.has_clksel)
> + clk = clk_get_rate(sfb->bus_clk);
> + else
> + clk = clk_get_rate(sfb->lcd_clk);
> +
> tmp = (unsigned long long)clk;
> tmp *= pixclk;
>
> @@ -1354,13 +1363,24 @@ static int __devinit s3c_fb_probe(struct
> platform_device *pdev)
>
> clk_enable(sfb->bus_clk);
>
> + if (!sfb->variant.has_clksel) {
> + sfb->lcd_clk = clk_get(dev, "sclk_fimd");
> + if (IS_ERR(sfb->lcd_clk)) {
> + dev_err(dev, "failed to get lcd clock\n");
> + ret = PTR_ERR(sfb->lcd_clk);
> + goto err_bus_clk;
> + }
> +
> + clk_enable(sfb->lcd_clk);
> + }
> +
> pm_runtime_enable(sfb->dev);
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!res) {
> dev_err(dev, "failed to find registers\n");
> ret = -ENOENT;
> - goto err_clk;
> + goto err_lcd_clk;
> }
>
> sfb->regs_res = request_mem_region(res->start, resource_size(res),
> @@ -1368,7 +1388,7 @@ static int __devinit s3c_fb_probe(struct
> platform_device *pdev)
> if (!sfb->regs_res) {
> dev_err(dev, "failed to claim register region\n");
> ret = -ENOENT;
> - goto err_clk;
> + goto err_lcd_clk;
> }
>
> sfb->regs = ioremap(res->start, resource_size(res));
> @@ -1450,7 +1470,13 @@ err_ioremap:
> err_req_region:
> release_mem_region(sfb->regs_res->start, resource_size(sfb-
> >regs_res));
>
>
[RFC][PATCH] gpio: Add device tree support for exynos4
Exynos4 GPIO helper functions registers each bank of GPIO as a gpio chip.
For each gpio chip being registered, this patch finds a matching node
in device tree and attaches the node pointer to the gpio chip. The match
is based on the compatible property of the node.
Signed-off-by: Thomas Abraham
---
Each gpio controller is listed as below in the dts file.
gpa0: gpio-controller@1140 {
compatible = "samsung,exynos4-gpio-gpa0","samsung,exynos4-gpio";
#gpio-cells = <2>;
gpio-controller;
};
gpa1: gpio-controller@11400020 {
compatible = "samsung,exynos4-gpio-gpa1","samsung,exynos4-gpio";
#gpio-cells = <2>;
gpio-controller;
};
gpb: gpio-controller@11400040 {
compatible = "samsung,exynos4-gpio-gpb","samsung,exynos4-gpio";
#gpio-cells = <2>;
gpio-controller;
};
and many more (gpc, gpd, , gpx)
For each linux domain gpio chip registered by the exynos4 gpio helpers,
a matching device node is found from the device tree by matching the
compatible property.
drivers/gpio/gpio-exynos4.c | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-exynos4.c b/drivers/gpio/gpio-exynos4.c
index 9029835..c727bf1 100644
--- a/drivers/gpio/gpio-exynos4.c
+++ b/drivers/gpio/gpio-exynos4.c
@@ -14,6 +14,10 @@
#include
#include
#include
+#ifdef CONFIG_OF
+#include
+#include
+#endif
#include
@@ -321,6 +325,29 @@ static struct s3c_gpio_chip exynos4_gpio_part3_4bit[] = {
},
};
+#ifdef CONFIG_OF
+static __init void exynos4_gpiolib_attach_ofnode(struct gpio_chip *gc)
+{
+ const char exynos4_gpio_compat_base[] = "samsung,exynos4-gpio-";
+ char *exynos4_gpio_compat;
+
+ exynos4_gpio_compat = kzalloc(strlen(exynos4_gpio_compat_base) +
+ strlen(gc->label), GFP_KERNEL);
+ if (!exynos4_gpio_compat)
+ return;
+
+ strcpy(exynos4_gpio_compat, exynos4_gpio_compat_base);
+ strcat(exynos4_gpio_compat, gc->label);
+ gc->of_node = of_find_compatible_node(NULL, NULL, exynos4_gpio_compat);
+ kfree(exynos4_gpio_compat);
+}
+#else
+static __init void exynos4_gpiolib_attach_ofnode(struct gpio_chip *chip)
+{
+ return;
+}
+#endif
+
static __init int exynos4_gpiolib_init(void)
{
struct s3c_gpio_chip *chip;
@@ -341,6 +368,7 @@ static __init int exynos4_gpiolib_init(void)
}
if (chip->base == NULL)
chip->base = S5P_VA_GPIO1 + (i) * 0x20;
+ exynos4_gpiolib_attach_ofnode(&chip->chip);
}
samsung_gpiolib_add_4bit_chips(exynos4_gpio_part1_4bit, nr_chips);
@@ -358,6 +386,7 @@ static __init int exynos4_gpiolib_init(void)
}
if (chip->base == NULL)
chip->base = S5P_VA_GPIO2 + (i) * 0x20;
+ exynos4_gpiolib_attach_ofnode(&chip->chip);
}
samsung_gpiolib_add_4bit_chips(exynos4_gpio_part2_4bit, nr_chips);
@@ -375,6 +404,7 @@ static __init int exynos4_gpiolib_init(void)
}
if (chip->base == NULL)
chip->base = S5P_VA_GPIO3 + (i) * 0x20;
+ exynos4_gpiolib_attach_ofnode(&chip->chip);
}
samsung_gpiolib_add_4bit_chips(exynos4_gpio_part3_4bit, nr_chips);
--
1.6.6.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-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 03-1/13] DMA: PL330: Support DMA_SLAVE_CONFIG command
On Thu, Jul 21, 2011 at 09:26:22PM +0530, Jassi Brar wrote: > Though you might want to consider changing the DMA_SLAVE_CONFIG API from > optional to mandatory for Slave capable DMACs. Otherwise I don't see common > client drivers working over different DMACs. Yes, I think we will have to, otherwise we can't ensure we have cross- compatibility between different DMA engine implementations. We already have platforms where we have peripheral drivers making use of several different DMA engine implementations, so nailing this down now, before the number of DMA engine implementations increases still further is definitely something that needs doing. -- To unsubscribe from this list: send the line "unsubscribe linux-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 03-1/13] DMA: PL330: Support DMA_SLAVE_CONFIG command
On Thu, Jul 21, 2011 at 8:53 PM, Russell King - ARM Linux wrote: > On Thu, Jul 21, 2011 at 08:42:40PM +0530, Jassi Brar wrote: >> On Thu, Jul 21, 2011 at 4:59 PM, Russell King - ARM Linux >> wrote: >> > Does your hardware have a hardware block from the device itself containing >> > all the systems FIFOs ? >> I am not sure what you ask, but let me say what I know. >> In this case atleast, all PL330 DMA channels have fixed source/destination >> address on the device side. So it's not like developer doesn't know >> fifo_addr here. > > Even so, your approach is _conceptually_ wrong. Think about it. > > You declare your devices giving the bus address where they're located. > So, lets say for argument that your UART is located at 0x10001000. > > Your UART driver knows that the FIFO register is at offset 0x20 from > the base address. Your platform data provides the UART driver with a > DMA match function and data specific for that match function. This > data encodes the specific DMA channel. > > Now, why should you have to encode into the DMA drivers platform data > that DMA channel X has its FIFO at 0x10001020? Not only do you have > to declare the base address of the UART but also you have to know the > offset into the UART. > > Why not just let the UART driver - which knows that the base address > is 0x10001000, and the FIFO is at offset 0x20 above that - tell the > DMA driver that's where the FIFO is located? Yes I understand, the idea was to avoid optional DMA_SLAVE_CONFIG call. Apparently we give different weightage to the pros and cons. Anyways, I accept your opinion. Though you might want to consider changing the DMA_SLAVE_CONFIG API from optional to mandatory for Slave capable DMACs. Otherwise I don't see common client drivers working over different DMACs. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 03-1/13] DMA: PL330: Support DMA_SLAVE_CONFIG command
On Thu, Jul 21, 2011 at 07:58:03PM +0530, Jassi Brar wrote: > While that does make sense, it makes mandatory the ritual of calling > DMA_SLAVE_CONFIG mandatory for most of the cases. > And I think the effort to set fifo_addr for peripherals is overrated. You have to do that anyway. You're dealing with DMA engine drivers which you don't know the implementation details of. Think about it for a moment, please. The point of the DMA engine abstraction is to make DMA users independent of the DMA engine actually being used. That means all DMA engine drivers and all DMA engine users have to provide a basic set of information to allow them to interact with each other. Encoding random bits of information into inappropriate places like FIFO addresses into DMA engine platform data just means you might was well stay with your private API, because that driver may never be able to work with another DMA engine implementation. So please, either do the job properly, or don't waste peoples time with a half hearted mess of inappropriate platform data. -- To unsubscribe from this list: send the line "unsubscribe linux-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 03-1/13] DMA: PL330: Support DMA_SLAVE_CONFIG command
On Thu, Jul 21, 2011 at 08:42:40PM +0530, Jassi Brar wrote: > On Thu, Jul 21, 2011 at 4:59 PM, Russell King - ARM Linux > wrote: > > Does your hardware have a hardware block from the device itself containing > > all the systems FIFOs ? > I am not sure what you ask, but let me say what I know. > In this case atleast, all PL330 DMA channels have fixed source/destination > address on the device side. So it's not like developer doesn't know > fifo_addr here. Even so, your approach is _conceptually_ wrong. Think about it. You declare your devices giving the bus address where they're located. So, lets say for argument that your UART is located at 0x10001000. Your UART driver knows that the FIFO register is at offset 0x20 from the base address. Your platform data provides the UART driver with a DMA match function and data specific for that match function. This data encodes the specific DMA channel. Now, why should you have to encode into the DMA drivers platform data that DMA channel X has its FIFO at 0x10001020? Not only do you have to declare the base address of the UART but also you have to know the offset into the UART. Why not just let the UART driver - which knows that the base address is 0x10001000, and the FIFO is at offset 0x20 above that - tell the DMA driver that's where the FIFO is located? Finally, your specific SoC may have a PL330, which may have FIFOs tied to specific DMA request signals. That's an _implementation_ _detail_. That doesn't mean that's always going to be the case. I've heard that ARM Ltd may start using the PL330 on their evaluation boards. They have a habbit of muxing several DMA request signals to several different peripherals. Will I need to rewrite all the Samsung users of PL330 when that happens because they've decided they don't like the DMA engine API and have gone off and done their own thing instead? So no, encoding the FIFO addresses into platform data for the DMA controller is brain dead and totally the wrong thing to do. And when you come to moving stuff over to DT, you'll see that's even more true there. So don't make the mistake now. Do things sensibly and follow the DMA engine API. Arrange for all your drivers to call DMA_SLAVE_CONFIG with the address of the FIFO. -- To unsubscribe from this list: send the line "unsubscribe linux-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 03-1/13] DMA: PL330: Support DMA_SLAVE_CONFIG command
On Thu, Jul 21, 2011 at 4:59 PM, Russell King - ARM Linux wrote: >> >> PL330 has fixed channels to peripherals. >> >> So FIFO addresses(burst_sz too?) should already be set via platform data. >> >> Client drivers shouldn't bother. >> > >> > That's utter crap, and isn't what the DMA engine API is about. >> > >> > The above looks correctly implemented. Slave DMA engine users are >> > supposed to supply the device DMA register address via this >> > DMA_SLAVE_CONFIG call. Doing this via platform data for the DMA >> > device is braindead. >> >> Rather than have 32 client drivers expect fifo_address from the >> platform and then >> provide to the DMAC, IMHO it is better for a single driver(DMAC) to >> get 32 addresses >> from the platform. >> Esp when the DMAC driver already expect similar h/w parameter -- *direction*. > > Conversely, when a platform doesn't know where the FIFOs are because > they're located inside the actual devices, and the device driver does, > then it makes much more sense for the device driver to provide the > DMA engine with the bus address of that. Yes, that is a case to consider. Perhaps we already do something like that while setting i2c addresses of attached devices in board files... and similarly it might be possible for the developer to know what the fifo address is going to be after the device is up and running esp when it is interfaced with an internal component like DMA. > > Does your hardware have a hardware block from the device itself containing > all the systems FIFOs ? I am not sure what you ask, but let me say what I know. In this case atleast, all PL330 DMA channels have fixed source/destination address on the device side. So it's not like developer doesn't know fifo_addr here. >> I don't understand why is 'fifo_address' a property much different >> than 'direction' of the channel ? > > Some channels can do memory-to-peripheral and peripheral-to-memory > transfers. Some peripherals provide a single set of DMA request/ack > lines to perform this function. Some peripherals have different > addresses for the TX and RX FIFOs within the device. Likewise we had something like that for I2S IP of S3C2440(or A0 ?) a single fifo address shared by TX and RX channel. Depending if it's full/half duplex capable we can have both or one 'virtual' channel active at a time. > >> If a channel is flexible enough to change it's 'fifo_address', most >> probably it could also change direction of transfers. > > There are DMA engines and setups where that's true. Of course, and I think this 'runtime' configuration should be done only for such cases. thnx -- To unsubscribe from this list: send the line "unsubscribe linux-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 S5P for v3.1 merge window
On Thursday 21 July 2011, Kukjin Kim wrote: > Please pull Samsung S5P updates from: > > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > for-arm-soc > > Or if you want to merge each branch into arm-soc, please use following. > As per your suggestion, I made following branches in my tree... > > - next-samsung-cleanup for arm-soc/next/cleanup > - next-samsung-devel for arm-soc/next/devel > - next-samsung-soc for arm-soc/next/soc (nothing) > - next-samsung-board for arm-soc/next/board > - and so on... > > If any problems, please let me know. > Looks all great now, thanks! Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 03-1/13] DMA: PL330: Support DMA_SLAVE_CONFIG command
On Thu, Jul 21, 2011 at 3:53 PM, Linus Walleij wrote:
> On Thu, Jul 21, 2011 at 11:14 AM, Jassi Brar wrote:
>> On Thu, Jul 21, 2011 at 1:41 PM, Russell King - ARM Linux
>> wrote:
>>> On Thu, Jul 21, 2011 at 12:47:49AM +0530, Jassi Brar wrote:
PL330 has fixed channels to peripherals.
So FIFO addresses(burst_sz too?) should already be set via platform data.
Client drivers shouldn't bother.
>>>
>>> That's utter crap, and isn't what the DMA engine API is about.
>>>
>>> The above looks correctly implemented. Slave DMA engine users are
>>> supposed to supply the device DMA register address via this
>>> DMA_SLAVE_CONFIG call. Doing this via platform data for the DMA
>>> device is braindead.
>>
>> Rather than have 32 client drivers expect fifo_address from the
>> platform and then
>> provide to the DMAC, IMHO it is better for a single driver(DMAC) to
>> get 32 addresses
>> from the platform.
>
> My idea (when I implemented it) is that the device driver knows the
> physical and virtual base and thus the address where DMA data is
> destined. It knows all other registers, it remaps them, noone else should
> be bothered with containing the knowledge of adress ranges for the
> specific hardware block.
>
> Passing this through platform data requires the machine to keep track
> not only of the base adress of the peripheral (as is generally contained
> in the machine or device tree) but also the offset of specific registers
> in that memory region, which is too much.
>
> Usually this means the offsets are defined in files like
> which means they can't be pushed down into drivers/foo/foo.c and
> creates unnecessary bindings and de-encapsulation of the driver.
> We want to get rid of such stuff. (I think?)
>
> Therefore I introduced this to confine the different registers into
> the driver itself and ask the DMA engine to transfer to a specific
> address.
While that does make sense, it makes mandatory the ritual of calling
DMA_SLAVE_CONFIG mandatory for most of the cases.
And I think the effort to set fifo_addr for peripherals is overrated.
>
>> Esp when the DMAC driver already expect similar h/w
>> parameter -- *direction*.
>>
>> I don't understand why is 'fifo_address' a property much different
>> than 'direction' of the
>> channel ?
>
> struct dma_slave_config {
> enum dma_data_direction direction;
> dma_addr_t src_addr;
> dma_addr_t dst_addr;
> enum dma_slave_buswidth src_addr_width;
> enum dma_slave_buswidth dst_addr_width;
> u32 src_maxburst;
> u32 dst_maxburst;
> };
>
> We do support changing direction as well as src and dst address
> (i.e. FIFO endpoint) at runtime.
>
> Check drivers/mmc/host/mmci.c for an example of how we switch
> a single channel from TX to RX in runtime using this one property.
>
> However it has been noted by Russell that the direction member
> is unnecessary since the device_prep_slave_sg() function in the
> dmaengine vtable already takes a direction argument like this:
>
> struct dma_async_tx_descriptor *(*device_prep_slave_sg)(
> struct dma_chan *chan, struct scatterlist *sgl,
> unsigned int sg_len, enum dma_data_direction direction,
> unsigned long flags);
>
> Therefore the direction setting needs to go from either the config
> struct or the device_prep_slave_sg() call, as right now the channel
> is being told about the direction twice which is not elegant and
> confusing.
>
> So you even have two ways of changing direction at runtime...
Of course there are ways to set the direction... but whatever we do
it can't really be changed from what h/w can only do.
And that is my point. Let clients not bother trying to 'configure' what is
the only supported option by h/w.
And I don't suggest dropping the DMA_SLAVE_CONFIG callback - just
keep it for rarer situations when we have configurable channels.
And I assumed that was your original idea too.
---
* @DMA_SLAVE_CONFIG: this command is only implemented by DMA controllers
* that need to runtime reconfigure the slave channels (as opposed to passing
* configuration data in statically from the platform). An additional
* argument of struct dma_slave_config must be passed in with this
* command.
---
Regards,
-j
>
> Yours,
> Linus Walleij
>
--
To unsubscribe from this list: send the line "unsubscribe linux-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 03-1/13] DMA: PL330: Support DMA_SLAVE_CONFIG command
On Thu, Jul 21, 2011 at 02:44:28PM +0530, Jassi Brar wrote:
> On Thu, Jul 21, 2011 at 1:41 PM, Russell King - ARM Linux
> wrote:
> > On Thu, Jul 21, 2011 at 12:47:49AM +0530, Jassi Brar wrote:
> >> On Wed, Jul 20, 2011 at 4:16 PM, Boojin Kim wrote:
> >> > + if (slave_config->direction == DMA_TO_DEVICE) {
> >> > + if (slave_config->dst_addr)
> >> > + peri->fifo_addr = slave_config->dst_addr;
> >> > + if (slave_config->dst_addr_width)
> >> > + peri->burst_sz =
> >> > __ffs(slave_config->dst_addr_width);
> >> > + } else if (slave_config->direction == DMA_FROM_DEVICE) {
> >> > + if (slave_config->src_addr)
> >> > + peri->fifo_addr = slave_config->src_addr;
> >> > + if (slave_config->src_addr_width)
> >> > + peri->burst_sz =
> >> > __ffs(slave_config->src_addr_width);
> >> > + }
> >> PL330 has fixed channels to peripherals.
> >> So FIFO addresses(burst_sz too?) should already be set via platform data.
> >> Client drivers shouldn't bother.
> >
> > That's utter crap, and isn't what the DMA engine API is about.
> >
> > The above looks correctly implemented. Slave DMA engine users are
> > supposed to supply the device DMA register address via this
> > DMA_SLAVE_CONFIG call. Doing this via platform data for the DMA
> > device is braindead.
>
> Rather than have 32 client drivers expect fifo_address from the
> platform and then
> provide to the DMAC, IMHO it is better for a single driver(DMAC) to
> get 32 addresses
> from the platform.
> Esp when the DMAC driver already expect similar h/w parameter -- *direction*.
Conversely, when a platform doesn't know where the FIFOs are because
they're located inside the actual devices, and the device driver does,
then it makes much more sense for the device driver to provide the
DMA engine with the bus address of that.
Does your hardware have a hardware block from the device itself containing
all the systems FIFOs ?
> I don't understand why is 'fifo_address' a property much different
> than 'direction' of the channel ?
Some channels can do memory-to-peripheral and peripheral-to-memory
transfers. Some peripherals provide a single set of DMA request/ack
lines to perform this function. Some peripherals have different
addresses for the TX and RX FIFOs within the device.
> If a channel is flexible enough to change it's 'fifo_address', most
> probably it could also change direction of transfers.
There are DMA engines and setups where that's true.
> So, why do we want to take seriously 'fifo_address' provided by the
> client drivers and not the 'direction' ?
The direction in the DMA slave config call I believe to be an annoying
overdesign which shouldn't be there - the DMA slave config call should
configure the DMA channel for the peripherals characteristics.
The actual channel direction should be setup at preparation time along
with the DMA buffer mapping etc.
--
To unsubscribe from this list: send the line "unsubscribe linux-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] ARM: EXYNOS4: Update config file of NURI to enable RTC
This patch update config file of NURI board to enable RTC Signed-off-by: Chanwoo Choi Signed-off-by: Kyungmin Park --- arch/arm/mach-exynos4/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig index b735705..bb675fb 100644 --- a/arch/arm/mach-exynos4/Kconfig +++ b/arch/arm/mach-exynos4/Kconfig @@ -184,6 +184,7 @@ config MACH_NURI bool "Mobile NURI Board" select CPU_EXYNOS4210 select S3C_DEV_WDT + select S3C_DEV_RTC select S3C_DEV_HSMMC select S3C_DEV_HSMMC2 select S3C_DEV_HSMMC3 -- 1.7.0.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: [PATCHv2 0/4] Updated s5p-tv platform definitions
Hello, On Thursday, July 21, 2011 11:52 AM Kukjin Kim wrote: > > This patch series contains platform definitions for s5p-tv driver > > rebased onto latest for-next branch (including generic GIC and clockdev > > changes). > > > > Changes since v1: > > - renamed i2c8 to common i2c-hdmiphy > > - moved common vpll code to plat-s5p/clocks.c > > - added check for pll locking > > - various minor coding style fixes here and there > > > > Best regards > > -- > > Marek Szyprowski > > Samsung Poland R&D Center > > > > > > Patch summary: > > > > Tomasz Stanislawski (4): > > ARM: Samsung: add i2c hdmiphy controller definitions > > ARM: S5P: add support for tv device > > ARM: Exynos4: enable TV support on Universal_C210 board > > ARM: S5PV210: enable TV support on GONI board > > > > arch/arm/mach-exynos4/Kconfig|2 + > > arch/arm/mach-exynos4/clock.c| 140 > > +- > > arch/arm/mach-exynos4/cpu.c |4 + > > arch/arm/mach-exynos4/include/mach/iic-hdmiphy.h | 16 +++ > > arch/arm/mach-exynos4/include/mach/irqs.h|4 + > > arch/arm/mach-exynos4/include/mach/map.h | 12 ++ > > arch/arm/mach-exynos4/include/mach/regs-pmu.h|6 + > > arch/arm/mach-exynos4/mach-universal_c210.c | 74 > > arch/arm/mach-s5pv210/Kconfig|1 + > > arch/arm/mach-s5pv210/clock.c| 87 -- > > arch/arm/mach-s5pv210/cpu.c |4 + > > arch/arm/mach-s5pv210/include/mach/iic-hdmiphy.h | 16 +++ > > arch/arm/mach-s5pv210/include/mach/irqs.h|4 +- > > arch/arm/mach-s5pv210/include/mach/map.h | 13 ++ > > arch/arm/mach-s5pv210/include/mach/regs-clock.h |9 +- > > arch/arm/mach-s5pv210/mach-goni.c|9 ++ > > arch/arm/plat-s5p/Kconfig| 10 ++ > > arch/arm/plat-s5p/Makefile |2 + > > arch/arm/plat-s5p/clock.c| 73 +++ > > arch/arm/plat-s5p/dev-i2c-hdmiphy.c | 59 + > > arch/arm/plat-s5p/dev-tv.c | 100 +++ > > arch/arm/plat-s5p/include/plat/s5p-clock.h |4 + > > arch/arm/plat-samsung/include/plat/devs.h|6 + > > arch/arm/plat-samsung/include/plat/iic.h |1 + > > arch/arm/plat-samsung/include/plat/tv-core.h | 44 +++ > > 25 files changed, 684 insertions(+), 16 deletions(-) > > create mode 100644 arch/arm/mach-exynos4/include/mach/iic-hdmiphy.h > > create mode 100644 arch/arm/mach-s5pv210/include/mach/iic-hdmiphy.h > > create mode 100644 arch/arm/plat-s5p/dev-i2c-hdmiphy.c > > create mode 100644 arch/arm/plat-s5p/dev-tv.c > > create mode 100644 arch/arm/plat-samsung/include/plat/tv-core.h > > > > -- > > 1.7.1.569.g6f426 > > Hi Marek, > > Looks good but happens following build failure with > s5pc100_defconfig/s5p64x0_defconfig. > Because they have no VPLL :( > > arch/arm/kernel/return_address.c:62: warning: #warning "TODO: return_address > should use unwind tables" > arch/arm/plat-s5p/clock.c: In function 's5p_vpll_set_rate': > arch/arm/plat-s5p/clock.c:237: error: 'S5P_VPLL_CON0' undeclared (first use > in this function) > arch/arm/plat-s5p/clock.c:237: error: (Each undeclared identifier is > reported only once > arch/arm/plat-s5p/clock.c:237: error: for each function it appears in.) > arch/arm/plat-s5p/clock.c:243: error: 'S5P_VPLL_CON1' undeclared (first use > in this function) > arch/arm/plat-s5p/clock.c:272: error: 'S5P_VPLLCON0_LOCKED_SHIFT' undeclared > (first use in this function) > make[1]: *** [arch/arm/plat-s5p/clock.o] Error 1 Huh... Right, I forgot about other platforms. What do you think about making this vpll code compiled conditionally only for EXYNOS4 and S5PV210? The other solution is to move it into a separate file. > First of all, I will send 'pull request' without this series... > > I'm not sure can have a chance to send 'pull request' again for this merge > window. Ok, I understand. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 03-1/13] DMA: PL330: Support DMA_SLAVE_CONFIG command
On Thu, Jul 21, 2011 at 11:14 AM, Jassi Brar wrote:
> On Thu, Jul 21, 2011 at 1:41 PM, Russell King - ARM Linux
> wrote:
>> On Thu, Jul 21, 2011 at 12:47:49AM +0530, Jassi Brar wrote:
>>> PL330 has fixed channels to peripherals.
>>> So FIFO addresses(burst_sz too?) should already be set via platform data.
>>> Client drivers shouldn't bother.
>>
>> That's utter crap, and isn't what the DMA engine API is about.
>>
>> The above looks correctly implemented. Slave DMA engine users are
>> supposed to supply the device DMA register address via this
>> DMA_SLAVE_CONFIG call. Doing this via platform data for the DMA
>> device is braindead.
>
> Rather than have 32 client drivers expect fifo_address from the
> platform and then
> provide to the DMAC, IMHO it is better for a single driver(DMAC) to
> get 32 addresses
> from the platform.
My idea (when I implemented it) is that the device driver knows the
physical and virtual base and thus the address where DMA data is
destined. It knows all other registers, it remaps them, noone else should
be bothered with containing the knowledge of adress ranges for the
specific hardware block.
Passing this through platform data requires the machine to keep track
not only of the base adress of the peripheral (as is generally contained
in the machine or device tree) but also the offset of specific registers
in that memory region, which is too much.
Usually this means the offsets are defined in files like
which means they can't be pushed down into drivers/foo/foo.c and
creates unnecessary bindings and de-encapsulation of the driver.
We want to get rid of such stuff. (I think?)
Therefore I introduced this to confine the different registers into
the driver itself and ask the DMA engine to transfer to a specific
address.
> Esp when the DMAC driver already expect similar h/w
> parameter -- *direction*.
>
> I don't understand why is 'fifo_address' a property much different
> than 'direction' of the
> channel ?
struct dma_slave_config {
enum dma_data_direction direction;
dma_addr_t src_addr;
dma_addr_t dst_addr;
enum dma_slave_buswidth src_addr_width;
enum dma_slave_buswidth dst_addr_width;
u32 src_maxburst;
u32 dst_maxburst;
};
We do support changing direction as well as src and dst address
(i.e. FIFO endpoint) at runtime.
Check drivers/mmc/host/mmci.c for an example of how we switch
a single channel from TX to RX in runtime using this one property.
However it has been noted by Russell that the direction member
is unnecessary since the device_prep_slave_sg() function in the
dmaengine vtable already takes a direction argument like this:
struct dma_async_tx_descriptor *(*device_prep_slave_sg)(
struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_data_direction direction,
unsigned long flags);
Therefore the direction setting needs to go from either the config
struct or the device_prep_slave_sg() call, as right now the channel
is being told about the direction twice which is not elegant and
confusing.
So you even have two ways of changing direction at runtime...
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] Samsung S5P for v3.1 merge window
Hi Arnd Please pull Samsung S5P updates from: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-arm-soc Or if you want to merge each branch into arm-soc, please use following. As per your suggestion, I made following branches in my tree... - next-samsung-cleanup for arm-soc/next/cleanup - next-samsung-devel for arm-soc/next/devel - next-samsung-soc for arm-soc/next/soc (nothing) - next-samsung-board for arm-soc/next/board - and so on... If any problems, please let me know. Note: merged above branches into the for-arm-soc - merged next-samsung-cleanup - merged next-samsung-devel Conflicts: arch/arm/mach-exynos4/Kconfig arch/arm/mach-exynos4/mach-smdkc210.c arch/arm/mach-s5pv210/mach-goni.c diff --cc arch/arm/mach-exynos4/Kconfig index ae433a0,dd8ae58..50602ef --- a/arch/arm/mach-exynos4/Kconfig +++ b/arch/arm/mach-exynos4/Kconfig @@@ -110,10 -122,9 +122,11 @@@ config MACH_SMDKC21 select S3C_DEV_HSMMC1 select S3C_DEV_HSMMC2 select S3C_DEV_HSMMC3 + select SAMSUNG_DEV_PWM + select SAMSUNG_DEV_BACKLIGHT select EXYNOS4_DEV_PD select EXYNOS4_DEV_SYSMMU + select EXYNOS4_SETUP_FIMD0 select EXYNOS4_SETUP_I2C1 select EXYNOS4_SETUP_SDHCI help @@@ -129,11 -141,11 +143,13 @@@ config MACH_SMDKV31 select S3C_DEV_HSMMC1 select S3C_DEV_HSMMC2 select S3C_DEV_HSMMC3 + select EXYNOS4_DEV_AHCI + select SAMSUNG_DEV_BACKLIGHT select SAMSUNG_DEV_KEYPAD select EXYNOS4_DEV_PD + select SAMSUNG_DEV_PWM select EXYNOS4_DEV_SYSMMU + select EXYNOS4_SETUP_FIMD0 select EXYNOS4_SETUP_I2C1 select EXYNOS4_SETUP_KEYPAD select EXYNOS4_SETUP_SDHCI diff --cc arch/arm/mach-exynos4/mach-smdkc210.c index f606ea7,31cfcd6..a1d4eb8 --- a/arch/arm/mach-exynos4/mach-smdkc210.c +++ b/arch/arm/mach-exynos4/mach-smdkc210.c @@@ -224,7 -279,7 +293,9 @@@ static void __init smdkc210_machine_ini s3c_sdhci2_set_platdata(&smdkc210_hsmmc2_pdata); s3c_sdhci3_set_platdata(&smdkc210_hsmmc3_pdata); + samsung_bl_set(&smdkc210_bl_gpio_info, &smdkc210_bl_data); ++ + s5p_fimd0_set_platdata(&smdkc210_lcd0_pdata); platform_add_devices(smdkc210_devices, ARRAY_SIZE(smdkc210_devices)); } - Then, finally merged next-samsung-board. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. The following changes since commit 620917de59eeb934b9f8cf35cc2d95c1ac8ed0fc Linux 3.0-rc7 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-arm-soc Ajay Kumar (3): ARM: S5PC100: Cleanup mach/regs-fb.h from mach-s5pc100 ARM: S5PV210: Cleanup mach/regs-fb.h from mach-s5pv210 ARM: S3C64XX: Cleanup mach/regs-fb.h from mach-s3c64xx Banajit Goswami (15): ARM: SAMSUNG: Create a common infrastructure for PWM backlight support ARM: EXYNOS4: Add PWM backlight support on SMDKV310 ARM: EXYNOS4: Add PWM backlight support on SMDKC210 ARM: S5PV210: Add PWM backlight support on SMDKV210 ARM: S5PC100: Add PWM backlight support on SMDKC100 ARM: S5P64X0: Add PWM backlight support on SMDK6440 ARM: S5P64X0: Add PWM backlight support on SMDK6450 ARM: S3C64XX: Add PWM backlight support on SMDK6410 ARM: SAMSUNG: Use generic s3c_set_platdata for TS ARM: SAMSUNG: Use generic s3c_set_platdata for FB ARM: SAMSUNG: Use generic s3c_set_platdata for HWMON ARM: SAMSUNG: Use generic s3c_set_platdata for USB OHCI ARM: SAMSUNG: Use generic s3c_set_platdata for NAND ARM: S3C64XX: Use generic s3c_set_platdata for OneNAND ARM: S3C24XX: Use generic s3c_set_platdata for devices Ben Dooks (2): ARM: S3C64XX: Ensure VIC based IRQs can be resumed from ARM: SAMSUNG: Add support for pre-sleep/post-restore gpio control Changhwan Youn (7): ARM: EXYNOS4: Add external GIC io memory mapping ARM: EXYNOS4: modify interrupt mappings for external GIC ARM: EXYNOS4: set the affinity of mct1 interrupt using IRQ_MCT_L1 ARM: GIC: move gic_chip_data structure declaration to header ARM: EXYNOS4: Add support external GIC ARM: EXYNOS4: Remove clock event timers using ARM private timers ARM: EXYNOS4: Add chained enrty/exit function to uart interrupt handler Chanwoo Choi (1): clocksource: convert 32-bit down counting clocksource on S5PV210/S5P64X0 Inderpal Singh (1): ARM: EXYNOS4: Enable SATA on SMDKV310 Jaecheol Lee (6): ARM: EXYNOS4: Support system level power down configuration ARM: EXYNOS4: Remove PMU configuration for S2RAM ARM: EXYNOS4: Support early wakeup entering sleep mode ARM: EXYNOS4: Move S5P_CENTRAL_SEQ_CONFIGURATION setting for PM ARM: EXYNOS4: Add save/restore for other ARM registers ARM: EXYNOS4: Add save/restore function for
RE: [PATCHv2 0/4] Updated s5p-tv platform definitions
Marek Szyprowski wrote: > > Hello, > Hi, > This patch series contains platform definitions for s5p-tv driver > rebased onto latest for-next branch (including generic GIC and clockdev > changes). > > Changes since v1: > - renamed i2c8 to common i2c-hdmiphy > - moved common vpll code to plat-s5p/clocks.c > - added check for pll locking > - various minor coding style fixes here and there > > Best regards > -- > Marek Szyprowski > Samsung Poland R&D Center > > > Patch summary: > > Tomasz Stanislawski (4): > ARM: Samsung: add i2c hdmiphy controller definitions > ARM: S5P: add support for tv device > ARM: Exynos4: enable TV support on Universal_C210 board > ARM: S5PV210: enable TV support on GONI board > > arch/arm/mach-exynos4/Kconfig|2 + > arch/arm/mach-exynos4/clock.c| 140 > +- > arch/arm/mach-exynos4/cpu.c |4 + > arch/arm/mach-exynos4/include/mach/iic-hdmiphy.h | 16 +++ > arch/arm/mach-exynos4/include/mach/irqs.h|4 + > arch/arm/mach-exynos4/include/mach/map.h | 12 ++ > arch/arm/mach-exynos4/include/mach/regs-pmu.h|6 + > arch/arm/mach-exynos4/mach-universal_c210.c | 74 > arch/arm/mach-s5pv210/Kconfig|1 + > arch/arm/mach-s5pv210/clock.c| 87 -- > arch/arm/mach-s5pv210/cpu.c |4 + > arch/arm/mach-s5pv210/include/mach/iic-hdmiphy.h | 16 +++ > arch/arm/mach-s5pv210/include/mach/irqs.h|4 +- > arch/arm/mach-s5pv210/include/mach/map.h | 13 ++ > arch/arm/mach-s5pv210/include/mach/regs-clock.h |9 +- > arch/arm/mach-s5pv210/mach-goni.c|9 ++ > arch/arm/plat-s5p/Kconfig| 10 ++ > arch/arm/plat-s5p/Makefile |2 + > arch/arm/plat-s5p/clock.c| 73 +++ > arch/arm/plat-s5p/dev-i2c-hdmiphy.c | 59 + > arch/arm/plat-s5p/dev-tv.c | 100 +++ > arch/arm/plat-s5p/include/plat/s5p-clock.h |4 + > arch/arm/plat-samsung/include/plat/devs.h|6 + > arch/arm/plat-samsung/include/plat/iic.h |1 + > arch/arm/plat-samsung/include/plat/tv-core.h | 44 +++ > 25 files changed, 684 insertions(+), 16 deletions(-) > create mode 100644 arch/arm/mach-exynos4/include/mach/iic-hdmiphy.h > create mode 100644 arch/arm/mach-s5pv210/include/mach/iic-hdmiphy.h > create mode 100644 arch/arm/plat-s5p/dev-i2c-hdmiphy.c > create mode 100644 arch/arm/plat-s5p/dev-tv.c > create mode 100644 arch/arm/plat-samsung/include/plat/tv-core.h > > -- > 1.7.1.569.g6f426 Hi Marek, Looks good but happens following build failure with s5pc100_defconfig/s5p64x0_defconfig. Because they have no VPLL :( arch/arm/kernel/return_address.c:62: warning: #warning "TODO: return_address should use unwind tables" arch/arm/plat-s5p/clock.c: In function 's5p_vpll_set_rate': arch/arm/plat-s5p/clock.c:237: error: 'S5P_VPLL_CON0' undeclared (first use in this function) arch/arm/plat-s5p/clock.c:237: error: (Each undeclared identifier is reported only once arch/arm/plat-s5p/clock.c:237: error: for each function it appears in.) arch/arm/plat-s5p/clock.c:243: error: 'S5P_VPLL_CON1' undeclared (first use in this function) arch/arm/plat-s5p/clock.c:272: error: 'S5P_VPLLCON0_LOCKED_SHIFT' undeclared (first use in this function) make[1]: *** [arch/arm/plat-s5p/clock.o] Error 1 First of all, I will send 'pull request' without this series... I'm not sure can have a chance to send 'pull request' again for this merge window. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-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 03-1/13] DMA: PL330: Support DMA_SLAVE_CONFIG command
On Thu, Jul 21, 2011 at 1:41 PM, Russell King - ARM Linux
wrote:
> On Thu, Jul 21, 2011 at 12:47:49AM +0530, Jassi Brar wrote:
>> On Wed, Jul 20, 2011 at 4:16 PM, Boojin Kim wrote:
>> > + if (slave_config->direction == DMA_TO_DEVICE) {
>> > + if (slave_config->dst_addr)
>> > + peri->fifo_addr = slave_config->dst_addr;
>> > + if (slave_config->dst_addr_width)
>> > + peri->burst_sz =
>> > __ffs(slave_config->dst_addr_width);
>> > + } else if (slave_config->direction == DMA_FROM_DEVICE) {
>> > + if (slave_config->src_addr)
>> > + peri->fifo_addr = slave_config->src_addr;
>> > + if (slave_config->src_addr_width)
>> > + peri->burst_sz =
>> > __ffs(slave_config->src_addr_width);
>> > + }
>> PL330 has fixed channels to peripherals.
>> So FIFO addresses(burst_sz too?) should already be set via platform data.
>> Client drivers shouldn't bother.
>
> That's utter crap, and isn't what the DMA engine API is about.
>
> The above looks correctly implemented. Slave DMA engine users are
> supposed to supply the device DMA register address via this
> DMA_SLAVE_CONFIG call. Doing this via platform data for the DMA
> device is braindead.
Rather than have 32 client drivers expect fifo_address from the
platform and then
provide to the DMAC, IMHO it is better for a single driver(DMAC) to
get 32 addresses
from the platform.
Esp when the DMAC driver already expect similar h/w parameter -- *direction*.
I don't understand why is 'fifo_address' a property much different
than 'direction' of the
channel ?
If a channel is flexible enough to change it's 'fifo_address', most probably it
could also change direction of transfers.
So, why do we want to take seriously 'fifo_address' provided by the
client drivers
and not the 'direction' ?
--
To unsubscribe from this list: send the line "unsubscribe linux-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 03-1/13] DMA: PL330: Support DMA_SLAVE_CONFIG command
On Thu, Jul 21, 2011 at 12:47:49AM +0530, Jassi Brar wrote:
> On Wed, Jul 20, 2011 at 4:16 PM, Boojin Kim wrote:
> > + if (slave_config->direction == DMA_TO_DEVICE) {
> > + if (slave_config->dst_addr)
> > + peri->fifo_addr = slave_config->dst_addr;
> > + if (slave_config->dst_addr_width)
> > + peri->burst_sz =
> > __ffs(slave_config->dst_addr_width);
> > + } else if (slave_config->direction == DMA_FROM_DEVICE) {
> > + if (slave_config->src_addr)
> > + peri->fifo_addr = slave_config->src_addr;
> > + if (slave_config->src_addr_width)
> > + peri->burst_sz =
> > __ffs(slave_config->src_addr_width);
> > + }
> PL330 has fixed channels to peripherals.
> So FIFO addresses(burst_sz too?) should already be set via platform data.
> Client drivers shouldn't bother.
That's utter crap, and isn't what the DMA engine API is about.
The above looks correctly implemented. Slave DMA engine users are
supposed to supply the device DMA register address via this
DMA_SLAVE_CONFIG call. Doing this via platform data for the DMA
device is braindead.
--
To unsubscribe from this list: send the line "unsubscribe linux-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 4/4] ARM: S5PV210: enable TV support on GONI board
From: Tomasz Stanislawski
This patch adds platform devices and regulators for TV devices on
Samsung Goni board.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
Signed-off-by: Marek Szyprowski
---
arch/arm/mach-s5pv210/Kconfig |1 +
arch/arm/mach-s5pv210/mach-goni.c |9 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index 69dd87c..ab6a87c 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -94,6 +94,7 @@ config MACH_GONI
select S3C_DEV_USB_HSOTG
select S5P_DEV_ONENAND
select SAMSUNG_DEV_KEYPAD
+ select S5P_DEV_TV
select S5PV210_SETUP_FB_24BPP
select S5PV210_SETUP_I2C1
select S5PV210_SETUP_I2C2
diff --git a/arch/arm/mach-s5pv210/mach-goni.c
b/arch/arm/mach-s5pv210/mach-goni.c
index 85c2d51..14578f5 100644
--- a/arch/arm/mach-s5pv210/mach-goni.c
+++ b/arch/arm/mach-s5pv210/mach-goni.c
@@ -285,6 +285,7 @@ static struct regulator_consumer_supply
goni_ldo5_consumers[] = {
static struct regulator_consumer_supply goni_ldo8_consumers[] = {
REGULATOR_SUPPLY("vusb_d", "s3c-hsotg"),
+ REGULATOR_SUPPLY("vdd33a_dac", "s5p-sdo"),
};
static struct regulator_consumer_supply goni_ldo11_consumers[] = {
@@ -475,6 +476,10 @@ static struct regulator_consumer_supply buck1_consumer =
static struct regulator_consumer_supply buck2_consumer =
REGULATOR_SUPPLY("vddint", NULL);
+static struct regulator_consumer_supply buck3_consumer =
+ REGULATOR_SUPPLY("vdet", "s5p-sdo");
+
+
static struct regulator_init_data goni_buck1_data = {
.constraints= {
.name = "VARM_1.2V",
@@ -511,6 +516,8 @@ static struct regulator_init_data goni_buck3_data = {
.enabled = 1,
},
},
+ .num_consumer_supplies = 1,
+ .consumer_supplies = &buck3_consumer,
};
static struct regulator_init_data goni_buck4_data = {
@@ -812,6 +819,8 @@ static struct platform_device *goni_devices[] __initdata = {
&s5p_device_mfc,
&s5p_device_mfc_l,
&s5p_device_mfc_r,
+ &s5p_device_mixer,
+ &s5p_device_sdo,
&s3c_device_i2c0,
&s5p_device_fimc0,
&s5p_device_fimc1,
--
1.7.1.569.g6f426
--
To unsubscribe from this list: send the line "unsubscribe linux-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: Exynos4: enable TV support on Universal_C210 board
From: Tomasz Stanislawski
This patch adds platform devices and regulators for TV devices on
Samsung Universal C210 board.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
Signed-off-by: Marek Szyprowski
---
arch/arm/mach-exynos4/Kconfig |2 +
arch/arm/mach-exynos4/mach-universal_c210.c | 74 +++
2 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index fc38532..b7b2ea5 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -175,9 +175,11 @@ config MACH_UNIVERSAL_C210
select S3C_DEV_I2C1
select S3C_DEV_I2C3
select S3C_DEV_I2C5
+ select S5P_DEV_I2C_HDMIPHY
select S5P_DEV_MFC
select S5P_DEV_ONENAND
select EXYNOS4_DEV_PD
+ select S5P_DEV_TV
select EXYNOS4_SETUP_I2C1
select EXYNOS4_SETUP_I2C3
select EXYNOS4_SETUP_I2C5
diff --git a/arch/arm/mach-exynos4/mach-universal_c210.c
b/arch/arm/mach-exynos4/mach-universal_c210.c
index 0e280d1..e9dbe79 100644
--- a/arch/arm/mach-exynos4/mach-universal_c210.c
+++ b/arch/arm/mach-exynos4/mach-universal_c210.c
@@ -110,6 +110,9 @@ static struct regulator_consumer_supply
lp3974_buck1_consumer =
static struct regulator_consumer_supply lp3974_buck2_consumer =
REGULATOR_SUPPLY("vddg3d", NULL);
+static struct regulator_consumer_supply lp3974_buck3_consumer =
+ REGULATOR_SUPPLY("vdet", "s5p-sdo");
+
static struct regulator_init_data lp3974_buck1_data = {
.constraints= {
.name = "VINT_1.1V",
@@ -153,6 +156,8 @@ static struct regulator_init_data lp3974_buck3_data = {
.enabled= 1,
},
},
+ .num_consumer_supplies = 1,
+ .consumer_supplies = &lp3974_buck3_consumer,
};
static struct regulator_init_data lp3974_buck4_data = {
@@ -181,6 +186,11 @@ static struct regulator_init_data lp3974_ldo2_data = {
},
};
+static struct regulator_consumer_supply lp3974_ldo3_consumer[] = {
+ REGULATOR_SUPPLY("vdd", "exynos4-hdmi"),
+ REGULATOR_SUPPLY("vdd_pll", "exynos4-hdmi"),
+};
+
static struct regulator_init_data lp3974_ldo3_data = {
.constraints= {
.name = "VUSB+MIPI_1.1V",
@@ -192,6 +202,12 @@ static struct regulator_init_data lp3974_ldo3_data = {
.disabled = 1,
},
},
+ .num_consumer_supplies = ARRAY_SIZE(lp3974_ldo3_consumer),
+ .consumer_supplies = lp3974_ldo3_consumer,
+};
+
+static struct regulator_consumer_supply lp3974_ldo4_consumer[] = {
+ REGULATOR_SUPPLY("vdd_osc", "exynos4-hdmi"),
};
static struct regulator_init_data lp3974_ldo4_data = {
@@ -205,6 +221,8 @@ static struct regulator_init_data lp3974_ldo4_data = {
.disabled = 1,
},
},
+ .num_consumer_supplies = ARRAY_SIZE(lp3974_ldo4_consumer),
+ .consumer_supplies = lp3974_ldo4_consumer,
};
static struct regulator_init_data lp3974_ldo5_data = {
@@ -246,6 +264,10 @@ static struct regulator_init_data lp3974_ldo7_data = {
},
};
+static struct regulator_consumer_supply lp3974_ldo8_consumer[] = {
+ REGULATOR_SUPPLY("vdd33a_dac", "s5p-sdo"),
+};
+
static struct regulator_init_data lp3974_ldo8_data = {
.constraints= {
.name = "VUSB+VDAC_3.3V",
@@ -257,6 +279,8 @@ static struct regulator_init_data lp3974_ldo8_data = {
.disabled = 1,
},
},
+ .num_consumer_supplies = ARRAY_SIZE(lp3974_ldo8_consumer),
+ .consumer_supplies = lp3974_ldo8_consumer,
};
static struct regulator_init_data lp3974_ldo9_data = {
@@ -472,6 +496,34 @@ static struct max8998_platform_data universal_lp3974_pdata
= {
.wakeup = true,
};
+static struct regulator_consumer_supply hdmi_fixed_consumer =
+ REGULATOR_SUPPLY("hdmi-en", "exynos4-hdmi");
+
+static struct regulator_init_data hdmi_fixed_voltage_init_data = {
+ .constraints= {
+ .name = "HDMI_5V",
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = &hdmi_fixed_consumer,
+};
+
+static struct fixed_voltage_config hdmi_fixed_voltage_config = {
+ .supply_name= "HDMI_EN1",
+ .microvolts = 500,
+ .gpio = EXYNOS4_GPE0(1),
+ .enable_high= true,
+ .init_data = &hdmi_fixed_voltage_init_data,
+};
+
+static struct platform_device hdmi_fixed_voltage = {
+ .name = "reg-fixed-voltage",
+ .id = 6,
+ .dev= {
+ .platform_data = &hdmi_fixed_voltage_config,
+ },
+};
+
/* GPIO I2C 5 (PMIC) */
st
[PATCH 2/4] ARM: S5P: add support for tv device
From: Tomasz Stanislawski
This patch adds all the resources for TV drivers and devices for Samsung
Exynos4 and S5PV210 platforms.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
[m.szyprowski: moved common vpll code to plat-s5p/clocks.c, squashed Exynos4
and S5PV210 patches and rewrote commit message]
Signed-off-by: Marek Szyprowski
---
arch/arm/mach-exynos4/clock.c | 134 ++-
arch/arm/mach-exynos4/cpu.c |4 +
arch/arm/mach-exynos4/include/mach/irqs.h |4 +-
arch/arm/mach-exynos4/include/mach/map.h|8 ++
arch/arm/mach-exynos4/include/mach/regs-pmu.h |6 +
arch/arm/mach-s5pv210/clock.c | 81 --
arch/arm/mach-s5pv210/cpu.c |4 +
arch/arm/mach-s5pv210/include/mach/irqs.h |2 +-
arch/arm/mach-s5pv210/include/mach/map.h| 10 ++
arch/arm/mach-s5pv210/include/mach/regs-clock.h |9 +-
arch/arm/plat-s5p/Kconfig |5 +
arch/arm/plat-s5p/Makefile |1 +
arch/arm/plat-s5p/clock.c | 73
arch/arm/plat-s5p/dev-tv.c | 100 +
arch/arm/plat-s5p/include/plat/s5p-clock.h |4 +
arch/arm/plat-samsung/include/plat/devs.h |5 +
arch/arm/plat-samsung/include/plat/tv-core.h| 44
17 files changed, 478 insertions(+), 16 deletions(-)
create mode 100644 arch/arm/plat-s5p/dev-tv.c
create mode 100644 arch/arm/plat-samsung/include/plat/tv-core.h
diff --git a/arch/arm/mach-exynos4/clock.c b/arch/arm/mach-exynos4/clock.c
index 965475c..3b0e7e5 100644
--- a/arch/arm/mach-exynos4/clock.c
+++ b/arch/arm/mach-exynos4/clock.c
@@ -83,6 +83,11 @@ static int exynos4_clk_ip_mfc_ctrl(struct clk *clk, int
enable)
return s5p_gatectrl(S5P_CLKGATE_IP_MFC, clk, enable);
}
+static int exynos4_clksrc_mask_tv_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(S5P_CLKSRC_MASK_TV, clk, enable);
+}
+
static int exynos4_clk_ip_cam_ctrl(struct clk *clk, int enable)
{
return s5p_gatectrl(S5P_CLKGATE_IP_CAM, clk, enable);
@@ -123,6 +128,16 @@ static int exynos4_clk_ip_perir_ctrl(struct clk *clk, int
enable)
return s5p_gatectrl(S5P_CLKGATE_IP_PERIR, clk, enable);
}
+static int exynos4_clk_hdmiphy_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(S5P_HDMI_PHY_CONTROL, clk, enable);
+}
+
+static int exynos4_clk_dac_ctrl(struct clk *clk, int enable)
+{
+ return s5p_gatectrl(S5P_DAC_PHY_CONTROL, clk, enable);
+}
+
/* Core list of CMU_CPU side */
static struct clksrc_clk clk_mout_apll = {
@@ -449,6 +464,36 @@ static struct clk init_clocks_off[] = {
.enable = exynos4_clk_ip_fsys_ctrl,
.ctrlbit= (1 << 9),
}, {
+ .name = "dac",
+ .devname= "s5p-sdo",
+ .enable = exynos4_clk_ip_tv_ctrl,
+ .ctrlbit= (1 << 2),
+ }, {
+ .name = "mixer",
+ .devname= "s5p-mixer",
+ .enable = exynos4_clk_ip_tv_ctrl,
+ .ctrlbit= (1 << 1),
+ }, {
+ .name = "vp",
+ .devname= "s5p-mixer",
+ .enable = exynos4_clk_ip_tv_ctrl,
+ .ctrlbit= (1 << 0),
+ }, {
+ .name = "hdmi",
+ .devname= "s5p-hdmi",
+ .enable = exynos4_clk_ip_tv_ctrl,
+ .ctrlbit= (1 << 3),
+ }, {
+ .name = "hdmiphy",
+ .devname= "s5p-hdmi",
+ .enable = exynos4_clk_hdmiphy_ctrl,
+ .ctrlbit= (1 << 0),
+ }, {
+ .name = "dacphy",
+ .devname= "s5p-sdo",
+ .enable = exynos4_clk_dac_ctrl,
+ .ctrlbit= (1 << 0),
+ }, {
.name = "sata",
.parent = &clk_aclk_133.clk,
.enable = exynos4_clk_ip_fsys_ctrl,
@@ -788,6 +833,81 @@ static struct clksrc_sources clkset_mout_mfc = {
.nr_sources = ARRAY_SIZE(clkset_mout_mfc_list),
};
+static struct clk *clkset_sclk_dac_list[] = {
+ [0] = &clk_sclk_vpll.clk,
+ [1] = &clk_sclk_hdmiphy,
+};
+
+static struct clksrc_sources clkset_sclk_dac = {
+ .sources= clkset_sclk_dac_list,
+ .nr_sources = ARRAY_SIZE(clkset_sclk_dac_list),
+};
+
+static struct clksrc_clk clk_sclk_dac = {
+ .clk= {
+ .name = "sclk_dac",
+ .enable = exynos4_clksrc_mask_tv_ctrl,
+ .ctrlbit= (1 << 8),
+ },
+ .sources = &clkset_sclk_dac,
+ .reg_src = { .reg = S5P_CLKSRC_TV, .shift = 8, .size
[PATCH 1/4] ARM: Samsung: add i2c hdmiphy controller definitions
From: Tomasz Stanislawski
This patch adds hdmiphy dedicated i2c controller definitions.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
[m.szyprowski: renamed to i2c-hdmiphy and squashed Exynos4 and S5PV210 patches]
Signed-off-by: Marek Szyprowski
---
arch/arm/mach-exynos4/clock.c|6 ++
arch/arm/mach-exynos4/include/mach/iic-hdmiphy.h | 16 ++
arch/arm/mach-exynos4/include/mach/irqs.h|2 +
arch/arm/mach-exynos4/include/mach/map.h |4 ++
arch/arm/mach-s5pv210/clock.c|6 ++
arch/arm/mach-s5pv210/include/mach/iic-hdmiphy.h | 16 ++
arch/arm/mach-s5pv210/include/mach/irqs.h|2 +-
arch/arm/mach-s5pv210/include/mach/map.h |3 +
arch/arm/plat-s5p/Kconfig|5 ++
arch/arm/plat-s5p/Makefile |1 +
arch/arm/plat-s5p/dev-i2c-hdmiphy.c | 59 ++
arch/arm/plat-samsung/include/plat/devs.h|1 +
arch/arm/plat-samsung/include/plat/iic.h |1 +
13 files changed, 121 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-exynos4/include/mach/iic-hdmiphy.h
create mode 100644 arch/arm/mach-s5pv210/include/mach/iic-hdmiphy.h
create mode 100644 arch/arm/plat-s5p/dev-i2c-hdmiphy.c
diff --git a/arch/arm/mach-exynos4/clock.c b/arch/arm/mach-exynos4/clock.c
index 629ea1d..965475c 100644
--- a/arch/arm/mach-exynos4/clock.c
+++ b/arch/arm/mach-exynos4/clock.c
@@ -581,6 +581,12 @@ static struct clk init_clocks_off[] = {
.enable = exynos4_clk_ip_peril_ctrl,
.ctrlbit= (1 << 13),
}, {
+ .name = "i2c",
+ .devname= "s3c2440-hdmiphy-i2c",
+ .parent = &clk_aclk_100.clk,
+ .enable = exynos4_clk_ip_peril_ctrl,
+ .ctrlbit= (1 << 14),
+ }, {
.name = "SYSMMU_MDMA",
.enable = exynos4_clk_ip_image_ctrl,
.ctrlbit= (1 << 5),
diff --git a/arch/arm/mach-exynos4/include/mach/iic-hdmiphy.h
b/arch/arm/mach-exynos4/include/mach/iic-hdmiphy.h
new file mode 100644
index 000..4f070e0
--- /dev/null
+++ b/arch/arm/mach-exynos4/include/mach/iic-hdmiphy.h
@@ -0,0 +1,16 @@
+/*
+ * Copyright (C) 2011 Samsung Electronics Co., Ltd.
+ *
+ * S5P series i2c hdmiphy helper definitions
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef PLAT_S5P_IIC_HDMIPHY_H_
+#define PLAT_S5P_IIC_HDMIPHY_H_
+
+#define S5P_IIC_HDMIPHY_BUS_NUM(8)
+
+#endif
diff --git a/arch/arm/mach-exynos4/include/mach/irqs.h
b/arch/arm/mach-exynos4/include/mach/irqs.h
index e2995be..e8eeb94 100644
--- a/arch/arm/mach-exynos4/include/mach/irqs.h
+++ b/arch/arm/mach-exynos4/include/mach/irqs.h
@@ -94,6 +94,8 @@
#define IRQ_2D IRQ_SPI(89)
#define IRQ_PCIE IRQ_SPI(90)
+#define IRQ_IIC_HDMIPHYIRQ_SPI(93)
+
#define IRQ_MFCIRQ_SPI(94)
#define IRQ_AUDIO_SS IRQ_SPI(96)
diff --git a/arch/arm/mach-exynos4/include/mach/map.h
b/arch/arm/mach-exynos4/include/mach/map.h
index 0d0b13c3..0b2b1dd 100644
--- a/arch/arm/mach-exynos4/include/mach/map.h
+++ b/arch/arm/mach-exynos4/include/mach/map.h
@@ -110,6 +110,8 @@
#define EXYNOS4_PA_UART0x1380
+#define EXYNOS4_PA_IIC_HDMIPHY 0x138E
+
#define EXYNOS4_PA_IIC(x) (0x1386 + ((x) * 0x1))
#define EXYNOS4_PA_ADC 0x1391
@@ -158,6 +160,8 @@
#define S5P_PA_TIMER EXYNOS4_PA_TIMER
#define S5P_PA_EHCIEXYNOS4_PA_EHCI
+#define S5P_PA_IIC_HDMIPHY EXYNOS4_PA_IIC_HDMIPHY
+
#define SAMSUNG_PA_KEYPAD EXYNOS4_PA_KEYPAD
/* UART */
diff --git a/arch/arm/mach-s5pv210/clock.c b/arch/arm/mach-s5pv210/clock.c
index 52a8e60..90a1966 100644
--- a/arch/arm/mach-s5pv210/clock.c
+++ b/arch/arm/mach-s5pv210/clock.c
@@ -407,6 +407,12 @@ static struct clk init_clocks_off[] = {
.enable = s5pv210_clk_ip3_ctrl,
.ctrlbit= (1<<9),
}, {
+ .name = "i2c",
+ .devname= "s3c2440-hdmiphy-i2c",
+ .parent = &clk_pclk_psys.clk,
+ .enable = s5pv210_clk_ip3_ctrl,
+ .ctrlbit= (1 << 11),
+ }, {
.name = "spi",
.devname= "s3c64xx-spi.0",
.parent = &clk_pclk_psys.clk,
diff --git a/arch/arm/mach-s5pv210/include/mach/iic-hdmiphy.h
b/arch/arm/mach-s5pv210/include/mach/iic-hdmiphy.h
new file mode 100644
index 000..b6ce613
--- /dev/null
+++ b/arch/arm/mach-s5pv210/include/m
[PATCHv2 0/4] Updated s5p-tv platform definitions
Hello, This patch series contains platform definitions for s5p-tv driver rebased onto latest for-next branch (including generic GIC and clockdev changes). Changes since v1: - renamed i2c8 to common i2c-hdmiphy - moved common vpll code to plat-s5p/clocks.c - added check for pll locking - various minor coding style fixes here and there Best regards -- Marek Szyprowski Samsung Poland R&D Center Patch summary: Tomasz Stanislawski (4): ARM: Samsung: add i2c hdmiphy controller definitions ARM: S5P: add support for tv device ARM: Exynos4: enable TV support on Universal_C210 board ARM: S5PV210: enable TV support on GONI board arch/arm/mach-exynos4/Kconfig|2 + arch/arm/mach-exynos4/clock.c| 140 +- arch/arm/mach-exynos4/cpu.c |4 + arch/arm/mach-exynos4/include/mach/iic-hdmiphy.h | 16 +++ arch/arm/mach-exynos4/include/mach/irqs.h|4 + arch/arm/mach-exynos4/include/mach/map.h | 12 ++ arch/arm/mach-exynos4/include/mach/regs-pmu.h|6 + arch/arm/mach-exynos4/mach-universal_c210.c | 74 arch/arm/mach-s5pv210/Kconfig|1 + arch/arm/mach-s5pv210/clock.c| 87 -- arch/arm/mach-s5pv210/cpu.c |4 + arch/arm/mach-s5pv210/include/mach/iic-hdmiphy.h | 16 +++ arch/arm/mach-s5pv210/include/mach/irqs.h|4 +- arch/arm/mach-s5pv210/include/mach/map.h | 13 ++ arch/arm/mach-s5pv210/include/mach/regs-clock.h |9 +- arch/arm/mach-s5pv210/mach-goni.c|9 ++ arch/arm/plat-s5p/Kconfig| 10 ++ arch/arm/plat-s5p/Makefile |2 + arch/arm/plat-s5p/clock.c| 73 +++ arch/arm/plat-s5p/dev-i2c-hdmiphy.c | 59 + arch/arm/plat-s5p/dev-tv.c | 100 +++ arch/arm/plat-s5p/include/plat/s5p-clock.h |4 + arch/arm/plat-samsung/include/plat/devs.h|6 + arch/arm/plat-samsung/include/plat/iic.h |1 + arch/arm/plat-samsung/include/plat/tv-core.h | 44 +++ 25 files changed, 684 insertions(+), 16 deletions(-) create mode 100644 arch/arm/mach-exynos4/include/mach/iic-hdmiphy.h create mode 100644 arch/arm/mach-s5pv210/include/mach/iic-hdmiphy.h create mode 100644 arch/arm/plat-s5p/dev-i2c-hdmiphy.c create mode 100644 arch/arm/plat-s5p/dev-tv.c create mode 100644 arch/arm/plat-samsung/include/plat/tv-core.h -- 1.7.1.569.g6f426 -- To unsubscribe from this list: send the line "unsubscribe linux-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] ARM: S5P64X0: External Interrupt Support
Padmavathi Venna wrote:
>
> Add external interrupt support for S5P64X0.The external interrupt
> group 0(0 to 15) is used for wake-up source in stop and sleep mode.
> Add generic irq chip support
>
> Signed-off-by: Padmavathi Venna
> ---
>
> Please ignore my previous patch due to wrong return value.
>
> arch/arm/mach-s5p64x0/Makefile |2 +-
> arch/arm/mach-s5p64x0/include/mach/regs-gpio.h | 10 ++
> arch/arm/mach-s5p64x0/irq-eint.c | 152
>
> 3 files changed, 163 insertions(+), 1 deletions(-)
> create mode 100644 arch/arm/mach-s5p64x0/irq-eint.c
>
> diff --git a/arch/arm/mach-s5p64x0/Makefile
b/arch/arm/mach-s5p64x0/Makefile
> index ae6bf6f..5f6afdf 100644
> --- a/arch/arm/mach-s5p64x0/Makefile
> +++ b/arch/arm/mach-s5p64x0/Makefile
> @@ -13,7 +13,7 @@ obj-:=
> # Core support for S5P64X0 system
>
> obj-$(CONFIG_ARCH_S5P64X0) += cpu.o init.o clock.o dma.o gpiolib.o
> -obj-$(CONFIG_ARCH_S5P64X0) += setup-i2c0.o
> +obj-$(CONFIG_ARCH_S5P64X0) += setup-i2c0.o irq-eint.o
> obj-$(CONFIG_CPU_S5P6440)+= clock-s5p6440.o
> obj-$(CONFIG_CPU_S5P6450)+= clock-s5p6450.o
>
> diff --git a/arch/arm/mach-s5p64x0/include/mach/regs-gpio.h
b/arch/arm/mach-
> s5p64x0/include/mach/regs-gpio.h
> index 0953ef6..6ce2547 100644
> --- a/arch/arm/mach-s5p64x0/include/mach/regs-gpio.h
> +++ b/arch/arm/mach-s5p64x0/include/mach/regs-gpio.h
> @@ -34,4 +34,14 @@
> #define S5P6450_GPQ_BASE (S5P_VA_GPIO + 0x0180)
> #define S5P6450_GPS_BASE (S5P_VA_GPIO + 0x0300)
>
> +/* External interrupt control registers for group0 */
> +
> +#define EINT0CON0_OFFSET (0x900)
> +#define EINT0MASK_OFFSET (0x920)
> +#define EINT0PEND_OFFSET (0x924)
> +
> +#define S5P64X0_EINT0CON0(S5P_VA_GPIO +
> EINT0CON0_OFFSET)
> +#define S5P64X0_EINT0MASK(S5P_VA_GPIO +
> EINT0MASK_OFFSET)
> +#define S5P64X0_EINT0PEND(S5P_VA_GPIO +
> EINT0PEND_OFFSET)
> +
> #endif /* __ASM_ARCH_REGS_GPIO_H */
> diff --git a/arch/arm/mach-s5p64x0/irq-eint.c
b/arch/arm/mach-s5p64x0/irq-eint.c
> new file mode 100644
> index 000..69ed454
> --- /dev/null
> +++ b/arch/arm/mach-s5p64x0/irq-eint.c
> @@ -0,0 +1,152 @@
> +/* arch/arm/mach-s5p64x0/irq-eint.c
> + *
> + * Copyright (c) 2011 Samsung Electronics Co., Ltd
> + * http://www.samsung.com/
> + *
> + * Based on linux/arch/arm/mach-s3c64xx/irq-eint.c
> + *
> + * S5P64X0 - Interrupt handling for External Interrupts.
> + *
> + * 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
> +
> +#define eint_offset(irq) ((irq) - IRQ_EINT(0))
> +
> +static int s5p64x0_irq_eint_set_type(struct irq_data *data, unsigned int
type)
> +{
> + int offs = eint_offset(data->irq);
> + int shift;
> + u32 ctrl, mask;
> + u32 newvalue = 0;
> +
> + if (offs > 15)
> + return -EINVAL;
> +
> + switch (type) {
> + case IRQ_TYPE_NONE:
> + printk(KERN_WARNING "No edge setting!\n");
> + break;
> + case IRQ_TYPE_EDGE_RISING:
> + newvalue = S3C2410_EXTINT_RISEEDGE;
> + break;
> + case IRQ_TYPE_EDGE_FALLING:
> + newvalue = S3C2410_EXTINT_FALLEDGE;
> + break;
> + case IRQ_TYPE_EDGE_BOTH:
> + newvalue = S3C2410_EXTINT_BOTHEDGE;
> + break;
> + case IRQ_TYPE_LEVEL_LOW:
> + newvalue = S3C2410_EXTINT_LOWLEV;
> + break;
> + case IRQ_TYPE_LEVEL_HIGH:
> + newvalue = S3C2410_EXTINT_HILEV;
> + break;
> + default:
> + printk(KERN_ERR "No such irq type %d", type);
> + return -EINVAL;
> + }
> +
> + shift = (offs / 2) * 4;
> + mask = 0x7 << shift;
> +
> + ctrl = __raw_readl(S5P64X0_EINT0CON0) & ~mask;
> + ctrl |= newvalue << shift;
> + __raw_writel(ctrl, S5P64X0_EINT0CON0);
> +
> + /* Configure the GPIO pin for 6450 or 6440 based on CPU ID */
> + if (0x5 == (__raw_readl(S5P64X0_SYS_ID) & 0xFF000))
> + s3c_gpio_cfgpin(S5P6450_GPN(offs), S3C_GPIO_SFN(2));
> + else
> + s3c_gpio_cfgpin(S5P6440_GPN(offs), S3C_GPIO_SFN(2));
> +
> + return 0;
> +}
> +
> +/*
> + * s5p64x0_irq_demux_eint
> + *
> + * This function demuxes the IRQ from the group0 external interrupts,
> + * from IRQ_EINT(0) to IRQ_EINT(15). It is designed to be inlined into
> + * the specific handlers s5p64x0_irq_demux_eintX_Y.
> + */
> +static inline void s5p64x0_irq_demux_eint(unsigned int start, unsigned
int end)
> +{
> + u32 status = __raw_readl(S5P64X0_EINT0PEND);
> + u32 mask = __raw_readl(S5P64X0_EINT0MASK);
> + unsigned int irq;
> +
> +
RE: [PATCH V2] ARM: EXYNOS4: Add support for ORIGEN board
Tushar Behera wrote:
>
> From: JeongHyeon Kim
>
> Insignal's ORIGEN board is based Samsung EXYNOS4210 SoC.
>
> Signed-off-by: JeongHyeon Kim
> Signed-off-by: Tushar Behera
> ---
>
> Changes for V2:
> - Reworked based on Kukjin's comments and rebased to kgene/for-next
>
> arch/arm/mach-exynos4/Kconfig | 10 +++
> arch/arm/mach-exynos4/Makefile |1 +
> arch/arm/mach-exynos4/mach-origen.c | 108
> +++
> 3 files changed, 119 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-exynos4/mach-origen.c
>
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index 52fc172..012c034 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -205,6 +205,16 @@ config MACH_NURI
> help
> Machine support for Samsung Mobile NURI Board.
>
> +config MACH_ORIGEN
> + bool "ORIGEN"
> + select CPU_EXYNOS4210
> + select S3C_DEV_RTC
> + select S3C_DEV_WDT
> + select S3C_DEV_HSMMC2
> + select EXYNOS4_SETUP_SDHCI
> + help
> + Machine support for ORIGEN based on Samsung S5PV310
> +
> endmenu
>
> comment "Configuration for HSMMC bus width"
> diff --git a/arch/arm/mach-exynos4/Makefile
b/arch/arm/mach-exynos4/Makefile
> index 2a0b682..ebec49c 100644
> --- a/arch/arm/mach-exynos4/Makefile
> +++ b/arch/arm/mach-exynos4/Makefile
> @@ -31,6 +31,7 @@ obj-$(CONFIG_MACH_SMDKV310) += mach-
> smdkv310.o
> obj-$(CONFIG_MACH_ARMLEX4210)+= mach-armlex4210.o
> obj-$(CONFIG_MACH_UNIVERSAL_C210)+= mach-universal_c210.o
> obj-$(CONFIG_MACH_NURI) += mach-nuri.o
> +obj-$(CONFIG_MACH_ORIGEN)+= mach-origen.o
>
> # device support
>
> diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-
> origen.c
> new file mode 100644
> index 000..ed59f86
> --- /dev/null
> +++ b/arch/arm/mach-exynos4/mach-origen.c
> @@ -0,0 +1,108 @@
> +/* linux/arch/arm/mach-exynos4/mach-origen.c
> + *
> + * Copyright (c) 2011 Insignal Co., Ltd.
> + * http://www.insignal.co.kr/
> + *
> + * 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
> +
> +/* Following are default values for UCON, ULCON and UFCON UART registers
*/
> +#define ORIGEN_UCON_DEFAULT (S3C2410_UCON_TXILEVEL |\
> + S3C2410_UCON_RXILEVEL |\
> + S3C2410_UCON_TXIRQMODE | \
> + S3C2410_UCON_RXIRQMODE | \
> + S3C2410_UCON_RXFIFO_TOI | \
> + S3C2443_UCON_RXERR_IRQEN)
> +
> +#define ORIGEN_ULCON_DEFAULT S3C2410_LCON_CS8
> +
> +#define ORIGEN_UFCON_DEFAULT (S3C2410_UFCON_FIFOMODE | \
> + S5PV210_UFCON_TXTRIG4 |\
> + S5PV210_UFCON_RXTRIG4)
> +
> +static struct s3c2410_uartcfg origen_uartcfgs[] __initdata = {
> + [0] = {
> + .hwport = 0,
> + .flags = 0,
> + .ucon = ORIGEN_UCON_DEFAULT,
> + .ulcon = ORIGEN_ULCON_DEFAULT,
> + .ufcon = ORIGEN_UFCON_DEFAULT,
> + },
> + [1] = {
> + .hwport = 1,
> + .flags = 0,
> + .ucon = ORIGEN_UCON_DEFAULT,
> + .ulcon = ORIGEN_ULCON_DEFAULT,
> + .ufcon = ORIGEN_UFCON_DEFAULT,
> + },
> + [2] = {
> + .hwport = 2,
> + .flags = 0,
> + .ucon = ORIGEN_UCON_DEFAULT,
> + .ulcon = ORIGEN_ULCON_DEFAULT,
> + .ufcon = ORIGEN_UFCON_DEFAULT,
> + },
> + [3] = {
> + .hwport = 3,
> + .flags = 0,
> + .ucon = ORIGEN_UCON_DEFAULT,
> + .ulcon = ORIGEN_ULCON_DEFAULT,
> + .ufcon = ORIGEN_UFCON_DEFAULT,
> + },
> +};
> +
> +static struct s3c_sdhci_platdata origen_hsmmc2_pdata __initdata = {
> + .cd_type= S3C_SDHCI_CD_GPIO,
> + .ext_cd_gpio= EXYNOS4_GPK2(2),
> + .ext_cd_gpio_invert = 1,
> + .clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
> +};
> +
> +static struct platform_device *origen_devices[] __initdata = {
> + &s3c_device_hsmmc2,
> + &s3c_device_rtc,
> + &s3c_device_wdt,
> +};
> +
> +static void __init origen_map_io(void)
> +{
> + s5p_init_io(NULL, 0, S5P_VA_CHIPID);
> + s3c24xx_init_clocks(2400);
> + s3c24xx_init_uarts(
RE: [PATCH V8 0/5] ARM: EXYNOS4: Add support EXYNOS4 FIMD
Jingoo Han wrote: > > The patches are created against "for-next" branch of Kukjin Kim's tree at: > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > > This was originally submitted by Jonghun Han > http://www.spinics.net/lists/arm-kernel/msg101781.html > > This patch adds support FIMD(Fully Interactive Mobile Display) on Exynos4. > The 4th patch is update for s3c-fb and others are for platform data > > NOTE: The common part for SMDKV310 will be updated later. > > v2: change clock name of exynos4 FIMD: "fimd" -> "lcd" > use 'has_clksel' variable in order to distinguish FIMD version > add 'lcd_clk' that can be used for only lcd pixel clock > add callback 'enable_clk()' to enable parent clock 'sclk_fimd'. > v3: remove the callback from the platform data structure > v4: move clk_enable(sfb->lcd_clk) under the if statement > v5: add clk_enable/disable(sfb->lcd_clk) to s3c_fb_runtime_suspend/resume(). > v6: rename dev-fimd-24bpp.c to dev-fimd0.c > add 'exynos4_fimd0_setup_clock()' to dev-fimd0.c to setup parent clock. > v7: remove parent clock setting from machine directory > use 'gpio_request_one()' to simply the gpio setting step > v8: updated minor fixes > > o To Kukjin Kim > [PATCH V8 1/5] ARM: EXYNOS4: Change clock name for FIMD > [PATCH V8 2/5] ARM: EXYNOS4: Add resource definition for FIMD > [PATCH V8 3/5] ARM: EXYNOS4: Add platform device and helper functions for > FIMD > [PATCH V8 5/5] ARM: EXYNOS4: Add platform data for EXYNOS4 FIMD and > LTE480WV platform-lcd on SMDKC210 > Hi Jingoo, As I replied in your 1st patch, will fix it when I apply this series. Others, looks ok to me. As you said, we need to implement handling of common part on each boards next time :) Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. > o To Paul Mundt > [PATCH V8 4/5] video: s3c-fb: Add support EXYNOS4 -- To unsubscribe from this list: send the line "unsubscribe linux-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/4] Add Samsung internal dma driver support
Sangbeom Kim wrote: > > I2S in samsung audio subsytem has a small internal dma(idma). > IDMA can be used in low power audio mode and I2S0 secondary fifo > data tranfer. > In this patchsets, idma driver is added. > Original code is made by jassi brar on SMDKV210 > After idma driver merge, I will submit low power audio support > with idma driver and samsung dsp driver. > > Changes since v1: > 1. Change idma_new by new pcm_new api > 2. Add handling different idma address > 3. As jassi comments, Modify the idma driver > > This patchset contains followings > > o To Jassi Brar, Mark Brown and Liam Girdwood, > [PATCH V2 1/4] ASoC: SAMSUNG: Modify I2S driver to support idma > [PATCH V2 2/4] ASoC: SAMSUNG: Add I2S0 internal dma driver > > o To Kukjin Kim > [PATCH V2 3/4] ARM: SAMSUNG: Add platform device for idma > [PATCH V2 4/4] ARM: SAMSUNG: Add IRQ_I2S0 definition > OK, applied 3rd and 4th. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-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 0/4] Updated s5p-mfc platform definitions
Marek Szyprowski wrote: > > Hello, > > This patch series contains platform definitions for s5p-mfc driver > rebased onto latest for-next branch (including generic GIC and clockdev > changes). Errors reported by check patch have been fixed. > OK, applied. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. > Best regards > -- > Marek Szyprowski > Samsung Poland R&D Center > > > Patch summary: > > Kamil Debski (3): > ARM: S5P: Add support for MFC device to plat-s5p, mach-s5pv210 and > mach-exynos4 > ARM: S5PV210: Enable MFC on Goni > ARM: EXYNOS4: Enable MFC on universal_c210 > > Marek Szyprowski (1): > ARM: EXYNOS4: Enable MFC on Samsung NURI > > arch/arm/Kconfig|2 + > arch/arm/mach-exynos4/Kconfig |4 + > arch/arm/mach-exynos4/clock.c | 61 + > arch/arm/mach-exynos4/include/mach/map.h|2 + > arch/arm/mach-exynos4/mach-nuri.c | 13 +++ > arch/arm/mach-exynos4/mach-universal_c210.c | 13 +++ > arch/arm/mach-s5pv210/Kconfig |1 + > arch/arm/mach-s5pv210/clock.c |7 ++ > arch/arm/mach-s5pv210/include/mach/map.h|3 + > arch/arm/mach-s5pv210/mach-goni.c | 10 ++ > arch/arm/plat-s5p/Kconfig |5 + > arch/arm/plat-s5p/Makefile |2 +- > arch/arm/plat-s5p/dev-mfc.c | 123 > +++ > arch/arm/plat-s5p/include/plat/mfc.h| 27 ++ > arch/arm/plat-samsung/include/plat/devs.h |3 + > 15 files changed, 275 insertions(+), 1 deletions(-) > create mode 100644 arch/arm/plat-s5p/dev-mfc.c > create mode 100644 arch/arm/plat-s5p/include/plat/mfc.h > > -- > 1.7.1.569.g6f426 -- To unsubscribe from this list: send the line "unsubscribe linux-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 03-1/13] DMA: PL330: Support DMA_SLAVE_CONFIG command
On Thu, Jul 21, 2011 at 12:04 PM, Boojin Kim wrote:
> Jassi Brar wrote:
>> Sent: Thursday, July 21, 2011 2:00 PM
>> To: Boojin Kim
>> Cc: linux-arm-ker...@lists.infradead.org; linux-samsung-soc@vger.kernel.org;
>> Vinod Koul; Dan Williams; Kukjin Kim
>> Subject: Re: [PATCH V4 03-1/13] DMA: PL330: Support DMA_SLAVE_CONFIG command
>>
>> On Thu, Jul 21, 2011 at 9:43 AM, Boojin Kim wrote:
>>
>> >> > - pl330_tasklet((unsigned long) pch);
>> >> > + list_splice_tail_init(&list, &pdmac->desc_pool);
>> >> > + spin_unlock_irqrestore(&pch->lock, flags);
>> >> > + break;
>> >> > + case DMA_SLAVE_CONFIG:
>> >> Please protect this section too using spin_lock.
>> > Why is spin_lock need here?
>> > This code just sets configuration data into own channel structure.
>> It does seem unncessary, but the configuration that is set here is read
>> in other parts of the driver. However unlikely but there is theoretical
>> possibility of race here - one shouldn't count upon goodness of client
>> drivers.
> Yes, Client driver doesn't afflict the configuration data again.
> So, I think spin_lock isn't required here.
>
>>
>> >>
>> >> > + if (slave_config->direction == DMA_TO_DEVICE) {
>> >> > + if (slave_config->dst_addr)
>> >> > + peri->fifo_addr =
>> >> > slave_config->dst_addr;
>> >> > + if (slave_config->dst_addr_width)
>> >> > + peri->burst_sz = __ffs(slave_config-
>> >> >dst_addr_width);
>> >> > + } else if (slave_config->direction == DMA_FROM_DEVICE)
>> >> > {
>> >> > + if (slave_config->src_addr)
>> >> > + peri->fifo_addr =
>> >> > slave_config->src_addr;
>> >> > + if (slave_config->src_addr_width)
>> >> > + peri->burst_sz = __ffs(slave_config-
>> >> >src_addr_width);
>> >> > + }
>> >> PL330 has fixed channels to peripherals.
>> >> So FIFO addresses(burst_sz too?) should already be set via platform data.
>> >> Client drivers shouldn't bother.
>> >
>> > First, DMA machine code should know the FIFO address of all client drivers
>> to
>> > set via platform data.
>> > In this case, Problem is that the definition of FIFO address is almost
>> > declared to the header file of client driver.
>> > For example, sound\soc\samsung\regs-i2s-v2.h only has the definition of
>> fifo
>> > address as following.
>> >
>> > #define S3C2412_IISTXD (0x10)
>> > #define S3C2412_IISRXD (0x14)
>> >
>> > These definitions should be referred to DMA machine code to set fifo
>> address
>> > through platform data.
>> > I think it's not good method.
>> Crap!
>> Client drivers don't conjure up the fifo address - if not hardcoded they
>> are gotten via platform_data already.
>
> For it, DMA machine code should include all header files of client driver that
> has definition of FIFO address.
> The number of header file would be more than 10. And I think it make the code
> a little complicated.
>
>>
>> > And, SLAVE_CONFIG command exist to pass slave configuration data from
>> client
>> > driver to DMA driver.
>> > So, I think that it's proper to pass fifo address through SLAVE_CONFIG
>> > command.
>> If it's still not clear, read the para above definition of 'struct
>> dma_slave_config'
>> in include/linux/dmaengine.h
>
> Other DMA client drivers in mainline code already use SLAVE_CONFIG command to
> pass fifo address as following.
> Please refer to Sound/soc/imx/imx-pcm-dma/mx2.c, Driver/mmc/host/mmci.c,
> Drivers/mmc/host/mxcmmc.c and so on.
>
> And, Other DMA drivers also support to SLAVE_CONFIG command for it.
> Please refer to amba-pl08x.c, coh901318.c, ste_dma40.c and so on in
> 'driver/dma' directory.
> So, In my opinion, this is proper method to handle the client's fifo address.
>
NAK.
--
To unsubscribe from this list: send the line "unsubscribe linux-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 V8 1/5] ARM: EXYNOS4: Change clock name for FIMD
Jingoo Han wrote:
>
> This patch changes clock for FIMD from 'fimd' to 'lcd'.
> Also, devname for FIMD is changed from 's5pv310-fb' to 'exynos4-fb'.
>
> Signed-off-by: Jingoo Han
> ---
> arch/arm/mach-exynos4/clock.c | 12 ++--
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/clock.c b/arch/arm/mach-exynos4/clock.c
> index 98b5cc4..778a202 100644
> --- a/arch/arm/mach-exynos4/clock.c
> +++ b/arch/arm/mach-exynos4/clock.c
> @@ -405,13 +405,13 @@ static struct clk init_clocks_off[] = {
> .enable = exynos4_clk_ip_cam_ctrl,
> .ctrlbit= (1 << 3),
> }, {
> - .name = "fimd",
> - .devname= "s5pv310-fb.0",
> + .name = "lcd",
> + .devname= "exynos4-fb.0",
> .enable = exynos4_clk_ip_lcd0_ctrl,
> .ctrlbit= (1 << 0),
> }, {
> - .name = "fimd",
> - .devname= "s5pv310-fb.1",
> + .name = "lcd",
As I remember, some guys discussed about the clock name before.
Please refer to the following diagram. Before EXYNOS4210 clk 'lcd' was used
for FIMD IP core clock and source of the LCD pixel clock. But the mux used
to select source of LCD pixel clock is removed. So 'lcd' clock is only used
for core clock of FIMD IP. It isn't used for LCD pixel clock.
As a result clock name was changed from lcd to fimd in the EXYNOS4210
datasheet.
Before EXYNOS4
dsys bus
+---
|
|1.clk 'lcd'
|
| FIMD block
+---+---+
4.mout_mpll |\ | | |
|m|| +-+-+ ++ |
|u|-+ | | +-+core| |
|x| | | | ++ |
|/ | | | |\ |
| | +-|m| +---+ |
| | |u|--+div| |
+--+---|x| +---+ |
2.SCLK_FIMD | |/ ||
| ||
+--++
|
inside of SoC |
---+--
outside of SoC |
| 3.LCD pixel clock
|
+--+
| LCD module |
+--+
EXYNOS4210
dsys bus
+---
|
|1.clk 'fimd'
|
| FIMD block
+---+---+
4.mout_mpll |\ | | |
|m|| | ++ |
|u|-+ | +---+core| |
|x| | | ++ |
|/ | | |
| |+---+ |
| | +--+div| |
+--+-+ +---+ |
2.SCLK_FIMD | ||
| ||
+--++
|
inside of SoC |
---+--
outside of SoC |
| 3.LCD pixel clock
|
+--+
| LCD module |
+--+
To change devname is ok to me. So will apply only it.
If any problems, please let me know :)
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> + .devname= "exynos4-fb.1",
> .enable = exynos4_clk_ip_lcd1_ctrl,
> .ctrlbit= (1 << 0),
> }, {
> @@ -909,7 +909,7 @@ static struct clksrc_clk clksrcs[] = {
> }, {
> .clk= {
> .name = "sclk_fimd",
> - .devname= "s5pv310-fb.0",
> + .devname= "exynos4-fb.0",
> .enable = exynos4_clksrc_mask_lcd0_ctrl,
> .ctrlbit= (1 << 0),
> },
> @@ -919,7 +919,7 @@ static struct clksrc_clk clksrcs[] = {
> }, {
> .clk= {
> .name = "sclk_fimd",
> - .devname= "s5pv310-fb.1",
> + .devname= "exynos4-fb.1",
> .enable = exynos4_cl
