[PATCH] ARM: EXYNOS: Fix compilation warning in dma.c
The following warning is fixed in dma.c file:
"warning: ‘dma_dmamask’ defined but not used [-Wunused-variable]"
Signed-off-by: Sachin Kamat
---
arch/arm/mach-exynos/dma.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/dma.c b/arch/arm/mach-exynos/dma.c
index 13607c4..d3ed1fb 100644
--- a/arch/arm/mach-exynos/dma.c
+++ b/arch/arm/mach-exynos/dma.c
@@ -35,8 +35,6 @@
#include
#include
-static u64 dma_dmamask = DMA_BIT_MASK(32);
-
static u8 exynos4210_pdma0_peri[] = {
DMACH_PCM0_RX,
DMACH_PCM0_TX,
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] ARM: Exynos: Add device tree support for interrupt combiner
On 13 March 2012 09:22, Grant Likely wrote:
> On Tue, 21 Feb 2012 10:03:26 +0530, Thomas Abraham
> wrote:
>> Add device tree based instantiation of the interrupt combiner controller.
>>
>> Cc: Grant Likely
>> Cc: Rob Herring
>> Signed-off-by: Thomas Abraham
>> ---
>> @@ -406,13 +432,33 @@ void __init combiner_init(void __iomem *combiner_base,
>> struct device_node *np)
>>
>> for (i = 0; i < MAX_COMBINER_NR; i++) {
>> combiner_init_one(i, combiner_base + (i >> 2) * 0x10);
>> - combiner_cascade_irq(i, IRQ_SPI(i));
>> +#ifdef CONFIG_OF
>> + irq = np ? irq_of_parse_and_map(np, i) : IRQ_SPI(i);
>> +#else
>> + irq = IRQ_SPI(i);
>> +#endif
>
> Hmmm, the #ifdef is rather ugly. I'd rather have an empty
> irq_of_parse_and_map() that always returns 0.
>
> The patch series is fine, and you can add my acked-by, but please send
> a follow-up patch to clean it up.
>
> Acked-by: Grant Likely
>
Thanks. I will send a follow-up to clean it.
Regards,
Thomas.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] regulator: add device tree support for max8997
On 13 March 2012 09:13, Grant Likely wrote:
> On Thu, 23 Feb 2012 18:08:08 +0530, Thomas Abraham
> wrote:
>> Add device tree based discovery support for max8997.
>>
>> Cc: MyungJoo Ham
>> Cc: Rajendra Nayak
>> Cc: Rob Herring
>> Cc: Grant Likely
>> Signed-off-by: Thomas Abraham
>> ---
>> .../devicetree/bindings/regulator/max8997-pmic.txt | 134
>> +++
>> drivers/mfd/max8997.c | 72 ++-
>> drivers/regulator/max8997.c | 139
>> +++-
>> include/linux/mfd/max8997.h | 1 +
>> 4 files changed, 344 insertions(+), 2 deletions(-)
>> create mode 100644
>> Documentation/devicetree/bindings/regulator/max8997-pmic.txt
>>
[...]
>> diff --git a/drivers/mfd/max8997.c b/drivers/mfd/max8997.c
>> index 20ecad3..13180be 100644
>> --- a/drivers/mfd/max8997.c
>> +++ b/drivers/mfd/max8997.c
>> @@ -23,6 +23,7 @@
>>
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -123,6 +124,60 @@ int max8997_update_reg(struct i2c_client *i2c, u8 reg,
>> u8 val, u8 mask)
>> }
>> EXPORT_SYMBOL_GPL(max8997_update_reg);
>>
>> +#ifdef CONFIG_OF
>> +/*
>> + * Only the common platform data elements for max8997 are parsed here from
>> the
>> + * device tree. Other sub-modules of max8997 such as pmic, rtc and others
>> have
>> + * to parse their own platform data elements from device tree.
>> + *
>> + * The max8997 platform data structure is instantiated here and the drivers
>> for
>> + * the sub-modules need not instantiate another instance while parsing their
>> + * platform data.
>> + */
>> +static int max8997_i2c_parse_dt_pdata(struct device *dev,
>> + struct max8997_platform_data **pdata)
>> +{
>> + struct max8997_platform_data *pd;
>> +
>> + pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
>> + if (!pd) {
>> + dev_err(dev, "could not allocate memory for pdata\n");
>> + return -ENOMEM;
>> + }
>> +
>> + pd->ono = irq_of_parse_and_map(dev->of_node, 1);
>> +
>> + /*
>> + * ToDo: the 'wakeup' member in the platform data is more of a linux
>> + * specfic information. Hence, there is no binding for that yet and
>> + * not parsed here.
>> + */
>> +
>> + *pdata = pd;
>> + return 0;
>> +}
>> +#else
>> +static int max8997_i2c_parse_dt_pdata(struct device *dev,
>> + struct max8997_platform_data **pdata)
>> +{
>> + return 0;
>> +}
>> +#endif
>> +
>> +static struct of_device_id __devinitdata max8997_pmic_dt_match[];
>
> Move the actual definition of this structure up to here so that a forward
> declaration becomes unnecessary.
>
Ok.
>> +static inline int max8997_i2c_get_driver_data(struct i2c_client *i2c,
>> + const struct i2c_device_id *id)
>> +{
>> +#ifdef CONFIG_OF
>> + if (i2c->dev.of_node) {
>> + const struct of_device_id *match;
>> + match = of_match_node(max8997_pmic_dt_match, i2c->dev.of_node);
>> + return (int)match->data;
>> + }
>> +#endif
>> + return (int)id->driver_data;
>> +}
>> +
>> static int max8997_i2c_probe(struct i2c_client *i2c,
>> const struct i2c_device_id *id)
>> {
>> @@ -137,9 +192,16 @@ static int max8997_i2c_probe(struct i2c_client *i2c,
>> i2c_set_clientdata(i2c, max8997);
>> max8997->dev = &i2c->dev;
>> max8997->i2c = i2c;
>> - max8997->type = id->driver_data;
>> + max8997->type = max8997_i2c_get_driver_data(i2c, id);
>> max8997->irq = i2c->irq;
>>
>> + if (max8997->dev->of_node) {
>> + ret = max8997_i2c_parse_dt_pdata(max8997->dev, &pdata);
>> + if (ret)
>> + goto err;
>> + i2c->dev.platform_data = pdata;
>
> This line is illegal. Drivers must *not* change the value of
> dev->platform_data.
> instead the valid pdata pointer needs to be stored in the max8997 private data
> structure.
The intention here was to let the max8897 driver's mfd portion create
an 'common' instance of max8897 platform data and allow the max8997
sub-drivers such as the pmic driver and charger driver use that
'common' instance to populate their respective platform data portions
from dt. But, assigning that allocated pdata pointer to
i2c->dev.platform_data was not correct, I agree.
Instead, a new pointer to 'struct max8997_platform_data' will be added
to 'struct max8997_dev', assign the pdata in the mfd driver to this
new member and let the sub-drivers use the pdata pointer in 'struct
max8997_dev'. I will do this change and repost this patch.
>
>> + }
>> +
>
> If you tweak the definition of max8997_i2c_parse_dt_pdata() then this block
> can
> be simplified to:
>
> pdata = max8997_i2c_parse_dt_pdata(max8997->dev, &pdata);
> if (!pdata)
> pdata = i2c->dev.platform_data,
> if (!pda
[PATCH] ARM: EXYNOS: Fix compilation warning in common.c
The following warning is fixed in common.c file:
"warning: unused variable ‘ret’ [-Wunused-variable]"
Signed-off-by: Sachin Kamat
---
arch/arm/mach-exynos/common.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index a6e6ad2..4610452 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -585,8 +585,6 @@ core_initcall(exynos_core_init);
#ifdef CONFIG_CACHE_L2X0
static int __init exynos4_l2x0_cache_init(void)
{
- int ret;
-
if (soc_is_exynos5250())
return 0;
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] mfd: add irq domain support for max8997 interrupts
On 13 March 2012 08:58, Grant Likely wrote:
> On Thu, 23 Feb 2012 18:08:07 +0530, Thomas Abraham
> wrote:
>> Add irq domain support for max8997 interrupts. The reverse mapping method
>> used is linear mapping since the sub-drivers of max8997 such as regulator
>> and charger drivers can use the max8997 irq_domain to get the linux irq
>> number for max8997 interrupts. All uses of irq_base in platform data and
>> max8997 driver private data are removed.
>>
>> Cc: Grant Likely
>> Cc: MyungJoo Ham
>> Signed-off-by: Thomas Abraham
>> ---
>> arch/arm/mach-exynos/mach-nuri.c | 4 --
>> arch/arm/mach-exynos/mach-origen.c | 1 -
>> drivers/mfd/max8997-irq.c | 60
>> --
>> drivers/mfd/max8997.c | 1 -
>> include/linux/mfd/max8997-private.h | 4 ++-
>> include/linux/mfd/max8997.h | 1 -
>> 6 files changed, 38 insertions(+), 33 deletions(-)
>
> Nice patch. Nice diffstat too. Some comments below, but I'm happy with where
> this is at.
>
> Acked-by: Grant Likely
Thank you Grant for reviewing this patch.
>
>>
>> diff --git a/arch/arm/mach-exynos/mach-nuri.c
>> b/arch/arm/mach-exynos/mach-nuri.c
>> index a6b9162..1e9ba12 100644
>> --- a/arch/arm/mach-exynos/mach-nuri.c
>> +++ b/arch/arm/mach-exynos/mach-nuri.c
>> @@ -1078,12 +1078,8 @@ static struct platform_device nuri_max8903_device = {
>> static void __init nuri_power_init(void)
>> {
>> int gpio;
>> - int irq_base = IRQ_GPIO_END + 1;
>> int ta_en = 0;
>>
>> - nuri_max8997_pdata.irq_base = irq_base;
>> - irq_base += MAX8997_IRQ_NR;
>> -
>> gpio = EXYNOS4_GPX0(7);
>> gpio_request(gpio, "AP_PMIC_IRQ");
>> s3c_gpio_cfgpin(gpio, S3C_GPIO_SFN(0xf));
>> diff --git a/arch/arm/mach-exynos/mach-origen.c
>> b/arch/arm/mach-exynos/mach-origen.c
>> index 02c242e..328dadb 100644
>> --- a/arch/arm/mach-exynos/mach-origen.c
>> +++ b/arch/arm/mach-exynos/mach-origen.c
>> @@ -424,7 +424,6 @@ static struct max8997_platform_data __initdata
>> origen_max8997_pdata = {
>> .buck1_gpiodvs = false,
>> .buck2_gpiodvs = false,
>> .buck5_gpiodvs = false,
>> - .irq_base = IRQ_GPIO_END + 1,
>>
>> .ignore_gpiodvs_side_effect = true,
>> .buck125_default_idx = 0x0,
>> diff --git a/drivers/mfd/max8997-irq.c b/drivers/mfd/max8997-irq.c
>> index 09274cf..3d8c9d1 100644
>> --- a/drivers/mfd/max8997-irq.c
>> +++ b/drivers/mfd/max8997-irq.c
>> @@ -142,7 +142,8 @@ static void max8997_irq_sync_unlock(struct irq_data
>> *data)
>> static const inline struct max8997_irq_data *
>> irq_to_max8997_irq(struct max8997_dev *max8997, int irq)
>> {
>> - return &max8997_irqs[irq - max8997->irq_base];
>> + struct irq_data *data = irq_get_irq_data(irq);
>> + return &max8997_irqs[data->hwirq];
>
> Hahaha. The max8997_irqs table is kind of overdone when the group and mask
> values
> can be arithmetically derived from the hwirq number..
Yes, I agree. Each group could have maximum of 8 interrupts. Then,
data->hwirq % 8 will be the group number and data->hwirq & 7 would be
the mask. The enum max8997_irq can then be adjusted to accommodate
unused irq numbers.
>
> This change is fine, but the driver could use some refactoring. :-)
Ok.
>
>> }
>>
>> static void max8997_irq_mask(struct irq_data *data)
>> @@ -182,7 +183,7 @@ static irqreturn_t max8997_irq_thread(int irq, void
>> *data)
>> u8 irq_reg[MAX8997_IRQ_GROUP_NR] = {};
>> u8 irq_src;
>> int ret;
>> - int i;
>> + int i, cur_irq;
>>
>> ret = max8997_read_reg(max8997->i2c, MAX8997_REG_INTSRC, &irq_src);
>> if (ret < 0) {
>> @@ -269,8 +270,10 @@ static irqreturn_t max8997_irq_thread(int irq, void
>> *data)
>>
>> /* Report */
>> for (i = 0; i < MAX8997_IRQ_NR; i++) {
>> - if (irq_reg[max8997_irqs[i].group] & max8997_irqs[i].mask)
>> - handle_nested_irq(max8997->irq_base + i);
>> + if (irq_reg[max8997_irqs[i].group] & max8997_irqs[i].mask) {
>> + cur_irq = irq_find_mapping(max8997->irq_domain, i);
>> + handle_nested_irq(cur_irq);
>> + }
>
> Well, if you're using the linear mapping, then only actually allocated irqs
> will
> have a mapping set up. So the driver could simply do:
>
> for (i = 0; i < MAX8997_IRQ_NR; i++) {
> cur_irq = irq_find_mapping(max8997->irq_domain, i);
> if (cur_irq)
> handle_nested_irq(cur_irq);
> }
Thanks for the suggestion. I will include this change and repost this patch.
Regards,
Thomas.
[...]
--
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/4] thermal: exynos: Add thermal interface support for linux thermal layer
Hi Amit, [snip.] > >> + > >> + kobject_uevent(&th_zone->therm_dev->device.kobj, KOBJ_CHANGE); > > > > Wouldn't it make more sense to pass the trip point id also as an 'env' > > parameter ? This way, the user space can easily figure out which trip > > point has been crossed. > Its a good suggestion. I will check if some uevent property allows that. The kobject_uevent_env(...) call allows that. The third argument takes a char *envp[]. For example, We could pass "trip=0" to indicate the trip point. I should have mentioned this in my previous reply itself..missed it.. Thanks, Durga -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: Exynos: Add DRM core device support for Universal C210 board
On 3/13/12, Sachin Kamat wrote:
> Hi Marek,
> Thanks for the patch.
>
> On 09/03/2012, Marek Szyprowski wrote:
>> Add core DRM device and alternative platform device data for FIMD DRM
>> subdriver. Based on the initial patch by Joonyoung Shim
>>
>>
>> Signed-off-by: Marek Szyprowski
>> Signed-off-by: Kyungmin Park
>> ---
>> arch/arm/mach-exynos/Kconfig |1 +
>> arch/arm/mach-exynos/mach-universal_c210.c | 31
>>
>> 2 files changed, 32 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
>> index 5a26944..c73eeba 100644
>> --- a/arch/arm/mach-exynos/Kconfig
>> +++ b/arch/arm/mach-exynos/Kconfig
>> @@ -257,6 +257,7 @@ config MACH_UNIVERSAL_C210
>> select S5P_DEV_ONENAND
>> select S5P_DEV_TV
>> select EXYNOS4_DEV_DMA
>> +select EXYNOS_DEV_DRM
>> select EXYNOS4_SETUP_FIMD0
>> select EXYNOS4_SETUP_I2C1
>> select EXYNOS4_SETUP_I2C3
>> diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
>> b/arch/arm/mach-exynos/mach-universal_c210.c
>> index 322b272..30a3ff3 100644
>> --- a/arch/arm/mach-exynos/mach-universal_c210.c
>> +++ b/arch/arm/mach-exynos/mach-universal_c210.c
>> @@ -23,6 +23,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -811,6 +812,27 @@ static struct i2c_board_info i2c1_devs[] __initdata =
>> {
>> /* Gyro, To be updated */
>> };
>>
>> +#ifdef CONFIG_DRM_EXYNOS
>> +static struct exynos_drm_fimd_pdata drm_fimd_pdata = {
>> +.timing = {
>> +.left_margin= 16,
>> +.right_margin = 16,
>> +.upper_margin = 2,
>> +.lower_margin = 28,
>> +.hsync_len = 2,
>> +.vsync_len = 1,
>> +.xres = 480,
>> +.yres = 800,
>> +.refresh= 55,
>> +},
>
> Shouldn't this be:
Right, recently we added the panel information. It should be drm-next soon.
Thank you,
Kyungmin Park
>.panel = {
> .timing = {
> .left_margin= 16,
> .right_margin = 16,
> .upper_margin = 2,
> .lower_margin = 28,
> .hsync_len = 2,
> .vsync_len = 1,
> .xres = 480,
> .yres = 800,
> .refresh= 55,
> },
> },
>
>
>> +.vidcon0= VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB |
>> + VIDCON0_CLKSEL_LCD,
>> +.vidcon1= VIDCON1_INV_VCLK | VIDCON1_INV_VDEN
>> + | VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
>> +.default_win= 3,
>> +.bpp= 32,
>> +};
>> +#else
>> /* Frame Buffer */
>> static struct s3c_fb_pd_win universal_fb_win0 = {
>> .win_mode = {
>> @@ -838,6 +860,7 @@ static struct s3c_fb_platdata universal_lcd_pdata
>> __initdata = {
>>| VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
>> .setup_gpio = exynos4_fimd0_gpio_setup_24bpp,
>> };
>> +#endif
>>
>> static struct regulator_consumer_supply cam_vt_dio_supply =
>> REGULATOR_SUPPLY("vdd_core", "0-003c");
>> @@ -1046,6 +1069,9 @@ static struct platform_device *universal_devices[]
>> __initdata = {
>> &universal_gpio_keys,
>> &s5p_device_onenand,
>> &s5p_device_fimd0,
>> +#ifdef CONFIG_DRM_EXYNOS
>> +&exynos_device_drm,
>> +#endif
>> &s5p_device_mfc,
>> &s5p_device_mfc_l,
>> &s5p_device_mfc_r,
>> @@ -1091,7 +1117,12 @@ static void __init universal_machine_init(void)
>> s5p_i2c_hdmiphy_set_platdata(NULL);
>> i2c_register_board_info(5, i2c5_devs, ARRAY_SIZE(i2c5_devs));
>>
>> +#ifdef CONFIG_DRM_EXYNOS
>> +s5p_device_fimd0.dev.platform_data = &drm_fimd_pdata;
>> +exynos4_fimd0_gpio_setup_24bpp();
>> +#else
>> s5p_fimd0_set_platdata(&universal_lcd_pdata);
>> +#endif
>>
>> universal_touchkey_init();
>> i2c_register_board_info(I2C_GPIO_BUS_12, i2c_gpio12_devs,
>> --
>> 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
>>
>
>
> --
> 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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: Exynos: Add DRM core support for NURI board
Hi Marek,
On 09/03/2012, Marek Szyprowski wrote:
> Add core DRM device and alternative platform device data for FIMD DRM
> subdriver. Based on the initial patch by Joonyoung Shim
>
>
> Signed-off-by: Marek Szyprowski
> Signed-off-by: Kyungmin Park
> ---
> arch/arm/mach-exynos/Kconfig |1 +
> arch/arm/mach-exynos/mach-nuri.c | 31 +++
> 2 files changed, 32 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index c73eeba..e996b5d 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -293,6 +293,7 @@ config MACH_NURI
> select S5P_DEV_USB_EHCI
> select S5P_SETUP_MIPIPHY
> select EXYNOS4_DEV_DMA
> + select EXYNOS_DEV_DRM
> select EXYNOS4_SETUP_FIMC
> select EXYNOS4_SETUP_FIMD0
> select EXYNOS4_SETUP_I2C1
> diff --git a/arch/arm/mach-exynos/mach-nuri.c
> b/arch/arm/mach-exynos/mach-nuri.c
> index a6b9162..682203a 100644
> --- a/arch/arm/mach-exynos/mach-nuri.c
> +++ b/arch/arm/mach-exynos/mach-nuri.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -210,6 +211,27 @@ static struct platform_device nuri_gpio_keys = {
> },
> };
>
> +#ifdef CONFIG_DRM_EXYNOS
> +static struct exynos_drm_fimd_pdata drm_fimd_pdata = {
> + .timing = {
> + .xres = 1024,
> + .yres = 600,
> + .hsync_len = 40,
> + .left_margin= 79,
> + .right_margin = 200,
> + .vsync_len = 10,
> + .upper_margin = 10,
> + .lower_margin = 11,
> + .refresh= 60,
> + },
Same comment as given for the previous patch [2/3] in this series.
> + .vidcon0= VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB |
> + VIDCON0_CLKSEL_LCD,
> + .vidcon1= VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
> + .default_win= 3,
> + .bpp= 32,
> +};
> +
> +#else
> /* Frame Buffer */
> static struct s3c_fb_pd_win nuri_fb_win0 = {
> .win_mode = {
> @@ -236,6 +258,7 @@ static struct s3c_fb_platdata nuri_fb_pdata __initdata =
> {
> .vidcon1= VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
> .setup_gpio = exynos4_fimd0_gpio_setup_24bpp,
> };
> +#endif
>
> static void nuri_lcd_power_on(struct plat_lcd_data *pd, unsigned int power)
> {
> @@ -1335,6 +1358,9 @@ static struct platform_device *nuri_devices[]
> __initdata = {
> &cam_vt_cam15_fixed_rdev,
> &cam_vdda_fixed_rdev,
> &cam_8m_12v_fixed_rdev,
> +#ifdef CONFIG_DRM_EXYNOS
> + &exynos_device_drm,
> +#endif
> };
>
> static void __init nuri_map_io(void)
> @@ -1366,7 +1392,12 @@ static void __init nuri_machine_init(void)
> i2c_register_board_info(9, i2c9_devs, ARRAY_SIZE(i2c9_devs));
> s3c_i2c6_set_platdata(&nuri_i2c6_platdata);
>
> +#ifdef CONFIG_DRM_EXYNOS
> + s5p_device_fimd0.dev.platform_data = &drm_fimd_pdata;
> + exynos4_fimd0_gpio_setup_24bpp();
> +#else
> s5p_fimd0_set_platdata(&nuri_fb_pdata);
> +#endif
>
> nuri_camera_init();
>
> --
> 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
>
--
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 2/3] ARM: Exynos: Add DRM core device support for Universal C210 board
Hi Marek,
Thanks for the patch.
On 09/03/2012, Marek Szyprowski wrote:
> Add core DRM device and alternative platform device data for FIMD DRM
> subdriver. Based on the initial patch by Joonyoung Shim
>
>
> Signed-off-by: Marek Szyprowski
> Signed-off-by: Kyungmin Park
> ---
> arch/arm/mach-exynos/Kconfig |1 +
> arch/arm/mach-exynos/mach-universal_c210.c | 31
>
> 2 files changed, 32 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 5a26944..c73eeba 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -257,6 +257,7 @@ config MACH_UNIVERSAL_C210
> select S5P_DEV_ONENAND
> select S5P_DEV_TV
> select EXYNOS4_DEV_DMA
> + select EXYNOS_DEV_DRM
> select EXYNOS4_SETUP_FIMD0
> select EXYNOS4_SETUP_I2C1
> select EXYNOS4_SETUP_I2C3
> diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
> b/arch/arm/mach-exynos/mach-universal_c210.c
> index 322b272..30a3ff3 100644
> --- a/arch/arm/mach-exynos/mach-universal_c210.c
> +++ b/arch/arm/mach-exynos/mach-universal_c210.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -811,6 +812,27 @@ static struct i2c_board_info i2c1_devs[] __initdata = {
> /* Gyro, To be updated */
> };
>
> +#ifdef CONFIG_DRM_EXYNOS
> +static struct exynos_drm_fimd_pdata drm_fimd_pdata = {
> + .timing = {
> + .left_margin= 16,
> + .right_margin = 16,
> + .upper_margin = 2,
> + .lower_margin = 28,
> + .hsync_len = 2,
> + .vsync_len = 1,
> + .xres = 480,
> + .yres = 800,
> + .refresh= 55,
> + },
Shouldn't this be:
.panel = {
.timing = {
.left_margin= 16,
.right_margin = 16,
.upper_margin = 2,
.lower_margin = 28,
.hsync_len = 2,
.vsync_len = 1,
.xres = 480,
.yres = 800,
.refresh= 55,
},
},
> + .vidcon0= VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB |
> + VIDCON0_CLKSEL_LCD,
> + .vidcon1= VIDCON1_INV_VCLK | VIDCON1_INV_VDEN
> + | VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
> + .default_win= 3,
> + .bpp= 32,
> +};
> +#else
> /* Frame Buffer */
> static struct s3c_fb_pd_win universal_fb_win0 = {
> .win_mode = {
> @@ -838,6 +860,7 @@ static struct s3c_fb_platdata universal_lcd_pdata
> __initdata = {
> | VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
> .setup_gpio = exynos4_fimd0_gpio_setup_24bpp,
> };
> +#endif
>
> static struct regulator_consumer_supply cam_vt_dio_supply =
> REGULATOR_SUPPLY("vdd_core", "0-003c");
> @@ -1046,6 +1069,9 @@ static struct platform_device *universal_devices[]
> __initdata = {
> &universal_gpio_keys,
> &s5p_device_onenand,
> &s5p_device_fimd0,
> +#ifdef CONFIG_DRM_EXYNOS
> + &exynos_device_drm,
> +#endif
> &s5p_device_mfc,
> &s5p_device_mfc_l,
> &s5p_device_mfc_r,
> @@ -1091,7 +1117,12 @@ static void __init universal_machine_init(void)
> s5p_i2c_hdmiphy_set_platdata(NULL);
> i2c_register_board_info(5, i2c5_devs, ARRAY_SIZE(i2c5_devs));
>
> +#ifdef CONFIG_DRM_EXYNOS
> + s5p_device_fimd0.dev.platform_data = &drm_fimd_pdata;
> + exynos4_fimd0_gpio_setup_24bpp();
> +#else
> s5p_fimd0_set_platdata(&universal_lcd_pdata);
> +#endif
>
> universal_touchkey_init();
> i2c_register_board_info(I2C_GPIO_BUS_12, i2c_gpio12_devs,
> --
> 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
>
--
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 1/4] thermal: exynos: Add thermal interface support for linux thermal layer
Hi Durgadoss,
Thanks for the detailed review.
On 12 March 2012 16:21, R, Durgadoss wrote:
> Hi Amit,
>
> Thanks for keeping this up. And Sorry for late reply.
>
>> -Original Message-
>> From: amit kachhap [mailto:amitdani...@gmail.com] On Behalf Of Amit Daniel
>> Kachhap
>> Sent: Saturday, March 03, 2012 4:36 PM
>> To: linux...@lists.linux-foundation.org; linux-samsung-soc@vger.kernel.org
>> Cc: linux-ker...@vger.kernel.org; mj...@srcf.ucam.org; linux-
>> a...@vger.kernel.org; l...@kernel.org; linaro-...@lists.linaro.org; lm-
>> sens...@lm-sensors.org; amit.kach...@linaro.org; eduardo.valen...@ti.com; R,
>> Durgadoss; patc...@linaro.org
>> Subject: [PATCH 1/4] thermal: exynos: Add thermal interface support for linux
>> thermal layer
>>
>> This codes uses the generic linux thermal layer and creates a bridge
>> between temperature sensors, linux thermal framework and cooling devices
>> for samsung exynos platform. This layer recieves or monitor the
>> temperature from the sensor and informs the generic thermal layer to take
>> the necessary cooling action.
>>
>> Signed-off-by: Amit Daniel Kachhap
>> ---
>> drivers/thermal/Kconfig | 8 +
>> drivers/thermal/Makefile | 1 +
>> drivers/thermal/exynos_thermal.c | 272
>> ++
>> include/linux/exynos_thermal.h | 72 ++
>> 4 files changed, 353 insertions(+), 0 deletions(-)
>> create mode 100644 drivers/thermal/exynos_thermal.c
>> create mode 100644 include/linux/exynos_thermal.h
>>
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index 298c1cd..4e8df56 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -29,3 +29,11 @@ config CPU_THERMAL
>> This will be useful for platforms using the generic thermal interface
>> and not the ACPI interface.
>> If you want this support, you should say Y or M here.
>> +
>> +config SAMSUNG_THERMAL_INTERFACE
>> + bool "Samsung Thermal interface support"
>> + depends on THERMAL && CPU_THERMAL
>> + help
>> + This is a samsung thermal interface which will be used as
>> + a link between sensors and cooling devices with linux thermal
>> + framework.
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index 655cbc4..c67b6b2 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -4,3 +4,4 @@
>>
>> obj-$(CONFIG_THERMAL) += thermal_sys.o
>> obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
>> +obj-$(CONFIG_SAMSUNG_THERMAL_INTERFACE) += exynos_thermal.o
>> diff --git a/drivers/thermal/exynos_thermal.c
>> b/drivers/thermal/exynos_thermal.c
>> new file mode 100644
>> index 000..878d45c
>> --- /dev/null
>> +++ b/drivers/thermal/exynos_thermal.c
>> @@ -0,0 +1,272 @@
>> +/* linux/drivers/thermal/exynos_thermal.c
>> + *
>> + * Copyright (c) 2010-2011 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
>> +
>> +#define MAX_COOLING_DEVICE 4
>> +struct exynos4_thermal_zone {
>> + unsigned int idle_interval;
>> + unsigned int active_interval;
>> + struct thermal_zone_device *therm_dev;
>> + struct thermal_cooling_device *cool_dev[MAX_COOLING_DEVICE];
>> + unsigned int cool_dev_size;
>> + struct platform_device *exynos4_dev;
>> + struct thermal_sensor_conf *sensor_conf;
>> +};
>> +
>> +static struct exynos4_thermal_zone *th_zone;
>> +
>> +static int exynos4_get_mode(struct thermal_zone_device *thermal,
>> + enum thermal_device_mode *mode)
>> +{
>> + if (th_zone->sensor_conf) {
>> + pr_info("Temperature sensor not initialised\n");
>> + *mode = THERMAL_DEVICE_DISABLED;
>> + } else
>> + *mode = THERMAL_DEVICE_ENABLED;
>> + return 0;
>> +}
>> +
>> +static int exynos4_set_mode(struct thermal_zone_device *thermal,
>> + enum thermal_device_mode mode)
>> +{
>> + if (!th_zone->therm_dev) {
>> + pr_notice("thermal zone not registered\n");
>> + return 0;
>> + }
>> + if (mode == THERMAL_DEVICE_ENABLED)
>> + th_zone->therm_dev->polling_delay =
>> + th_zone->active_interval*1000;
>> + else
>> + th_zone->therm_dev->polling_delay =
>> + th_zone->idle_interval*1000;
>
> If it is 'DISABLED' mode, shouldn't the polling delay be just 0 ?
Yes Ideally this should be zero. But I wanted thermal monitoring to
always happen with some long interval in case of error scenarios.
Anyway I will check this again.
>
>> +
>> + thermal_zone_devi
Re: [PATCH v4 2/2] ARM: Exynos: Add device tree support for interrupt combiner
On Tue, 21 Feb 2012 10:03:26 +0530, Thomas Abraham
wrote:
> Add device tree based instantiation of the interrupt combiner controller.
>
> Cc: Grant Likely
> Cc: Rob Herring
> Signed-off-by: Thomas Abraham
> ---
> @@ -406,13 +432,33 @@ void __init combiner_init(void __iomem *combiner_base,
> struct device_node *np)
>
> for (i = 0; i < MAX_COMBINER_NR; i++) {
> combiner_init_one(i, combiner_base + (i >> 2) * 0x10);
> - combiner_cascade_irq(i, IRQ_SPI(i));
> +#ifdef CONFIG_OF
> + irq = np ? irq_of_parse_and_map(np, i) : IRQ_SPI(i);
> +#else
> + irq = IRQ_SPI(i);
> +#endif
Hmmm, the #ifdef is rather ugly. I'd rather have an empty
irq_of_parse_and_map() that always returns 0.
The patch series is fine, and you can add my acked-by, but please send
a follow-up patch to clean it up.
Acked-by: Grant Likely
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] regulator: add device tree support for max8997
On Thu, 23 Feb 2012 18:08:08 +0530, Thomas Abraham
wrote:
> Add device tree based discovery support for max8997.
>
> Cc: MyungJoo Ham
> Cc: Rajendra Nayak
> Cc: Rob Herring
> Cc: Grant Likely
> Signed-off-by: Thomas Abraham
> ---
> .../devicetree/bindings/regulator/max8997-pmic.txt | 134 +++
> drivers/mfd/max8997.c | 72 ++-
> drivers/regulator/max8997.c| 139
> +++-
> include/linux/mfd/max8997.h|1 +
> 4 files changed, 344 insertions(+), 2 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/regulator/max8997-pmic.txt
>
> diff --git a/Documentation/devicetree/bindings/regulator/max8997-pmic.txt
> b/Documentation/devicetree/bindings/regulator/max8997-pmic.txt
> new file mode 100644
> index 000..d282635
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/max8997-pmic.txt
> @@ -0,0 +1,134 @@
> +* Maxim MAX8997 Voltage and Current Regulator
> +
> +The Maxim MAX8997 is a multi-function device which includes volatage and
> +current regulators, rtc, charger controller and other sub-blocks. It is
> +interfaced to the host controller using a i2c interface. Each sub-block is
> +addressed by the host system using different i2c slave address. This document
> +describes the bindings for 'pmic' sub-block of max8997.
> +
> +Required properties:
> +- compatible: Should be "maxim,max8997-pmic".
> +- reg: Specifies the i2c slave address of the pmic block. It should be 0x66.
> +
> +- max8997,pmic-buck1-dvs-voltage: A set of 8 voltage values in micro-volt
> (uV)
> + units for buck1 when changing voltage using gpio dvs. Refer to [1] below
> + for additional information.
> +
> +- max8997,pmic-buck2-dvs-voltage: A set of 8 voltage values in micro-volt
> (uV)
> + units for buck2 when changing voltage using gpio dvs. Refer to [1] below
> + for additional information.
> +
> +- max8997,pmic-buck5-dvs-voltage: A set of 8 voltage values in micro-volt
> (uV)
> + units for buck5 when changing voltage using gpio dvs. Refer to [1] below
> + for additional information.
> +
> +[1] If none of the 'max8997,pmic-buck[1/2/5]-uses-gpio-dvs' optional
> +property is specified, the 'max8997,pmic-buck[1/2/5]-dvs-voltage'
> +property should specify atleast one voltage level (which would be a
> +safe operating voltage).
> +
> +If either of the 'max8997,pmic-buck[1/2/5]-uses-gpio-dvs' optional
> +property is specified, then all the eigth voltage values for the
> +'max8997,pmic-buck[1/2/5]-dvs-voltage' should be specified.
> +
> +Optional properties:
> +- interrupt-parent: Specifies the phandle of the interrupt controller to
> which
> + the interrupts from max8997 are delivered to.
> +- interrupts: Interrupt specifiers for two interrupt sources.
> + - First interrupt specifier is for 'irq1' interrupt.
> + - Second interrupt specifier is for 'alert' interrupt.
> +- max8997,pmic-buck1-uses-gpio-dvs: 'buck1' can be controlled by gpio dvs.
> +- max8997,pmic-buck2-uses-gpio-dvs: 'buck2' can be controlled by gpio dvs.
> +- max8997,pmic-buck5-uses-gpio-dvs: 'buck5' can be controlled by gpio dvs.
> +
> +Additional properties required if either of the optional properties are used:
> +- max8997,pmic-ignore-gpiodvs-side-effect: When GPIO-DVS mode is used for
> + multiple bucks, changing the voltage value of one of the bucks may affect
> + that of another buck, which is the side effect of the change (set_voltage).
> + Use this property to ignore such side effects and change the voltage.
> +
> +- max8997,pmic-buck125-default-dvs-idx: Default voltage setting selected from
> + the possible 8 options selectable by the dvs gpios. The value of this
> + property should be between 0 and 7. If not specified or if out of range,
> the
> + default value of this property is set to 0.
> +
> +- max8997,pmic-buck125-dvs-gpios: GPIO specifiers for three host gpio's used
> + for dvs. The format of the gpio specifier depends in the gpio controller.
> +
> +
> +Regulators: The regulators of max8997 that have to be instantiated should be
> +included in a sub-node named 'regulators'. Regulator nodes included in this
> +sub-node should be of the format as below. Note: The 'n' in LDOn and BUCKn
> +represents the LDO or BUCK number as per the datasheet of max8997.
> +
> +For LDO's:
> + LDOn {
> + standard regulator bindings here
> + };
> +
> +For BUCK's:
> + BUCKn {
> + standard regulator bindings here
> + };
> +
> +The bindings inside the regulator nodes use the standard regulator bindings
> +which are documented elsewhere.
> +
> +Example:
> +
> + max8997_pmic@66 {
> + compatible = "maxim,max8997-pmic";
> + interrupt-parent = <&wakeup_eint>;
> + reg = <0x66>;
> + interrupts = <4 0>, <3 0>;
> +
> + max8997,pmic-buc
Re: [PATCH v3 1/2] mfd: add irq domain support for max8997 interrupts
On Thu, 23 Feb 2012 18:08:07 +0530, Thomas Abraham
wrote:
> Add irq domain support for max8997 interrupts. The reverse mapping method
> used is linear mapping since the sub-drivers of max8997 such as regulator
> and charger drivers can use the max8997 irq_domain to get the linux irq
> number for max8997 interrupts. All uses of irq_base in platform data and
> max8997 driver private data are removed.
>
> Cc: Grant Likely
> Cc: MyungJoo Ham
> Signed-off-by: Thomas Abraham
> ---
> arch/arm/mach-exynos/mach-nuri.c|4 --
> arch/arm/mach-exynos/mach-origen.c |1 -
> drivers/mfd/max8997-irq.c | 60 --
> drivers/mfd/max8997.c |1 -
> include/linux/mfd/max8997-private.h |4 ++-
> include/linux/mfd/max8997.h |1 -
> 6 files changed, 38 insertions(+), 33 deletions(-)
Nice patch. Nice diffstat too. Some comments below, but I'm happy with where
this is at.
Acked-by: Grant Likely
>
> diff --git a/arch/arm/mach-exynos/mach-nuri.c
> b/arch/arm/mach-exynos/mach-nuri.c
> index a6b9162..1e9ba12 100644
> --- a/arch/arm/mach-exynos/mach-nuri.c
> +++ b/arch/arm/mach-exynos/mach-nuri.c
> @@ -1078,12 +1078,8 @@ static struct platform_device nuri_max8903_device = {
> static void __init nuri_power_init(void)
> {
> int gpio;
> - int irq_base = IRQ_GPIO_END + 1;
> int ta_en = 0;
>
> - nuri_max8997_pdata.irq_base = irq_base;
> - irq_base += MAX8997_IRQ_NR;
> -
> gpio = EXYNOS4_GPX0(7);
> gpio_request(gpio, "AP_PMIC_IRQ");
> s3c_gpio_cfgpin(gpio, S3C_GPIO_SFN(0xf));
> diff --git a/arch/arm/mach-exynos/mach-origen.c
> b/arch/arm/mach-exynos/mach-origen.c
> index 02c242e..328dadb 100644
> --- a/arch/arm/mach-exynos/mach-origen.c
> +++ b/arch/arm/mach-exynos/mach-origen.c
> @@ -424,7 +424,6 @@ static struct max8997_platform_data __initdata
> origen_max8997_pdata = {
> .buck1_gpiodvs = false,
> .buck2_gpiodvs = false,
> .buck5_gpiodvs = false,
> - .irq_base = IRQ_GPIO_END + 1,
>
> .ignore_gpiodvs_side_effect = true,
> .buck125_default_idx = 0x0,
> diff --git a/drivers/mfd/max8997-irq.c b/drivers/mfd/max8997-irq.c
> index 09274cf..3d8c9d1 100644
> --- a/drivers/mfd/max8997-irq.c
> +++ b/drivers/mfd/max8997-irq.c
> @@ -142,7 +142,8 @@ static void max8997_irq_sync_unlock(struct irq_data *data)
> static const inline struct max8997_irq_data *
> irq_to_max8997_irq(struct max8997_dev *max8997, int irq)
> {
> - return &max8997_irqs[irq - max8997->irq_base];
> + struct irq_data *data = irq_get_irq_data(irq);
> + return &max8997_irqs[data->hwirq];
Hahaha. The max8997_irqs table is kind of overdone when the group and mask
values
can be arithmetically derived from the hwirq number..
This change is fine, but the driver could use some refactoring. :-)
> }
>
> static void max8997_irq_mask(struct irq_data *data)
> @@ -182,7 +183,7 @@ static irqreturn_t max8997_irq_thread(int irq, void *data)
> u8 irq_reg[MAX8997_IRQ_GROUP_NR] = {};
> u8 irq_src;
> int ret;
> - int i;
> + int i, cur_irq;
>
> ret = max8997_read_reg(max8997->i2c, MAX8997_REG_INTSRC, &irq_src);
> if (ret < 0) {
> @@ -269,8 +270,10 @@ static irqreturn_t max8997_irq_thread(int irq, void
> *data)
>
> /* Report */
> for (i = 0; i < MAX8997_IRQ_NR; i++) {
> - if (irq_reg[max8997_irqs[i].group] & max8997_irqs[i].mask)
> - handle_nested_irq(max8997->irq_base + i);
> + if (irq_reg[max8997_irqs[i].group] & max8997_irqs[i].mask) {
> + cur_irq = irq_find_mapping(max8997->irq_domain, i);
> + handle_nested_irq(cur_irq);
> + }
Well, if you're using the linear mapping, then only actually allocated irqs will
have a mapping set up. So the driver could simply do:
for (i = 0; i < MAX8997_IRQ_NR; i++) {
cur_irq = irq_find_mapping(max8997->irq_domain, i);
if (cur_irq)
handle_nested_irq(cur_irq);
}
> }
>
> return IRQ_HANDLED;
> @@ -278,26 +281,40 @@ static irqreturn_t max8997_irq_thread(int irq, void
> *data)
>
> int max8997_irq_resume(struct max8997_dev *max8997)
> {
> - if (max8997->irq && max8997->irq_base)
> - max8997_irq_thread(max8997->irq_base, max8997);
> + if (max8997->irq && max8997->irq_domain)
> + max8997_irq_thread(0, max8997);
> + return 0;
> +}
> +
> +static int max8997_irq_domain_map(struct irq_domain *d, unsigned int irq,
> + irq_hw_number_t hw)
> +{
> + struct max8997_dev *max8997 = d->host_data;
> +
> + irq_set_chip_data(irq, max8997);
> + irq_set_chip_and_handler(irq, &max8997_irq_chip, handle_edge_irq);
> + irq_set_nested_thread(irq, 1);
> +#ifdef CONFIG_ARM
> + set_irq_flags(irq, IRQF_VALID);
> +#else
> + irq_set_noprobe(irq);
> +#endif
>
Re: [PATCH v4 0/2] ARM: Exynos: Add irq_domain and device tree support for combiner
On 02/20/2012 10:33 PM, Thomas Abraham wrote: > Changes since v3: > - In dt case, the use of fixed gic linux irq number to map the combiner > interrupt output is removed. This is replaced with the interrupt number > obtained from the gic irq domain. (Thanks to Rob Herring and Grant > Likely for this suggestion). > - Split the patch into two parts - irq_domain and device tree support > addition. > > Changes since v2: > - Rebased to Grant's irqdomain/next branch. > > Changes since v1: > - Includes all changes suggested by Rob Herring. > - Tested with SPARSE_IRQ enabled. > > This patchset adds irq_domain and device tree support for the Exynos Interrupt > Combiner controller. > > The first patch adds a common irq domain for the interrupts managed by the > interrupt combiners. All the instances of irq combiner reference the common > irq > domain for translating hardware interrupts to linux irq number. > > The second patch adds a interrupt specifier translator to support device tree > based instantiation. It can translate interrupt specifiers for device nodes > which use combiner as their interrupt parent. > > This patchset is based on > http://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > [for-next] > > with all irq_domain (v5) patches merged from > http://git.secretlab.ca/git/linux-2.6.git [irqdomain/next] > > Thomas Abraham (2): > ARM: Exynos: Add irq_domain support for interrupt combiner > ARM: Exynos: Add device tree support for interrupt combiner > > .../bindings/arm/samsung/interrupt-combiner.txt| 48 + > arch/arm/mach-exynos/common.c | 112 > > 2 files changed, 140 insertions(+), 20 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt Acked-by: Rob Herring Rob -- 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 0/2] regulator: add irq domain and device tree support for MAX8997
Hi Rob/Grant, On 23 February 2012 18:08, Thomas Abraham wrote: > Changes since v2: > - Atleast one voltage level has to be specfied for Buck 1/2/5 even if GPIO > DVS option is not used (suggested by MyungJoo Ham). > - Reworked the irq_domain support based the v5 of irq_domain generalization > patches. > > MAX8997 is a multi-function device which includes support for regulators, rtc, > battery charger and other sub-blocks. This patchset adds device tree support > for the pmic (regulators) sub-block. > > The first patch adds irq domain support for the interrupts supported by > max8997 > mainly for removing the need to pass a irq_base from the platform code. The > irq_base could not anyway be passed in case of device tree based > instantiation. > The reverse mapping method used is linear since the sub-drivers of max8997 has > access to the max8997 irq_domain from which the linux irq number can be > obtained. > > The second patch adds device tree support for max8997. This patch modifies > both > mfd and regulator portions of the max8997 code. > > This patchset is based on the following tree. > http://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > [for-next] > > with all patches merged from > http://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git > [for-next] > http://git.secretlab.ca/git/linux-2.6.git [irqdomain/next] > > and depends on the following patchset. > [PATCH v3 0/4] ARM: Exynos4: Add irq domain and device tree support for > wakeup interrupts. > > This patchset has been tested on Origen board. > > Thomas Abraham (2): > mfd: add irq domain support for max8997 interrupts > regulator: add device tree support for max8997 Any comments for this patch series? Thanks, Thomas. > > .../devicetree/bindings/regulator/max8997-pmic.txt | 134 +++ > arch/arm/mach-exynos/mach-nuri.c | 4 - > arch/arm/mach-exynos/mach-origen.c | 1 - > drivers/mfd/max8997-irq.c | 60 + > drivers/mfd/max8997.c | 73 ++- > drivers/regulator/max8997.c | 139 > +++- > include/linux/mfd/max8997-private.h | 4 +- > include/linux/mfd/max8997.h | 2 +- > 8 files changed, 382 insertions(+), 35 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/regulator/max8997-pmic.txt > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/2] ARM: Exynos: Add irq_domain and device tree support for combiner
Hi Rob/Grant, On 21 February 2012 10:03, Thomas Abraham wrote: > Changes since v3: > - In dt case, the use of fixed gic linux irq number to map the combiner > interrupt output is removed. This is replaced with the interrupt number > obtained from the gic irq domain. (Thanks to Rob Herring and Grant > Likely for this suggestion). > - Split the patch into two parts - irq_domain and device tree support > addition. > > Changes since v2: > - Rebased to Grant's irqdomain/next branch. > > Changes since v1: > - Includes all changes suggested by Rob Herring. > - Tested with SPARSE_IRQ enabled. > > This patchset adds irq_domain and device tree support for the Exynos Interrupt > Combiner controller. > > The first patch adds a common irq domain for the interrupts managed by the > interrupt combiners. All the instances of irq combiner reference the common > irq > domain for translating hardware interrupts to linux irq number. > > The second patch adds a interrupt specifier translator to support device tree > based instantiation. It can translate interrupt specifiers for device nodes > which use combiner as their interrupt parent. > > This patchset is based on > http://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > [for-next] > > with all irq_domain (v5) patches merged from > http://git.secretlab.ca/git/linux-2.6.git [irqdomain/next] > > Thomas Abraham (2): > ARM: Exynos: Add irq_domain support for interrupt combiner > ARM: Exynos: Add device tree support for interrupt combiner Any comments on this patch series? If it helps, I can repost this patch series. This patch series is a pre-requsite for the irq-domain and dt support for wakeup interrupts, which Rob has acked. Thanks, Thomas. > > .../bindings/arm/samsung/interrupt-combiner.txt | 48 + > arch/arm/mach-exynos/common.c | 112 > > 2 files changed, 140 insertions(+), 20 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt > > > -- > 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 v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
For all the Samsung SoC based boards which have the platform data for
s3c-fb driver, the 'default_win' element in the platform data is removed
and the lcd panel video timing values are moved out of individual window
configuration data.
Cc: Jingoo Han
Cc: Kyungmin Park
Cc: JeongHyeon Kim
Cc: Kukjin Kim
Cc: Heiko Stuebner
Cc: Ben Dooks
Cc: Kwangwoo Lee
Cc: Mark Brown
Cc: Peter Korsgaard
Cc: Darius Augulis
Cc: Maurus Cuelenaere
Signed-off-by: Thomas Abraham
---
arch/arm/mach-exynos/mach-nuri.c | 26 ++---
arch/arm/mach-exynos/mach-origen.c | 24 ++---
arch/arm/mach-exynos/mach-smdkv310.c | 28 +++
arch/arm/mach-exynos/mach-universal_c210.c | 26 ++---
arch/arm/mach-s3c24xx/mach-smdk2416.c | 27 ++
arch/arm/mach-s3c64xx/mach-anw6410.c | 25 ++---
arch/arm/mach-s3c64xx/mach-crag6410.c | 25 ++---
arch/arm/mach-s3c64xx/mach-hmt.c | 24 ++---
arch/arm/mach-s3c64xx/mach-mini6410.c | 40 ---
arch/arm/mach-s3c64xx/mach-real6410.c | 40 ---
arch/arm/mach-s3c64xx/mach-smartq5.c | 26 ++---
arch/arm/mach-s3c64xx/mach-smartq7.c | 26 ++---
arch/arm/mach-s3c64xx/mach-smdk6410.c | 25 ++---
arch/arm/mach-s5p64x0/mach-smdk6440.c | 24 ++---
arch/arm/mach-s5p64x0/mach-smdk6450.c | 24 ++---
arch/arm/mach-s5pc100/mach-smdkc100.c | 27 ++
arch/arm/mach-s5pv210/mach-aquila.c| 36 +++--
arch/arm/mach-s5pv210/mach-goni.c | 26 ++---
arch/arm/mach-s5pv210/mach-smdkv210.c | 24 ++---
19 files changed, 285 insertions(+), 238 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c
index 7ac81ce..a7e6731 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -212,25 +212,29 @@ static struct platform_device nuri_gpio_keys = {
/* Frame Buffer */
static struct s3c_fb_pd_win nuri_fb_win0 = {
- .win_mode = {
- .left_margin= 64,
- .right_margin = 16,
- .upper_margin = 64,
- .lower_margin = 1,
- .hsync_len = 48,
- .vsync_len = 3,
- .xres = 1024,
- .yres = 600,
- .refresh= 60,
- },
.max_bpp= 24,
.default_bpp= 16,
+ .xres = 1024,
+ .yres = 600,
.virtual_x = 1024,
.virtual_y = 2 * 600,
};
+static struct fb_videomode nuri_lcd_timing = {
+ .left_margin= 64,
+ .right_margin = 16,
+ .upper_margin = 64,
+ .lower_margin = 1,
+ .hsync_len = 48,
+ .vsync_len = 3,
+ .xres = 1024,
+ .yres = 600,
+ .refresh= 60,
+};
+
static struct s3c_fb_platdata nuri_fb_pdata __initdata = {
.win[0] = &nuri_fb_win0,
+ .vtiming= &nuri_lcd_timing,
.vidcon0= VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB |
VIDCON0_CLKSEL_LCD,
.vidcon1= VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
diff --git a/arch/arm/mach-exynos/mach-origen.c
b/arch/arm/mach-exynos/mach-origen.c
index 25c9b46..de71237 100644
--- a/arch/arm/mach-exynos/mach-origen.c
+++ b/arch/arm/mach-exynos/mach-origen.c
@@ -583,22 +583,26 @@ static struct platform_device origen_lcd_hv070wsa = {
};
static struct s3c_fb_pd_win origen_fb_win0 = {
- .win_mode = {
- .left_margin= 64,
- .right_margin = 16,
- .upper_margin = 64,
- .lower_margin = 16,
- .hsync_len = 48,
- .vsync_len = 3,
- .xres = 1024,
- .yres = 600,
- },
+ .xres = 1024,
+ .yres = 600,
.max_bpp= 32,
.default_bpp= 24,
};
+static struct fb_videomode origen_lcd_timing = {
+ .left_margin= 64,
+ .right_margin = 16,
+ .upper_margin = 64,
+ .lower_margin = 16,
+ .hsync_len = 48,
+ .vsync_len = 3,
+ .xres = 1024,
+ .yres = 600,
+};
+
static struct s3c_fb_platdata origen_lcd_pdata __initdata = {
.win[0] = &origen_fb_win0,
+ .vtiming= &origen_lcd_timing,
.vidcon0= VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
.vidcon1= VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC |
VIDCON1_INV_VCLK,
diff --git a/arch/arm/mach-exynos/mach-smdkv310.c
b/arch/arm/mach-exynos/mach-smdkv310.c
index f08529f..6c00fa6
[PATCH v2 2/3] video: s3c-fb: remove 'default_win' element from platform data
The decision to enable or disable the data output to the lcd panel from
the controller need not be based on the value of 'default_win' element
in the platform data. Instead, the data output to the panel is enabled
if any of the windows are active, else data output is disabled.
Cc: Ben Dooks
Cc: Jingoo Han
Signed-off-by: Thomas Abraham
---
arch/arm/plat-samsung/include/plat/fb.h |2 --
drivers/video/s3c-fb.c | 28 ++--
2 files changed, 6 insertions(+), 24 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/fb.h
b/arch/arm/plat-samsung/include/plat/fb.h
index 39d6bd7..536002f 100644
--- a/arch/arm/plat-samsung/include/plat/fb.h
+++ b/arch/arm/plat-samsung/include/plat/fb.h
@@ -62,8 +62,6 @@ struct s3c_fb_platdata {
struct s3c_fb_pd_win*win[S3C_FB_MAX_WIN];
struct fb_videomode *vtiming;
- u32 default_win;
-
u32 vidcon0;
u32 vidcon1;
};
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 60d1c12..cfe5113 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -531,8 +531,8 @@ static int s3c_fb_set_par(struct fb_info *info)
/* disable the window whilst we update it */
writel(0, regs + WINCON(win_no));
- if (win_no == sfb->pdata->default_win)
- s3c_fb_enable(sfb, 1);
+ if (!sfb->output_on)
+ s3c_fb_enable(sfb, 1);
/* write the buffer address */
@@ -798,7 +798,7 @@ static int s3c_fb_blank(int blank_mode, struct fb_info
*info)
struct s3c_fb_win *win = info->par;
struct s3c_fb *sfb = win->parent;
unsigned int index = win->index;
- u32 wincon;
+ u32 wincon, output_on = sfb->output_on;
dev_dbg(sfb->dev, "blank mode %d\n", blank_mode);
@@ -837,34 +837,18 @@ static int s3c_fb_blank(int blank_mode, struct fb_info
*info)
shadow_protect_win(win, 1);
writel(wincon, sfb->regs + sfb->variant.wincon + (index * 4));
- shadow_protect_win(win, 0);
/* Check the enabled state to see if we need to be running the
* main LCD interface, as if there are no active windows then
* it is highly likely that we also do not need to output
* anything.
*/
-
- /* We could do something like the following code, but the current
-* system of using framebuffer events means that we cannot make
-* the distinction between just window 0 being inactive and all
-* the windows being down.
-*
-* s3c_fb_enable(sfb, sfb->enabled ? 1 : 0);
- */
-
- /* we're stuck with this until we can do something about overriding
-* the power control using the blanking event for a single fb.
-*/
- if (index == sfb->pdata->default_win) {
- shadow_protect_win(win, 1);
- s3c_fb_enable(sfb, blank_mode != FB_BLANK_POWERDOWN ? 1 : 0);
- shadow_protect_win(win, 0);
- }
+ s3c_fb_enable(sfb, sfb->enabled ? 1 : 0);
+ shadow_protect_win(win, 0);
pm_runtime_put_sync(sfb->dev);
- return 0;
+ return output_on == sfb->output_on;
}
/**
--
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
[PATCH v2 1/3] video: s3c-fb: move video interface timing out of window setup data
The video interface timing is independent of the window setup data.
The resolution of the window can be smaller than that of the lcd
panel to which the video data is output.
So move the video timing data from the per-window setup data to the
platform specific section in the platform data. This also removes
the restriction that atleast one window should have the same
resolution as that of the panel attached.
Cc: Ben Dooks
Signed-off-by: Thomas Abraham
Acked-by: Jingoo Han
---
arch/arm/plat-samsung/include/plat/fb.h |9 ++-
drivers/video/s3c-fb.c | 114 +--
2 files changed, 68 insertions(+), 55 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/fb.h
b/arch/arm/plat-samsung/include/plat/fb.h
index 0fedf47..39d6bd7 100644
--- a/arch/arm/plat-samsung/include/plat/fb.h
+++ b/arch/arm/plat-samsung/include/plat/fb.h
@@ -24,15 +24,16 @@
/**
* struct s3c_fb_pd_win - per window setup data
- * @win_mode: The display parameters to initialise (not for window 0)
+ * @xres : The window X size.
+ * @yres : The window Y size.
* @virtual_x: The virtual X size.
* @virtual_y: The virtual Y size.
*/
struct s3c_fb_pd_win {
- struct fb_videomode win_mode;
-
unsigned short default_bpp;
unsigned short max_bpp;
+ unsigned short xres;
+ unsigned short yres;
unsigned short virtual_x;
unsigned short virtual_y;
};
@@ -45,6 +46,7 @@ struct s3c_fb_pd_win {
* @default_win: default window layer number to be used for UI layer.
* @vidcon0: The base vidcon0 values to control the panel data format.
* @vidcon1: The base vidcon1 values to control the panel data output.
+ * @vtiming: Video timing when connected to a RGB type panel.
* @win: The setup data for each hardware window, or NULL for unused.
* @display_mode: The LCD output display mode.
*
@@ -58,6 +60,7 @@ struct s3c_fb_platdata {
void(*setup_gpio)(void);
struct s3c_fb_pd_win*win[S3C_FB_MAX_WIN];
+ struct fb_videomode *vtiming;
u32 default_win;
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index f310516..60d1c12 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -495,7 +495,6 @@ static int s3c_fb_set_par(struct fb_info *info)
u32 alpha = 0;
u32 data;
u32 pagewidth;
- int clkdiv;
dev_dbg(sfb->dev, "setting framebuffer parameters\n");
@@ -532,47 +531,8 @@ static int s3c_fb_set_par(struct fb_info *info)
/* disable the window whilst we update it */
writel(0, regs + WINCON(win_no));
- /* use platform specified window as the basis for the lcd timings */
-
- if (win_no == sfb->pdata->default_win) {
- clkdiv = s3c_fb_calc_pixclk(sfb, var->pixclock);
-
- data = sfb->pdata->vidcon0;
- data &= ~(VIDCON0_CLKVAL_F_MASK | VIDCON0_CLKDIR);
-
- if (clkdiv > 1)
- data |= VIDCON0_CLKVAL_F(clkdiv-1) | VIDCON0_CLKDIR;
- else
- data &= ~VIDCON0_CLKDIR;/* 1:1 clock */
-
- /* write the timing data to the panel */
-
- if (sfb->variant.is_2443)
- data |= (1 << 5);
-
- writel(data, regs + VIDCON0);
-
- s3c_fb_enable(sfb, 1);
-
- data = VIDTCON0_VBPD(var->upper_margin - 1) |
- VIDTCON0_VFPD(var->lower_margin - 1) |
- VIDTCON0_VSPW(var->vsync_len - 1);
-
- writel(data, regs + sfb->variant.vidtcon);
-
- data = VIDTCON1_HBPD(var->left_margin - 1) |
- VIDTCON1_HFPD(var->right_margin - 1) |
- VIDTCON1_HSPW(var->hsync_len - 1);
-
- /* VIDTCON1 */
- writel(data, regs + sfb->variant.vidtcon + 4);
-
- data = VIDTCON2_LINEVAL(var->yres - 1) |
- VIDTCON2_HOZVAL(var->xres - 1) |
- VIDTCON2_LINEVAL_E(var->yres - 1) |
- VIDTCON2_HOZVAL_E(var->xres - 1);
- writel(data, regs + sfb->variant.vidtcon + 8);
- }
+ if (win_no == sfb->pdata->default_win)
+ s3c_fb_enable(sfb, 1);
/* write the buffer address */
@@ -1144,11 +1104,11 @@ static int __devinit s3c_fb_alloc_memory(struct s3c_fb
*sfb,
dev_dbg(sfb->dev, "allocating memory for display\n");
- real_size = windata->win_mode.xres * windata->win_mode.yres;
+ real_size = windata->xres * windata->yres;
virt_size = windata->virtual_x * windata->virtual_y;
dev_dbg(sfb->dev, "real_size=%u (%u.%u), virt_size=%u (%u.%u)\n",
- real_size, windata->win_mode.xres, windata->win_mode.yres,
+ real_size, windata->xres, windata->yres,
virt_size, windata->virtual_x, wind
[PATCH v2 0/3] video: s3c-fb: Rearrange the elements in platform data
Changes since v1: - Includes all changes suggested by Jingoo Han. - Reworked s3c-fb platform data in all Samsung SoC based board files. This patchset rearranges the elements in the platform data of the s3c-fb driver with the intent of adding device tree support to the driver in subsequent patches. The first patch moves the video timing information from the individual window setup data into the platform specific configuration section in the platform data. The video timing is independent of the window setup. The resolution of the window could be smaller than that of the lcd panel attached. So the video timing data is removed from window configuration data. The second patch removes the need for the 'default_win' element in the platform data. This element was used to decide whether the video data output from the controller should be enabled or disabled when the window specified by 'default_win' is enabled or disabled. With the first patch removing the need for atleast one window to be of the same resolution as that of the lcd panel, it is now possible to decide when to enable/disable the video data output based on the state of each window. If any of the window is active, the lcd data output is enabled. Otherwise, the lcd data output is disabled. Hence, the 'default_win' parameter from the platform data can be removed, which anyways cannot be specified when using device tree. For all the Samsung SoC based boards, the third patch reworks the platform data of the display controller based on the changes introduced in the first two patches. This patch series is based on http://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git [for-next] with all patches merged from https://github.com/schandinat/linux-2.6.git [fbdev-next] and tested one Exynos4210 based Origen board (only compile tested for other boards) Thomas Abraham (3): video: s3c-fb: move video interface timing out of window setup data video: s3c-fb: remove 'default_win' element from platform data ARM: Samsung: Rework platform data of s3c-fb driver arch/arm/mach-exynos/mach-nuri.c | 26 +++--- arch/arm/mach-exynos/mach-origen.c | 24 +++-- arch/arm/mach-exynos/mach-smdkv310.c | 28 --- arch/arm/mach-exynos/mach-universal_c210.c | 26 +++--- arch/arm/mach-s3c24xx/mach-smdk2416.c | 27 +++--- arch/arm/mach-s3c64xx/mach-anw6410.c | 25 +++--- arch/arm/mach-s3c64xx/mach-crag6410.c | 25 +++--- arch/arm/mach-s3c64xx/mach-hmt.c | 24 +++-- arch/arm/mach-s3c64xx/mach-mini6410.c | 40 - arch/arm/mach-s3c64xx/mach-real6410.c | 40 - arch/arm/mach-s3c64xx/mach-smartq5.c | 26 +++--- arch/arm/mach-s3c64xx/mach-smartq7.c | 26 +++--- arch/arm/mach-s3c64xx/mach-smdk6410.c | 25 +++--- arch/arm/mach-s5p64x0/mach-smdk6440.c | 24 +++-- arch/arm/mach-s5p64x0/mach-smdk6450.c | 24 +++-- arch/arm/mach-s5pc100/mach-smdkc100.c | 27 +++--- arch/arm/mach-s5pv210/mach-aquila.c| 36 arch/arm/mach-s5pv210/mach-goni.c | 26 +++--- arch/arm/mach-s5pv210/mach-smdkv210.c | 24 +++-- arch/arm/plat-samsung/include/plat/fb.h| 11 ++- drivers/video/s3c-fb.c | 136 +--- 21 files changed, 356 insertions(+), 314 deletions(-) -- 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 6/6] spi/s3c64xx: Allow usage for ARCH_S3C24XX
Newer SoCs from the S3C24XX line, namely S3C2416/2443/2450 contain hsspi-controllers compatible with the s3c64xx type. The previous patches enabled platform support for it, so make the driver also usable for the S3C24xx architecture. Signed-off-by: Heiko Stuebner Acked-by: Grant Likely --- drivers/spi/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 004e6d1..e981fe6 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -305,7 +305,7 @@ config SPI_S3C24XX_FIQ config SPI_S3C64XX tristate "Samsung S3C64XX series type SPI" - depends on (ARCH_S3C64XX || ARCH_S5P64X0 || ARCH_EXYNOS) + depends on (ARCH_S3C24XX || ARCH_S3C64XX || ARCH_S5P64X0 || ARCH_EXYNOS) select S3C64XX_DMA if ARCH_S3C64XX help SPI driver for Samsung S3C64XX and newer SoCs. -- 1.7.2.3 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/6] ARM: S3C24XX: Add HSSPI setup callback for s3c64xx-spi driver
This lets the s3c64xx-spi driver know the specifics of the controller-
variant and also setups the gpios and the misccr bit.
This setup is valid for all S3C24XX SoCs containing a HSSPI controller
(i.e. S3C2416/2450 and S3C2443)
Signed-off-by: Heiko Stuebner
---
changes since v1: adapt to changes in Makefile
arch/arm/mach-s3c24xx/Kconfig |5
arch/arm/mach-s3c24xx/Makefile|1 +
arch/arm/mach-s3c24xx/setup-spi.c | 39 +
3 files changed, 45 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-s3c24xx/setup-spi.c
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 0f3a327..38e6b30 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -518,6 +518,11 @@ config S3C2443_DMA
help
Internal config node for S3C2443 DMA support
+config S3C2443_SETUP_SPI
+ bool
+ help
+ Common setup code for SPI GPIO configurations
+
endif # CPU_S3C2443 || CPU_S3C2416
if CPU_S3C2443
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index 3518fe8..d0f3a92 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -91,5 +91,6 @@ obj-$(CONFIG_MACH_OSIRIS_DVS) += mach-osiris-dvs.o
# device setup
obj-$(CONFIG_S3C2416_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
+obj-$(CONFIG_S3C2443_SETUP_SPI)+= setup-spi.o
obj-$(CONFIG_ARCH_S3C24XX) += setup-i2c.o
obj-$(CONFIG_S3C24XX_SETUP_TS) += setup-ts.o
diff --git a/arch/arm/mach-s3c24xx/setup-spi.c
b/arch/arm/mach-s3c24xx/setup-spi.c
new file mode 100644
index 000..5712c85
--- /dev/null
+++ b/arch/arm/mach-s3c24xx/setup-spi.c
@@ -0,0 +1,39 @@
+/*
+ * HS-SPI device setup for S3C2443/S3C2416
+ *
+ * Copyright (C) 2011 Samsung Electronics 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
+
+#ifdef CONFIG_S3C64XX_DEV_SPI0
+struct s3c64xx_spi_info s3c64xx_spi0_pdata __initdata = {
+ .fifo_lvl_mask = 0x7f,
+ .rx_lvl_offset = 13,
+ .tx_st_done = 21,
+ .high_speed = 1,
+};
+
+int s3c64xx_spi0_cfg_gpio(struct platform_device *pdev)
+{
+ /* enable hsspi bit in misccr */
+ s3c2410_modify_misccr(S3C2416_MISCCR_HSSPI_EN2, 1);
+
+ s3c_gpio_cfgall_range(S3C2410_GPE(11), 3,
+ S3C_GPIO_SFN(2), S3C_GPIO_PULL_UP);
+
+ return 0;
+}
+#endif
--
1.7.2.3
--
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/6] ARM: S3C24XX: Add clock-lookup entries required by s3c64xx-spi
Currently usable are busclk0 and busclk2.
Signed-off-by: Heiko Stuebner
---
arch/arm/mach-s3c24xx/clock-s3c2416.c |1 +
arch/arm/mach-s3c24xx/clock-s3c2443.c |1 +
arch/arm/mach-s3c24xx/common-s3c2443.c | 15 ++-
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/clock-s3c2416.c
b/arch/arm/mach-s3c24xx/clock-s3c2416.c
index dbc9ab4..8702ecf 100644
--- a/arch/arm/mach-s3c24xx/clock-s3c2416.c
+++ b/arch/arm/mach-s3c24xx/clock-s3c2416.c
@@ -144,6 +144,7 @@ static struct clk_lookup s3c2416_clk_lookup[] = {
CLKDEV_INIT("s3c-sdhci.0", "mmc_busclk.0", &hsmmc0_clk),
CLKDEV_INIT("s3c-sdhci.0", "mmc_busclk.2", &hsmmc_mux0.clk),
CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.2", &hsmmc_mux1.clk),
+ CLKDEV_INIT("s3c64xx-spi.0", "spi_busclk2", &hsspi_mux.clk),
};
void __init s3c2416_init_clocks(int xtal)
diff --git a/arch/arm/mach-s3c24xx/clock-s3c2443.c
b/arch/arm/mach-s3c24xx/clock-s3c2443.c
index bce1cd3..bb3231d 100644
--- a/arch/arm/mach-s3c24xx/clock-s3c2443.c
+++ b/arch/arm/mach-s3c24xx/clock-s3c2443.c
@@ -181,6 +181,7 @@ static struct clk *clks[] __initdata = {
static struct clk_lookup s3c2443_clk_lookup[] = {
CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.2", &clk_hsmmc),
+ CLKDEV_INIT("s3c64xx-spi.0", "spi_busclk2", &clk_hsspi.clk),
};
void __init s3c2443_init_clocks(int xtal)
diff --git a/arch/arm/mach-s3c24xx/common-s3c2443.c
b/arch/arm/mach-s3c24xx/common-s3c2443.c
index 4604315..aeeb2be 100644
--- a/arch/arm/mach-s3c24xx/common-s3c2443.c
+++ b/arch/arm/mach-s3c24xx/common-s3c2443.c
@@ -424,11 +424,6 @@ static struct clk init_clocks_off[] = {
.enable = s3c2443_clkcon_enable_p,
.ctrlbit= S3C2443_PCLKCON_IIS,
}, {
- .name = "hsspi",
- .parent = &clk_p,
- .enable = s3c2443_clkcon_enable_p,
- .ctrlbit= S3C2443_PCLKCON_HSSPI,
- }, {
.name = "adc",
.parent = &clk_p,
.enable = s3c2443_clkcon_enable_p,
@@ -562,6 +557,14 @@ static struct clk hsmmc1_clk = {
.ctrlbit= S3C2443_HCLKCON_HSMMC,
};
+static struct clk hsspi_clk = {
+ .name = "spi",
+ .devname= "s3c64xx-spi.0",
+ .parent = &clk_p,
+ .enable = s3c2443_clkcon_enable_p,
+ .ctrlbit= S3C2443_PCLKCON_HSSPI,
+};
+
/* EPLLCON compatible enough to get on/off information */
void __init_or_cpufreq s3c2443_common_setup_clocks(pll_fn get_mpll)
@@ -612,6 +615,7 @@ static struct clk *clks[] __initdata = {
&clk_usb_bus,
&clk_armdiv,
&hsmmc1_clk,
+ &hsspi_clk,
};
static struct clksrc_clk *clksrcs[] __initdata = {
@@ -629,6 +633,7 @@ static struct clk_lookup s3c2443_clk_lookup[] = {
CLKDEV_INIT(NULL, "clk_uart_baud2", &clk_p),
CLKDEV_INIT(NULL, "clk_uart_baud3", &clk_esys_uart.clk),
CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.0", &hsmmc1_clk),
+ CLKDEV_INIT("s3c64xx-spi.0", "spi_busclk0", &hsspi_clk),
};
void __init s3c2443_common_init_clocks(int xtal, pll_fn get_mpll,
--
1.7.2.3
--
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/6] ARM: S3C24XX: Add map entries needed by the s3c64xx-spi devices
The S3C_PA_SPIx constants are only used by the s3c64xx-spi driver and don't conflict with the older SoCs as they don't support hsspi. Signed-off-by: Heiko Stuebner --- arch/arm/mach-s3c24xx/include/mach/map.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-s3c24xx/include/mach/map.h b/arch/arm/mach-s3c24xx/include/mach/map.h index 78ae807..8ba381f 100644 --- a/arch/arm/mach-s3c24xx/include/mach/map.h +++ b/arch/arm/mach-s3c24xx/include/mach/map.h @@ -98,6 +98,8 @@ /* SPI */ #define S3C2410_PA_SPI(0x5900) +#define S3C2443_PA_SPI0(0x5200) +#define S3C2443_PA_SPI1S3C2410_PA_SPI /* SDI */ #define S3C2410_PA_SDI(0x5A00) @@ -162,4 +164,7 @@ #define S3C_PA_WDT S3C2410_PA_WATCHDOG #define S3C_PA_NANDS3C24XX_PA_NAND +#define S3C_PA_SPI0S3C2443_PA_SPI0 +#define S3C_PA_SPI1S3C2443_PA_SPI1 + #endif /* __ASM_ARCH_MAP_H */ -- 1.7.2.3 -- 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/6] ARM: S3C24XX: claim spi channels for hsspi in dma-s3c2443
SoCs starting with the S3C2443 contain SPI controllers compatible with the
spi-s3c64xx driver and therefore need separate dma channels for rx and tx.
This patch introduces dma channel declarations for these and changes the
dma-s3c2443.c accordingly.
None of the older SoCs use the spi-dma at all. Most boards bitbang their
spi use and the spi-s3c24xx driver also does not use the dma system.
Signed-off-by: Heiko Stuebner
---
arch/arm/mach-s3c24xx/dma-s3c2443.c | 16
arch/arm/mach-s3c24xx/include/mach/dma.h |4
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/dma-s3c2443.c
b/arch/arm/mach-s3c24xx/dma-s3c2443.c
index e227c47..2d94228 100644
--- a/arch/arm/mach-s3c24xx/dma-s3c2443.c
+++ b/arch/arm/mach-s3c24xx/dma-s3c2443.c
@@ -55,12 +55,20 @@ static struct s3c24xx_dma_map __initdata
s3c2443_dma_mappings[] = {
.name = "sdi",
.channels = MAP(S3C2443_DMAREQSEL_SDI),
},
- [DMACH_SPI0] = {
- .name = "spi0",
+ [DMACH_SPI0_RX] = {
+ .name = "spi0-rx",
+ .channels = MAP(S3C2443_DMAREQSEL_SPI0RX),
+ },
+ [DMACH_SPI0_TX] = {
+ .name = "spi0-tx",
.channels = MAP(S3C2443_DMAREQSEL_SPI0TX),
},
- [DMACH_SPI1] = { /* only on S3C2443/S3C2450 */
- .name = "spi1",
+ [DMACH_SPI1_RX] = { /* only on S3C2443/S3C2450 */
+ .name = "spi1-rx",
+ .channels = MAP(S3C2443_DMAREQSEL_SPI1RX),
+ },
+ [DMACH_SPI1_TX] = { /* only on S3C2443/S3C2450 */
+ .name = "spi1-tx",
.channels = MAP(S3C2443_DMAREQSEL_SPI1TX),
},
[DMACH_UART0] = {
diff --git a/arch/arm/mach-s3c24xx/include/mach/dma.h
b/arch/arm/mach-s3c24xx/include/mach/dma.h
index acbdfec..454831b 100644
--- a/arch/arm/mach-s3c24xx/include/mach/dma.h
+++ b/arch/arm/mach-s3c24xx/include/mach/dma.h
@@ -47,6 +47,10 @@ enum dma_ch {
DMACH_UART2_SRC2,
DMACH_UART3,/* s3c2443 has extra uart */
DMACH_UART3_SRC2,
+ DMACH_SPI0_TX, /* s3c2443/2416/2450 hsspi0 */
+ DMACH_SPI0_RX, /* s3c2443/2416/2450 hsspi0 */
+ DMACH_SPI1_TX, /* s3c2443/2450 hsspi1 */
+ DMACH_SPI1_RX, /* s3c2443/2450 hsspi1 */
DMACH_MAX, /* the end entry */
};
--
1.7.2.3
--
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/6] ARM: S3C24XX: Add forgotten clock lookup table to S3C2443
When the hsmmc clock lookup was changed to be lookup tables based,
it seems the S3C2443 was forgotten.
As subsequent patches will want to add more lookups to it, this
patch adds the base table with the missing hsmmc lookup.
Signed-off-by: Heiko Stuebner
---
arch/arm/mach-s3c24xx/clock-s3c2443.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/clock-s3c2443.c
b/arch/arm/mach-s3c24xx/clock-s3c2443.c
index efb3ac3..bce1cd3 100644
--- a/arch/arm/mach-s3c24xx/clock-s3c2443.c
+++ b/arch/arm/mach-s3c24xx/clock-s3c2443.c
@@ -179,6 +179,10 @@ static struct clk *clks[] __initdata = {
&clk_hsmmc,
};
+static struct clk_lookup s3c2443_clk_lookup[] = {
+ CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.2", &clk_hsmmc),
+};
+
void __init s3c2443_init_clocks(int xtal)
{
unsigned long epllcon = __raw_readl(S3C2443_EPLLCON);
@@ -210,6 +214,7 @@ void __init s3c2443_init_clocks(int xtal)
s3c_register_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
s3c_disable_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
+ clkdev_add_table(s3c2443_clk_lookup, ARRAY_SIZE(s3c2443_clk_lookup));
s3c_pwmclk_init();
}
--
1.7.2.3
--
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 0/6] S3C24XX: Add support for HSSPI on S3C2416/S3C2443
The S3C2416/S3C2443/S3C2450 SoCs contain HSSPI controllers compatible with the ones in the S3C64xx and later. The second patch modifying the dma selection depends on the series enabling the dma support on the S3C2416, but as the whole s3c64xx-spi driver needs dma support this should be ok. Tested on an Asus DR-900 ebook reader with a Marvell MR8686 using the libertas driver. This is a repost of the series adapted to changes resulting from the other cleanup series. Heiko Stuebner (6): ARM: S3C24XX: Add forgotten clock lookup table to S3C2443 ARM: S3C24XX: claim spi channels for hsspi in dma-s3c2443 ARM: S3C24XX: Add map entries needed by the s3c64xx-spi devices ARM: S3C24XX: Add clock-lookup entries required by s3c64xx-spi ARM: S3C24XX: Add HSSPI setup callback for s3c64xx-spi driver spi/s3c64xx: Allow usage for ARCH_S3C24XX arch/arm/mach-s3c24xx/Kconfig|5 arch/arm/mach-s3c24xx/Makefile |1 + arch/arm/mach-s3c24xx/clock-s3c2416.c|1 + arch/arm/mach-s3c24xx/clock-s3c2443.c|6 arch/arm/mach-s3c24xx/common-s3c2443.c | 15 +++ arch/arm/mach-s3c24xx/dma-s3c2443.c | 16 +--- arch/arm/mach-s3c24xx/include/mach/dma.h |4 +++ arch/arm/mach-s3c24xx/include/mach/map.h |5 arch/arm/mach-s3c24xx/setup-spi.c| 39 ++ drivers/spi/Kconfig |2 +- 10 files changed, 84 insertions(+), 10 deletions(-) create mode 100644 arch/arm/mach-s3c24xx/setup-spi.c -- 1.7.2.3 -- 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 3/3] gpio/samsung: use ioremap() for EXYNOS4 GPIOlib
Grant Likely wrote: > On Thu, 16 Feb 2012 06:37:09 +0900, Kukjin Kim wrote: >> From: Sangsu Park >> >> This patch changes to use ioremap() for EXYNOS4210 >> so that we can drop the static mapping for EXYNOS >> SoCs. >> >> Note: Will be updated for all of Samsung GPIOlibs >> to use ioremap() next time. >> >> Signed-off-by: Sangsu Park >> Cc: Grant Likely >> Signed-off-by: Kukjin Kim > > Acked-by: Grant Likely > > Kukjin, I think you wanted to take this via your tree? I'm fine with that. > Let me know if you'd rather it go via the gpio tree. > Hi Grant, I think, since this series has no depenency with current samsung tree for upcoming merge window, this can be sent to upstream via the gpio tree. If any problems, please kindly let me know. 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 v2 3/3] gpio/samsung: use ioremap() for EXYNOS4 GPIOlib
On Thu, 16 Feb 2012 06:37:09 +0900, Kukjin Kim wrote:
> From: Sangsu Park
>
> This patch changes to use ioremap() for EXYNOS4210
> so that we can drop the static mapping for EXYNOS
> SoCs.
>
> Note: Will be updated for all of Samsung GPIOlibs
> to use ioremap() next time.
>
> Signed-off-by: Sangsu Park
> Cc: Grant Likely
> Signed-off-by: Kukjin Kim
Acked-by: Grant Likely
Kukjin, I think you wanted to take this via your tree? I'm fine with that.
Let me know if you'd rather it go via the gpio tree.
g.
> ---
> arch/arm/mach-exynos/common.c | 15
> drivers/gpio/gpio-samsung.c | 48
> +
> 2 files changed, 34 insertions(+), 29 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
> index 63a2b04..618e7f3 100644
> --- a/arch/arm/mach-exynos/common.c
> +++ b/arch/arm/mach-exynos/common.c
> @@ -172,21 +172,6 @@ static struct map_desc exynos4_iodesc[] __initdata = {
> .length = SZ_4K,
> .type = MT_DEVICE,
> }, {
> - .virtual= (unsigned long)S5P_VA_GPIO1,
> - .pfn= __phys_to_pfn(EXYNOS4_PA_GPIO1),
> - .length = SZ_4K,
> - .type = MT_DEVICE,
> - }, {
> - .virtual= (unsigned long)S5P_VA_GPIO2,
> - .pfn= __phys_to_pfn(EXYNOS4_PA_GPIO2),
> - .length = SZ_4K,
> - .type = MT_DEVICE,
> - }, {
> - .virtual= (unsigned long)S5P_VA_GPIO3,
> - .pfn= __phys_to_pfn(EXYNOS4_PA_GPIO3),
> - .length = SZ_256,
> - .type = MT_DEVICE,
> - }, {
> .virtual= (unsigned long)S5P_VA_DMC0,
> .pfn= __phys_to_pfn(EXYNOS4_PA_DMC0),
> .length = SZ_4K,
> diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
> index d6cfdee7..4627787 100644
> --- a/drivers/gpio/gpio-samsung.c
> +++ b/drivers/gpio/gpio-samsung.c
> @@ -2331,7 +2331,6 @@ static struct samsung_gpio_chip exynos4_gpios_2[] = {
> .label = "GPY6",
> },
> }, {
> - .base = (S5P_VA_GPIO2 + 0xC00),
> .config = &samsung_gpio_cfgs[9],
> .irq_base = IRQ_EINT(0),
> .chip = {
> @@ -2341,7 +2340,6 @@ static struct samsung_gpio_chip exynos4_gpios_2[] = {
> .to_irq = samsung_gpiolib_to_irq,
> },
> }, {
> - .base = (S5P_VA_GPIO2 + 0xC20),
> .config = &samsung_gpio_cfgs[9],
> .irq_base = IRQ_EINT(8),
> .chip = {
> @@ -2351,7 +2349,6 @@ static struct samsung_gpio_chip exynos4_gpios_2[] = {
> .to_irq = samsung_gpiolib_to_irq,
> },
> }, {
> - .base = (S5P_VA_GPIO2 + 0xC40),
> .config = &samsung_gpio_cfgs[9],
> .irq_base = IRQ_EINT(16),
> .chip = {
> @@ -2361,7 +2358,6 @@ static struct samsung_gpio_chip exynos4_gpios_2[] = {
> .to_irq = samsung_gpiolib_to_irq,
> },
> }, {
> - .base = (S5P_VA_GPIO2 + 0xC60),
> .config = &samsung_gpio_cfgs[9],
> .irq_base = IRQ_EINT(24),
> .chip = {
> @@ -2789,9 +2785,16 @@ static __init int samsung_gpiolib_init(void)
> s5p_register_gpioint_bank(IRQ_GPIOINT, 0,
> S5P_GPIOINT_GROUP_MAXNR);
> #endif
> } else if (soc_is_exynos4210()) {
> - group = 0;
> +#ifdef CONFIG_CPU_EXYNOS4210
> + void __iomem *gpx_base;
>
> /* gpio part1 */
> + gpio_base1 = ioremap(EXYNOS4_PA_GPIO1, SZ_4K);
> + if (gpio_base1 == NULL) {
> + pr_err("unable to ioremap for gpio_base1\n");
> + goto err_ioremap1;
> + }
> +
> chip = exynos4_gpios_1;
> nr_chips = ARRAY_SIZE(exynos4_gpios_1);
>
> @@ -2800,14 +2803,25 @@ static __init int samsung_gpiolib_init(void)
> chip->config = &exynos_gpio_cfg;
> chip->group = group++;
> }
> -#ifdef CONFIG_CPU_EXYNOS4210
> exynos_gpiolib_attach_ofnode(chip,
> EXYNOS4_PA_GPIO1, i * 0x20);
> -#endif
> }
> - samsung_gpiolib_add_4bit_chips(exynos4_gpios_1, nr_chips,
> S5P_VA_GPIO1);
> + samsung_gpiolib_add_4bit_chips(exynos4_gpios_1,
> +nr_chips, gpio_base1);
>
> /* gpio part2 */
> + gpio_base2 = ioremap(EXYNOS4_PA_GPIO2, SZ_4K);
> + if (gpio_base2 == NULL) {
> + pr_err("unable to ioremap for gpio_base2\n");
> +
Re: [PATCH 5/5] mmc: sdhci-s3c: setup pins using pinctrl interface
On Mon, Mar 12, 2012 at 08:01:34PM +0530, Thomas Abraham wrote: > Yes, I agree with your comment. I did refer to manuals of s3c24xx to > Exynos to ensure that the samsung pinctrl driver is generic and > reusable on all samsung soc's. I hope I have not missed out something > important that would require additional tweaks in the samsung pinctrl > driver. The missing bits now are gpio interrupt and wakeup interrupt > support in the samsung pinctrl driver. Once that is complete, I > believe it should be easy to add support for other SoC and convert the > drivers to use pinctrl (other option being to let pinctrl driver hog > all the mappings at boot and remove the cfg_gpio platform callbacks > from the driver). Yes, I don't see any fundamental problems here - it's more that either we'll need to get all the SoCs converted over (which is a lot of work) or we'll need to have drivers be able to cope with running either way. signature.asc Description: Digital signature
Re: [PATCH v11 3/3] iommu/exynos: Add iommu driver for Exynos Platforms
On Fri, Mar 09, 2012 at 09:15:24PM +0900, Cho KyongHo wrote:
> +/* We does not consider super section mapping (16MB) */
> +struct iommu_client {
> + struct list_head node;
> + struct device *dev;
> +};
> +
> +struct exynos_iommu_domain {
> + struct list_head clients; /* list of iommu_client */
> + unsigned long *pgtable; /* lv1 page table, 16KB */
> + short *lv2entcnt; /* free lv2 entry counter for each section */
> + spinlock_t lock; /* lock for this structure and attached iommu_client */
> + spinlock_t pgtablelock; /* lock for modifying page table @ pgtable */
> +};
> +
> +struct sysmmu_drvdata {
> + struct device *sysmmu;
> + char *dbgname;
> + int nsfrs;
> + void __iomem **sfrbases;
> + struct clk *clk[2];
> + int activations;
> + rwlock_t lock;
> + struct iommu_domain *domain;
> + sysmmu_fault_handler_t fault_handler;
> + unsigned long pgtable;
> + struct iommu_client client;
> +};
Is there any reason why 'struct iommu_client' is a seperate data
structure? Otherwise it can be merged with 'truct sysmmu_drvdata'.
> +static void exynos_iommu_domain_destroy(struct iommu_domain *domain)
> +{
> + struct exynos_iommu_domain *priv = domain->priv;
> + struct list_head *pos, *n;
> + unsigned long flags;
> + int i;
> +
> + WARN_ON(!list_empty(&priv->clients));
> +
> + spin_lock_irqsave(&priv->lock, flags);
> +
> + list_for_each_safe(pos, n, &priv->clients) {
> + struct iommu_client *client;
> +
> + client = list_entry(pos, struct iommu_client, node);
> + exynos_sysmmu_disable(client->dev);
> + kfree(client);
> + }
Why this kfree here? Aren't all iommu_clients just a part of another
data-structre?
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] mmc: sdhci-s3c: setup pins using pinctrl interface
On 12 March 2012 19:51, Mark Brown wrote: > On Sun, Mar 11, 2012 at 06:16:05PM +0530, Thomas Abraham wrote: >> The platform specific callback to setup the sdhci pin mux and pin config >> is removed and the pinctrl subsystem interface is used to setup the >> mux and config. > > You've only added pinctrl support for Exynos but this driver is also > used by SoCs going back to s3c24xx era. Either all those SoCs need to > be converted to use pinctrl or the driver needs to understand both > methods (eg, using pinctrl if no callback is supplied). Yes, I agree with your comment. I did refer to manuals of s3c24xx to Exynos to ensure that the samsung pinctrl driver is generic and reusable on all samsung soc's. I hope I have not missed out something important that would require additional tweaks in the samsung pinctrl driver. The missing bits now are gpio interrupt and wakeup interrupt support in the samsung pinctrl driver. Once that is complete, I believe it should be easy to add support for other SoC and convert the drivers to use pinctrl (other option being to let pinctrl driver hog all the mappings at boot and remove the cfg_gpio platform callbacks from the driver). Thank you Mark for your comments. Regards, Thomas. -- 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] i2c-s3c2410: Rework device type handling
On 12 March 2012 18:46, Karol Lewandowski wrote:
> On 12.03.2012 06:58, Thomas Abraham wrote:
>
> Hi Thomas!
>
>> On 9 March 2012 22:34, Karol Lewandowski wrote:
>>> Reorganize driver a bit to better handle device tree-based systems:
>>>
>>> - move machine type to driver's private structure instead of
>>> quering platform device variants in runtime
>>>
>>> - replace s3c24xx_i2c_type enum with plain unsigned int that can
>>> hold not only device type but also hw revision-specific quirks
>>>
>>> Signed-off-by: Karol Lewandowski
>>> Signed-off-by: Kyungmin Park
>>> ---
>>> drivers/i2c/busses/i2c-s3c2410.c | 56
>>> +
>>> 1 files changed, 20 insertions(+), 36 deletions(-)
>>>
>>> diff --git a/drivers/i2c/busses/i2c-s3c2410.c
>>> b/drivers/i2c/busses/i2c-s3c2410.c
>>> index 737f721..5b400c6 100644
>>> --- a/drivers/i2c/busses/i2c-s3c2410.c
>>> +++ b/drivers/i2c/busses/i2c-s3c2410.c
>>> @@ -44,8 +44,12 @@
>>> #include
>>> #include
>>>
>>> -/* i2c controller state */
>>> +/* type */
>>> +#define TYPE_BITS 0x00ff
>>> +#define TYPE_S3C2410 0x0001
>>> +#define TYPE_S3C2440 0x0002
>>>
>>> +/* i2c controller state */
>>> enum s3c24xx_i2c_state {
>>> STATE_IDLE,
>>> STATE_START,
>>> @@ -54,14 +58,10 @@ enum s3c24xx_i2c_state {
>>> STATE_STOP
>>> };
>>>
>>> -enum s3c24xx_i2c_type {
>>> - TYPE_S3C2410,
>>> - TYPE_S3C2440,
>>> -};
>>> -
>>> struct s3c24xx_i2c {
>>> spinlock_t lock;
>>> wait_queue_head_t wait;
>>> + unsigned int type;
>>> unsigned int suspended:1;
>>>
>>> struct i2c_msg *msg;
>>> @@ -88,28 +88,6 @@ struct s3c24xx_i2c {
>>> #endif
>>> };
>>>
>>> -/* default platform data removed, dev should always carry data. */
>>> -
>>> -/* s3c24xx_i2c_is2440()
>>> - *
>>> - * return true is this is an s3c2440
>>> -*/
>>> -
>>> -static inline int s3c24xx_i2c_is2440(struct s3c24xx_i2c *i2c)
>>> -{
>>> - struct platform_device *pdev = to_platform_device(i2c->dev);
>>> - enum s3c24xx_i2c_type type;
>>> -
>>> -#ifdef CONFIG_OF
>>> - if (i2c->dev->of_node)
>>> - return of_device_is_compatible(i2c->dev->of_node,
>>> - "samsung,s3c2440-i2c");
>>> -#endif
>>> -
>>> - type = platform_get_device_id(pdev)->driver_data;
>>> - return type == TYPE_S3C2440;
>>> -}
>>> -
>>> /* s3c24xx_i2c_master_complete
>>> *
>>> * complete the message and wake up the caller, using the given return code,
>>> @@ -676,7 +654,7 @@ static int s3c24xx_i2c_clockrate(struct s3c24xx_i2c
>>> *i2c, unsigned int *got)
>>>
>>> writel(iiccon, i2c->regs + S3C2410_IICCON);
>>>
>>> - if (s3c24xx_i2c_is2440(i2c)) {
>>> + if (i2c->type & TYPE_S3C2440) {
>>
>> This should be changed to
>> if (i2c->type == TYPE_S3C2440)
>
>
> Equality check won't work here after second patch is applied
> (i2c->type might have FLAG_*s set on upper bits).
>
Right. I assumed that if a another type is added, its value will be 3.
But looks like you intend to assign 4, 8, 16 and so on for the new
types. Probably, this approach needs to documented in this file.
Otherwise, the above check would not work if ever a new type is added
without knowing this approach.
>>
>>> unsigned long sda_delay;
>>>
>>> if (pdata->sda_delay) {
>>> @@ -847,6 +825,8 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
>>> }
>>>
>>> #ifdef CONFIG_OF
>>> +static const struct of_device_id s3c24xx_i2c_match[];
>>> +
>>> /* s3c24xx_i2c_parse_dt
>>> *
>>> * Parse the device tree node and retreive the platform data.
>>> @@ -856,11 +836,16 @@ static void
>>> s3c24xx_i2c_parse_dt(struct device_node *np, struct s3c24xx_i2c *i2c)
>>> {
>>> struct s3c2410_platform_i2c *pdata = i2c->pdata;
>>> + const struct of_device_id *match;
>>>
>>> if (!np)
>>> return;
>>>
>>> pdata->bus_num = -1; /* i2c bus number is dynamically assigned */
>>> +
>>> + match = of_match_node(&s3c24xx_i2c_match[0], np);
>>
>> This could be
>> match = of_match_node(s3c24xx_i2c_match, np);
>
>
> If you (and Ben, of course) don't mind I would prefer more verbose but
> also more explicit version.
>
I am fine the explicit version.
>>> + i2c->type = (unsigned int)match->data;
>>> +
>>
>> This function (s3c24xx_i2c_parse_dt) is intended to retrieve the data
>> from i2c device node. It would be better to not add the determination
>> of the i2c type inside this function.
>>
>>> of_property_read_u32(np, "samsung,i2c-sda-delay", &pdata->sda_delay);
>>> of_property_read_u32(np, "samsung,i2c-slave-addr",
>>> &pdata->slave_addr);
>>> of_property_read_u32(np, "samsung,i2c-max-bus-freq",
>>> @@ -906,9 +891,10 @@ static int s3c24xx_i2c_probe(struct platform_device
>>> *pdev)
>>> goto err_noclk;
>>> }
>>>
>>> - if (pda
Re: [PATCH 5/5] mmc: sdhci-s3c: setup pins using pinctrl interface
On Sun, Mar 11, 2012 at 06:16:05PM +0530, Thomas Abraham wrote: > The platform specific callback to setup the sdhci pin mux and pin config > is removed and the pinctrl subsystem interface is used to setup the > mux and config. You've only added pinctrl support for Exynos but this driver is also used by SoCs going back to s3c24xx era. Either all those SoCs need to be converted to use pinctrl or the driver needs to understand both methods (eg, using pinctrl if no callback is supplied). -- 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] i2c-s3c2410: Rework device type handling
On 12.03.2012 06:58, Thomas Abraham wrote:
Hi Thomas!
> On 9 March 2012 22:34, Karol Lewandowski wrote:
>> Reorganize driver a bit to better handle device tree-based systems:
>>
>> - move machine type to driver's private structure instead of
>> quering platform device variants in runtime
>>
>> - replace s3c24xx_i2c_type enum with plain unsigned int that can
>> hold not only device type but also hw revision-specific quirks
>>
>> Signed-off-by: Karol Lewandowski
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/i2c/busses/i2c-s3c2410.c | 56
>> +
>> 1 files changed, 20 insertions(+), 36 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-s3c2410.c
>> b/drivers/i2c/busses/i2c-s3c2410.c
>> index 737f721..5b400c6 100644
>> --- a/drivers/i2c/busses/i2c-s3c2410.c
>> +++ b/drivers/i2c/busses/i2c-s3c2410.c
>> @@ -44,8 +44,12 @@
>> #include
>> #include
>>
>> -/* i2c controller state */
>> +/* type */
>> +#define TYPE_BITS 0x00ff
>> +#define TYPE_S3C2410 0x0001
>> +#define TYPE_S3C2440 0x0002
>>
>> +/* i2c controller state */
>> enum s3c24xx_i2c_state {
>>STATE_IDLE,
>>STATE_START,
>> @@ -54,14 +58,10 @@ enum s3c24xx_i2c_state {
>>STATE_STOP
>> };
>>
>> -enum s3c24xx_i2c_type {
>> - TYPE_S3C2410,
>> - TYPE_S3C2440,
>> -};
>> -
>> struct s3c24xx_i2c {
>>spinlock_t lock;
>>wait_queue_head_t wait;
>> + unsigned inttype;
>>unsigned intsuspended:1;
>>
>>struct i2c_msg *msg;
>> @@ -88,28 +88,6 @@ struct s3c24xx_i2c {
>> #endif
>> };
>>
>> -/* default platform data removed, dev should always carry data. */
>> -
>> -/* s3c24xx_i2c_is2440()
>> - *
>> - * return true is this is an s3c2440
>> -*/
>> -
>> -static inline int s3c24xx_i2c_is2440(struct s3c24xx_i2c *i2c)
>> -{
>> - struct platform_device *pdev = to_platform_device(i2c->dev);
>> - enum s3c24xx_i2c_type type;
>> -
>> -#ifdef CONFIG_OF
>> - if (i2c->dev->of_node)
>> - return of_device_is_compatible(i2c->dev->of_node,
>> - "samsung,s3c2440-i2c");
>> -#endif
>> -
>> - type = platform_get_device_id(pdev)->driver_data;
>> - return type == TYPE_S3C2440;
>> -}
>> -
>> /* s3c24xx_i2c_master_complete
>> *
>> * complete the message and wake up the caller, using the given return code,
>> @@ -676,7 +654,7 @@ static int s3c24xx_i2c_clockrate(struct s3c24xx_i2c
>> *i2c, unsigned int *got)
>>
>>writel(iiccon, i2c->regs + S3C2410_IICCON);
>>
>> - if (s3c24xx_i2c_is2440(i2c)) {
>> + if (i2c->type & TYPE_S3C2440) {
>
> This should be changed to
> if (i2c->type == TYPE_S3C2440)
Equality check won't work here after second patch is applied
(i2c->type might have FLAG_*s set on upper bits).
>
>>unsigned long sda_delay;
>>
>>if (pdata->sda_delay) {
>> @@ -847,6 +825,8 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
>> }
>>
>> #ifdef CONFIG_OF
>> +static const struct of_device_id s3c24xx_i2c_match[];
>> +
>> /* s3c24xx_i2c_parse_dt
>> *
>> * Parse the device tree node and retreive the platform data.
>> @@ -856,11 +836,16 @@ static void
>> s3c24xx_i2c_parse_dt(struct device_node *np, struct s3c24xx_i2c *i2c)
>> {
>>struct s3c2410_platform_i2c *pdata = i2c->pdata;
>> + const struct of_device_id *match;
>>
>>if (!np)
>>return;
>>
>>pdata->bus_num = -1; /* i2c bus number is dynamically assigned */
>> +
>> + match = of_match_node(&s3c24xx_i2c_match[0], np);
>
> This could be
> match = of_match_node(s3c24xx_i2c_match, np);
If you (and Ben, of course) don't mind I would prefer more verbose but
also more explicit version.
>> + i2c->type = (unsigned int)match->data;
>> +
>
> This function (s3c24xx_i2c_parse_dt) is intended to retrieve the data
> from i2c device node. It would be better to not add the determination
> of the i2c type inside this function.
>
>>of_property_read_u32(np, "samsung,i2c-sda-delay", &pdata->sda_delay);
>>of_property_read_u32(np, "samsung,i2c-slave-addr",
>> &pdata->slave_addr);
>>of_property_read_u32(np, "samsung,i2c-max-bus-freq",
>> @@ -906,9 +891,10 @@ static int s3c24xx_i2c_probe(struct platform_device
>> *pdev)
>>goto err_noclk;
>>}
>>
>> - if (pdata)
>> + if (pdata) {
>>memcpy(i2c->pdata, pdata, sizeof(*pdata));
>> - else
>> + i2c->type = platform_get_device_id(pdev)->driver_data;
>> + } else
>>s3c24xx_i2c_parse_dt(pdev->dev.of_node, i2c);
>
> It would be better to move the task of retrieving the driver data to a
> separate function. An example of this listed below (copied from the
> samsung uart driver).
Well, I was under impression that #ifdefs inside functions were quite
disliked by kernel devs. Now I see t
RE: [PATCH 1/4] thermal: exynos: Add thermal interface support for linux thermal layer
Hi Amit,
Thanks for keeping this up. And Sorry for late reply.
> -Original Message-
> From: amit kachhap [mailto:amitdani...@gmail.com] On Behalf Of Amit Daniel
> Kachhap
> Sent: Saturday, March 03, 2012 4:36 PM
> To: linux...@lists.linux-foundation.org; linux-samsung-soc@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org; mj...@srcf.ucam.org; linux-
> a...@vger.kernel.org; l...@kernel.org; linaro-...@lists.linaro.org; lm-
> sens...@lm-sensors.org; amit.kach...@linaro.org; eduardo.valen...@ti.com; R,
> Durgadoss; patc...@linaro.org
> Subject: [PATCH 1/4] thermal: exynos: Add thermal interface support for linux
> thermal layer
>
> This codes uses the generic linux thermal layer and creates a bridge
> between temperature sensors, linux thermal framework and cooling devices
> for samsung exynos platform. This layer recieves or monitor the
> temperature from the sensor and informs the generic thermal layer to take
> the necessary cooling action.
>
> Signed-off-by: Amit Daniel Kachhap
> ---
> drivers/thermal/Kconfig |8 +
> drivers/thermal/Makefile |1 +
> drivers/thermal/exynos_thermal.c | 272
> ++
> include/linux/exynos_thermal.h | 72 ++
> 4 files changed, 353 insertions(+), 0 deletions(-)
> create mode 100644 drivers/thermal/exynos_thermal.c
> create mode 100644 include/linux/exynos_thermal.h
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 298c1cd..4e8df56 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -29,3 +29,11 @@ config CPU_THERMAL
> This will be useful for platforms using the generic thermal interface
> and not the ACPI interface.
> If you want this support, you should say Y or M here.
> +
> +config SAMSUNG_THERMAL_INTERFACE
> + bool "Samsung Thermal interface support"
> + depends on THERMAL && CPU_THERMAL
> + help
> + This is a samsung thermal interface which will be used as
> + a link between sensors and cooling devices with linux thermal
> + framework.
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 655cbc4..c67b6b2 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -4,3 +4,4 @@
>
> obj-$(CONFIG_THERMAL)+= thermal_sys.o
> obj-$(CONFIG_CPU_THERMAL)+= cpu_cooling.o
> +obj-$(CONFIG_SAMSUNG_THERMAL_INTERFACE) += exynos_thermal.o
> diff --git a/drivers/thermal/exynos_thermal.c
> b/drivers/thermal/exynos_thermal.c
> new file mode 100644
> index 000..878d45c
> --- /dev/null
> +++ b/drivers/thermal/exynos_thermal.c
> @@ -0,0 +1,272 @@
> +/* linux/drivers/thermal/exynos_thermal.c
> + *
> + * Copyright (c) 2010-2011 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
> +
> +#define MAX_COOLING_DEVICE 4
> +struct exynos4_thermal_zone {
> + unsigned int idle_interval;
> + unsigned int active_interval;
> + struct thermal_zone_device *therm_dev;
> + struct thermal_cooling_device *cool_dev[MAX_COOLING_DEVICE];
> + unsigned int cool_dev_size;
> + struct platform_device *exynos4_dev;
> + struct thermal_sensor_conf *sensor_conf;
> +};
> +
> +static struct exynos4_thermal_zone *th_zone;
> +
> +static int exynos4_get_mode(struct thermal_zone_device *thermal,
> + enum thermal_device_mode *mode)
> +{
> + if (th_zone->sensor_conf) {
> + pr_info("Temperature sensor not initialised\n");
> + *mode = THERMAL_DEVICE_DISABLED;
> + } else
> + *mode = THERMAL_DEVICE_ENABLED;
> + return 0;
> +}
> +
> +static int exynos4_set_mode(struct thermal_zone_device *thermal,
> + enum thermal_device_mode mode)
> +{
> + if (!th_zone->therm_dev) {
> + pr_notice("thermal zone not registered\n");
> + return 0;
> + }
> + if (mode == THERMAL_DEVICE_ENABLED)
> + th_zone->therm_dev->polling_delay =
> + th_zone->active_interval*1000;
> + else
> + th_zone->therm_dev->polling_delay =
> + th_zone->idle_interval*1000;
If it is 'DISABLED' mode, shouldn't the polling delay be just 0 ?
> +
> + thermal_zone_device_update(th_zone->therm_dev);
> + pr_info("thermal polling set for duration=%d sec\n",
> + th_zone->therm_dev->polling_delay/1000);
> + return 0;
> +}
> +
> +/*This may be called from interrupt based temperature sensor*/
> +void exynos4_report_trigger(void)
> +{
> + unsigned int monitor_temp;
> +
> + if (!th_zone || !th_zone->therm_dev)
>
Re: [PATCH 2/3] ARM: EXYNOS: Add clkdev lookup entry for lcd clock
On 03/10/2012 07:52 PM, Chenglie He wrote:
> I am doing the suspend and resume of s3cfb on exynos. the clk_on and
> clk_off just failed. I think this is a related issue.
>
Without this patch, the probe for s3cfb driver itself fails - hence what
you are seeing must be different.
> On 29 February 2012 13:45, Tushar Behera wrote:
>
>> Hi Kukjin,
>>
>> On 12/01/2011 11:20 AM, Tushar Behera wrote:
>>> The framebuffer driver needs the clock named 'lcd' as its bus
>>> clock but the equivalent clock on Exynos4 is named as 'fimd'.
>>> Hence, create a clkdev lookup entry with the name 'lcd' that
>>> references the 'fimd' clock.
>>>
>>> Signed-off-by: Tushar Behera
>>> ---
>>> arch/arm/mach-exynos/clock.c | 14 +-
>>> 1 files changed, 9 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-exynos/clock.c b/arch/arm/mach-exynos/clock.c
>>> index 5d8d483..607ec28 100644
>>> --- a/arch/arm/mach-exynos/clock.c
>>> +++ b/arch/arm/mach-exynos/clock.c
>>> @@ -489,11 +489,6 @@ static struct clk init_clocks_off[] = {
>>> .enable = exynos4_clk_ip_cam_ctrl,
>>> .ctrlbit= (1 << 3),
>>> }, {
>>> - .name = "fimd",
>>> - .devname= "exynos4-fb.0",
>>> - .enable = exynos4_clk_ip_lcd0_ctrl,
>>> - .ctrlbit= (1 << 0),
>>> - }, {
>>> .name = "hsmmc",
>>> .devname= "s3c-sdhci.0",
>>> .parent = &clk_aclk_133.clk,
>>> @@ -782,6 +777,13 @@ static struct clk clk_pdma1 = {
>>> .ctrlbit= (1 << 1),
>>> };
>>>
>>> +static struct clk clk_fimd0 = {
>>> + .name = "fimd",
>>> + .devname= "exynos4-fb.0",
>>> + .enable = exynos4_clk_ip_lcd0_ctrl,
>>> + .ctrlbit= (1 << 0),
>>> +};
>>> +
>>> struct clk *clkset_group_list[] = {
>>> [0] = &clk_ext_xtal_mux,
>>> [1] = &clk_xusbxti,
>>> @@ -1294,6 +1296,7 @@ static struct clksrc_clk *sysclks[] = {
>>> static struct clk *clk_cdev[] = {
>>> &clk_pdma0,
>>> &clk_pdma1,
>>> + &clk_fimd0,
>>> };
>>>
>>> static struct clksrc_clk *clksrc_cdev[] = {
>>> @@ -1318,6 +1321,7 @@ static struct clk_lookup exynos4_clk_lookup[] = {
>>> CLKDEV_INIT("s3c-sdhci.3", "mmc_busclk.2", &clk_sclk_mmc3.clk),
>>> CLKDEV_INIT("dma-pl330.0", "apb_pclk", &clk_pdma0),
>>> CLKDEV_INIT("dma-pl330.1", "apb_pclk", &clk_pdma1),
>>> + CLKDEV_INIT("exynos4-fb.0", "lcd", &clk_fimd0),
>>> };
>>>
>>> static int xtal_rate;
>>
>> Would you please review this patch and let me know your opinion? Without
>> this patch, frame-buffer support on EXYNOS4 is broken.
>>
>> --
>> Tushar Behera
>>
>> ___
>> linaro-dev mailing list
>> linaro-...@lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/linaro-dev
>>
>
--
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
