Re: [PATCH 2/3] s5p-g2d: add G2D to mach-nuri
On 12/20/11, Mark Brown wrote: > On Mon, Dec 12, 2011 at 11:32:28PM +0900, Kyungmin Park wrote: >> On Mon, Dec 12, 2011 at 7:03 PM, Mark Brown > >> > I'm not sure I understand why we would not be ready to do things like >> > this? I'd also expect that doing things in a board specific fashion >> > might create issues with things being set up twice. > >> Please see the below, >> https://lkml.org/lkml/2011/11/15/16 > >> Even though I can't agree with his opinions. There are other voice like >> this. > >> I also want to common registration and select at each board. > > So, I looked at the discussion there and I'm not sure I'm buying what's > being said; it seems to be as much a fear of change and a lack of > awareness of modern infrastructure as anything else. It seems to me > that this is a case where we should just be turning round and saying > that the default position ought to be the other way around, if things > need to be done per board there should be a strong reason for it. Please ask the Mr. Kim. Now he's working on common file so include these functionality. then other boards can follow up. Thank you, Kyungmin Park -- 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] ARM: EXYNOS4: Add DMC1, allow PPMU access for DMC.
Hi Mr. Kim,
It's maybe missing for v3.3 merge at samsung soc.
Please give your opinion, how to handle it?
If you don't mind it, it can merge it by devfreq.
Thank you,
Kyungmin Park
On 12/1/11, MyungJoo Ham wrote:
> - Add DMC1
> - Enlarge address space for DMC from 4k to 64k so that PPMU registers
> may be accessed.
>
> Signed-off-by: MyungJoo Ham
> Signed-off-by: Kyungmin Park
> ---
> arch/arm/mach-exynos/cpu.c |7 ++-
> arch/arm/mach-exynos/include/mach/map.h |1 +
> 2 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/cpu.c b/arch/arm/mach-exynos/cpu.c
> index 90ec247..8bdcba9 100644
> --- a/arch/arm/mach-exynos/cpu.c
> +++ b/arch/arm/mach-exynos/cpu.c
> @@ -108,7 +108,12 @@ static struct map_desc exynos4_iodesc[] __initdata = {
> }, {
> .virtual= (unsigned long)S5P_VA_DMC0,
> .pfn= __phys_to_pfn(EXYNOS4_PA_DMC0),
> - .length = SZ_4K,
> + .length = SZ_64K,
> + .type = MT_DEVICE,
> + }, {
> + .virtual= (unsigned long)S5P_VA_DMC1,
> + .pfn= __phys_to_pfn(EXYNOS4_PA_DMC1),
> + .length = SZ_64K,
> .type = MT_DEVICE,
> }, {
> .virtual= (unsigned long)S5P_VA_SROMC,
> diff --git a/arch/arm/mach-exynos/include/mach/map.h
> b/arch/arm/mach-exynos/include/mach/map.h
> index 058541d..870a980 100644
> --- a/arch/arm/mach-exynos/include/mach/map.h
> +++ b/arch/arm/mach-exynos/include/mach/map.h
> @@ -57,6 +57,7 @@
> #define EXYNOS4_PA_KEYPAD0x100A
>
> #define EXYNOS4_PA_DMC0 0x1040
> +#define EXYNOS4_PA_DMC1 0x1041
>
> #define EXYNOS4_PA_COMBINER 0x1044
>
> --
> 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
>
--
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] s5p-g2d: add G2D to mach-nuri
On Mon, Dec 12, 2011 at 7:03 PM, Mark Brown wrote: > On Mon, Dec 12, 2011 at 06:27:30PM +0900, Kyungmin Park wrote: >> On 12/12/11, Mark Brown wrote: > >> >> + &s5p_device_g2d, > >> > For devices like g2d which are always part of the SoC and which don't >> > require any external wiring on the board I was thinking we should just >> > have the core code for the SoC register the device rather than including >> > it in each board individually. It'd save effort and ensure that people >> > automatically get to use the feature. > >> I'm welcome to use these scheme. make a common.c and register it >> automatically. >> but I'm not sure we're ready to use this scheme. and I hope to start >> these work at smdk board instead of this patch. > > I'm not sure I understand why we would not be ready to do things like > this? I'd also expect that doing things in a board specific fashion > might create issues with things being set up twice. Please see the below, https://lkml.org/lkml/2011/11/15/16 Even though I can't agree with his opinions. There are other voice like this. I also want to common registration and select at each board. Thank you, Kyungmin Park > -- > 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 2/3] s5p-g2d: add G2D to mach-nuri
On 12/12/11, Mark Brown wrote:
> On Fri, Dec 09, 2011 at 05:04:41PM +0100, Kamil Debski wrote:
>
>> index 236bbe1..5251e91 100644
>> --- a/arch/arm/mach-exynos/mach-nuri.c
>> +++ b/arch/arm/mach-exynos/mach-nuri.c
>> @@ -1262,6 +1262,7 @@ static struct platform_device *nuri_devices[]
>> __initdata = {
>> &s3c_device_i2c3,
>> &i2c9_gpio,
>> &s3c_device_adc,
>> +&s5p_device_g2d,
>
> For devices like g2d which are always part of the SoC and which don't
> require any external wiring on the board I was thinking we should just
> have the core code for the SoC register the device rather than including
> it in each board individually. It'd save effort and ensure that people
> automatically get to use the feature.
I'm welcome to use these scheme. make a common.c and register it automatically.
but I'm not sure we're ready to use this scheme. and I hope to start
these work at smdk board instead of this patch.
Thank you,
Kyungmin Park
>
> The crypto accelerators are another example of this - it's not really
> board specific if they're useful.
> --
> 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 2/2] regulator: add device tree support for max8997
max8997,pmic-ignore-gpiodvs-side-effect;
> + max8997,pmic-buck125-default-dvs-idx = <0>;
> +
> + max8997,pmic-buck125-dvs-gpios = <&gpx0 0 1 0 0>, /* SET1 */
> + <&gpx0 1 1 0 0>, /* SET2 */
> + <&gpx0 2 1 0 0>; /* SET3 */
> +
> + max8997,pmic-buck1-dvs-voltage = <135>, <130>,
> + <125>, <120>,
> + <115>, <110>,
> + <100>, <95>;
> +
> + max8997,pmic-buck2-dvs-voltage = <110>, <110>,
> + <110>, <110>,
> + <100>, <100>,
> + <100>, <100>;
> +
> + max8997,pmic-buck5-dvs-voltage = <120>, <120>,
> + <120>, <120>,
> + <120>, <120>,
> + <120>, <120>;
> +
> + regulators {
> + ldo1_reg: LDO1 {
> + regulator-name = "VDD_ABB_3.3V";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + ldo2_reg: LDO2 {
> + regulator-name = "VDD_ALIVE_1.1V";
> + regulator-min-microvolt = <110>;
> + regulator-max-microvolt = <110>;
> + regulator-always-on;
> + };
> +
> + buck1_reg: BUCK1 {
> + regulator-name = "VDD_ARM_1.2V";
> + regulator-min-microvolt = <95>;
> + regulator-max-microvolt = <135>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> + };
> + };
> diff --git a/drivers/mfd/max8997.c b/drivers/mfd/max8997.c
> index b996c6e..1749cf9 100644
> --- a/drivers/mfd/max8997.c
> +++ b/drivers/mfd/max8997.c
> @@ -23,6 +23,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -122,6 +123,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)
It should be 'int' instead of 'int *'
It's helpful to compile without CONFIG_OF.
Thank you,
Kyungmin Park
> +{
> + return 0;
> +}
> +#endif
> +
> +static struct of_device_id __devinitdata max8997_pmic_dt_match[];
> +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) {
> +
Re: [PATCH v7 0/2] iommu/exynos: Add IOMMU/System MMU driver for Samsung Exynos
On Tue, Dec 6, 2011 at 9:13 PM, KyongHo Cho wrote: > On Tue, Dec 6, 2011 at 8:24 AM, Kyungmin Park wrote: >> On 12/6/11, Joerg Roedel wrote: >>> On Fri, Nov 18, 2011 at 06:47:28PM +0900, KyongHo Cho wrote: >>>> Patch Summary: >>>> [PATCH v7 1/2] ARM: EXYNOS: Change System MMU platform device definitions >>>> [PATCH v7 2/2] iommu/exynos: Add iommu driver for Exynos Platforms >>> >>> Okay, I merged it into arm/exynos, but it is not pushed yet. Actually >>> there were conflicts while merging, which I resolved. What I failed >>> to find is a config for Exynos that actually builds for upstream Linux. >>> Probably I havn't tried hard enough to find one... Can you provide a >>> kernel config that I can use for my testing and that builds a current >>> 3.2-rc4 kernel for Exynos? >> and I hope to see the real example how to use it with exynos platform. >> >> Now I can't find the interface between exynos platform and generic exynos >> iommu. > In "[PATCH v7 1/2] ARM: EXYNOS: Change System MMU platform device > definitions" patch, > you can find sysmmu_init(). > It stores associations between a system MMU and a peripheral device in > platform data of platform device descriptor. > If Exynos IOMMU driver finds the association while probing, then the > driver can control the system MMU. Maybe it's still call the function directly instead of using struct dev field as OMAP did. Even though generic DMA mapping IOMMU doesn't used, you can connect the iommu field at arch/arm/include/asm/device.h BR, Kyungmin Park > >> BTW, how do you test it at mainline kernel? >> > I merged IOMMU mainline branch to our kernel branch and tested it with > our FIMC, MFC, JPEG, 2D. -- 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 v7 0/2] iommu/exynos: Add IOMMU/System MMU driver for Samsung Exynos
On 12/6/11, Joerg Roedel wrote: > On Fri, Nov 18, 2011 at 06:47:28PM +0900, KyongHo Cho wrote: >> Patch Summary: >> [PATCH v7 1/2] ARM: EXYNOS: Change System MMU platform device definitions >> [PATCH v7 2/2] iommu/exynos: Add iommu driver for Exynos Platforms > > Okay, I merged it into arm/exynos, but it is not pushed yet. Actually > there were conflicts while merging, which I resolved. What I failed > to find is a config for Exynos that actually builds for upstream Linux. > Probably I havn't tried hard enough to find one... Can you provide a > kernel config that I can use for my testing and that builds a current > 3.2-rc4 kernel for Exynos? and I hope to see the real example how to use it with exynos platform. Now I can't find the interface between exynos platform and generic exynos iommu. BTW, how do you test it at mainline kernel? Thank you, Kyungmin Park > > Thanks, > > Joerg > > -- > AMD Operating System Research Center > > Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach > General Managers: Alberto Bozzo, Andrew Bowd > 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 > -- 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/2] arm: exynos: allow platform-lcd driver to control lcd regulator source on origen
On 12/5/11, Thomas Abraham wrote:
> The buck7 regulator of max8997 pmic which provides the power source to lcd
> panel
> and the lvds transmitter is allowed to be controlled by the platform-lcd
> driver.
> It is not required to apply the voltage source by default. Also, the voltage
> range for buck7 regulator is modified as the per the values in the
> datasheet.
>
> Signed-off-by: Thomas Abraham
> ---
> arch/arm/mach-exynos/mach-origen.c | 12 +++-
> 1 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/mach-origen.c
> b/arch/arm/mach-exynos/mach-origen.c
> index f56d027..5456254 100644
> --- a/arch/arm/mach-exynos/mach-origen.c
> +++ b/arch/arm/mach-exynos/mach-origen.c
> @@ -126,7 +126,7 @@ static struct regulator_consumer_supply __initdata
> buck3_consumer[] = {
> REGULATOR_SUPPLY("vdd_g3d", "mali_drm"), /* G3D */
> };
> static struct regulator_consumer_supply __initdata buck7_consumer[] = {
> - REGULATOR_SUPPLY("vcc", "platform-lcd"), /* LCD */
> + REGULATOR_SUPPLY("vcc_lcd", "platform-lcd.0"), /* LCD */
> };
>
> static struct regulator_init_data __initdata max8997_ldo1_data = {
> @@ -379,11 +379,11 @@ static struct regulator_init_data __initdata
> max8997_buck5_data = {
> static struct regulator_init_data __initdata max8997_buck7_data = {
> .constraints= {
> .name = "VDD_LCD_3.3V",
> - .min_uV = 330,
> - .max_uV = 330,
> + .min_uV = 75,
> + .max_uV = 390,
It can support the voltage change at buck itself, but in board it's
fixed. I'm not sure it's correct usage at board file.
I think original code is better to understand and use it as name, it's
fixed v3.3 voltage.
Thank you,
Kyungmin Park
> .boot_on= 1,
> - .apply_uV = 1,
> - .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> + .valid_ops_mask = REGULATOR_CHANGE_STATUS |
> + REGULATOR_CHANGE_VOLTAGE,
> .state_mem = {
> .disabled = 1
> },
> @@ -562,6 +562,8 @@ static void lcd_hv070wsa_set_power(struct plat_lcd_data
> *pd, unsigned int power)
>
> static struct plat_lcd_data origen_lcd_hv070wsa_data = {
> .set_power = lcd_hv070wsa_set_power,
> + .min_uV = 330,
> + .max_uV = 330,
> };
>
> static struct platform_device origen_lcd_hv070wsa = {
> --
> 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
>
--
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] backlight: add regulator support for platform_lcd driver
On 12/5/11, Thomas Abraham wrote:
> The power source to the lcd panel or the lcd interface such as lvds
> transmitters could be controlled by a regulator supply. Add support
> for enabling/disabling the regulator when switching power to lcd.
>
> Two new elements 'min_uV' and 'max_uV' in the platform data are added
> to allow platform code to specifiy the desired output voltage from the
> regulator.
>
> Cc: Ben Dooks
> Signed-off-by: Thomas Abraham
> ---
> drivers/video/backlight/platform_lcd.c | 29 +
> include/video/platform_lcd.h |7 +++
> 2 files changed, 36 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/backlight/platform_lcd.c
> b/drivers/video/backlight/platform_lcd.c
> index 302330a..ffa8108 100644
> --- a/drivers/video/backlight/platform_lcd.c
> +++ b/drivers/video/backlight/platform_lcd.c
> @@ -17,6 +17,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
>
> @@ -44,11 +46,38 @@ static int platform_lcd_get_power(struct lcd_device
> *lcd)
> static int platform_lcd_set_power(struct lcd_device *lcd, int power)
> {
> struct platform_lcd *plcd = to_our_lcd(lcd);
> + struct regulator *lcd_regulator;
> int lcd_power = 1;
>
> if (power == FB_BLANK_POWERDOWN || plcd->suspended)
> lcd_power = 0;
>
> + /*
> + * If power to lcd and/or lcd interface is controlled using a regulator,
> + * enable or disable the regulator based in the power setting.
> + */
> + lcd_regulator = regulator_get(plcd->us, "vcc_lcd");
> + if (IS_ERR(lcd_regulator)) {
> + dev_info(plcd->us, "could not get regulator\n");
> + goto set_power;
> + }
Recent regulator discussion. it should be failed instead fall through
gracefully.
> +
> + if (lcd_power) {
> + if (plcd->pdata->min_uV || plcd->pdata->max_uV)
> + if (regulator_set_voltage(lcd_regulator,
> + plcd->pdata->min_uV, plcd->pdata->max_uV))
> + dev_info(plcd->us,
> + "regulator voltage set failed\n");
Are there case to change the voltage? Doesn't it easy to set the
voltage at board file? I mean don't need to setup at drivers?
Thank you,
Kyungmin Park
> +
> + if (regulator_enable(lcd_regulator))
> + dev_info(plcd->us, "failed to enable regulator\n");
> + } else {
> + regulator_disable(lcd_regulator);
> + }
> +
> + regulator_put(lcd_regulator);
> +
> +set_power:
> plcd->pdata->set_power(plcd->pdata, lcd_power);
> plcd->power = power;
>
> diff --git a/include/video/platform_lcd.h b/include/video/platform_lcd.h
> index ad3bdfe..acd5d21 100644
> --- a/include/video/platform_lcd.h
> +++ b/include/video/platform_lcd.h
> @@ -14,8 +14,15 @@
> struct plat_lcd_data;
> struct fb_info;
>
> +/**
> + * struct plat_lcd_data - platform data for platform_lcd driver.
> + * @min_uV: Minimum required voltage output from the regulator.
> + * @max_uV: Maximum acceptable voltage output from the regulator.
> + */
> struct plat_lcd_data {
> void(*set_power)(struct plat_lcd_data *, unsigned int power);
> int (*match_fb)(struct plat_lcd_data *, struct fb_info *);
> + int min_uV;
> + int max_uV;
> };
>
> --
> 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
>
--
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] ARM: EXYNOS4: Add DMC1, allow PPMU access for DMC.
On 12/2/11, Kukjin Kim wrote:
> MyungJoo Ham wrote:
>>
>> - Add DMC1
>> - Enlarge address space for DMC from 4k to 64k so that PPMU registers
>> may be accessed.
>>
>> Signed-off-by: MyungJoo Ham
>> Signed-off-by: Kyungmin Park
>> ---
>> arch/arm/mach-exynos/cpu.c |7 ++-
>> arch/arm/mach-exynos/include/mach/map.h |1 +
>> 2 files changed, 7 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/cpu.c b/arch/arm/mach-exynos/cpu.c
>> index 90ec247..8bdcba9 100644
>> --- a/arch/arm/mach-exynos/cpu.c
>> +++ b/arch/arm/mach-exynos/cpu.c
>> @@ -108,7 +108,12 @@ static struct map_desc exynos4_iodesc[] __initdata =
>> {
>> }, {
>> .virtual= (unsigned long)S5P_VA_DMC0,
>> .pfn= __phys_to_pfn(EXYNOS4_PA_DMC0),
>> -.length = SZ_4K,
>> +.length = SZ_64K,
>> +.type = MT_DEVICE,
>> +}, {
>> +.virtual= (unsigned long)S5P_VA_DMC1,
>> +.pfn= __phys_to_pfn(EXYNOS4_PA_DMC1),
>> +.length = SZ_64K,
>> .type = MT_DEVICE,
>> }, {
>> .virtual= (unsigned long)S5P_VA_SROMC,
>> diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-
>> exynos/include/mach/map.h
>> index 058541d..870a980 100644
>> --- a/arch/arm/mach-exynos/include/mach/map.h
>> +++ b/arch/arm/mach-exynos/include/mach/map.h
>> @@ -57,6 +57,7 @@
>> #define EXYNOS4_PA_KEYPAD 0x100A
>>
>> #define EXYNOS4_PA_DMC0 0x1040
>> +#define EXYNOS4_PA_DMC1 0x1041
>
> If required, so just '.length = SZ_128K'?...
Doesn't it more confuse and difficult to use?
Even though there's not much definitions. it defines the offset concept.
"arch/arm/mach-exynos/include/mach/regs-mem.h"
BR,
>
> 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
>
--
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: S3C64XX: Implement basic power domain support
Hi Mark,
I'm not sure what's the next step at s3c64xx for generic power domain.
Related with exysno4 series, it's helpful to read following threads.
http://68.183.106.108/lists/linux-pm/msg26291.html
"I don't think we should control/gate the clocks with regarding power
domain" from Mr. Kim
Thank you,
Kyungmin Park
On 12/2/11, Mark Brown wrote:
> The S3C64xx SoCs contain a set of gateable power domains which can be
> enabled and disabled at runtime in order to save power. Use the generic
> power domain code to implement support for these in software, enabling
> runtime control of most domains:
>
> - ETM (not supported in mainline).
> - Domain G: 3D acceleration (no mainline support).
> - Domain V: MFC (no mainline support).
> - Domain I: JPEG and camera interface (no mainline support).
> - Domain P: 2D acceleration, TV encoder and scaler (no mainline support)
> - Domain S: Security (no mainline support).
> - Domain F: LCD (driver already uses runtime PM), post processing and
>rotation (no mainline support).
>
> The IROM domain is marked as always enabled as we should arrange for it
> to be enabled when we suspend which will need a bit more work.
>
> Due to all the conditional device registration that the platform does
> wrap s3c_pm_init() with s3c64xx_pm_init() which actually puts the device
> into the power domain after the machines have registered, looking for
> platform data to tell if the device was registered. Since currently only
> Cragganmore actually sets up PM that is the only machine updated.
>
> Signed-off-by: Mark Brown
> ---
>
> Kikjin, this superceeds my previous patch unconditionally disabling some
> of the domains. I've given it quite a bit of testing and it appears to
> be working well on my systems though I'm not sure the power saving is
> really all that much to write home about.
>
> arch/arm/mach-s3c64xx/Kconfig |1 +
> arch/arm/mach-s3c64xx/mach-crag6410.c |2 +-
> arch/arm/mach-s3c64xx/pm.c | 173
> ++-
> arch/arm/plat-samsung/include/plat/pm.h |6 +
> 4 files changed, 179 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
> index 4d8c489..5c6c22e 100644
> --- a/arch/arm/mach-s3c64xx/Kconfig
> +++ b/arch/arm/mach-s3c64xx/Kconfig
> @@ -8,6 +8,7 @@ config PLAT_S3C64XX
> bool
> depends on ARCH_S3C64XX
> select SAMSUNG_WAKEMASK
> + select PM_GENERIC_DOMAINS
> default y
> help
> Base platform code for any Samsung S3C64XX device
> diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c
> b/arch/arm/mach-s3c64xx/mach-crag6410.c
> index 98d42b3..4ce4a74 100644
> --- a/arch/arm/mach-s3c64xx/mach-crag6410.c
> +++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
> @@ -743,7 +743,7 @@ static void __init crag6410_machine_init(void)
>
> regulator_has_full_constraints();
>
> - s3c_pm_init();
> + s3c64xx_pm_init();
> }
>
> MACHINE_START(WLF_CRAGG_6410, "Wolfson Cragganmore 6410")
> diff --git a/arch/arm/mach-s3c64xx/pm.c b/arch/arm/mach-s3c64xx/pm.c
> index b375cd5..aa7b5d1 100644
> --- a/arch/arm/mach-s3c64xx/pm.c
> +++ b/arch/arm/mach-s3c64xx/pm.c
> @@ -17,10 +17,12 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
>
> +#include
> #include
> #include
>
> @@ -31,6 +33,145 @@
> #include
> #include
>
> +struct s3c64xx_pm_domain {
> + char *const name;
> + u32 ena;
> + u32 pwr_stat;
> + struct generic_pm_domain pd;
> +};
> +
> +static int s3c64xx_pd_off(struct generic_pm_domain *domain)
> +{
> + struct s3c64xx_pm_domain *pd;
> + u32 val;
> +
> + pd = container_of(domain, struct s3c64xx_pm_domain, pd);
> +
> + val = __raw_readl(S3C64XX_NORMAL_CFG);
> + val &= ~(pd->ena);
> + __raw_writel(val, S3C64XX_NORMAL_CFG);
> +
> + return 0;
> +}
> +
> +static int s3c64xx_pd_on(struct generic_pm_domain *domain)
> +{
> + struct s3c64xx_pm_domain *pd;
> + u32 val;
> + long retry = 100L;
> +
> + pd = container_of(domain, struct s3c64xx_pm_domain, pd);
> +
> + val = __raw_readl(S3C64XX_NORMAL_CFG);
> + val |= pd->ena;
> + __raw_writel(val, S3C64XX_NORMAL_CFG);
> +
> + /* Not all domains provide power status readback */
> + if (pd->pwr_stat) {
> + while (retry--)
> + if (__raw_readl(S3C64XX_BLK_PWR_STAT) & pd->pwr_stat)
> + break;
> + if (!retry) {
> + pr_err("Failed to
Re: [GIT PULL] Samsung fixes for v3.2
Hi, Don't you fix the mct compiler error if LOCAL_TIMERS are not defined? arch/arm/mach-exynos/mct.c: In function 'exynos4_timer_resources': arch/arm/mach-exynos/mct.c:451: error: 'exynos4_mct_tick_isr' undeclared (first use in this function) arch/arm/mach-exynos/mct.c:451: error: (Each undeclared identifier is reported only once arch/arm/mach-exynos/mct.c:451: error: for each function it appears in.) make[1]: *** [arch/arm/mach-exynos/mct.o] Error 1 Thank you, Kyungmin Park On 11/21/11, Kukjin Kim wrote: > Hi Arnd, > > Please pull samsung-fixes for v3.2 from: > > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > samsung-fixes > > This includes fix of inclusion header. > If any problems, please let me know. > > Thanks. > > Best regards, > Kgene. > -- > Kukjin Kim , Senior Engineer, > SW Solution Development Team, Samsung Electronics Co., Ltd. > > The following changes since commit 1ea6b8f48918282bdca0b32a34095504ee65bab5: > > Linux 3.2-rc1 (2011-11-07 16:16:02 -0800) > > are available in the git repository at: > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > samsung-fixes > > Axel Lin (1): > ARM: SAMSUNG: include linux/types.h at gpio-cfg.h > > Kukjin Kim (2): > ARM: S5P: Fix export.h inclusion > ARM: SAMSUNG: inclusion export.h instead of module.h > > Kyungmin Park (1): > ARM: EXYNOS: Fix compiler error with THIS_MODULE > > arch/arm/mach-exynos/cpuidle.c|2 ++ > arch/arm/mach-s3c64xx/mach-crag6410-module.c |2 +- > arch/arm/plat-s3c24xx/cpu-freq-debugfs.c |2 +- > arch/arm/plat-s5p/sysmmu.c|1 + > arch/arm/plat-samsung/include/plat/gpio-cfg.h |2 ++ > arch/arm/plat-samsung/pd.c|2 +- > arch/arm/plat-samsung/pwm.c |2 +- > 7 files changed, 9 insertions(+), 4 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 > -- 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: [linux-pm] [PATCH 1/3 v3] ARM: EXYNOS4: Support for generic I/O power domains on EXYNOS4210/4212
On 11/15/11, Kukjin Kim wrote: > Chanwoo Choi wrote: >> Hi Kukjin Kim, >> >> Please reply about Sylwester Nawrocki and me. >> 2011/11/3 Sylwester Nawrocki >> Hi Kgene, >> >> On 11/03/2011 03:09 AM, Kukjin Kim wrote: >> > As I said, I don't think we should control/gate the clocks with > regarding power domain. >> As far as I know there is a plan to let the drivers override > start/stop_device callbacks, >> moreover the clock control can be disabled globally by not implementing > start/stop_device >> callbacks or per device by not adding clkdev entities to the device clock > list at runtime >> PM core. So IMHO, there is/going to be enough flexibility. >> >> > It should be controlled by each regarding device driver and in addition, > as I know, >> > to handle block of clock is not recommended on EXYNOS4 now. >> What do you mean by this ? I couldn't find such information in any > documentation. >> Shouldn't "clock gate block" registers be touched by boot loader and the > kernel? >> Our boot loaders disable all clocks, and if the global clock gate is not > enabled >> by the kernel there is no chance any multimedia device will work. >> >> Should the global clock block gate be always enabled then ? I'm afraid it > is not >> optimal form power management POV. >> > Sylwester, let me check again before replying. > >> To Kukjin Kim, >> > Hi Chanwoo, > > Firstly, please use text-typed e-mail when you reply. > >> > It should be controlled by each regarding device driver and in addition, > as I know, >> > to handle block of clock is not recommended on EXYNOS4 now. >> >> As you said, should we separately control power and clock of power domain? > > If you ask my opinion, yes, I mean when it is required, it would be > controlled independent. Okay. It's meaning-less, Until change his mind, just drop it. I hope you don't change this mind for long time. Thank you, Kyungmin Park > >> or Have to turn on the clock of power domain always? > > I didn't say like that. > >> I think that it is to happen unnecessary power consumption. > > I don't think, when the power of block/domain is downed, does it happen > _really_ meaningful power consumption? > >> If we have to maintain on state of power domain clock, please let me know > guide about this. >> >> Also, >> For example, fimg2d and framebuffer use LCD0 power domain as parent > device.I >> If fimg2d and framebuffer is disabled state due to not using their, >> I think that we should turn off the clock of LCD0 power domain to reduce > power leakage. > > I think, probably it doesn't matter. If any useful data, please let me know. > >> Which each regarding device driver control the clock of power domain? >> >> I will expect for your reply. >> > > 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/2] iommu/exynos: Add iommu driver for Exynos Platforms
On 11/15/11, KyongHo Cho wrote:
> This is the System MMU driver and IOMMU API implementation for
> Exynos SOC platforms. Exynos platforms has more than 10 System
> MMUs dedicated for each multimedia accellerators.
>
> The System MMU driver is already in arc/arm/plat-s5p but it is
> moved to drivers/iommu due to Ohad Ben-Cohen gathered IOMMU drivers
> there
>
> This patch also includes fault handling feature in IOMMU driver
> suggested by Ohad.
> Users of IOMMU API can register its own fault handler with
> iommu_set_fault_handler() and the handler is called by IRQ handler
> of System MMU.
> If no user installs fault handler, IOMMU driver prints debugging
> message and generates kernel oops.
>
> This IOMMU driver calls bus_set_iommu() instead of register_iommu()
> since Joerg suggested that installing iommu_ops in bus_type.
>
> Cc: Joerg Roedel
> Cc: Ohad Ben-Cohen
> Cc: Sylwester Nawrocki
> Cc: Russell King
> Signed-off-by: KyongHo Cho
> ---
> arch/arm/plat-s5p/Kconfig |8 -
> arch/arm/plat-s5p/Makefile |1 -
> arch/arm/plat-s5p/sysmmu.c | 312
> arch/arm/plat-samsung/include/plat/sysmmu.h | 95 ---
> drivers/iommu/Kconfig | 12 +
> drivers/iommu/Makefile |1 +
> drivers/iommu/exynos-iommu.c| 1035
> +++
> 7 files changed, 1048 insertions(+), 416 deletions(-)
> delete mode 100644 arch/arm/plat-s5p/sysmmu.c
> delete mode 100644 arch/arm/plat-samsung/include/plat/sysmmu.h
> create mode 100644 drivers/iommu/exynos-iommu.c
>
> diff --git a/arch/arm/plat-s5p/Kconfig b/arch/arm/plat-s5p/Kconfig
> index 9b9968f..805b979 100644
> --- a/arch/arm/plat-s5p/Kconfig
> +++ b/arch/arm/plat-s5p/Kconfig
> @@ -45,14 +45,6 @@ config S5P_PM
> Common code for power management support on S5P and newer SoCs
> Note: Do not select this for S5P6440 and S5P6450.
>
> -comment "System MMU"
> -
> -config S5P_SYSTEM_MMU
> - bool "S5P SYSTEM MMU"
> - depends on ARCH_EXYNOS4
> - help
> - Say Y here if you want to enable System MMU
> -
> config S5P_SLEEP
> bool
> help
> diff --git a/arch/arm/plat-s5p/Makefile b/arch/arm/plat-s5p/Makefile
> index 8763440..0757ce0 100644
> --- a/arch/arm/plat-s5p/Makefile
> +++ b/arch/arm/plat-s5p/Makefile
> @@ -18,7 +18,6 @@ obj-y += clock.o
> obj-y+= irq.o
> obj-$(CONFIG_S5P_EXT_INT)+= irq-eint.o
> obj-$(CONFIG_S5P_GPIO_INT) += irq-gpioint.o
> -obj-$(CONFIG_S5P_SYSTEM_MMU) += sysmmu.o
> obj-$(CONFIG_S5P_PM) += pm.o irq-pm.o
> obj-$(CONFIG_S5P_SLEEP) += sleep.o
> obj-$(CONFIG_S5P_HRT)+= s5p-time.o
> diff --git a/arch/arm/plat-s5p/sysmmu.c b/arch/arm/plat-s5p/sysmmu.c
> deleted file mode 100644
> index e1cbc72..000
> --- a/arch/arm/plat-s5p/sysmmu.c
> +++ /dev/null
> @@ -1,312 +0,0 @@
> -/* linux/arch/arm/plat-s5p/sysmmu.c
> - *
> - * Copyright (c) 2010 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
> -
> -#define CTRL_ENABLE 0x5
> -#define CTRL_BLOCK 0x7
> -#define CTRL_DISABLE 0x0
> -
> -static struct device *dev;
> -
> -static unsigned short fault_reg_offset[SYSMMU_FAULTS_NUM] = {
> - S5P_PAGE_FAULT_ADDR,
> - S5P_AR_FAULT_ADDR,
> - S5P_AW_FAULT_ADDR,
> - S5P_DEFAULT_SLAVE_ADDR,
> - S5P_AR_FAULT_ADDR,
> - S5P_AR_FAULT_ADDR,
> - S5P_AW_FAULT_ADDR,
> - S5P_AW_FAULT_ADDR
> -};
> -
> -static char *sysmmu_fault_name[SYSMMU_FAULTS_NUM] = {
> - "PAGE FAULT",
> - "AR MULTI-HIT FAULT",
> - "AW MULTI-HIT FAULT",
> - "BUS ERROR",
> - "AR SECURITY PROTECTION FAULT",
> - "AR ACCESS PROTECTION FAULT",
> - "AW SECURITY PROTECTION FAULT",
> - "AW ACCESS PROTECTION FAULT"
> -};
> -
> -static int (*fault_handlers[S5P_SYSMMU_TOTAL_IPNUM])(
> - enum S5P_SYSMMU_INTERRUPT_TYPE itype,
> - unsigned long pgtable_base,
> - unsigned long fault_addr);
> -
> -/*
> - * If adjacent 2 bits are true, the system MMU is enabled.
> - * The system MMU is disabled, otherwise.
> - */
> -static unsigned long sysmmu_states;
> -
> -static inline void set_sysmmu_active(sysmmu_ips ips)
> -{
> - sysmmu_states |= 3 << (ips * 2);
> -}
> -
> -static inline void set_sysmmu_inactive(sysmmu_ips ips)
> -{
> - sysmmu_states &= ~(3 << (ips * 2));
> -}
> -
> -static inline int is_sysmmu_active(sysmmu_ips ips)
> -{
> - return sysmmu_states & (3 << (ips * 2));
> -}
> -
> -static void __iomem *sysmmusfrs[S5P_SYSMMU_TOTAL_IPNUM];
> -
> -static inline void sysmmu_block(sysmmu_ips ips)
> -{
> - _
Re: [PATCH v6 1/2] ARM: EXYNOS: Change System MMU platform device definitions
mp;exynos4_device_pd[PD_TV].dev);
> +
> + sysmmu_set_owner(&SYSMMU_PLATDEV(fimc0).dev, &s5p_device_fimc0.dev);
> + sysmmu_set_owner(&SYSMMU_PLATDEV(fimc1).dev, &s5p_device_fimc1.dev);
> + sysmmu_set_owner(&SYSMMU_PLATDEV(fimc2).dev, &s5p_device_fimc2.dev);
> + sysmmu_set_owner(&SYSMMU_PLATDEV(fimc3).dev, &s5p_device_fimc3.dev);
> + sysmmu_set_owner(&SYSMMU_PLATDEV(mfc_l).dev, &s5p_device_mfc.dev);
> + sysmmu_set_owner(&SYSMMU_PLATDEV(mfc_r).dev, &s5p_device_mfc.dev);
> + sysmmu_set_owner(&SYSMMU_PLATDEV(fimd0).dev, &s5p_device_fimd0.dev);
> + sysmmu_set_owner(&SYSMMU_PLATDEV(tv).dev, &s5p_device_mixer.dev);
> +}
> +
> static void __init smdkv310_machine_init(void)
> {
> s3c_i2c1_set_platdata(NULL);
> @@ -365,6 +404,8 @@ static void __init smdkv310_machine_init(void)
> smdkv310_ehci_init();
> clk_xusbxti.rate = 2400;
>
> + sysmmu_init();
> +
> platform_add_devices(smdkv310_devices, ARRAY_SIZE(smdkv310_devices));
> s5p_device_mfc.dev.parent = &exynos4_device_pd[PD_MFC].dev;
> }
> diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
> b/arch/arm/mach-exynos/mach-universal_c210.c
> index a2a177f..b30be39 100644
> --- a/arch/arm/mach-exynos/mach-universal_c210.c
> +++ b/arch/arm/mach-exynos/mach-universal_c210.c
> @@ -42,6 +42,7 @@
> #include
>
> #include
> +#include
>
> #include
> #include
> @@ -988,6 +989,21 @@ static struct platform_device *universal_devices[]
> __initdata = {
> &cam_i_core_fixed_reg_dev,
> &cam_s_if_fixed_reg_dev,
> &s5p_device_fimc_md,
> + &SYSMMU_PLATDEV(sss),
> + &SYSMMU_PLATDEV(jpeg),
> + &SYSMMU_PLATDEV(fimd1),
> + &SYSMMU_PLATDEV(2d),
> + &SYSMMU_PLATDEV(rot),
> + &SYSMMU_PLATDEV(mdma),
> + &SYSMMU_PLATDEV(tv),
> + &SYSMMU_PLATDEV(mfc_l),
> + &SYSMMU_PLATDEV(mfc_r),
> + &SYSMMU_PLATDEV(fimc0),
> + &SYSMMU_PLATDEV(fimc1),
> + &SYSMMU_PLATDEV(fimc2),
> + &SYSMMU_PLATDEV(fimc3),
> + &SYSMMU_PLATDEV(fimd0),
> + &SYSMMU_PLATDEV(pcie),
Platform device is optional for each board and pcie doesn't used at
mobile board. Does it require to register all platform devices at
board?
> };
>
> static void __init universal_map_io(void)
> @@ -1016,6 +1032,30 @@ static void __init universal_reserve(void)
> s5p_mfc_reserve_mem(0x4300, 8 << 20, 0x5100, 8 << 20);
> }
>
> +static void __init sysmmu_init(void)
> +{
> + ASSIGN_SYSMMU_POWERDOMAIN(fimc0, &exynos4_device_pd[PD_CAM].dev);
> + ASSIGN_SYSMMU_POWERDOMAIN(fimc1, &exynos4_device_pd[PD_CAM].dev);
> + ASSIGN_SYSMMU_POWERDOMAIN(fimc2, &exynos4_device_pd[PD_CAM].dev);
> + ASSIGN_SYSMMU_POWERDOMAIN(fimc3, &exynos4_device_pd[PD_CAM].dev);
> + ASSIGN_SYSMMU_POWERDOMAIN(jpeg, &exynos4_device_pd[PD_CAM].dev);
> + ASSIGN_SYSMMU_POWERDOMAIN(mfc_l, &exynos4_device_pd[PD_MFC].dev);
> + ASSIGN_SYSMMU_POWERDOMAIN(mfc_r, &exynos4_device_pd[PD_MFC].dev);
> + ASSIGN_SYSMMU_POWERDOMAIN(fimd0, &exynos4_device_pd[PD_LCD0].dev);
> + ASSIGN_SYSMMU_POWERDOMAIN(rot, &exynos4_device_pd[PD_LCD0].dev);
> + ASSIGN_SYSMMU_POWERDOMAIN(mdma, &exynos4_device_pd[PD_LCD0].dev);
> + ASSIGN_SYSMMU_POWERDOMAIN(tv, &exynos4_device_pd[PD_TV].dev);
> +
> + sysmmu_set_owner(&SYSMMU_PLATDEV(fimc0).dev, &s5p_device_fimc0.dev);
> + sysmmu_set_owner(&SYSMMU_PLATDEV(fimc1).dev, &s5p_device_fimc1.dev);
> + sysmmu_set_owner(&SYSMMU_PLATDEV(fimc2).dev, &s5p_device_fimc2.dev);
> + sysmmu_set_owner(&SYSMMU_PLATDEV(fimc3).dev, &s5p_device_fimc3.dev);
> + sysmmu_set_owner(&SYSMMU_PLATDEV(mfc_l).dev, &s5p_device_mfc.dev);
> + sysmmu_set_owner(&SYSMMU_PLATDEV(mfc_r).dev, &s5p_device_mfc.dev);
> + sysmmu_set_owner(&SYSMMU_PLATDEV(fimd0).dev, &s5p_device_fimd0.dev);
> + sysmmu_set_owner(&SYSMMU_PLATDEV(tv).dev, &s5p_device_mixer.dev);
> +}
> +
> static void __init universal_machine_init(void)
> {
> universal_sdhci_init();
> @@ -1040,6 +1080,8 @@ static void __init universal_machine_init(void)
>
> universal_camera_init();
>
> + sysmmu_init();
I think how do you implement the sysmm_init at cpu or common file? and
board select it to use iommu or not. no need to implement the almost
same codes at each board.
Otherwise looks good.
Thank you,
Kyungmin Park
> +
> /* Last */
> platform_add_devices(universal_devices, ARRAY_SIZE(universal_devices));
>
> diff --git a/arch/arm/plat-samsung/include/plat/devs.h
> b/arch/arm/plat-samsung/include/plat/devs.h
> index ab633c9..57c2636 100644
> --- a/arch/arm/plat-samsung/include/plat/devs.h
> +++ b/arch/arm/plat-samsung/include/plat/devs.h
> @@ -134,7 +134,6 @@ extern struct platform_device exynos4_device_pcm1;
> extern struct platform_device exynos4_device_pcm2;
> extern struct platform_device exynos4_device_pd[];
> extern struct platform_device exynos4_device_spdif;
> -extern struct platform_device exynos4_device_sysmmu;
>
> extern struct platform_device samsung_asoc_dma;
> extern struct platform_device samsung_asoc_idma;
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: EXYNOS4: Enable write full line for zeros mode
Hi,
On 11/4/11, Boojin Kim wrote:
> This patch enables the 'write full line for zeros mode' feature of
> cortex-A9.
> The performance of memset() with zero is increased about 10% with this
> patch.
It seems CA9 common parts, does other SoC require same feature?
>
> Signed-off-by: Boojin Kim
> ---
> arch/arm/mach-exynos4/platsmp.c | 18 ++
> 1 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/platsmp.c
> b/arch/arm/mach-exynos4/platsmp.c
> index d5f0f29..edf7054 100644
> --- a/arch/arm/mach-exynos4/platsmp.c
> +++ b/arch/arm/mach-exynos4/platsmp.c
> @@ -90,6 +90,16 @@ static void __cpuinit exynos4_gic_secondary_init(void)
> __raw_writel(1, cpu_base + GIC_CPU_CTRL);
> }
>
> +static void enable_foz(void)
> +{
> + u32 val;
> + asm volatile(
> + "mrc p15, 0, %0, c1, c0, 1\n"
> + "orr %0, %0, #(1 << 3)\n"
> + "mcr p15, 0, %0, c1, c0, 1"
> + : "=r" (val));
> +}
> +
> void __cpuinit platform_secondary_init(unsigned int cpu)
> {
> /*
> @@ -106,6 +116,14 @@ void __cpuinit platform_secondary_init(unsigned int
> cpu)
> write_pen_release(-1);
>
> /*
> + * Enable write full line for zeros mode
> + */
> + if (soc_is_exynos4210() | soc_is_exynos4212() | soc_is_exynos4412()) {
Now CA15 is not ready so this if statement is meaningless.
> + enable_foz();
> + smp_call_function((void (*)(void *))enable_foz, NULL, 0);
> + }
> +
> + /*
>* Synchronise with the boot thread.
>*/
> spin_lock(&boot_lock);
Thank you,
Kyungmin Park
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: SAMSUNG: Add clk enable/disable of pwm
On 11/3/11, Kukjin Kim wrote:
> Kyungmin Park wrote:
>>
>> On 11/3/11, Kyungmin Park wrote:
>> > On 11/3/11, Joonyoung Shim wrote:
>> >> 11/03/2011 04:46 PM, Kukjin Kim 쓴 글:
>> >>> Joonyoung Shim wrote:
>> >>>> 11/03/2011 10:59 AM, Kukjin Kim 쓴 글:
>> >>>>> Joonyoung Shim wrote:
>> >>>>>> PWM timers use pclk("timers" clk) as parent clk. If this pclk is
>> >>>>>> the
>> >>>>>> disabled state when PWM driver is probed, then it causes wrong read
>> >>>>>> and
>> >>>>>> write operation about registers of PWM.
>> >>>>>>
>> >>>>>> Signed-off-by: Joonyoung Shim
>> >>>>>> Signed-off-by: Kyungmin Park
>> >>>>>> ---
>> >>>>>>arch/arm/plat-samsung/pwm.c |7 +++
>> >>>>>>1 files changed, 7 insertions(+), 0 deletions(-)
>> >>>>>>
>> >>>>>> diff --git a/arch/arm/plat-samsung/pwm.c
>> >>>>>> b/arch/arm/plat-samsung/pwm.c
>> >>>>>> index f37457c..dc1185d 100644
>> >>>>>> --- a/arch/arm/plat-samsung/pwm.c
>> >>>>>> +++ b/arch/arm/plat-samsung/pwm.c
>> >>>>>> @@ -299,6 +299,9 @@ static int s3c_pwm_probe(struct platform_device
>> >>>>>> *pdev)
>> >>>>>> goto err_clk_tin;
>> >>>>>> }
>> >>>>>>
>> >>>>>> + clk_enable(pwm->clk);
>> >>>>>> + clk_enable(pwm->clk_div);
>> >>>>>> +
>> >>>>>> local_irq_save(flags);
>> >>>>>>
>> >>>>>> tcon = __raw_readl(S3C2410_TCON);
>> >>>>>> @@ -326,6 +329,8 @@ static int s3c_pwm_probe(struct platform_device
>> >>>>>> *pdev)
>> >>>>>> return 0;
>> >>>>>>
>> >>>>>> err_clk_tdiv:
>> >>>>>> + clk_disable(pwm->clk_div);
>> >>>>>> + clk_disable(pwm->clk);
>> >>>>>> clk_put(pwm->clk_div);
>> >>>>>>
>> >>>>>> err_clk_tin:
>> >>>>>> @@ -340,6 +345,8 @@ static int __devexit s3c_pwm_remove(struct
>> >>>>>> platform_device *pdev)
>> >>>>>>{
>> >>>>>> struct pwm_device *pwm = platform_get_drvdata(pdev);
>> >>>>>>
>> >>>>>> + clk_disable(pwm->clk_div);
>> >>>>>> + clk_disable(pwm->clk);
>> >>>>>> clk_put(pwm->clk_div);
>> >>>>>> clk_put(pwm->clk);
>> >>>>>> kfree(pwm);
>> >>>>>> --
>> >>>>>> 1.7.5.4
>> >>>>> Well, I wonder when this is needed. I think it should be enabled
>> >>>>> during
>> >>>>> kernel booting...
>> >>>> The exynos4 machine using just timer turns on "timer" clock in the
>> >>>> past,
>> >>>> but "timer" clock is disable state when boot since MCT is used. MCT
>> >>>> doesn't control "timer" clock.
>> >>>>
>> >>>> I think pwm driver should control(enable/disable) using clocks
>> >>>> regardless of their parents clock.
>> >>>>
>> >>> I mean, why that is disabled when kernel boot...
>> >>>
>> >>
>> >> Please see arch/arm/mach-exynos4/clock.c
>> >> There is "timers' clock in the clk init_clocks_off[].
>> One more, Don't assume some clocks are enabled at bootloader. user can
>> use any bootloader and any configuration.
>>
> Kyungmin,
> NO! I didn't. Just I thought your bootloader disables the clock and why it
> is needed.
As you don't unaware the power consumption. you don't care the clock gating.
You think this clock disable is meaningless but the basic idea of PM
is disable the clock and power domain and use it only enable during
use
See your team product kernel codes. why they are register the unused
clock at there and implement the clock gating and runtime pm not at
mainline.
>
> Anyway, Joonyoung,
&
Re: [PATCH] ARM: SAMSUNG: Add clk enable/disable of pwm
On 11/3/11, Kyungmin Park wrote:
> On 11/3/11, Joonyoung Shim wrote:
>> 11/03/2011 04:46 PM, Kukjin Kim 쓴 글:
>>> Joonyoung Shim wrote:
>>>> 11/03/2011 10:59 AM, Kukjin Kim 쓴 글:
>>>>> Joonyoung Shim wrote:
>>>>>> PWM timers use pclk("timers" clk) as parent clk. If this pclk is the
>>>>>> disabled state when PWM driver is probed, then it causes wrong read
>>>>>> and
>>>>>> write operation about registers of PWM.
>>>>>>
>>>>>> Signed-off-by: Joonyoung Shim
>>>>>> Signed-off-by: Kyungmin Park
>>>>>> ---
>>>>>>arch/arm/plat-samsung/pwm.c |7 +++
>>>>>>1 files changed, 7 insertions(+), 0 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm/plat-samsung/pwm.c
>>>>>> b/arch/arm/plat-samsung/pwm.c
>>>>>> index f37457c..dc1185d 100644
>>>>>> --- a/arch/arm/plat-samsung/pwm.c
>>>>>> +++ b/arch/arm/plat-samsung/pwm.c
>>>>>> @@ -299,6 +299,9 @@ static int s3c_pwm_probe(struct platform_device
>>>>>> *pdev)
>>>>>> goto err_clk_tin;
>>>>>> }
>>>>>>
>>>>>> +clk_enable(pwm->clk);
>>>>>> +clk_enable(pwm->clk_div);
>>>>>> +
>>>>>> local_irq_save(flags);
>>>>>>
>>>>>> tcon = __raw_readl(S3C2410_TCON);
>>>>>> @@ -326,6 +329,8 @@ static int s3c_pwm_probe(struct platform_device
>>>>>> *pdev)
>>>>>> return 0;
>>>>>>
>>>>>> err_clk_tdiv:
>>>>>> +clk_disable(pwm->clk_div);
>>>>>> +clk_disable(pwm->clk);
>>>>>> clk_put(pwm->clk_div);
>>>>>>
>>>>>> err_clk_tin:
>>>>>> @@ -340,6 +345,8 @@ static int __devexit s3c_pwm_remove(struct
>>>>>> platform_device *pdev)
>>>>>>{
>>>>>> struct pwm_device *pwm = platform_get_drvdata(pdev);
>>>>>>
>>>>>> +clk_disable(pwm->clk_div);
>>>>>> +clk_disable(pwm->clk);
>>>>>> clk_put(pwm->clk_div);
>>>>>> clk_put(pwm->clk);
>>>>>> kfree(pwm);
>>>>>> --
>>>>>> 1.7.5.4
>>>>> Well, I wonder when this is needed. I think it should be enabled
>>>>> during
>>>>> kernel booting...
>>>> The exynos4 machine using just timer turns on "timer" clock in the
>>>> past,
>>>> but "timer" clock is disable state when boot since MCT is used. MCT
>>>> doesn't control "timer" clock.
>>>>
>>>> I think pwm driver should control(enable/disable) using clocks
>>>> regardless of their parents clock.
>>>>
>>> I mean, why that is disabled when kernel boot...
>>>
>>
>> Please see arch/arm/mach-exynos4/clock.c
>> There is "timers' clock in the clk init_clocks_off[].
One more, Don't assume some clocks are enabled at bootloader. user can
use any bootloader and any configuration.
Thanks.
>>
>> Thanks.
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-samsung-soc"
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: SAMSUNG: Add clk enable/disable of pwm
On 11/3/11, Joonyoung Shim wrote:
> 11/03/2011 04:46 PM, Kukjin Kim 쓴 글:
>> Joonyoung Shim wrote:
>>> 11/03/2011 10:59 AM, Kukjin Kim 쓴 글:
>>>> Joonyoung Shim wrote:
>>>>> PWM timers use pclk("timers" clk) as parent clk. If this pclk is the
>>>>> disabled state when PWM driver is probed, then it causes wrong read and
>>>>> write operation about registers of PWM.
>>>>>
>>>>> Signed-off-by: Joonyoung Shim
>>>>> Signed-off-by: Kyungmin Park
>>>>> ---
>>>>>arch/arm/plat-samsung/pwm.c |7 +++
>>>>>1 files changed, 7 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/plat-samsung/pwm.c b/arch/arm/plat-samsung/pwm.c
>>>>> index f37457c..dc1185d 100644
>>>>> --- a/arch/arm/plat-samsung/pwm.c
>>>>> +++ b/arch/arm/plat-samsung/pwm.c
>>>>> @@ -299,6 +299,9 @@ static int s3c_pwm_probe(struct platform_device
>>>>> *pdev)
>>>>> goto err_clk_tin;
>>>>> }
>>>>>
>>>>> + clk_enable(pwm->clk);
>>>>> + clk_enable(pwm->clk_div);
>>>>> +
>>>>> local_irq_save(flags);
>>>>>
>>>>> tcon = __raw_readl(S3C2410_TCON);
>>>>> @@ -326,6 +329,8 @@ static int s3c_pwm_probe(struct platform_device
>>>>> *pdev)
>>>>> return 0;
>>>>>
>>>>> err_clk_tdiv:
>>>>> + clk_disable(pwm->clk_div);
>>>>> + clk_disable(pwm->clk);
>>>>> clk_put(pwm->clk_div);
>>>>>
>>>>> err_clk_tin:
>>>>> @@ -340,6 +345,8 @@ static int __devexit s3c_pwm_remove(struct
>>>>> platform_device *pdev)
>>>>>{
>>>>> struct pwm_device *pwm = platform_get_drvdata(pdev);
>>>>>
>>>>> + clk_disable(pwm->clk_div);
>>>>> + clk_disable(pwm->clk);
>>>>> clk_put(pwm->clk_div);
>>>>> clk_put(pwm->clk);
>>>>> kfree(pwm);
>>>>> --
>>>>> 1.7.5.4
>>>> Well, I wonder when this is needed. I think it should be enabled during
>>>> kernel booting...
>>> The exynos4 machine using just timer turns on "timer" clock in the past,
>>> but "timer" clock is disable state when boot since MCT is used. MCT
>>> doesn't control "timer" clock.
>>>
>>> I think pwm driver should control(enable/disable) using clocks
>>> regardless of their parents clock.
>>>
>> I mean, why that is disabled when kernel boot...
>>
>
> Please see arch/arm/mach-exynos4/clock.c
> There is "timers' clock in the clk init_clocks_off[].
>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Samsung: gpio-interrupts: fix offset calculation
Hi Kukjin and Arnd, If there's chance to merge for 3.1 bugfix. It's required to run 2nd GPIO banks for exynos4210. and it should be applied for stable tree also. Thank you, Kyungmin Park On Tue, Oct 18, 2011 at 7:16 PM, Marek Szyprowski wrote: > Offsets of the irq controller registers were calculated correctly only > for first GPIO bank. This patch fixes calculation of the register > offsets for all GPIO banks. > > Reported-by: Sylwester Nawrocki > Signed-off-by: Marek Szyprowski > Signed-off-by: Kyungmin Park > --- > arch/arm/plat-s5p/irq-gpioint.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/plat-s5p/irq-gpioint.c b/arch/arm/plat-s5p/irq-gpioint.c > index a566523..1fdfaa4 100644 > --- a/arch/arm/plat-s5p/irq-gpioint.c > +++ b/arch/arm/plat-s5p/irq-gpioint.c > @@ -163,9 +163,9 @@ static __init int s5p_gpioint_add(struct > samsung_gpio_chip *chip) > ct->chip.irq_mask = irq_gc_mask_set_bit; > ct->chip.irq_unmask = irq_gc_mask_clr_bit; > ct->chip.irq_set_type = s5p_gpioint_set_type, > - ct->regs.ack = PEND_OFFSET + REG_OFFSET(chip->group); > - ct->regs.mask = MASK_OFFSET + REG_OFFSET(chip->group); > - ct->regs.type = CON_OFFSET + REG_OFFSET(chip->group); > + ct->regs.ack = PEND_OFFSET + REG_OFFSET(group - bank->start); > + ct->regs.mask = MASK_OFFSET + REG_OFFSET(group - bank->start); > + ct->regs.type = CON_OFFSET + REG_OFFSET(group - bank->start); > irq_setup_generic_chip(gc, IRQ_MSK(chip->chip.ngpio), > IRQ_GC_INIT_MASK_CACHE, > IRQ_NOREQUEST | IRQ_NOPROBE, 0); > -- > 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Samsung board-2 for v3.2
Hi,
As you decide to rename the mach name, how to change the board name together?
Historically samsung use the "mach-" prefix for board name, but others
are use the "board-" prefix.
So let's use the same convention as others?
How do you think?
Thank you,
Kyungmin Park
On Tue, Oct 4, 2011 at 10:21 PM, Kukjin Kim wrote:
> Hi Arnd,
>
> This is a second Samsung board stuff for v3.2 and includes new board,
> SMDK4412.
>
> Please pull from:
> git://github.com/kgene/linux-samsung.git next-samsung-board-2
>
> As a note, since supporting SMDK4412 needs previous next-samsung-board
> branch so this is based on next-samsung-board which has been already merged
> into arm-soc and this includes converting boot_params to atag_offset for
> adding/changing boards in this time.
>
> If any problems, please let me know.
>
> One more as a note, the next-samsung-devel and next-samsung-devel-2 will be
> sent to you soon after testing ;)
>
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim , Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
> The following changes since commit 2520123382e97271e932377c83bca010c265be55:
>
> Merge branch 'next-samsung-board-v3.1' into next-samsung-board (2011-09-16
> 17:13:09 +0900)
>
> are available in the git repository at:
>
> git://github.com/kgene/linux-samsung.git next-samsung-board-2
>
> Changhwan Youn (7):
> ARM: EXYNOS4: Add support PPI in external GIC
> ARM: EXYNOS4: Add support MCT PPI for EXYNOS4212
> ARM: EXYNOS4: Add support new EXYNOS4412 SoC
> ARM: EXYNOS4: Add support clock for EXYNOS4412
> ARM: EXYNOS4: Add functions for gic interrupt handling
> ARM: EXYNOS4: Add MCT support for EXYNOS4412
> ARM: EXYNOS4: Add support SMDK4412 Board
>
> Tushar Behera (1):
> ARM: EXYNOS4: convert boot_params to atag_offset
>
> arch/arm/mach-exynos4/Kconfig | 14 ++
> arch/arm/mach-exynos4/Makefile | 3 +-
> arch/arm/mach-exynos4/clock.c | 4 +-
> arch/arm/mach-exynos4/cpu.c | 21 ++-
> arch/arm/mach-exynos4/include/mach/entry-macro.S | 29 +++-
> arch/arm/mach-exynos4/include/mach/irqs.h | 2 +
> arch/arm/mach-exynos4/include/mach/map.h | 1 -
> arch/arm/mach-exynos4/include/mach/regs-mct.h | 5 +-
> arch/arm/mach-exynos4/mach-origen.c | 2 +-
> .../{mach-smdk4212.c => mach-smdk4x12.c} | 128 ---
> arch/arm/mach-exynos4/mach-smdkv310.c | 4 +-
> arch/arm/mach-exynos4/mct.c | 166
>
> arch/arm/mach-exynos4/platsmp.c | 5 +-
> arch/arm/plat-s5p/cpu.c | 9 +
> arch/arm/plat-samsung/include/plat/cpu.h | 8 +
> 15 files changed, 251 insertions(+), 150 deletions(-)
> rename arch/arm/mach-exynos4/{mach-smdk4212.c => mach-smdk4x12.c} (61%)
>
> --
> 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 V2 2/2] ARM: SAMSUNG: Cleanup resources by using macro
On Wed, Oct 5, 2011 at 12:26 AM, Arnd Bergmann wrote: > On Tuesday 04 October 2011, Kukjin Kim wrote: >> > I think the string concatenation really just obfuscates the code, and >> > it does not actually save much at all. When you replace >> > >> > + [0] = SAMSUNG_RES_MEM(S3C, WDT, SZ_1K), >> > + [1] = SAMSUNG_RES_IRQ(WDT), >> > >> > with >> > >> > + [0] = DEFINE_RES_MEM(S3C_PA_WDT, SZ_1K), >> > + [1] = DEFINE_RES_IRQ(IRQ_WDT), >> > >> > you need practically no extra space, but you gain the advantages that >> > >> > * Someone using grep for DEFINE_RES_MEM finds all memory resources without >> > having to look up what your macros do an where they are used. >> > * Someone using grep to look for S3C_PA_WDT finds the place where it is >> used. >> > * Someone reading the resource definition immediately knows what the >> > macro does if familiar with other platforms using that macro. >> >> Yes, right. But I'm preparing to reduce the 'soc' part to consolidate some >> duplicated resources and platform data after this and the new SAMSUNG_RES >> macro will be used. There are tools for source browsing e.g., ctags, cscope, grep, git grep and so on. If you create new SAMSUNG_RES, these tools can't find macro and symbols properly. Please use the existing macros for own purpose. Thank you, Kyungmin Park > > Hmm, can't you instead change the names of these constants to be > always the same? That would let you use the regular DEFINE_RES_* > definitions without having to introduce your own. > > Arnd > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- 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/3] mmc: sdhci-s3c: Remove usage of clk_type member in platform data
> {
> struct s3c_sdhci_platdata *pdata = pdev->dev.platform_data;
> + struct sdhci_s3c_drv_data *drv_data;
> struct device *dev = &pdev->dev;
> struct sdhci_host *host;
> struct sdhci_s3c *sc;
> @@ -414,6 +455,7 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
> return PTR_ERR(host);
> }
>
> + drv_data = sdhci_s3c_get_driver_data(pdev);
> sc = sdhci_priv(host);
>
> sc->host = host;
> @@ -494,6 +536,8 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
> /* Setup quirks for the controller */
> host->quirks |= SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC;
> host->quirks |= SDHCI_QUIRK_NO_HISPD_BIT;
> + if (drv_data)
> + host->quirks |= drv_data->sdhci_quirks;
>
> #ifndef CONFIG_MMC_SDHCI_S3C_DMA
>
> @@ -534,7 +578,7 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
> * If controller does not have internal clock divider,
> * we can use overriding functions instead of default.
> */
> - if (pdata->clk_type) {
> + if (host->quirks & SDHCI_QUIRK_NONSTANDARD_CLOCK) {
> sdhci_s3c_ops.set_clock = sdhci_cmu_set_clock;
> sdhci_s3c_ops.get_min_clock = sdhci_cmu_get_min_clock;
> sdhci_s3c_ops.get_max_clock = sdhci_cmu_get_max_clock;
> @@ -639,9 +683,31 @@ static int sdhci_s3c_resume(struct platform_device *dev)
> #define sdhci_s3c_resume NULL
> #endif
>
> +#if defined(CONFIG_CPU_EXYNOS4210) || defined(CONFIG_SOC_EXYNOS4212)
> +static struct sdhci_s3c_drv_data exynos4_sdhci_drv_data = {
> + .sdhci_quirks = SDHCI_QUIRK_NONSTANDARD_CLOCK,
> +};
> +#define EXYNOS4_SDHCI_DRV_DATA ((kernel_ulong_t)&exynos4_sdhci_drv_data)
> +#else
> +#define EXYNOS4_SDHCI_DRV_DATA (kernel_ulong_t)NULL
> +#endif
It's too small to save the memory. I think no need to guard the exynos
driver data with ifdef/endif.
> +
> +static struct platform_device_id sdhci_s3c_driver_ids[] = {
> + {
> + .name = "s3c-sdhci",
> + .driver_data = (kernel_ulong_t)NULL,
> + },
> + {
> + .name = "exynos4-sdhci",
> + .driver_data = EXYNOS4_SDHCI_DRV_DATA,
> + },
> +};
> +MODULE_DEVICE_TABLE(platform, sdhci_s3c_driver_ids);
Do you have a plan to use the sdhci-pltfm.c as other drivers did?
some drivers are already use it and support OF features.
Thank you,
Kyungmin Park
> +
> static struct platform_driver sdhci_s3c_driver = {
> .probe = sdhci_s3c_probe,
> .remove = __devexit_p(sdhci_s3c_remove),
> + .id_table = sdhci_s3c_driver_ids,
> .suspend = sdhci_s3c_suspend,
> .resume = sdhci_s3c_resume,
> .driver = {
> --
> 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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: EXYNOS: Add ARCH_EXYNOS and reorganize arch/arm/mach-exynos
Hi,
I'm afraid to change machine directory name again. mach-s5pv310 ->
mach-exynos4 -> mach-exynos.
As I remember linus blamed the renaming the file names are happened
frequently at ARM
Thank you,
Kyungmin Park
2011/10/2 Kukjin Kim :
> The arch/arm/mach-exynos4 directory (CONFIG_ARCH_EXYNOS4) has
> made for plaforms based on EXYNOS4 SoCs. But since upcoming
> Samsung's SoCs such as EXYNOS5 (ARM Cortex A15) can reuse most
> codes in current mach-exynos4, one mach-exynos directory will
> be used for them.
>
> This patch changes to CONFIG_ARCH_EXYNOS (arch/arm/mach-exynos)
> but keeps original CONFIG_ARCH_EXYNOS4 in mach-exynos/Kconfig to
> avoid changing in driver side.
>
> Cc: Arnd Bergmann
> Cc: Russell King
> Signed-off-by: Kukjin Kim
> ---
> NOTE: The codes for upcoming SoCs will be implemented soon.
>
> arch/arm/Kconfig | 8 +-
> arch/arm/Makefile | 2 +-
> arch/arm/configs/exynos4_defconfig | 7 +--
> arch/arm/{mach-exynos4 => mach-exynos}/Kconfig | 41 +---
> arch/arm/{mach-exynos4 => mach-exynos}/Makefile | 8 +-
> .../{mach-exynos4 => mach-exynos}/Makefile.boot | 0
> .../clock-exynos4210.c | 0
> .../clock-exynos4212.c | 0
> arch/arm/{mach-exynos4 => mach-exynos}/clock.c | 0
> arch/arm/{mach-exynos4 => mach-exynos}/cpu.c | 69
> +++-
> arch/arm/{mach-exynos4 => mach-exynos}/cpuidle.c | 0
> arch/arm/{mach-exynos4 => mach-exynos}/dev-ahci.c | 0
> arch/arm/{mach-exynos4 => mach-exynos}/dev-audio.c | 0
> arch/arm/{mach-exynos4 => mach-exynos}/dev-dwmci.c | 0
> arch/arm/{mach-exynos4 => mach-exynos}/dev-pd.c | 0
> .../arm/{mach-exynos4 => mach-exynos}/dev-sysmmu.c | 0
> arch/arm/{mach-exynos4 => mach-exynos}/dma.c | 0
> arch/arm/{mach-exynos4 => mach-exynos}/headsmp.S | 0
> arch/arm/{mach-exynos4 => mach-exynos}/hotplug.c | 0
> .../include/mach/debug-macro.S | 0
> .../include/mach/dma.h | 0
> .../include/mach/dwmci.h | 0
> .../include/mach/entry-macro.S | 0
> .../include/mach/exynos4-clock.h | 0
> .../include/mach/gpio.h | 0
> .../include/mach/hardware.h | 0
> .../include/mach/io.h | 0
> .../include/mach/irqs.h | 0
> .../include/mach/map.h | 32 ++
> .../include/mach/memory.h | 0
> .../include/mach/pm-core.h | 0
> .../include/mach/pmu.h | 0
> .../include/mach/regs-audss.h | 0
> .../include/mach/regs-clock.h | 0
> .../include/mach/regs-gpio.h | 0
> .../include/mach/regs-irq.h | 0
> .../include/mach/regs-mct.h | 0
> .../include/mach/regs-mem.h | 0
> .../include/mach/regs-pmu.h | 0
> .../include/mach/regs-sysmmu.h | 0
> .../include/mach/regs-usb-phy.h | 0
> .../include/mach/sysmmu.h | 0
> .../include/mach/system.h | 0
> .../include/mach/timex.h | 0
> .../include/mach/uncompress.h | 0
> .../include/mach/vmalloc.h | 0
> arch/arm/{mach-exynos4 => mach-exynos}/init.c | 0
> .../{mach-exynos4 => mach-exynos}/irq-combiner.c | 0
> arch/arm/{mach-exynos4 => mach-exynos}/irq-eint.c | 0
> .../mach-armlex4210.c | 0
> arch/arm/{mach-exynos4 => mach-exynos}/mach-nuri.c | 0
> .../{mach-exynos4 => mach-exynos}/mach-origen.c | 0
> .../{mach-exynos4 => mach-exynos}/mach-smdk4x12.c | 0
> .../{mach-exynos4 => mach-exynos}/mach-smdkv310.c | 0
> .../mach-universal_c210.c | 0
> arch/arm/{mach-exynos4 => mach-exynos}/mct.c | 0
> arch/arm/{mach-exynos4 => mach-exynos}/platsmp.c | 0
> arch/arm/{mach-exynos4 => mach-exynos}/pm.c | 0
> arch/arm/{mach-exynos4 => mach-exynos}/pmu.c | 0
> .../arm/{mach-exynos4 => mach-exynos}/setup-fimc.c | 0
> .../{mach-exynos4 => mach-exynos}/setup-fimd0.c | 0
> .../arm/{mach-exynos4 => mach-exynos}/setup-i2c0.c
Re: [PATCH V2 2/2] ARM: SAMSUNG: Cleanup resources by using macro
latform_device s5p_device_hdmi = {
> @@ -1670,16 +1278,8 @@ struct platform_device s5p_device_hdmi = {
> };
>
> static struct resource s5p_sdo_resources[] = {
> - [0] = {
> - .start = S5P_PA_SDO,
> - .end = S5P_PA_SDO + SZ_64K - 1,
> - .flags = IORESOURCE_MEM,
> - },
> - [1] = {
> - .start = IRQ_SDO,
> - .end = IRQ_SDO,
> - .flags = IORESOURCE_IRQ,
> - }
> + [0] = SAMSUNG_RES_MEM(S5P, SDO, SZ_64K),
> + [1] = SAMSUNG_RES_IRQ(SDO),
> };
>
> struct platform_device s5p_device_sdo = {
> @@ -1690,24 +1290,9 @@ struct platform_device s5p_device_sdo = {
> };
>
> static struct resource s5p_mixer_resources[] = {
> - [0] = {
> - .start = S5P_PA_MIXER,
> - .end = S5P_PA_MIXER + SZ_64K - 1,
> - .flags = IORESOURCE_MEM,
> - .name = "mxr"
> - },
> - [1] = {
> - .start = S5P_PA_VP,
> - .end = S5P_PA_VP + SZ_64K - 1,
> - .flags = IORESOURCE_MEM,
> - .name = "vp"
> - },
> - [2] = {
> - .start = IRQ_MIXER,
> - .end = IRQ_MIXER,
> - .flags = IORESOURCE_IRQ,
> - .name = "irq"
> - }
> + [0] = SAMSUNG_RES_MEM_NAMED(S5P, MIXER, SZ_64K, "mxr"),
> + [1] = SAMSUNG_RES_MEM_NAMED(S5P, VP, SZ_64K, "vp"),
> + [2] = SAMSUNG_RES_IRQ_NAMED(MIXER, "irq"),
> };
>
> struct platform_device s5p_device_mixer = {
> @@ -1726,16 +1311,8 @@ struct platform_device s5p_device_mixer = {
>
> #ifdef CONFIG_S3C_DEV_USB_HOST
> static struct resource s3c_usb_resource[] = {
> - [0] = {
> - .start = S3C_PA_USBHOST,
> - .end = S3C_PA_USBHOST + 0x100 - 1,
> - .flags = IORESOURCE_MEM,
> - },
> - [1] = {
> - .start = IRQ_USBH,
> - .end = IRQ_USBH,
> - .flags = IORESOURCE_IRQ,
> - }
> + [0] = SAMSUNG_RES_MEM(S3C, USBHOST, SZ_256),
> + [1] = SAMSUNG_RES_IRQ(USBH),
> };
>
> struct platform_device s3c_device_ohci = {
> @@ -1769,16 +1346,8 @@ void __init s3c_ohci_set_platdata(struct
> s3c2410_hcd_info *info)
>
> #ifdef CONFIG_PLAT_S3C24XX
> static struct resource s3c_usbgadget_resource[] = {
> - [0] = {
> - .start = S3C24XX_PA_USBDEV,
> - .end = S3C24XX_PA_USBDEV + S3C24XX_SZ_USBDEV - 1,
> - .flags = IORESOURCE_MEM,
> - },
> - [1] = {
> - .start = IRQ_USBD,
> - .end = IRQ_USBD,
> - .flags = IORESOURCE_IRQ,
> - }
> + [0] = SAMSUNG_RES_MEM(S3C24XX, USBDEV, S3C24XX_SZ_USBDEV),
> + [1] = SAMSUNG_RES_IRQ(USBD),
> };
>
> struct platform_device s3c_device_usbgadget = {
> @@ -1798,16 +1367,8 @@ void __init s3c24xx_udc_set_platdata(struct
> s3c2410_udc_mach_info *pd)
>
> #ifdef CONFIG_S5P_DEV_USB_EHCI
> static struct resource s5p_ehci_resource[] = {
> - [0] = {
> - .start = S5P_PA_EHCI,
> - .end = S5P_PA_EHCI + SZ_256 - 1,
> - .flags = IORESOURCE_MEM,
> - },
> - [1] = {
> - .start = IRQ_USB_HOST,
> - .end = IRQ_USB_HOST,
> - .flags = IORESOURCE_IRQ,
> - }
> + [0] = SAMSUNG_RES_MEM(S5P, EHCI, SZ_256),
> + [1] = SAMSUNG_RES_IRQ(USB_HOST),
> };
>
> struct platform_device s5p_device_ehci = {
> @@ -1839,16 +1400,8 @@ void __init s5p_ehci_set_platdata(struct
> s5p_ehci_platdata *pd)
>
> #ifdef CONFIG_S3C_DEV_USB_HSOTG
> static struct resource s3c_usb_hsotg_resources[] = {
> - [0] = {
> - .start = S3C_PA_USB_HSOTG,
> - .end = S3C_PA_USB_HSOTG + 0x1 - 1,
> - .flags = IORESOURCE_MEM,
> - },
> - [1] = {
> - .start = IRQ_OTG,
> - .end = IRQ_OTG,
> - .flags = IORESOURCE_IRQ,
> - },
> + [0] = SAMSUNG_RES_MEM(S3C, USB_HSOTG, SZ_16K),
> + [1] = SAMSUNG_RES_IRQ(OTG),
> };
>
> struct platform_device s3c_device_usb_hsotg = {
> @@ -1867,16 +1420,8 @@ struct platform_device s3c_device_usb_hsotg = {
>
> #ifdef CONFIG_PLAT_S3C24XX
> static struct resource s3c_hsudc_resource[] = {
> - [0] = {
> - .start = S3C2416_PA_HSUDC,
> - .end = S3C2416_PA_HSUDC + S3C2416_SZ_HSUDC - 1,
> - .flags = IORESOURCE_MEM,
> - },
> - [1] = {
> - .start = IRQ_USBD,
> - .end = IRQ_USBD,
> - .flags = IORESOURCE_IRQ,
> - }
> + [0] = SAMSUNG_RES_MEM(S3C2416, HSUDC, S3C2416_SZ_HSUDC),
> + [1] = SAMSUNG_RES_IRQ(USBD),
> };
>
> struct platform_device s3c_device_usb_hsudc = {
> @@ -1900,16 +1445,8 @@ void __init s3c24xx_hsudc_set_platdata(struct
> s3c24xx_hsudc_platdata *pd)
>
> #ifdef CONFIG_S3C_DEV_WDT
> static struct resource s3c_wdt_resource[] = {
> - [0] = {
> - .start = S3C_PA_WDT,
> - .end = S3C_PA_WDT + SZ_1K,
> - .flags = IORESOURCE_MEM,
> - },
> - [1] = {
> - .start = IRQ_WDT,
> - .end = IRQ_WDT,
> - .flags = IORESOURCE_IRQ,
> - }
> + [0] = SAMSUNG_RES_MEM(S3C, WDT, SZ_1K),
> + [1] = SAMSUNG_RES_IRQ(WDT),
> };
>
> struct platform_device s3c_device_wdt = {
> diff --git a/arch/arm/plat-samsung/include/plat/devs.h
> b/arch/arm/plat-samsung/include/plat/devs.h
> index 8f19241..a506831 100644
> --- a/arch/arm/plat-samsung/include/plat/devs.h
> +++ b/arch/arm/plat-samsung/include/plat/devs.h
> @@ -18,6 +18,17 @@
>
> #include
>
> +#define SAMSUNG_RES_MEM(soc, ip, sz) DEFINE_RES_MEM(soc##_PA_##ip, sz)
> +#define SAMSUNG_RES_IRQ(ip) DEFINE_RES_IRQ(IRQ_##ip)
> +
> +#define SAMSUNG_RES_MEM_NAMED(soc, ip, sz, name) \
> + DEFINE_RES_MEM_NAMED(soc##_PA_##ip, sz, name)
> +#define SAMSUNG_RES_IRQ_NAMED(ip, name) \
> + DEFINE_RES_IRQ_NAMED(IRQ_##ip, name)
> +#define SAMSUNG_RES_DMA_NAMED(ch, name) \
> + DEFINE_RES_DMA_NAMED(DMACH_##ch, name)
It's good for readability. but do you think that it's hard to find out
defined macros are used at real place?
e.g., Now I want to find out the S3C_PA_USB_HSOTG. it's difficult if
you use the SAMSUNG_RES_* series macro.
but if you use the DEFINED_RES_* series directly. it's easy to find
out at real codes.
Thank you,
Kyungmin Park
> +
> +
> struct s3c24xx_uart_resources {
> struct resource *resources;
> unsigned long nr_resources;
> --
> 1.7.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
>
--
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: boot failure of exynos4 on 3.1.0-rc7
On Wed, Sep 28, 2011 at 3:40 PM, Subash Patel wrote: > On 09/28/2011 12:07 PM, Kyungmin Park wrote: >> >> On Wed, Sep 28, 2011 at 3:33 PM, Subash Patel wrote: >>> >>> Hello, >>> >>> I am attempting to boot linux version in subject on SMDKV310 board[EVT0]. >>> The booting stops after "Uncompressing Linux... done, booting the >>> kernel." >>> After some debugging I found that the timer initialization fails. >>> exynos4_mct_frc_start() calls exynos4_mct_write(lo, EXYNOS4_MCT_G_CNT_L) >>> which fails to write to the register, which should have asserted >>> G-CNT_WSTAT[0] to 1. Hence panic() will be called which halts booting. >>> >>> I have booted 3.0.0-rc1 before this, which used PWM. I found a related >>> thread for C210, which I couldnt make head-tail out of it :( >>> http://www.spinics.net/lists/arm-kernel/msg140431.html >>> >>> Can anyone let me know if this is known issue and if there is a solution >>> available for this. >> >> Need to wait for sched_clock patch are merged. Before that, you need a >> workaround patch as universal_c210 does. >> Note that de-select the MCT timer since EVT0 doesn't have it. > > This code is available in arch/arm/mach-exynos4/Kconfig > > config EXYNOS4_MCT > bool > default y > help > Use MCT (Multi Core Timer) as kernel timers > > Which I think is wrong, if EVT0 doesnt have the hardware. It should have had > condition to check the silicon revision isn't it? now soc_is_* is possible for next branch, but not exist the evt0 or evt1 check. Of course it needed for evt0 based board. Thank you, Kyungmin Park > > Regards, > Subash > > >> >> Thank you, >> Kyungmin Park >>> >>> Regards, >>> Subash >>> -- >>> 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 > -- 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: boot failure of exynos4 on 3.1.0-rc7
On Wed, Sep 28, 2011 at 3:33 PM, Subash Patel wrote: > Hello, > > I am attempting to boot linux version in subject on SMDKV310 board[EVT0]. > The booting stops after "Uncompressing Linux... done, booting the kernel." > After some debugging I found that the timer initialization fails. > exynos4_mct_frc_start() calls exynos4_mct_write(lo, EXYNOS4_MCT_G_CNT_L) > which fails to write to the register, which should have asserted > G-CNT_WSTAT[0] to 1. Hence panic() will be called which halts booting. > > I have booted 3.0.0-rc1 before this, which used PWM. I found a related > thread for C210, which I couldnt make head-tail out of it :( > http://www.spinics.net/lists/arm-kernel/msg140431.html > > Can anyone let me know if this is known issue and if there is a solution > available for this. Need to wait for sched_clock patch are merged. Before that, you need a workaround patch as universal_c210 does. Note that de-select the MCT timer since EVT0 doesn't have it. Thank you, Kyungmin Park > > Regards, > Subash > -- > 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: [RESEND PATCH 2/3] ARM: EXYNOS4: Update consistent DMA size to 8MB
Hi, As I know, CONSISTENT_DMA_SIZE is removed, please use the updated APIs. Thank you, Kyungmin Park On Wed, Sep 21, 2011 at 2:44 PM, Hatim Ali wrote: > Change the consistent DMA allocation to 8MB to support the > TVOUT driver. > > NOTE: Once CMA support is merged into mainline, we will use it for memory > allocation. > > Signed-off-by: Hatim Ali > --- > arch/arm/mach-exynos4/include/mach/memory.h | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-exynos4/include/mach/memory.h > b/arch/arm/mach-exynos4/include/mach/memory.h > index 374ef2c..7549742 100644 > --- a/arch/arm/mach-exynos4/include/mach/memory.h > +++ b/arch/arm/mach-exynos4/include/mach/memory.h > @@ -15,6 +15,8 @@ > > #define PLAT_PHYS_OFFSET UL(0x4000) > > +#define CONSISTENT_DMA_SIZE SZ_8M > + > /* Maximum of 256MiB in one bank */ > #define MAX_PHYSMEM_BITS 32 > #define SECTION_SIZE_BITS 28 > -- > 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 > -- 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/2] ARM: Exynos4: use s5p-timer for UniversalC210 board
On Thu, Sep 15, 2011 at 4:38 PM, Kukjin Kim wrote:
> Kyungmin Park wrote:
>>
>> On Thu, Sep 15, 2011 at 3:03 PM, Kukjin Kim wrote:
>> > Kukjin Kim wrote:
>> >>
>> >> Kyungmin Park wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > It's required for boot universal c210 w/ EVT0 chip.
>> >> > Can you include it at 3.1 fixed branch?
>> >> >
>> >> Sure, will apply into samsung-fixes for 3.1.
>> >
>> > Unfortunately, it happens boot failure with this patch on other
> EXYNOS4210
>> > boards and it is due to HAVE_SCHED_CLOCK.
>> >
>> >> > > + select HAVE_SCHED_CLOCK
>> >
>> > I think, we need to sort out the method...
>> As sched_clock_postinit is called at generic time code by
>> HAVE_SCHED_CLOCK. and there's no sched_clock_update_fn() is defined.
>> As a work-around, you can test it.
>>
>> static void sched_clock_poll(unsigned long wrap_ticks)
>> {
>> mod_timer(&sched_clock_timer, round_jiffies(jiffies +
> wrap_ticks));
>> if (sched_clock_update_fn)
>> sched_clock_update_fn();
>> }
>>
>
> Following is better than above but need Russell's review
Right, during the make a patch, I also found it. Check the patch
And boot tested both EVT0 and others.
>
> diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
> index 9a46370..b1a1283 100644
> --- a/arch/arm/kernel/sched_clock.c
> +++ b/arch/arm/kernel/sched_clock.c
> @@ -70,5 +70,6 @@ void __init init_sched_clock(struct clock_data *cd, void
> (*update)(void),
>
> void __init sched_clock_postinit(void)
> {
> - sched_clock_poll(sched_clock_timer.data);
> + if (sched_clock_update_fn)
> + sched_clock_poll(sched_clock_timer.data);
> }
>
>
>> To solve the problem correctly. you can add init_sched_clock at
>> "arch/arm/mach-exynos4/mct.c" properly
>>
>> Please test the work-around and share the result. I'll try to find the
>> proper place to add init_sched_clock at mct.c
>>
>> Thank you,
>> Kyungmin Park
>>
>>
>> >
>> > Thanks.
>> >
>> > Best regards,
>> > Kgene.
>> > --
>> > Kukjin Kim , Senior Engineer,
>> > SW Solution Development Team, Samsung Electronics Co., Ltd.
>> >
>> >>
>> >> > Thank you,
>> >> > Kyungmin Park
>> >> >
>> >> > On Tue, Jul 26, 2011 at 2:50 PM, Marek Szyprowski
>> >> > wrote:
>> >> > > Commit 069d4e743 removed support for local timers and forced to use
>> > MCT
>> >> as
>> >> > > event source. However MCT is not operating properly on early
> revision
>> > (EVT0)
>> >> > > of Exynos4 SoCs. All UniversalC210 boards are based on Exynos4
> EVT0,
>> > so
>> >> > that
>> >> > > commit broke support for it. This patch provides a workaround that
>> > enables
>> >> > > UniversalC210 boards to boot again. s5p-timer is used as an event
>> > source.
>> >> > >
>> >> > > Signed-off-by: Marek Szyprowski
>> >> > > Signed-off-by: Kyungmin Park
>> >> > > ---
>> >> > > arch/arm/mach-exynos4/Kconfig | 3 +++
>> >> > > arch/arm/mach-exynos4/mach-universal_c210.c | 4 +++-
>> >> > > 2 files changed, 6 insertions(+), 1 deletions(-)
>> >> > >
>> >> > > diff --git a/arch/arm/mach-exynos4/Kconfig
>> > b/arch/arm/mach-exynos4/Kconfig
>> >> > > index 9d62e13..2aad73f 100644
>> >> > > --- a/arch/arm/mach-exynos4/Kconfig
>> >> > > +++ b/arch/arm/mach-exynos4/Kconfig
>> >> > > @@ -173,6 +173,9 @@ config MACH_ARMLEX4210
>> >> > > config MACH_UNIVERSAL_C210
>> >> > > bool "Mobile UNIVERSAL_C210 Board"
>> >> > > select CPU_EXYNOS4210
>> >> > > + select S5P_HRT
>> >> > > + select CLKSRC_MMIO
>> >> > > + select HAVE_SCHED_CLOCK
>> >> > > select S5P_GPIO_INT
>> >> > > select S5P_DEV_FIMC0
>> >> > > select S5P_DEV_FIMC1
>> >> > > diff --git a/arch/arm/mach-exynos4/mach-universal_c210.c
>> > b/arch/arm/mach-
>
Re: [PATCH 2/2] ARM: Exynos4: use s5p-timer for UniversalC210 board
On Thu, Sep 15, 2011 at 3:03 PM, Kukjin Kim wrote:
> Kukjin Kim wrote:
>>
>> Kyungmin Park wrote:
>> >
>> > Hi,
>> >
>> > It's required for boot universal c210 w/ EVT0 chip.
>> > Can you include it at 3.1 fixed branch?
>> >
>> Sure, will apply into samsung-fixes for 3.1.
>
> Unfortunately, it happens boot failure with this patch on other EXYNOS4210
> boards and it is due to HAVE_SCHED_CLOCK.
>
>> > > + select HAVE_SCHED_CLOCK
>
> I think, we need to sort out the method...
As sched_clock_postinit is called at generic time code by
HAVE_SCHED_CLOCK. and there's no sched_clock_update_fn() is defined.
As a work-around, you can test it.
static void sched_clock_poll(unsigned long wrap_ticks)
{
mod_timer(&sched_clock_timer, round_jiffies(jiffies + wrap_ticks));
if (sched_clock_update_fn)
sched_clock_update_fn();
}
To solve the problem correctly. you can add init_sched_clock at
"arch/arm/mach-exynos4/mct.c" properly
Please test the work-around and share the result. I'll try to find the
proper place to add init_sched_clock at mct.c
Thank you,
Kyungmin Park
>
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim , Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
>>
>> > Thank you,
>> > Kyungmin Park
>> >
>> > On Tue, Jul 26, 2011 at 2:50 PM, Marek Szyprowski
>> > wrote:
>> > > Commit 069d4e743 removed support for local timers and forced to use
> MCT
>> as
>> > > event source. However MCT is not operating properly on early revision
> (EVT0)
>> > > of Exynos4 SoCs. All UniversalC210 boards are based on Exynos4 EVT0,
> so
>> > that
>> > > commit broke support for it. This patch provides a workaround that
> enables
>> > > UniversalC210 boards to boot again. s5p-timer is used as an event
> source.
>> > >
>> > > Signed-off-by: Marek Szyprowski
>> > > Signed-off-by: Kyungmin Park
>> > > ---
>> > > arch/arm/mach-exynos4/Kconfig | 3 +++
>> > > arch/arm/mach-exynos4/mach-universal_c210.c | 4 +++-
>> > > 2 files changed, 6 insertions(+), 1 deletions(-)
>> > >
>> > > diff --git a/arch/arm/mach-exynos4/Kconfig
> b/arch/arm/mach-exynos4/Kconfig
>> > > index 9d62e13..2aad73f 100644
>> > > --- a/arch/arm/mach-exynos4/Kconfig
>> > > +++ b/arch/arm/mach-exynos4/Kconfig
>> > > @@ -173,6 +173,9 @@ config MACH_ARMLEX4210
>> > > config MACH_UNIVERSAL_C210
>> > > bool "Mobile UNIVERSAL_C210 Board"
>> > > select CPU_EXYNOS4210
>> > > + select S5P_HRT
>> > > + select CLKSRC_MMIO
>> > > + select HAVE_SCHED_CLOCK
>> > > select S5P_GPIO_INT
>> > > select S5P_DEV_FIMC0
>> > > select S5P_DEV_FIMC1
>> > > diff --git a/arch/arm/mach-exynos4/mach-universal_c210.c
> b/arch/arm/mach-
>> > exynos4/mach-universal_c210.c
>> > > index 0e280d1..ca9e7b7 100644
>> > > --- a/arch/arm/mach-exynos4/mach-universal_c210.c
>> > > +++ b/arch/arm/mach-exynos4/mach-universal_c210.c
>> > > @@ -34,6 +34,7 @@
>> > > #include
>> > > #include
>> > > #include
>> > > +#include
>> > >
>> > > #include
>> > >
>> > > @@ -730,6 +731,7 @@ static void __init universal_map_io(void)
>> > > s5p_init_io(NULL, 0, S5P_VA_CHIPID);
>> > > s3c24xx_init_clocks(2400);
>> > > s3c24xx_init_uarts(universal_uartcfgs,
> ARRAY_SIZE(universal_uartcfgs));
>> > > + s5p_set_timer_source(S5P_PWM2, S5P_PWM4);
>> > > }
>> > >
>> > > static void __init universal_reserve(void)
>> > > @@ -766,6 +768,6 @@ MACHINE_START(UNIVERSAL_C210,
>> > "UNIVERSAL_C210")
>> > > .init_irq = exynos4_init_irq,
>> > > .map_io = universal_map_io,
>> > > .init_machine = universal_machine_init,
>> > > - .timer = &exynos4_timer,
>> > > + .timer = &s5p_timer,
>> > > .reserve = &universal_reserve,
>> > > MACHINE_END
>> > > --
>> > > 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
>> > >
>
> --
> 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 2/2] ARM: Exynos4: use s5p-timer for UniversalC210 board
Hi, It's required for boot universal c210 w/ EVT0 chip. Can you include it at 3.1 fixed branch? Thank you, Kyungmin Park On Tue, Jul 26, 2011 at 2:50 PM, Marek Szyprowski wrote: > Commit 069d4e743 removed support for local timers and forced to use MCT as > event source. However MCT is not operating properly on early revision (EVT0) > of Exynos4 SoCs. All UniversalC210 boards are based on Exynos4 EVT0, so that > commit broke support for it. This patch provides a workaround that enables > UniversalC210 boards to boot again. s5p-timer is used as an event source. > > Signed-off-by: Marek Szyprowski > Signed-off-by: Kyungmin Park > --- > arch/arm/mach-exynos4/Kconfig | 3 +++ > arch/arm/mach-exynos4/mach-universal_c210.c | 4 +++- > 2 files changed, 6 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig > index 9d62e13..2aad73f 100644 > --- a/arch/arm/mach-exynos4/Kconfig > +++ b/arch/arm/mach-exynos4/Kconfig > @@ -173,6 +173,9 @@ config MACH_ARMLEX4210 > config MACH_UNIVERSAL_C210 > bool "Mobile UNIVERSAL_C210 Board" > select CPU_EXYNOS4210 > + select S5P_HRT > + select CLKSRC_MMIO > + select HAVE_SCHED_CLOCK > select S5P_GPIO_INT > select S5P_DEV_FIMC0 > select S5P_DEV_FIMC1 > diff --git a/arch/arm/mach-exynos4/mach-universal_c210.c > b/arch/arm/mach-exynos4/mach-universal_c210.c > index 0e280d1..ca9e7b7 100644 > --- a/arch/arm/mach-exynos4/mach-universal_c210.c > +++ b/arch/arm/mach-exynos4/mach-universal_c210.c > @@ -34,6 +34,7 @@ > #include > #include > #include > +#include > > #include > > @@ -730,6 +731,7 @@ static void __init universal_map_io(void) > s5p_init_io(NULL, 0, S5P_VA_CHIPID); > s3c24xx_init_clocks(2400); > s3c24xx_init_uarts(universal_uartcfgs, ARRAY_SIZE(universal_uartcfgs)); > + s5p_set_timer_source(S5P_PWM2, S5P_PWM4); > } > > static void __init universal_reserve(void) > @@ -766,6 +768,6 @@ MACHINE_START(UNIVERSAL_C210, "UNIVERSAL_C210") > .init_irq = exynos4_init_irq, > .map_io = universal_map_io, > .init_machine = universal_machine_init, > - .timer = &exynos4_timer, > + .timer = &s5p_timer, > .reserve = &universal_reserve, > MACHINE_END > -- > 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 > -- 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] mmc: core: Add default timeout value for CMD6.
Acked-by: Kyungmin Park
Nitpick: see below comments and typo.
On Thu, Sep 8, 2011 at 3:10 PM, Seungwon Jeon wrote:
> EXT_CSD[248] includes the default maximum timeout for CMD6.
> This field is added at eMMC4.5 Spec. And it can be used for default
> timeout except for some operations which don't define the timeout(i.e.
> background operation, sanitize, flush cache) in eMMC4.5 Spec.
>
> Signed-off-by: Seungwon Jeon
> ---
> v2 : apply default maximum timeout of CMD6 which specific timeout is not
> defined.
>
> drivers/mmc/core/mmc.c | 14 ++
> include/linux/mmc/card.h | 1 +
> include/linux/mmc/mmc.h | 1 +
> 3 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 5700b1c..b148bb1 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -410,6 +410,10 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8
> *ext_csd)
> else
> card->erased_byte = 0x0;
>
> + if (card->ext_csd.rev >= 6)
> + card->ext_csd.generic_cmd6_time = 10 *
> + ext_csd[EXT_CSD_GENERIC_CMD6_TIME];
Even though generic_cmd6_time is cleared at card initialization. Make
sure set the 0 when not eMMC v4.5 to make consistent with previous
version and codes.
else
card->ext_csd.generic_cmd6_time = 0;
> +
> out:
> return err;
> }
> @@ -668,7 +672,8 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
> */
> if (card->ext_csd.enhanced_area_en) {
> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> - EXT_CSD_ERASE_GROUP_DEF, 1, 0);
> + EXT_CSD_ERASE_GROUP_DEF, 1,
> + card->ext_csd.generic_cmd6_time);
>
> if (err && err != -EBADMSG)
> goto free_card;
> @@ -711,7 +716,8 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
> if ((card->ext_csd.hs_max_dtr != 0) &&
> (host->caps & MMC_CAP_MMC_HIGHSPEED)) {
> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> - EXT_CSD_HS_TIMING, 1, 0);
> + EXT_CSD_HS_TIMING, 1,
> + card->ext_csd.generic_cmd6_time);
> if (err && err != -EBADMSG)
> goto free_card;
>
> @@ -783,7 +789,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> EXT_CSD_BUS_WIDTH,
> ext_csd_bits[idx][0],
> - 0);
> + card->ext_csd.generic_cmd6_time);
> if (!err) {
> mmc_set_bus_width(card->host, bus_width);
>
> @@ -806,7 +812,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> EXT_CSD_BUS_WIDTH,
> ext_csd_bits[idx][1],
> - 0);
> + card->ext_csd.generic_cmd6_time);
> }
> if (err) {
> printk(KERN_WARNING "%s: switch to bus width %d ddr %d
> "
> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
> index b460fc2..e992fe3 100644
> --- a/include/linux/mmc/card.h
> +++ b/include/linux/mmc/card.h
> @@ -52,6 +52,7 @@ struct mmc_ext_csd {
> u8 part_config;
> unsigned int part_time; /* Units: ms */
> unsigned int sa_timeout; /* Units: 100ns */
> + unsigned int generic_cmd6_time; /* Units: ms */
The correct unit is 10ms
> unsigned int hs_max_dtr;
> unsigned int sectors;
> unsigned int card_type;
> diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
> index 5a794cb..e869f00 100644
> --- a/include/linux/mmc/mmc.h
> +++ b/include/linux/mmc/mmc.h
> @@ -293,6 +293,7 @@ struct _mmc_csd {
> #define EXT_CSD_SEC_ERASE_MULT 230 /* RO */
> #define EXT_CSD_SEC_FEATURE_SUPPORT 231 /* RO */
> #define EXT_CSD_TRIM_MULT 232 /* RO */
> +#define EXT_CSD_GENERIC_CMD6_TIME 248 /* RO */
>
> /*
> * EXT_CSD field definitions
> --
> 1.7.0.4
>
>
Re: [PATCH] mmc: core: Fix the incorrect calculation for erase unit size.
Acked-by: Kyungmin Park On Thu, Sep 8, 2011 at 2:59 PM, Seungwon Jeon wrote: > Erase unit size of high capacity is multiple of 512KiB not 1024KiB. > > Signed-off-by: Seungwon Jeon > --- > drivers/mmc/core/mmc.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c > index b148bb1..7991ecf 100644 > --- a/drivers/mmc/core/mmc.c > +++ b/drivers/mmc/core/mmc.c > @@ -332,7 +332,7 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 > *ext_csd) > card->ext_csd.hc_erase_timeout = 300 * > ext_csd[EXT_CSD_ERASE_TIMEOUT_MULT]; > card->ext_csd.hc_erase_size = > - ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] << 10; > + ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] << 9; > > card->ext_csd.rel_sectors = ext_csd[EXT_CSD_REL_WR_SEC_C]; > > -- > 1.7.0.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] mmc: core: Add Poweroff Notify handling
On Tue, Sep 6, 2011 at 7:59 PM, Girish K S
wrote:
> This patch adds the power off notification handling
> during suspend and system poweroff.
> For suspend mode short timeout is used, whereas for the
> normal poweroff long timeout is used.
>
> Signed-off-by: Girish K S
> ---
> drivers/mmc/core/core.c | 33 +
> drivers/mmc/core/mmc.c | 4 +++-
> drivers/mmc/host/sdhci.c | 10 ++
> include/linux/mmc/card.h | 19 +++
> include/linux/mmc/host.h | 4
> 5 files changed, 69 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index a65e1ca..16da927 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -1130,9 +1130,38 @@ static void mmc_power_up(struct mmc_host *host)
>
> static void mmc_power_off(struct mmc_host *host)
> {
> + struct mmc_card *card = host->card;
> + unsigned int notify_type;
> + unsigned int timeout;
> + int err;
> +
> host->ios.clock = 0;
> host->ios.vdd = 0;
>
> + if (mmc_card_mmc(card) &&
> + (mmc_card_powernotify_on(card))) {
> +
> + if (host->power_notify_type == MMC_HOST_PW_NOTIFY_SHORT) {
> + notify_type = EXT_CSD_POWER_OFF_SHORT;
> + timeout = card->ext_csd.generic_cmd6_time;
> + mmc_card_set_powernotify_short(card);
> + } else {
> + notify_type = EXT_CSD_POWER_OFF_LONG;
> + timeout = card->ext_csd.power_off_longtime;
> + mmc_card_set_powernotify_long(card);
> + }
> +
> + err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> + EXT_CSD_POWER_OFF_NOTIFICATION,
> + notify_type, timeout);
> +
> + if (err && err != -EBADMSG)
> + printk(KERN_ERR "Device failed to respond "
> + "within %d poweroff time."
> + "forcefully powering down"
> + "the device\n", timeout);
> + }
> +
Okay this function is called when suspend.
> /*
> * Reset ocr mask to be the highest possible voltage supported for
> * this mmc host. This value will be used at next power up.
> @@ -1147,6 +1176,8 @@ static void mmc_power_off(struct mmc_host *host)
> host->ios.bus_width = MMC_BUS_WIDTH_1;
> host->ios.timing = MMC_TIMING_LEGACY;
> mmc_set_ios(host);
> + /*Set the card state to no notification after the poweroff*/
> + mmc_card_set_powernotify_off(card);
> }
>
> /*
> @@ -2026,6 +2057,7 @@ int mmc_pm_notify(struct notifier_block *notify_block,
>
> spin_lock_irqsave(&host->lock, flags);
> host->rescan_disable = 1;
> + host->power_notify_type = MMC_HOST_PW_NOTIFY_SHORT;
> spin_unlock_irqrestore(&host->lock, flags);
> cancel_delayed_work_sync(&host->detect);
>
> @@ -2048,6 +2080,7 @@ int mmc_pm_notify(struct notifier_block *notify_block,
>
> spin_lock_irqsave(&host->lock, flags);
> host->rescan_disable = 0;
> + host->power_notify_type = MMC_HOST_PW_NOTIFY_LONG;
> spin_unlock_irqrestore(&host->lock, flags);
> mmc_detect_change(host, 0);
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 2f06b37..8868da8 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -715,13 +715,15 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
> * If the host supports the power_off_notify capability then
> * set the notification byte in the ext_csd register of device
> */
> - if (host->caps & MMC_CAP_POWER_OFF_NOTIFY) {
> + if ((host->caps & MMC_CAP_POWER_OFF_NOTIFY) &&
> + (mmc_card_powernotify_off(card))) {
> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> EXT_CSD_POWER_OFF_NOTIFICATION,
> EXT_CSD_POWER_ON,
> card->ext_csd.generic_cmd6_time);
> if (err && err != -EBADMSG)
> goto free_card;
> + mmc_card_set_powernotify_on(card);
> }
>
> /*
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 0e02cc1..2ca427a 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2566,6 +2566,16 @@ int sdhci_add_host(struct sdhci_host *host)
> if (caps[1] & SDHCI_DRIVER_TYPE_D)
> mmc->caps |= MMC_CAP_DRIVER_TYPE_D;
>
> + /*
> + * If Notify capability is enabled and
> + * notify type is not initialised by host, set default to
> + * long power off notify timeout value
> + */
> + if (mmc->caps ==
Re: [PATCH 2/2] mmc: core: Add poweroff notify handling feature
Hi Girish,
I think it's still incomplete, does power off short function is called
at suspend properly?
there are some comments below.
Thank you,
Kyungmin Park
On Mon, Sep 5, 2011 at 8:49 PM, Girish K S
wrote:
> This patch adds the handling of the poweroff notify feature
> during powerdown phase.
>
> Signed-off-by: Girish K S
> ---
> drivers/mmc/core/core.c | 29 +
> drivers/mmc/core/mmc.c | 3 +++
> drivers/mmc/host/sdhci.c | 11 +++
> include/linux/mmc/card.h | 29 +
> include/linux/mmc/host.h | 7 +--
> 5 files changed, 73 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index a65e1ca..37b09d7 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -1130,9 +1130,38 @@ static void mmc_power_up(struct mmc_host *host)
>
> static void mmc_power_off(struct mmc_host *host)
> {
> + struct mmc_card *card = host->card;
> + unsigned int notify_type;
> + unsigned int timeout;
> + int err;
> +
> host->ios.clock = 0;
> host->ios.vdd = 0;
>
> + if (mmc_card_mmc(card) && mmc_card_powernotify_on(card)) {
> +
> + if (host->power_notify_type == MMC_POWEROFF_NOTIFY_SHORT) {
> + notify_type = EXT_CSD_POWER_OFF_SHORT;
> + timeout = card->ext_csd.generic_cmd6_time;
> + mmc_card_set_powernotify_short(card);
> + } else {
> + notify_type = EXT_CSD_POWER_OFF_LONG;
> + timeout = card->ext_csd.power_off_longtime;
> + mmc_card_set_powernotify_long(card);
> + }
> +
> + err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> + EXT_CSD_POWER_OFF_NOTIFICATION,
> + notify_type, timeout);
> +
> + if (err && err != -EBADMSG)
> + printk(KERN_ERR "Device failed to respond "
> + "within %d poweroff time."
> + "forcefully powering down"
> + "the device\n", timeout);
> +
> + mmc_card_set_powernotify_off(card);
> + }
> /*
> * Reset ocr mask to be the highest possible voltage supported for
> * this mmc host. This value will be used at next power up.
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 2f06b37..b369c6f 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -720,8 +720,11 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
> EXT_CSD_POWER_OFF_NOTIFICATION,
> EXT_CSD_POWER_ON,
> card->ext_csd.generic_cmd6_time);
> +
> if (err && err != -EBADMSG)
> goto free_card;
> +
> + mmc_card_set_powernotify_on(card);
> }
>
> /*
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 0e02cc1..a24a31b 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2566,6 +2566,17 @@ int sdhci_add_host(struct sdhci_host *host)
> if (caps[1] & SDHCI_DRIVER_TYPE_D)
> mmc->caps |= MMC_CAP_DRIVER_TYPE_D;
>
> + if (mmc->caps == MMC_CAP_POWER_OFF_NOTIFY) {
It should be if (mmc->caps & MMC_CAP_POWER_OFF_NOTIFY) {
> + /*
> + * If Notify capability is enabled and
> + * platform data is not initialised, set default to
> + * long power off notify timeout value
> + */
> + if (mmc->power_notify_type == MMC_POWEROFF_NOTIFY_NONE)
> + mmc->power_notify_type = MMC_POWEROFF_NOTIFY_LONG;
> + } else {
> + mmc->power_notify_type = MMC_POWEROFF_NOTIFY_NONE;
> + }
What's the goal of these statements?
> /* Initial value for re-tuning timer count */
> host->tuning_count = (caps[1] & SDHCI_RETUNING_TIMER_COUNT_MASK) >>
> SDHCI_RETUNING_TIMER_COUNT_SHIFT;
> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
> index 2bf2843..d40b7b3 100644
> --- a/include/linux/mmc/card.h
> +++ b/include/linux/mmc/card.h
> @@ -179,7 +179,12 @@ struct mmc_card {
> #define MMC_STATE_HIGHSPEED_DDR (1<<4) /* card is in high speed mode
> */
> #define MMC_STATE_U
Re: [PATCH] mmc: core: Add power off notify feature(eMMC 4.5)
Hi,
Good job on eMMC v4.5. but this patch is incomplete for power off
notification feature.
Now you just enable the Power off notification, and don't handle the
reaming one.
As you read the spec, it takes more time the sleep & wake-up and next
booting time if no proper power off notification
Please also consider it.
Thank you,
Kyungmin Park
On Fri, Sep 2, 2011 at 4:25 PM, Girish K S
wrote:
> This patch adds the support for power off notify feature
> available in eMMC 4.5 devices.
> If the the host has support for this feature, then the
> mmc core will notify it to the device by setting the
> POWER_OFF_NOTIFICATION byte in the extended csd register
> with a value 1(POWER_ON).
> This patch should be applied after Seungwon Jeon's
> patch for cmd6 timeout.
>
> Signed-off-by: Girish K S
> ---
> drivers/mmc/core/mmc.c | 19 +--
> include/linux/mmc/card.h | 1 +
> include/linux/mmc/host.h | 1 +
> include/linux/mmc/mmc.h | 8 +++-
> 4 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 68eb368..2f06b37 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -410,10 +410,12 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8
> *ext_csd)
> else
> card->erased_byte = 0x0;
>
> - if (card->ext_csd.rev >= 6)
> + if (card->ext_csd.rev >= 6) {
> card->ext_csd.generic_cmd6_time = 10 *
> ext_csd[EXT_CSD_GENERIC_CMD6_TIME];
> -
> + card->ext_csd.power_off_longtime = 10 *
> + ext_csd[EXT_CSD_POWER_OFF_LONG_TIME];
> + }
> out:
> return err;
> }
> @@ -710,6 +712,19 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
> }
>
> /*
> + * If the host supports the power_off_notify capability then
> + * set the notification byte in the ext_csd register of device
> + */
> + if (host->caps & MMC_CAP_POWER_OFF_NOTIFY) {
> + err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> + EXT_CSD_POWER_OFF_NOTIFICATION,
> + EXT_CSD_POWER_ON,
> + card->ext_csd.generic_cmd6_time);
> + if (err && err != -EBADMSG)
> + goto free_card;
> + }
> +
> + /*
> * Activate high speed (if supported)
> */
> if ((card->ext_csd.hs_max_dtr != 0) &&
> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
> index e992fe3..2bf2843 100644
> --- a/include/linux/mmc/card.h
> +++ b/include/linux/mmc/card.h
> @@ -53,6 +53,7 @@ struct mmc_ext_csd {
> unsigned int part_time; /* Units: ms */
> unsigned int sa_timeout; /* Units: 100ns */
> unsigned int generic_cmd6_time; /* Units: ms */
> + unsigned int power_off_longtime; /* Units: ms */
> unsigned int hs_max_dtr;
> unsigned int sectors;
> unsigned int card_type;
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index 1d09562..21c85e1 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -229,6 +229,7 @@ struct mmc_host {
> #define MMC_CAP_MAX_CURRENT_600 (1 << 28) /* Host max current
> limit is 600mA */
> #define MMC_CAP_MAX_CURRENT_800 (1 << 29) /* Host max current
> limit is 800mA */
> #define MMC_CAP_CMD23 (1 << 30) /* CMD23 supported. */
> +#define MMC_CAP_POWER_OFF_NOTIFY (1 << 31)/*NOtify poweroff supported */
>
> mmc_pm_flag_t pm_caps; /* supported pm features */
>
> diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
> index e869f00..8e86d77 100644
> --- a/include/linux/mmc/mmc.h
> +++ b/include/linux/mmc/mmc.h
> @@ -269,7 +269,7 @@ struct _mmc_csd {
> /*
> * EXT_CSD fields
> */
> -
> +#define EXT_CSD_POWER_OFF_NOTIFICATION 34 /* R/W */
> #define EXT_CSD_PARTITION_ATTRIBUTE 156 /* R/W */
> #define EXT_CSD_PARTITION_SUPPORT 160 /* RO */
> #define EXT_CSD_WR_REL_PARAM 166 /* RO */
> @@ -293,6 +293,7 @@ struct _mmc_csd {
> #define EXT_CSD_SEC_ERASE_MULT 230 /* RO */
> #define EXT_CSD_SEC_FEATURE_SUPPORT 231 /* RO */
> #define EXT_CSD_TRIM_MULT 232 /* RO */
> +#define EXT_CSD_POWER_OFF_LONG_TIME 247 /*RO*/
> #define EXT_CSD_GENERIC_CMD6_TIME 248 /* RO */
>
>
Re: [PATCH 0/4] ARM: SAMSUNG: Add support CPU ID and Rev. at runtime
Good change the mind to use the runtime soc detection. it's really required feature. but previous time Ben did'n like it. https://lkml.org/lkml/2010/3/30/831 I'm still prefer to use it when only early boot time if possible and another mail said cpu_is_* doesn't proper name, soc_is_* is better. Thank you, Kyungmin Park On Sat, Aug 20, 2011 at 2:05 PM, Kukjin Kim wrote: > This patch adds support handling of CPU ID and varialble silicon revision > at runtime. > > [PATCH 1/4] ARM: SAMSUNG: Add support for detecting CPU at runtime > [PATCH 2/4] ARM: S5P64X0: Use cpu_is_s5p64x0() to distinguish cpu at runtime > [PATCH 3/4] ARM: SAMSUNG: Add support for handling of cpu revision > [PATCH 4/4] ARM: EXYNOS4: Use samsung_rev() to distinguish silicon revision > -- > 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: [RFC PATCH 2/4] ARM: EXYNOS4: Fix to work with origen boards.
On Fri, Aug 19, 2011 at 10:09 PM, Amit Daniel Kachhap
wrote:
> This adds a function to get the revision id.
>
> Signed-off-by: Jaecheol Lee
> Signed-off-by: Changhwan Youn
> ---
> arch/arm/mach-exynos4/cpu.c | 10 ++
> arch/arm/plat-s5p/include/plat/exynos4.h | 1 +
> 2 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
> index 2d8a40c..8b106b8 100644
> --- a/arch/arm/mach-exynos4/cpu.c
> +++ b/arch/arm/mach-exynos4/cpu.c
> @@ -234,6 +234,16 @@ static int __init exynos4_l2x0_cache_init(void)
> early_initcall(exynos4_l2x0_cache_init);
> #endif
>
> +int exynos4_subrev(void)
> +{
> + static int subrev = -1;
> +
> + if (unlikely(subrev < 0))
> + subrev = readl(S5P_VA_CHIPID) & 0xf;
How about to add the clock control here?
1. Register chipid clk
2. Get the chipid clk
3. Read CHPIID,
4. Put tht chipid clk.
Then you can save some power.
Thank you,
Kyungmin Park
> +
> + return subrev;
> +}
> +
> int __init exynos4_init(void)
> {
> printk(KERN_INFO "EXYNOS4: Initializing architecture\n");
> diff --git a/arch/arm/plat-s5p/include/plat/exynos4.h
> b/arch/arm/plat-s5p/include/plat/exynos4.h
> index 907caab..d62f7f7 100644
> --- a/arch/arm/plat-s5p/include/plat/exynos4.h
> +++ b/arch/arm/plat-s5p/include/plat/exynos4.h
> @@ -15,6 +15,7 @@
> extern void exynos4_common_init_uarts(struct s3c2410_uartcfg *cfg, int no);
> extern void exynos4_register_clocks(void);
> extern void exynos4_setup_clocks(void);
> +extern int exynos4_subrev(void);
>
> #ifdef CONFIG_CPU_EXYNOS4210
>
> --
> 1.7.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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: EXYNOS4: Remove useless codes on NURI board
Maybe charger manager codes are not merged. it's used for charger managers.
To Mr. Ham,
which patches are missing?
Thank you,
Kyungmin Park
On Fri, Aug 19, 2011 at 10:01 PM, Kukjin Kim wrote:
> The 'nuri_cm_devices' is defined but not used.
>
> Cc: Kyungmin Park
> Signed-off-by: Kukjin Kim
> ---
> arch/arm/mach-exynos4/mach-nuri.c | 7 ---
> 1 files changed, 0 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/mach-nuri.c
> b/arch/arm/mach-exynos4/mach-nuri.c
> index 43be71b..65df994 100644
> --- a/arch/arm/mach-exynos4/mach-nuri.c
> +++ b/arch/arm/mach-exynos4/mach-nuri.c
> @@ -1037,13 +1037,6 @@ static struct platform_device nuri_max8903_device = {
> },
> };
>
> -static struct device *nuri_cm_devices[] = {
> - &s3c_device_i2c5.dev,
> - &s3c_device_adc.dev,
> - NULL, /* Reserved for UART */
> - NULL,
> -};
> -
> static void __init nuri_power_init(void)
> {
> int gpio;
> --
> 1.7.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
>
--
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] ARM: Samsung: fix watchdog reset issue with clk_get()
Interesting. there's no s5p_reset_hook at exynos4. Anyway, after implement the s5p_reset_hook, it's working without hacking of v7-fin. Send it another mail. Thank you, Kyungmin Park On Fri, Aug 19, 2011 at 7:25 PM, Marek Szyprowski wrote: > Hello, > > On Friday, August 19, 2011 11:38 AM Tushar Behera wrote: > >> Hi, >> >> On Thursday 18 August 2011 03:55 PM, Marek Szyprowski wrote: >> > clkdev framework uses global mutex to protect clock tree, so it is not >> > possible to call clk_get() in interrupt context. This patch fixes this >> > issue and makes system reset by watchdog call working again. >> > >> > Signed-off-by: Marek Szyprowski >> > Signed-off-by: Kyungmin Park >> > --- >> > arch/arm/plat-samsung/clock.c | 11 +++ >> > arch/arm/plat-samsung/include/plat/clock.h | 3 +++ >> > .../arm/plat-samsung/include/plat/watchdog-reset.h | 10 +++--- >> > 3 files changed, 17 insertions(+), 7 deletions(-) >> > >> > >> > history: >> > v3: >> > - moved initialization to arch_initcall, cleaned the code >> > >> > v2: >> > - added missing '__init' section modifiers >> (snip) >> >> I tried to test this patch with ORIGEN board. >> >> I took the ORIGEN board support patch from kgene's >> next-samsung-board-v3.1 branch and rebased it onto the for-next branch >> for testing. >> >> The system reboot stops at a message saying "Restarting system" and hangs. >> >> However applying below patch reboots the system without even applying >> Marek's patch. >> >> Is there something wrong with mach-origen.c or u-boot [1]? >> >> [1] git://git.linaro.org/people/angus/u-boot.git (origen) >> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >> From: Tushar Behera >> Date: Fri, 19 Aug 2011 14:47:04 +0530 >> Subject: [PATCH] [TEST] ARM: Disabling cache operation during system reset >> >> On ORIGEN/SMDKV310 board, system reboot hangs during cache disabling >> call in arm_machine_restart()=>cpu_proc_fin(). Applying given patch >> enables the system to reboot properly. >> >> This patch is no way a proposed solution. It is intended for further >> investigation. > > My patch solves the following issue on all Samsung platforms: > > [ 32.636689] SysRq : Resetting > [ 32.638319] arch_reset: attempting watchdog reset > [ 32.642864] BUG: sleeping function called from invalid context at > kernel/mutex.c:271 > [ 32.650589] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper > [ 32.657183] INFO: lockdep is turned off. > [ 32.661090] irq event stamp: 6363 > [ 32.664388] hardirqs last enabled at (6363): [] > _raw_spin_unlock_irq+0x24/0x50 > [ 32.672547] hardirqs last disabled at (6362): [] > _raw_spin_lock_irq+0x18/0x58 > [ 32.680532] softirqs last enabled at (6358): [] > irq_exit+0x58/0x68 > [ 32.687650] softirqs last disabled at (6291): [] > irq_exit+0x58/0x68 > [ 32.694782] [] (unwind_backtrace+0x0/0xf0) from [] > (mutex_lock_nested+0x30/0x324) > [ 32.703980] [] (mutex_lock_nested+0x30/0x324) from [] > (clk_get_sys+0x28/0xd0) > [ 32.712834] [] (clk_get_sys+0x28/0xd0) from [] > (arm_machine_restart+0x68/0x120) > [ 32.721859] [] (arm_machine_restart+0x68/0x120) from [] > (machine_restart+0x18/0x20) > [ 32.731233] [] (machine_restart+0x18/0x20) from [] > (__handle_sysrq+0xc0/0x16c) > [ 32.740175] [] (__handle_sysrq+0xc0/0x16c) from [] > (s3c24xx_serial_rx_chars+0x1c0/0x2d0) > [ 32.749985] [] (s3c24xx_serial_rx_chars+0x1c0/0x2d0) from > [] (handle_irq_event_percpu+0x30/0x178) > [ 32.760572] [] (handle_irq_event_percpu+0x30/0x178) from > [] (handle_irq_event+0x3c/0x5c) > [ 32.770380] [] (handle_irq_event+0x3c/0x5c) from [] > (handle_level_irq+0xc4/0xf4) > [ 32.779494] [] (handle_level_irq+0xc4/0xf4) from [] > (generic_handle_irq+0x28/0x3c) > [ 32.788782] [] (generic_handle_irq+0x28/0x3c) from [] > (s3c_irq_demux_uart+0x68/0xc0) > [ 32.798242] [] (s3c_irq_demux_uart+0x68/0xc0) from [] > (generic_handle_irq+0x28/0x3c) > [ 32.807704] [] (generic_handle_irq+0x28/0x3c) from [] > (handle_IRQ+0x60/0x84) > [ 32.816470] [] (handle_IRQ+0x60/0x84) from [] > (__irq_svc+0x4c/0xb0) > [ 32.824457] [] (__irq_svc+0x4c/0xb0) from [] > (exynos4_idle+0x28/0x2c) >
Re: [PATCH 0/3] ARM: SAMSUNG: register the second instance of PL330 DMAC
Does it also need to provide the mdma? On Wed, Aug 17, 2011 at 1:06 PM, alim akhtar wrote: > From: Alim Akhtar > > Two instance of platform data is provided for PL330 but only one PL330 DMAC > instance is registered with amba_device. > These patch sets registers the second instance with amba_device. > > These patches are based on kgene's tree next/topic-dma-pl330 branch. > http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git;;a=summary > > Alim Akhtar (3): > ARM: EXYNOS4: register the second instance of pl330 DMAC > ARM: S5PV210: register the second instance of pl330 DMAC > ARM: S5PC100: register the second instance of pl330 DMAC > > arch/arm/mach-exynos4/dma.c | 1 + > arch/arm/mach-s5pc100/dma.c | 1 + > arch/arm/mach-s5pv210/dma.c | 1 + > 3 files changed, 3 insertions(+), 0 deletions(-) > > -- > 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 > -- 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/9] TV driver for Samsung S5P platform (platform-part)
On Sat, Jul 16, 2011 at 4:11 PM, Kukjin Kim wrote: > Tomasz Stanislawski wrote: >> >> Hello Everyone, >> This patchset introduce TV devices to Samsung S5P platform. It includes > Goni >> (S5PV210 machine) and Universal (Exynos4 machine) boards. The patchset is >> dedicated for 2.6.39 kernel. Moreover, the patchset adds following > auxiliary >> entities and features: >> - I2C controllers for HDMI physical interface >> - power regulators >> - TV clocks, include ops for fout_vpll clock >> - fixes to power domain driver (only for Exynos4) >> - dependecies between TV and Power Domain devices (only for Exynos4) >> >> Please refer to post 'TV driver for Samsung S5P platform (media part)' for >> sources of the TV driver. >> >> The most recent changes: >> - TV becomes S5P platform device >> - support for Universal-c210 and Goni boards >> - code cleanup after Kukjin Kim's review >> >> Tomasz Stanislawski (9): >> arm: exynos4: pd: fixes block gating and code cleanup >> i2c-s3c2410: fix I2C dedicated for hdmiphy >> arm: exynos4: i2c: add controller 8 (HDMIPHY) >> arm: s5pv210: i2c: add controller 3 (HDMIPHY) >> arm: plat-s5p: add TV support >> arm: exynos4: add TV support >> arm: exynos4: universal_c210: add TV support >> arm: s5pv210: add TV support >> arm: s5pv210: goni: add TV support >> >> arch/arm/mach-exynos4/Kconfig | 3 + >> arch/arm/mach-exynos4/clock.c | 223 >> ++- >> arch/arm/mach-exynos4/cpu.c | 7 + >> arch/arm/mach-exynos4/dev-pd.c | 93 +++--- >> arch/arm/mach-exynos4/include/mach/irqs.h | 8 + >> arch/arm/mach-exynos4/include/mach/map.h | 27 +++ >> arch/arm/mach-exynos4/include/mach/regs-clock.h | 8 + >> arch/arm/mach-exynos4/include/mach/regs-pmu.h | 6 + >> arch/arm/mach-exynos4/mach-universal_c210.c | 80 >> arch/arm/mach-s5pv210/Kconfig | 8 + >> arch/arm/mach-s5pv210/Makefile | 1 + >> arch/arm/mach-s5pv210/clock.c | 169 >> -- >> arch/arm/mach-s5pv210/cpu.c | 6 + >> arch/arm/mach-s5pv210/include/mach/irqs.h | 2 +- >> arch/arm/mach-s5pv210/include/mach/map.h | 19 ++ >> arch/arm/mach-s5pv210/include/mach/regs-clock.h | 7 +- >> arch/arm/mach-s5pv210/mach-goni.c | 9 + >> arch/arm/mach-s5pv210/setup-i2c3.c | 27 +++ >> arch/arm/plat-s5p/Kconfig | 5 + >> arch/arm/plat-s5p/Makefile | 1 + >> arch/arm/plat-s5p/dev-tv.c | 100 ++ >> arch/arm/plat-samsung/Kconfig | 5 + >> arch/arm/plat-samsung/Makefile | 1 + >> arch/arm/plat-samsung/dev-i2c8.c | 68 +++ >> arch/arm/plat-samsung/include/plat/devs.h | 6 + >> arch/arm/plat-samsung/include/plat/iic-core.h | 14 ++ >> arch/arm/plat-samsung/include/plat/iic.h | 1 + >> arch/arm/plat-samsung/include/plat/pd.h | 1 + >> arch/arm/plat-samsung/include/plat/tv-core.h | 45 + >> drivers/i2c/busses/i2c-s3c2410.c | 36 - >> 30 files changed, 947 insertions(+), 39 deletions(-) >> create mode 100644 arch/arm/mach-s5pv210/setup-i2c3.c >> create mode 100644 arch/arm/plat-s5p/dev-tv.c >> create mode 100644 arch/arm/plat-samsung/dev-i2c8.c >> create mode 100644 arch/arm/plat-samsung/include/plat/tv-core.h >> >> -- >> 1.7.5.1 > > Hi, > > As I said on your previous patch, dev-i2c8 should not be used for HDMIPHY on > EXYNOS4. > It can be used for general i2c not specific HDMI. Okay create the arch/arm/plat-samsung/dev-i2c-hdmi.c. since it's dedicated i2c for hdmi. no need to stick on i2c8 anymore. > > This is needed to update based on current my for-next because to update > clkdev is required. As s5p-tv codes are merged for v3.1. it's time to merge the system part also. Thank you, Kyungmin Park > > > 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: EXYNOS4: Add platform device for dwmci driver.
On Fri, Jul 15, 2011 at 3:58 PM, Seungwon Jeon wrote: > Hi, > > Kyungmin Park wrote: >> On Thu, Jul 14, 2011 at 6:53 PM, Seungwon Jeon >> wrote: >> > This patch add platform devices for Synopsys DesignWare Multimedia Card >> > Interface driver. >> > >> > Signed-off-by: Seungwon Jeon >> > --- >> > arch/arm/mach-exynos4/Kconfig | 12 >> > arch/arm/mach-exynos4/Makefile | 1 + >> > arch/arm/mach-exynos4/dev-dwmci.c | 88 >> + >> > arch/arm/mach-exynos4/include/mach/irqs.h | 1 + >> > arch/arm/mach-exynos4/include/mach/map.h | 1 + >> > arch/arm/plat-samsung/include/plat/devs.h | 1 + >> > 6 files changed, 104 insertions(+), 0 deletions(-) >> > create mode 100644 arch/arm/mach-exynos4/dev-dwmci.c >> > >> > diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach- >> exynos4/Kconfig >> > index 5115b90..2ec5b96 100644 >> > --- a/arch/arm/mach-exynos4/Kconfig >> > +++ b/arch/arm/mach-exynos4/Kconfig >> > @@ -35,6 +35,11 @@ config EXYNOS4_DEV_SYSMMU >> > help >> > Common setup code for SYSTEM MMU in EXYNOS4 >> > >> > +config EXYNOS4_DEV_DWMCI >> > + bool >> > + help >> > + Compile in platform device definitions for DWMCI >> > + >> > config EXYNOS4_SETUP_I2C1 >> > bool >> > help >> > @@ -200,6 +205,13 @@ comment "Configuration for HSMMC bus width" >> > >> > menu "Use 8-bit bus width" >> > >> > +config EXYNOS4_DWMCI_8BIT >> > + bool "DWMCI with 8-bit bus" >> > + depends on EXYNOS4_DEV_DWMCI >> > + help >> > + Support DWMCI 8-bit bus. >> > + If selected, Channel 1 is disabled. >> >> No it should be determined at runtime instead of compile time. > > Sorry for that I don't understand your meaning. > Perhaps, you want to decide the width according to the board type at runtime? > I expect the reason and description about your comment. > Bus width is board-specific information related with capability > which is not determined in runtime. > So we should decide and choice bus width considering the board target > before compiling. It prohibit to make a single kernel as other platform does. As you know, now we can select multiple board support at exynos4. some board want to use 4-bit, other board want to use 8-bit. then how to select proper bus width? > > Best regards, > Seungwon Jeon. > >> >> > + >> > config EXYNOS4_SDHCI_CH0_8BIT >> > bool "Channel 0 with 8-bit bus" >> > help >> > diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach- >> exynos4/Makefile >> > index 60fe5ec..eeeaada 100644 >> > --- a/arch/arm/mach-exynos4/Makefile >> > +++ b/arch/arm/mach-exynos4/Makefile >> > @@ -43,6 +43,7 @@ obj-y += dev-audio.o >> > obj-$(CONFIG_EXYNOS4_DEV_AHCI) += dev-ahci.o >> > obj-$(CONFIG_EXYNOS4_DEV_PD) += dev-pd.o >> > obj-$(CONFIG_EXYNOS4_DEV_SYSMMU) += dev-sysmmu.o >> > +obj-$(CONFIG_EXYNOS4_DEV_DWMCI) += dev-dwmci.o >> > >> > obj-$(CONFIG_EXYNOS4_SETUP_FIMC) += setup-fimc.o >> > obj-$(CONFIG_EXYNOS4_SETUP_I2C1) += setup-i2c1.o >> > diff --git a/arch/arm/mach-exynos4/dev-dwmci.c b/arch/arm/mach- >> exynos4/dev-dwmci.c >> > new file mode 100644 >> > index 000..a0defa4 >> > --- /dev/null >> > +++ b/arch/arm/mach-exynos4/dev-dwmci.c >> > @@ -0,0 +1,88 @@ >> > +/* >> > + * linuxarch/arm/mach-exynos4/dev-dwmci.c >> > + * >> > + * Copyright (c) 2011 Samsung Electronics Co., Ltd. >> > + * http://www.samsung.com >> > + * >> > + * Platform device for Synopsys DesignWare Mobile Storage IP >> > + * >> > + * This program is free software; you can redistribute it and/or modify >> > + * it under the terms of the GNU General Public License as published by >> > + * the Free Software Foundation; either version 2 of the License, or >> > + * (at your option) any later version. >> > + */ >> > + >> > +#include >> > +#include >> > +#include >> > +#include >> > +#include >> > +#include >> > +#include >> > +#include >> > + >> >
Re: [PATCH v2] ARM: EXYNOS4: Add platform device for dwmci driver.
On Thu, Jul 14, 2011 at 6:53 PM, Seungwon Jeon wrote:
> This patch add platform devices for Synopsys DesignWare Multimedia Card
> Interface driver.
>
> Signed-off-by: Seungwon Jeon
> ---
> arch/arm/mach-exynos4/Kconfig | 12
> arch/arm/mach-exynos4/Makefile | 1 +
> arch/arm/mach-exynos4/dev-dwmci.c | 88
> +
> arch/arm/mach-exynos4/include/mach/irqs.h | 1 +
> arch/arm/mach-exynos4/include/mach/map.h | 1 +
> arch/arm/plat-samsung/include/plat/devs.h | 1 +
> 6 files changed, 104 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-exynos4/dev-dwmci.c
>
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index 5115b90..2ec5b96 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -35,6 +35,11 @@ config EXYNOS4_DEV_SYSMMU
> help
> Common setup code for SYSTEM MMU in EXYNOS4
>
> +config EXYNOS4_DEV_DWMCI
> + bool
> + help
> + Compile in platform device definitions for DWMCI
> +
> config EXYNOS4_SETUP_I2C1
> bool
> help
> @@ -200,6 +205,13 @@ comment "Configuration for HSMMC bus width"
>
> menu "Use 8-bit bus width"
>
> +config EXYNOS4_DWMCI_8BIT
> + bool "DWMCI with 8-bit bus"
> + depends on EXYNOS4_DEV_DWMCI
> + help
> + Support DWMCI 8-bit bus.
> + If selected, Channel 1 is disabled.
No it should be determined at runtime instead of compile time.
> +
> config EXYNOS4_SDHCI_CH0_8BIT
> bool "Channel 0 with 8-bit bus"
> help
> diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
> index 60fe5ec..eeeaada 100644
> --- a/arch/arm/mach-exynos4/Makefile
> +++ b/arch/arm/mach-exynos4/Makefile
> @@ -43,6 +43,7 @@ obj-y += dev-audio.o
> obj-$(CONFIG_EXYNOS4_DEV_AHCI) += dev-ahci.o
> obj-$(CONFIG_EXYNOS4_DEV_PD) += dev-pd.o
> obj-$(CONFIG_EXYNOS4_DEV_SYSMMU) += dev-sysmmu.o
> +obj-$(CONFIG_EXYNOS4_DEV_DWMCI) += dev-dwmci.o
>
> obj-$(CONFIG_EXYNOS4_SETUP_FIMC) += setup-fimc.o
> obj-$(CONFIG_EXYNOS4_SETUP_I2C1) += setup-i2c1.o
> diff --git a/arch/arm/mach-exynos4/dev-dwmci.c
> b/arch/arm/mach-exynos4/dev-dwmci.c
> new file mode 100644
> index 000..a0defa4
> --- /dev/null
> +++ b/arch/arm/mach-exynos4/dev-dwmci.c
> @@ -0,0 +1,88 @@
> +/*
> + * linuxarch/arm/mach-exynos4/dev-dwmci.c
> + *
> + * Copyright (c) 2011 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Platform device for Synopsys DesignWare Mobile Storage IP
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#ifdef EXYNOS4_DWMCI_8BIT
> +#define BUS_WIDTH 8
> +#else
> +#define BUS_WIDTH 4
> +#endif
Right, each board can modify the bus width. so it needs the helper
function to setup.
> +
> +static int exynos4_dwmci_get_ocr(u32 slot_id)
> +{
> + return MMC_VDD_32_33 | MMC_VDD_33_34;
> +}
> +
> +static int exynos4_dwmci_get_bus_wd(u32 slot_id)
> +{
> + return BUS_WIDTH;
> +}
> +
> +static int exynos4_dwmci_init(u32 slot_id, irq_handler_t handler, void *data)
> +{
> + return 0;
> +}
> +
> +static struct resource exynos4_dwmci_resource[] = {
> + [0] = {
> + .start = EXYNOS4_PA_DWMCI,
> + .end = EXYNOS4_PA_DWMCI + SZ_4K - 1,
> + .flags = IORESOURCE_MEM,
> + },
> + [1] = {
> + .start = IRQ_DWMCI,
> + .end = IRQ_DWMCI,
> + .flags = IORESOURCE_IRQ,
> + }
> +};
> +
> +static struct dw_mci_board exynos4_dwci_pdata = {
> + .num_slots = 1,
> + .quirks = DW_MCI_QUIRK_BROKEN_CARD_DETECTION,
> + .bus_hz = 80*1000*1000,
> + .detect_delay_ms = 200,
> + .init = exynos4_dwmci_init,
> + .get_ocr = exynos4_dwmci_get_ocr,
> + .get_bus_wd = exynos4_dwmci_get_bus_wd,
> + .select_slot = NULL,
> +};
> +
> +static u64 exynos4_dwmci_dmamask = DMA_BIT_MASK(32);
> +
> +struct platform_device exynos4_device_dwmci = {
> + .name = "dw_mmc",
> + .id = -1,
> + .num_resources = ARRAY_SIZE(exynos4_dwmci_resource),
> + .resource = exynos4_dwmci_resource,
> + .dev = {
> + .dma_mask = &exynos4_dwmci_dmamask,
> + .coherent_dma_mask = DMA_BIT_MASK(32),
> + .
Re: [PATCH] ARM: EXYNOS4: Add platform device for dwmci driver.
On Wed, Jul 13, 2011 at 4:17 PM, Seungwon Jeon wrote:
> This patch add platform devices for Synopsys DesignWare Multimedia Card
> Interface driver.
>
> Signed-off-by: Seungwon Jeon
> ---
> arch/arm/mach-exynos4/Kconfig | 5 ++
> arch/arm/mach-exynos4/Makefile | 1 +
> arch/arm/mach-exynos4/dev-dwmci.c | 86
> +
> arch/arm/mach-exynos4/include/mach/irqs.h | 1 +
> arch/arm/mach-exynos4/include/mach/map.h | 1 +
> arch/arm/plat-samsung/include/plat/devs.h | 1 +
> 6 files changed, 95 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-exynos4/dev-dwmci.c
>
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index 5115b90..c82674a 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -35,6 +35,11 @@ config EXYNOS4_DEV_SYSMMU
> help
> Common setup code for SYSTEM MMU in EXYNOS4
>
> +config EXYNOS4_DEV_DWMCI
> + bool
> + help
> + Compile in platform device definitions for DWMCI
> +
> config EXYNOS4_SETUP_I2C1
> bool
> help
> diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
> index 60fe5ec..eeeaada 100644
> --- a/arch/arm/mach-exynos4/Makefile
> +++ b/arch/arm/mach-exynos4/Makefile
> @@ -43,6 +43,7 @@ obj-y += dev-audio.o
> obj-$(CONFIG_EXYNOS4_DEV_AHCI) += dev-ahci.o
> obj-$(CONFIG_EXYNOS4_DEV_PD) += dev-pd.o
> obj-$(CONFIG_EXYNOS4_DEV_SYSMMU) += dev-sysmmu.o
> +obj-$(CONFIG_EXYNOS4_DEV_DWMCI) += dev-dwmci.o
>
> obj-$(CONFIG_EXYNOS4_SETUP_FIMC) += setup-fimc.o
> obj-$(CONFIG_EXYNOS4_SETUP_I2C1) += setup-i2c1.o
> diff --git a/arch/arm/mach-exynos4/dev-dwmci.c
> b/arch/arm/mach-exynos4/dev-dwmci.c
> new file mode 100644
> index 000..6b69707
> --- /dev/null
> +++ b/arch/arm/mach-exynos4/dev-dwmci.c
> @@ -0,0 +1,86 @@
> +/*
> + * linuxarch/arm/mach-exynos4/dev-dwmci.c
> + *
> + * Copyright (c) 2011 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Platform device for Synopsys DesignWare Mobile Storage IP
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +static int exynos4_dwmci_init(u32 slot_id, irq_handler_t handler, void
> *data);
> +static int exynos4_dwmci_get_ocr(u32 slot_id);
> +static int exynos4_dwmci_get_bus_wd(u32 slot_id);
No need to declare it at here.
Just put the exynos4_dwci_pdata at last.
> +
> +static struct resource exynos4_dwmci_resource[] = {
> + [0] = {
> + .start = EXYNOS4_PA_DWMCI,
> + .end = EXYNOS4_PA_DWMCI + SZ_4K - 1,
> + .flags = IORESOURCE_MEM,
> + },
> + [1] = {
> + .start = IRQ_DWMCI,
> + .end = IRQ_DWMCI,
> + .flags = IORESOURCE_IRQ,
> + }
> +};
> +
> +static struct dw_mci_board exynos4_dwci_pdata = {
> + .num_slots = 1,
> + .quirks = DW_MCI_QUIRK_BROKEN_CARD_DETECTION,
> + .bus_hz = 80*1000*1000,
Does it correct value?
> + .detect_delay_ms = 200,
> + .init = exynos4_dwmci_init,
> + .get_ocr = exynos4_dwmci_get_ocr,
> + .get_bus_wd = exynos4_dwmci_get_bus_wd,
> + .select_slot = NULL,
> +};
> +
> +static u64 exynos4_dwmci_dmamask = DMA_BIT_MASK(32);
> +
> +struct platform_device exynos4_device_dwmci = {
> + .name = "dw_mmc",
> + .id = -1,
> + .num_resources = ARRAY_SIZE(exynos4_dwmci_resource),
> + .resource = exynos4_dwmci_resource,
> + .dev = {
> + .dma_mask = &exynos4_dwmci_dmamask,
> + .coherent_dma_mask = DMA_BIT_MASK(32),
> + .platform_data = &exynos4_dwci_pdata,
> + },
> +};
> +
> +static int exynos4_dwmci_get_ocr(u32 slot_id)
> +{
> + return MMC_VDD_32_33 | MMC_VDD_33_34;
> +}
> +
> +static int exynos4_dwmci_get_bus_wd(u32 slot_id)
> +{
> + return 4;
It's platform dependent value. Please give also platform helper
function to setup at each platform.
> +}
> +
> +static int exynos4_dwmci_init(u32 slot_id, irq_handler_t handler, void *data)
> +{
> + return 0;
> +}
> +
> diff --git a/arch/arm/mach-exynos4/include/mach/irqs.h
> b/arch/arm/mach-exynos4/include/mach/irqs.h
> index 5d03730..b720246 100644
> --- a/arch/arm/mach-exynos4/include/mach/irqs.h
> +++ b/arch/arm/mach-exyn
Re: [PATCH 4/4] [CPUFREQ] EXYNOS4210: Add Support for DVS Lock
On Tue, Jul 5, 2011 at 5:06 PM, Kukjin Kim wrote:
> From: Jongpill Lee
>
> Signed-off-by: Jongpill Lee
> Signed-off-by: SangWook Ju
> Signed-off-by: Jonghwan Choi
> Signed-off-by: Kukjin Kim
> ---
> arch/arm/mach-exynos4/include/mach/cpufreq.h | 39 ++
> drivers/cpufreq/exynos4210-cpufreq.c | 167
> +-
> 2 files changed, 200 insertions(+), 6 deletions(-)
> create mode 100644 arch/arm/mach-exynos4/include/mach/cpufreq.h
>
> diff --git a/arch/arm/mach-exynos4/include/mach/cpufreq.h
> b/arch/arm/mach-exynos4/include/mach/cpufreq.h
> new file mode 100644
> index 000..7e00931
> --- /dev/null
> +++ b/arch/arm/mach-exynos4/include/mach/cpufreq.h
> @@ -0,0 +1,39 @@
> +/* linux/arch/arm/mach-exynos4/include/mach/cpufreq.h
> + *
> + * Copyright (c) 2011 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * EXYNOS4 - CPUFreq support
> + *
> + * 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.
> + */
> +
> +/*
> + * CPU frequency level index for using cpufreq lock API
> + * This should be same with cpufreq_frequency_table
> + */
> +enum cpufreq_level_request {
> + CPU_L0, /* 1200MHz */
> + CPU_L1, /* 1000MHz */
> + CPU_L2, /* 800MHz */
> + CPU_L3, /* 500MHz */
> + CPU_L4, /* 200MHz */
> + CPU_LEVEL_END,
> +};
> +
> +enum cpufreq_lock_ID {
> + DVFS_LOCK_ID_G2D, /* G2D */
> + DVFS_LOCK_ID_TV, /* TV */
> + DVFS_LOCK_ID_MFC, /* MFC */
> + DVFS_LOCK_ID_USB, /* USB */
> + DVFS_LOCK_ID_CAM, /* CAM */
> + DVFS_LOCK_ID_PM, /* PM */
> + DVFS_LOCK_ID_USER, /* USER */
> + DVFS_LOCK_ID_END,
> +};
> +
> +int exynos4_cpufreq_lock(unsigned int nId,
> + enum cpufreq_level_request cpufreq_level);
> +void exynos4_cpufreq_lock_free(unsigned int nId);
> diff --git a/drivers/cpufreq/exynos4210-cpufreq.c
> b/drivers/cpufreq/exynos4210-cpufreq.c
> index 2e04e01..1d2b7da 100644
> --- a/drivers/cpufreq/exynos4210-cpufreq.c
> +++ b/drivers/cpufreq/exynos4210-cpufreq.c
> @@ -17,14 +17,21 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
> #include
> #include
> +#include
>
> #include
> #include
>
> +static bool exynos4_cpufreq_init_done;
> +static DEFINE_MUTEX(set_freq_lock);
> +static DEFINE_MUTEX(set_cpu_freq_lock);
> +
> static struct clk *cpu_clk;
> static struct clk *moutcore;
> static struct clk *mout_mpll;
> @@ -53,6 +60,12 @@ static struct cpufreq_frequency_table exynos4_freq_table[]
> = {
> {0, CPUFREQ_TABLE_END},
> };
>
> +/* This defines are for cpufreq lock */
> +#define CPUFREQ_MIN_LEVEL (CPUFREQ_LEVEL_END - 1)
> +unsigned int cpufreq_lock_id;
> +unsigned int cpufreq_lock_val[DVFS_LOCK_ID_END];
> +unsigned int cpufreq_lock_level = CPUFREQ_MIN_LEVEL;
> +
> static unsigned int clkdiv_cpu0[CPUFREQ_LEVEL_END][7] = {
> /*
> * Clock divider value for following
> @@ -272,22 +285,31 @@ static int exynos4_target(struct cpufreq_policy *policy,
> {
> unsigned int index, old_index;
> unsigned int arm_volt;
> + int ret = 0;
> +
> + mutex_lock(&set_freq_lock);
>
> freqs.old = exynos4_getspeed(policy->cpu);
>
> if (cpufreq_frequency_table_target(policy, exynos4_freq_table,
> - freqs.old, relation, &old_index))
> - return -EINVAL;
> + freqs.old, relation, &old_index)) {
> + ret = -EINVAL;
> + goto out;
> + }
>
> if (cpufreq_frequency_table_target(policy, exynos4_freq_table,
> - target_freq, relation, &index))
> - return -EINVAL;
> + target_freq, relation, &index)) {
> + ret = -EINVAL;
> + goto out;
> + }
>
> freqs.new = exynos4_freq_table[index].frequency;
> freqs.cpu = policy->cpu;
>
> - if (freqs.new == freqs.old)
> - return 0;
> + if (freqs.new == freqs.old) {
> + ret = -EINVAL;
> + goto out;
> + }
>
> /* get the voltage value */
> arm_volt = exynos4_volt_table[index].arm_volt;
> @@ -309,9 +331,98 @@ static int exynos4_target(struct cpufreq_policy *policy,
> /* Voltage down */
> regulator_set_voltage(arm_regulator, arm_volt, arm_volt);
>
> +out:
> + mutex_unlock(&set_freq_lock);
> +
> + return ret;
> +}
> +
> +atomic_t exynos4_cpufreq_lock_count;
> +
> +int exynos4_cpufreq_lock(unsigned int id,
> + enum cpufreq_level_request cpufreq_level)
> +{
> + int i, old_idx = 0;
> + unsigned int freq_old, freq_new, arm_volt
Re: [PATCH] ARM: exynos4: fix secondary CPU boot
It's first step to handle the EVT.
Acked-by: Kyungmin Park
> Jazz is not dead. It just smells funny...
> From a24392183d396fab790557b0efb35e840c9e8a81 Mon Sep 17 00:00:00 2001
> From: Marc Zyngier
> Date: Fri, 20 May 2011 14:38:25 +0100
> Subject: [PATCH] ARM: exynos4: fix secondary CPU boot on early SoC revisions
>
> It appears that the system-wide flags register that used to be at
> 0x02025000 on the first revision of Exynos4 has moved to 0x0202.
>
> The kernel has been updated accordingly, but this unfortunately leaves
> early boards without SMP support (the secondary CPU spins endlessly
> in BL0 waiting for an address to be written at that memory location).
>
> Solve the problem by providing an s3c_get_chip_id() function, common
> to all s3c/s5p implementations, and test the result on the secondary boot
> path.
>
> Revision table, as provided by Kyungmin Park :
> 0x4320 0200 EVT0
> 0x4321 0210 EVT1
> 0x4321 0211 EVT2
>
> The last 8 bits can be overrided by efuses, so only bits [16:19] are
> used to identify the revision.
>
> Tested on a vintage SMDK-v310.
>
> Cc: Kukjin Kim
> Cc: Kyungmin Park
> Signed-off-by: Marc Zyngier
> ---
> arch/arm/mach-exynos4/include/mach/map.h | 1 +
> arch/arm/mach-exynos4/platsmp.c | 22 +-
> arch/arm/plat-samsung/include/plat/cpu.h | 2 ++
> arch/arm/plat-samsung/init.c | 8
> 4 files changed, 32 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/include/mach/map.h
> b/arch/arm/mach-exynos4/include/mach/map.h
> index 57d8074..da08f5c 100644
> --- a/arch/arm/mach-exynos4/include/mach/map.h
> +++ b/arch/arm/mach-exynos4/include/mach/map.h
> @@ -24,6 +24,7 @@
> #include
>
> #define EXYNOS4_PA_SYSRAM 0x0202
> +#define EXYNOS4_PA_SYSRAM_EVT0 0x02025000
>
> #define EXYNOS4_PA_FIMC0 0x1180
> #define EXYNOS4_PA_FIMC1 0x1181
> diff --git a/arch/arm/mach-exynos4/platsmp.c b/arch/arm/mach-exynos4/platsmp.c
> index c5e65a0..086d1e3 100644
> --- a/arch/arm/mach-exynos4/platsmp.c
> +++ b/arch/arm/mach-exynos4/platsmp.c
> @@ -26,6 +26,8 @@
> #include
> #include
>
> +#include
> +
> #include
> #include
>
> @@ -170,6 +172,24 @@ void __init platform_smp_prepare_cpus(unsigned int
> max_cpus)
> * system-wide flags register. The boot monitor waits
> * until it receives a soft interrupt, and then the
> * secondary CPU branches to this address.
> + *
> + * EVT0 has the system-wide flags register at a different
> + * address, hence the following hackery...
> */
> - __raw_writel(BSYM(virt_to_phys(exynos4_secondary_startup)),
> S5P_VA_SYSRAM);
> + if (s3c_get_chip_id() & 0xFUL)
> + __raw_writel(BSYM(virt_to_phys(exynos4_secondary_startup)),
> + S5P_VA_SYSRAM);
> + else {
> + void __iomem *sysram_evt0;
> +
> + sysram_evt0 = ioremap(EXYNOS4_PA_SYSRAM_EVT0, SZ_4K);
> + if (!sysram_evt0) {
> + pr_err("Unable to remap EXYNOS4_PA_SYSRAM_EVT0\n");
> + return;
> + }
> + __raw_writel(BSYM(virt_to_phys(exynos4_secondary_startup)),
> + sysram_evt0);
> + iounmap(sysram_evt0);
> + }
> +
> }
> diff --git a/arch/arm/plat-samsung/include/plat/cpu.h
> b/arch/arm/plat-samsung/include/plat/cpu.h
> index c0a5741..41573cc 100644
> --- a/arch/arm/plat-samsung/include/plat/cpu.h
> +++ b/arch/arm/plat-samsung/include/plat/cpu.h
> @@ -44,6 +44,8 @@ struct cpu_table {
> extern void s3c_init_cpu(unsigned long idcode,
> struct cpu_table *cpus, unsigned int cputab_size);
>
> +extern unsigned long s3c_get_chip_id(void);
> +
> /* core initialisation functions */
>
> extern void s3c24xx_init_irq(void);
> diff --git a/arch/arm/plat-samsung/init.c b/arch/arm/plat-samsung/init.c
> index 79d10fc..320b88f 100644
> --- a/arch/arm/plat-samsung/init.c
> +++ b/arch/arm/plat-samsung/init.c
> @@ -30,6 +30,7 @@
> #include
>
> static struct cpu_table *cpu;
> +static unsigned long s3c_chip_id;
>
> static struct cpu_table * __init s3c_lookup_cpu(unsigned long idcode,
> struct cpu_table *tab,
> @@ -60,6 +61,8 @@ void __init s3c_init_cpu(unsigned long idcode,
> panic("Unsupported Samsung CPU");
> }
>
> + s3c_chip_id = idcode;
> +
> cpu->map_io();
> }
>
> @@ -140,6 +143,11 @@ void __in
Re: [RFC][PATCH 4/5] ARM: S5P64x0: Adding OTG PHY control code
On Tue, Jun 21, 2011 at 4:03 PM, wrote:
> From: Praveen Paneri
>
> A generic method to initialize and exit OTG PHY which can be
> used for all the samsung SoCs.
> OTG platdata structure added in platform to pass required
> platform specific functions and data to the driver.
>
> Signed-off-by: Praveen Paneri
> ---
> arch/arm/mach-s5p64x0/Makefile | 1 +
> arch/arm/mach-s5p64x0/include/mach/map.h | 4 +
> arch/arm/mach-s5p64x0/setup-otg-phy.c | 89
> ++
> arch/arm/plat-s5p/include/plat/otg.h | 29 ++
> 4 files changed, 123 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-s5p64x0/setup-otg-phy.c
> create mode 100644 arch/arm/plat-s5p/include/plat/otg.h
>
> diff --git a/arch/arm/mach-s5p64x0/Makefile b/arch/arm/mach-s5p64x0/Makefile
> index ae6bf6f..611fb3a 100644
> --- a/arch/arm/mach-s5p64x0/Makefile
> +++ b/arch/arm/mach-s5p64x0/Makefile
> @@ -28,3 +28,4 @@ obj-y += dev-audio.o
> obj-$(CONFIG_S3C64XX_DEV_SPI) += dev-spi.o
>
> obj-$(CONFIG_S5P64X0_SETUP_I2C1) += setup-i2c1.o
> +obj-$(CONFIG_S3C_DEV_DWC_OTG) += setup-otg-phy.o
> diff --git a/arch/arm/mach-s5p64x0/include/mach/map.h
> b/arch/arm/mach-s5p64x0/include/mach/map.h
> index 95c9125..717c279 100644
> --- a/arch/arm/mach-s5p64x0/include/mach/map.h
> +++ b/arch/arm/mach-s5p64x0/include/mach/map.h
> @@ -44,6 +44,8 @@
> #define S5P64X0_PA_SPI1 0xEC50
>
> #define S5P64X0_PA_HSOTG 0xED10
> +#define S5P64X0_PA_USB_HSPHY 0xED20
> +#define S5P64X0_VA_USB_HSPHY S3C_ADDR_CPU(0x0010)
>
> #define S5P64X0_PA_HSMMC(x) (0xED80 + ((x) * 0x10))
>
> @@ -71,6 +73,8 @@
> #define S5P_PA_TIMER S5P64X0_PA_TIMER
>
> #define SAMSUNG_PA_ADC S5P64X0_PA_ADC
> +#define S3C_PA_USB_HSOTG S5P64X0_PA_HSOTG
> +#define S3C_VA_USB_HSPHY S5P64X0_VA_USB_HSPHY
>
> /* UART */
>
> diff --git a/arch/arm/mach-s5p64x0/setup-otg-phy.c
> b/arch/arm/mach-s5p64x0/setup-otg-phy.c
> new file mode 100644
> index 000..c351554
> --- /dev/null
> +++ b/arch/arm/mach-s5p64x0/setup-otg-phy.c
> @@ -0,0 +1,89 @@
> +/*
> + * Copyright (C) 2011 Samsung Electronics Co.Ltd
> + * Author: Praveen Paneri
> + * based on arch/arm/mach-exynos4/setup-usb-phy.c
> + * written by Joonyoung Shim
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct clk *otg_clk;
> +static int s5p64x0_otg_phy_init(struct platform_device *pdev)
> +{
> + int err;
> +
> + otg_clk = clk_get(&pdev->dev, "otg");
> + if (IS_ERR(otg_clk)) {
> + dev_err(&pdev->dev, "Failed to get otg clock\n");
> + return PTR_ERR(otg_clk);
> + }
> +
> + err = clk_enable(otg_clk);
> + if (err) {
> + clk_put(otg_clk);
> + return err;
> + }
> +
> + if (gpio_is_valid(S5P6440_GPN(1))) {
> + err = gpio_request(S5P6440_GPN(1), "GPN");
> + if (err)
> + printk(KERN_ERR "failed to request GPN1\n");
> + gpio_direction_output(S5P6440_GPN(1), 1);
> + }
What's the GPN(1)? I think it's board specific pins. so please replace
it at board file.
> +
> + writel(readl(S5P64X0_OTHERS)&~S5P64X0_OTHERS_USB_SIG_MASK,
> + S5P64X0_OTHERS);
> + writel(0x0, S3C_PHYPWR); /* Power up */
> + writel(S3C_PHYCLK_CLKSEL_12M, S3C_PHYCLK);
> + writel(S3C_RSTCON_PHY, S3C_RSTCON);
> +
> + udelay(50);
> + writel(0x0, S3C_RSTCON);
> + udelay(50);
> +
> + return 0;
> +}
> +
> +static int s5p64x0_otg_phy_exit(struct platform_device *pdev)
> +{
> + writel(readl(S3C_PHYPWR)|(0x1F<<1), S3C_PHYPWR);
> + writel(readl(S5P64X0_OTHERS)&~S5P64X0_OTHERS_USB_SIG_MASK,
> + S5P64X0_OTHERS);
> +
> + gpio_free(S5P6440_GPN(1));
ditto
> +
> + clk_disable(otg_clk);
> + clk_put(otg_clk);
> +
> + return 0;
> +}
> +
> +int s5p_usb_phy_init(struct platform_device *pdev, int type)
> +{
> + if (type == S5P_USB_PHY_DEVICE)
> + return s5p64x0_otg_phy_init(pdev);
> +
> + return -EINVAL;
> +}
> +
> +int s5p_usb_phy_exit(struct platform_device *pdev, int type)
> +{
> + if (type == S5P_USB_PHY_DEVICE)
> + return s5p64x0_otg_phy_exit(pdev);
> +
> + return -EINVAL;
> +}
> diff --git a/arch/arm/plat-s5p/include/plat/otg.h
> b/arch/arm/plat-s5p/include/plat/otg.h
> new file mode 100644
> index 000..3111dcc
> --- /dev/null
> +++ b/arch/arm/
Re: [PATCH 0/7] ARM: EXYNOS4: Adds External GIC
Hi, There are some boards which use the EVT0 chip. some SMDKV310 and Universal-C210. With this changes, it can't use these boards. Do you want to remove EVT0 based boards? Thank you, Kyungmin Park On Mon, Jun 20, 2011 at 4:34 PM, Changhwan Youn wrote: > This patch adds implementation External GIC on EXYNOS4 SoC. > > Note: need to update timer codes for supporting old type of > EXYNOS4 SoCs. > > [PATCH 1/7] ARM: EXYNOS4: Add external GIC io memory mapping > [PATCH 2/7] ARM: EXYNOS4: modify interrupt mappings for external GIC > [PATCH 3/7] ARM: EXYNOS4: set the affinity of mct1 interrupt using IRQ_MCT_L1 > [PATCH 4/7] ARM: GIC: move gic_chip_data structure declaration to header > [PATCH 5/7] ARM: EXYNOS4: Add support external GIC > [PATCH 6/7] ARM: EXYNOS4: Remove clock event timers using ARM private timers > [PATCH 7/7] ARM: EXYNOS4: Add chained enrty/exit function to uart interrupt > handler > -- > 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] ARM:SAMSUNG: Move S3C DMA driver to drivers/dma
2011/6/10 Kukjin Kim : > On 06/07/11 15:36, Russell King - ARM Linux wrote: >> I see no effort from the Samsung folk to even start considering moving >> to common APIs - I see precisely the opposite. They seem to have a >> strong desire to invent their own new APIs all the time rather than >> look at existing APIs and discuss how they can be used or adapted so >> they work for Samsung. >> >> That is not sustainable, and if it continues, it will probably result >> in Samsung stuff being chucked out of mainline. We are most definitely >> at the point where custom APIs are no longer permissible, especially >> for any new SoCs. > > Hi Russell and everyone, > > Sorry for late participation on this :( > I'm out of my office for biz. trip so it was hard to check my e-mail > and will be back to my country this weekend. > > Anyway, I and my colleagues know what we have to do for Linux world. > And as I know, we are preparing some stuff for it so please don't > expect the worst :) > > I should be back on this after discussing with my colleagues. Any updates? still need more time? > > 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] ARM: exynos4: fix secondary CPU boot
On Wed, Jun 15, 2011 at 7:26 AM, Angus Ainslie wrote: > On Thu, Jun 2, 2011 at 2:54 AM, Marc Zyngier wrote: >> On Thu, 2011-06-02 at 17:39 +0900, Kyungmin Park wrote: >>> On Thu, Jun 2, 2011 at 5:34 PM, Marc Zyngier wrote: >>> > On Thu, 2011-06-02 at 16:01 +0900, Kyungmin Park wrote: >>> >> On Fri, May 27, 2011 at 12:11 AM, Marc Zyngier >>> >> wrote: >>> >> > On Wed, 2011-05-25 at 12:06 -0700, Kukjin Kim wrote: >>> >> >> On 05/25/11 11:04, Marc Zyngier wrote: >>> >> >> > On Wed, 2011-05-25 at 10:28 -0700, Kukjin Kim wrote: >>> >> >> >> On 05/20/11 06:46, Marc Zyngier wrote: >>> >> >> >>> >> >> (snip) >>> >> >> >>> >> >> > So that address has changed between two SoC revisions? That's >>> >> >> > unfortunate, to say the least. I'm most probably using an early >>> >> >> > revision >>> >> >> > of the hardware (EVT0?), as it doesn't even support MCT. >>> >> >> > >>> >> >> I'm afraid :( and I agree secondary CPU should work on all of >>> >> >> Exynos4210. But I'm still think about the method... >>> >> >> >>> >> >> > What about the following patch? >>> >> >> > >>> >> >> Uhm...this is really hack but I'd like to use another normal way...? >>> >> > >>> >> > Oh, no question about the hack status. The trouble is, unless there is >>> >> > a >>> >> > sure way to tell which SoC revision we're running on, there's little >>> >> > else we can do than poke both locations and pray. >>> >> > >>> >> > Is there such a way to identify the SoC revision? >>> >> >>> >> It's also required for OneNAND. as you know C210 EVT0 OneNAND DMA has >>> >> bug and need to workaround. >>> >> >>> >> platform codes should provide the these function. please see the OMAP >>> >> codes. how to handle it. >>> > >>> > So we know there's a need beyond the wish to see the second core up and >>> > running on my board. >>> > >>> > Now what is the proper method to detect the revision of the SOC? >>> > Handling it is no problem, once we have the information. Unfortunately >>> > the documentation I have is less than helpful on that subject. >>> >>> It can be distinguished by chip id. but there's no code to handle this one. >>> >>> 0x4320 0200 EVT0 >>> 0x4321 0210 EVT1 >>> 0x4321 0211 EVT2 >> >> Apparently, the low 8 bits can be overloaded by the efuse. Which makes >> telling EVT1 from EVT2 unreliable. >> >> But at least this is a start. I'll see if I can come up with something >> minimal enough to be merged as a fix. >> >> Thanks, >> >> M. >> -- >> Reality is an implementation detail. >> >> >> -- >> 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 >> > > Would something like this work instead ? It seems to work on EVT0 but > I haven't had a chance to test on EVT1. > > > From a4c1b643596599df9d79776c9b94f2536661a4c9 Mon Sep 17 00:00:00 2001 > From: Angus Ainslie > Date: Tue, 14 Jun 2011 16:13:35 -0600 > Subject: [PATCH] ARM: exynos4: fix secondary CPU boot on early SoC revisions > > It appears that the system-wide flags register that used to be at > 0x02025000 on the first revision of Exynos4 has moved to 0x0202. > > The kernel has been updated accordingly, but this unfortunately leaves > early boards without SMP support (the secondary CPU spins endlessly > in BL0 waiting for an address to be written at that memory location). > > Use the CPU id to decide whether we are running on EVT0 and use the > old location in that case. Hi Angus, Now this information is also required for other device drivers such as OneNAND. So can you make a generic function at common place such as plat-s5p? I mean we need a generic helper function for handling the EVT version at samsung platform. Thank you, Kyungmin Park > > Signed-off-by: Marc Zyngier > Signed-off-by: Angus Ainslie > --- > arch/arm/mach-exynos4/include/mach/map.h | 1
Re: [PATCH 0/4] s3c-fb: Add support S5PV310 FIMD
CCed Display developers from other Samsung open source team On Sat, Jun 11, 2011 at 9:19 PM, Sylwester Nawrocki wrote: > Hi Anand, > > On 06/10/2011 10:15 AM, Anand Kumar N wrote: >> This patch series is based on the latest >> git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-next >> >> This was originally submitted by Jonghun Han >> http://www.spinics.net/lists/arm-kernel/msg101781.html >> This patchset has been not picked up in the mainline due to the >> unavailibility >> of cldev lookup. So it is being re-submitted rebased to 3.0.0-rc1 and tested >> over the clkdev patches. > > As far as I can see there is no functional changes in these patches comparing > to the original ones. AFAIR the idea with clkdev was to create clock to device > mapping for each SoC variant and have driver using unified clock names across > SoC variants. There is nothing close to that in your following patches. > > Moreover looking at the S5PC110 datasheet only, the list of possible sclk_fimd > parent clocks is specified as "All possible clock sources". It exactly means: > XXTI, XusbXTI, SCLK_HDMI_27M, SCLK_USBPHY_0, SCLK_USBPHY_1, SCLK_HDMIPHY, > SCLK_M_PLL, SCLK_E_PLL, SCLK_V_PLL. So quite many, whereas you are trying > to forcibly use in the driver SCLK_M_PLL only. As it has been pointed out > setting FIMD clock parent should be moved away to board code/DT/bootloader, > which allows to use the driver in unchanged form in various system > configurations. Let the board designer to make decisions about the clock > configurations. > > -- > Regards, > Sylwester > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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/4] ASoC: SAMSUNG: Add I2S0 internal dma driver
void idma_free(struct snd_pcm *pcm)
> +{
> + struct snd_pcm_substream *substream;
> + struct snd_dma_buffer *buf;
> +
> + pr_debug("Entered %s\n", __func__);
> +
> + substream = pcm->streams[SNDRV_PCM_STREAM_PLAYBACK].substream;
> + if (!substream)
> + return;
> +
> + buf = &substream->dma_buffer;
> + if (!buf->area)
> + return;
> +
> + iounmap(buf->area);
> +
> + buf->area = NULL;
> + buf->addr = 0;
> +}
> +
> +static int preallocate_idma_buffer(struct snd_pcm *pcm, int stream)
> +{
> + struct snd_pcm_substream *substream = pcm->streams[stream].substream;
> + struct snd_dma_buffer *buf = &substream->dma_buffer;
> +
> + pr_debug("Entered %s\n", __func__);
> + buf->dev.dev = pcm->card->dev;
> + buf->private_data = NULL;
> +
> + /* Assign PCM buffer pointers */
> + buf->dev.type = SNDRV_DMA_TYPE_CONTINUOUS;
> + buf->addr = LP_TXBUFF_ADDR;
> + buf->bytes = idma_hardware.buffer_bytes_max;
> + buf->area = (unsigned char *)ioremap(buf->addr, buf->bytes);
> + pr_debug("%s: VA-%p PA-%X %ubytes\n",
> + __func__, buf->area, buf->addr, buf->bytes);
> +
> + return 0;
> +}
> +
> +static u64 idma_mask = DMA_BIT_MASK(32);
> +
> +static int idma_new(struct snd_card *card,
> + struct snd_soc_dai *dai, struct snd_pcm *pcm)
> +{
> + int ret = 0;
> +
> + pr_debug("Entered %s\n", __func__);
> + if (!card->dev->dma_mask)
> + card->dev->dma_mask = &idma_mask;
> + if (!card->dev->coherent_dma_mask)
> + card->dev->coherent_dma_mask = DMA_BIT_MASK(32);
> +
> + if (dai->driver->playback.channels_min)
> + ret = preallocate_idma_buffer(pcm,
> + SNDRV_PCM_STREAM_PLAYBACK);
> +
> + return ret;
> +}
> +
> +void idma_init(void *regs)
> +{
> + spin_lock_init(&idma.lock);
> + idma.regs = regs;
> +}
> +
> +struct snd_soc_platform_driver asoc_idma_platform = {
> + .ops = &idma_ops,
> + .pcm_new = idma_new,
> + .pcm_free = idma_free,
> +};
> +
> +static int __devinit asoc_idma_platform_probe(struct platform_device *pdev)
> +{
> + return snd_soc_register_platform(&pdev->dev, &asoc_idma_platform);
> +}
> +
> +static int __devexit asoc_idma_platform_remove(struct platform_device *pdev)
> +{
> + snd_soc_unregister_platform(&pdev->dev);
> + return 0;
> +}
> +
> +static struct platform_driver asoc_idma_driver = {
> + .driver = {
> + .name = "samsung-idma",
> + .owner = THIS_MODULE,
> + },
> +
> + .probe = asoc_idma_platform_probe,
> + .remove = __devexit_p(asoc_idma_platform_remove),
> +};
> +
> +static int __init asoc_idma_init(void)
> +{
> + return platform_driver_register(&asoc_idma_driver);
> +}
> +module_init(asoc_idma_init);
> +
> +static void __exit asoc_idma_exit(void)
> +{
> + platform_driver_unregister(&asoc_idma_driver);
> +}
> +module_exit(asoc_idma_exit);
> +
> +MODULE_AUTHOR("Sangbeom Kim, ");
> +MODULE_DESCRIPTION("Samsung ASoC IDMA Driver");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:samsung-idma");
> diff --git a/sound/soc/samsung/idma.h b/sound/soc/samsung/idma.h
> new file mode 100644
> index 000..2b0ac37
> --- /dev/null
> +++ b/sound/soc/samsung/idma.h
> @@ -0,0 +1,28 @@
> +/*
> + * idma.h -- I2S0's Internal Dma driver
> + *
> + * Copyright (c) 2010 Samsung Electronics Co. Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + */
> +
> +#ifndef __S3C_IDMA_H_
> +#define __S3C_IDMA_H_
> +
> +#ifdef CONFIG_ARCH_EXYNOS4
> +#define LP_TXBUFF_ADDR (0x0202)
> +#else
> +#define LP_TXBUFF_ADDR (0xC000)
> +#endif
Are there more fancy way to define the internal DMA address?
Are you sure new EXYNOS4 series will use the same address?
Thank you,
Kyungmin Park
> +
> +/* idma_state */
> +#define LPAM_DMA_STOP 0
> +#define LPAM_DMA_START 1
> +
> +extern void idma_init(void *regs);
> +
> +#endif /* __S3C_IDMA_H_ */
> --
> 1.7.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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: S5PV210: Fix build breakage due to renaming of S3C_VA_USB_HSPHY
On Wed, Jun 8, 2011 at 10:53 PM, Marek Szyprowski
wrote:
> Hello,
>
> There is already the patch that fixes this issue available on
> kgene/s5p_fixes_for_linus branch. Please check commit 08115a139 from
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>
> On Wednesday, June 08, 2011 1:26 PM Thomas Abraham wrote:
>
>> Commit 8f1d169f999fea892c3fcbf5a79ae8525a477572
>> ("ARM: EXYNOS4: Add usb host phy control") renamed S3C_VA_USB_HSPHY
>> to S5P_VA_USB_HSPHY in s5p-map.h file. Fix build for S5PV210 platform.
Hi Thomas & Marek,
We lived for long time with mismatch prefix.
So how about to clean up the mismatch prefix, S3C_* and S5P_* at this time?
One method is that it just passes the physical address and driver
should ioremap at driver instead of static mapping.
How do you think?
Thank you,
Kyungmin Park
>>
>> Signed-off-by: Thomas Abraham
>> ---
>> arch/arm/mach-s5pv210/cpu.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-s5pv210/cpu.c b/arch/arm/mach-s5pv210/cpu.c
>> index 61e6c24..b343582 100644
>> --- a/arch/arm/mach-s5pv210/cpu.c
>> +++ b/arch/arm/mach-s5pv210/cpu.c
>> @@ -91,7 +91,7 @@ static struct map_desc s5pv210_iodesc[] __initdata = {
>> .length = SZ_4K,
>> .type = MT_DEVICE,
>> }, {
>> - .virtual = (unsigned long)S3C_VA_USB_HSPHY,
>> + .virtual = (unsigned long)S5P_VA_USB_HSPHY,
>> .pfn =__phys_to_pfn(S5PV210_PA_HSPHY),
>> .length = SZ_4K,
>> .type = MT_DEVICE,
>> --
>> 1.6.6.rc2
>
> S3C_VA_USB_HSPHY is the correct name, it is also used on s3c64xx and
> s3c-hsotg driver (see drivers/usb/gadget).
>
> Best regards
> --
> Marek Szyprowski
> Samsung Poland R&D Center
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: EXYNOS4: Fix incorrect mapping of gpio pull-up macro to register setting
On Tue, Jun 7, 2011 at 5:34 PM, Thomas Abraham wrote:
> The S3C_GPIO_PULL_UP macro value incorrectly maps to a reserved setting of
> GPIO
> pull up/down registers on Exynos4 platform. Fix this incorrect mapping by
> adding
> wrappers to the s3c_gpio_setpull_updown and s3c_gpio_getpull_updown functions.
Personally I like to use the variable instead of function hooking.
set the correct variable at cpu dection and use it
then these thing make a single generic function and each gpio_cfg use
the same thing.
Anyway it's next step. current fix the bug first.
Acked-by: Kyungmin Park
>
> Signed-off-by: Thomas Abraham
> ---
> drivers/gpio/gpio-exynos4.c | 29 +
> 1 files changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpio/gpio-exynos4.c b/drivers/gpio/gpio-exynos4.c
> index d54ca6a..9029835 100644
> --- a/drivers/gpio/gpio-exynos4.c
> +++ b/drivers/gpio/gpio-exynos4.c
> @@ -21,16 +21,37 @@
> #include
> #include
>
> +int s3c_gpio_setpull_exynos4(struct s3c_gpio_chip *chip,
> + unsigned int off, s3c_gpio_pull_t pull)
> +{
> + if (pull == S3C_GPIO_PULL_UP)
> + pull = 3;
> +
> + return s3c_gpio_setpull_updown(chip, off, pull);
> +}
static?
> +
> +s3c_gpio_pull_t s3c_gpio_getpull_exynos4(struct s3c_gpio_chip *chip,
> + unsigned int off)
> +{
> + s3c_gpio_pull_t pull;
> +
> + pull = s3c_gpio_getpull_updown(chip, off);
> + if (pull == 3)
> + pull = S3C_GPIO_PULL_UP;
> +
> + return pull;
> +}
ditto.
> +
> static struct s3c_gpio_cfg gpio_cfg = {
> .set_config = s3c_gpio_setcfg_s3c64xx_4bit,
> - .set_pull = s3c_gpio_setpull_updown,
> - .get_pull = s3c_gpio_getpull_updown,
> + .set_pull = s3c_gpio_setpull_exynos4,
> + .get_pull = s3c_gpio_getpull_exynos4,
> };
>
> static struct s3c_gpio_cfg gpio_cfg_noint = {
> .set_config = s3c_gpio_setcfg_s3c64xx_4bit,
> - .set_pull = s3c_gpio_setpull_updown,
> - .get_pull = s3c_gpio_getpull_updown,
> + .set_pull = s3c_gpio_setpull_exynos4,
> + .get_pull = s3c_gpio_getpull_exynos4,
> };
>
> /*
> --
> 1.6.6.rc2
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM:SAMSUNG: Move S3C DMA driver to drivers/dma
On Tue, Jun 7, 2011 at 5:15 PM, Russell King - ARM Linux wrote: > On Tue, Jun 07, 2011 at 01:39:43PM +0530, Jassi Brar wrote: >> Unfortunately, no. There are some features of Samsung's DMA API that >> the drivers have come to rely upon. >> Besides, I am not particularly a fan of the generic API. And IIRC, >> neither is Ben Dooks, the designer of the >> Samsung's DMA API. > > We are now at the point where this is non-optional. If the generic API > doesn't fit what Samsung needs, then that needs to be discussed and > whatever problems there are need to be resolved. > > Continuing the platform specific DMA APIs is not sustainable. > > I'm getting rather fed up with Samsung needing custom this and that, and > refusing to use the generic infrastructure such as clkdev. This attitude > needs to change NOW. > > Fix your platform specific crap and start using the generic services. > I think Jassi is the right person to handle this one even though you don't like the generic DMA APIs 1) since you become a member of linaro. it's role of linaro. 2) know the how to use the s3c-pl330 at sound (most user of DMA is sound, SPI and MMC) 3) now you're the Samsung Sound maintainer If we move the generic DMA APIs, it's also need to modify the its consumer, sound and SPI. Thank you, Kyungmin Park -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: exynos4: fix secondary CPU boot
On Thu, Jun 2, 2011 at 5:34 PM, Marc Zyngier wrote: > On Thu, 2011-06-02 at 16:01 +0900, Kyungmin Park wrote: >> On Fri, May 27, 2011 at 12:11 AM, Marc Zyngier wrote: >> > On Wed, 2011-05-25 at 12:06 -0700, Kukjin Kim wrote: >> >> On 05/25/11 11:04, Marc Zyngier wrote: >> >> > On Wed, 2011-05-25 at 10:28 -0700, Kukjin Kim wrote: >> >> >> On 05/20/11 06:46, Marc Zyngier wrote: >> >> >> >> (snip) >> >> >> >> > So that address has changed between two SoC revisions? That's >> >> > unfortunate, to say the least. I'm most probably using an early revision >> >> > of the hardware (EVT0?), as it doesn't even support MCT. >> >> > >> >> I'm afraid :( and I agree secondary CPU should work on all of >> >> Exynos4210. But I'm still think about the method... >> >> >> >> > What about the following patch? >> >> > >> >> Uhm...this is really hack but I'd like to use another normal way...? >> > >> > Oh, no question about the hack status. The trouble is, unless there is a >> > sure way to tell which SoC revision we're running on, there's little >> > else we can do than poke both locations and pray. >> > >> > Is there such a way to identify the SoC revision? >> >> It's also required for OneNAND. as you know C210 EVT0 OneNAND DMA has >> bug and need to workaround. >> >> platform codes should provide the these function. please see the OMAP >> codes. how to handle it. > > So we know there's a need beyond the wish to see the second core up and > running on my board. > > Now what is the proper method to detect the revision of the SOC? > Handling it is no problem, once we have the information. Unfortunately > the documentation I have is less than helpful on that subject. It can be distinguished by chip id. but there's no code to handle this one. 0x4320 0200 EVT0 0x4321 0210 EVT1 0x4321 0211 EVT2 Thank you, Kyungmin Park > > Cheers, > > M. > -- > Reality is an implementation detail. > > > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: exynos4: fix secondary CPU boot
On Fri, May 27, 2011 at 12:11 AM, Marc Zyngier wrote:
> On Wed, 2011-05-25 at 12:06 -0700, Kukjin Kim wrote:
>> On 05/25/11 11:04, Marc Zyngier wrote:
>> > On Wed, 2011-05-25 at 10:28 -0700, Kukjin Kim wrote:
>> >> On 05/20/11 06:46, Marc Zyngier wrote:
>>
>> (snip)
>>
>> > So that address has changed between two SoC revisions? That's
>> > unfortunate, to say the least. I'm most probably using an early revision
>> > of the hardware (EVT0?), as it doesn't even support MCT.
>> >
>> I'm afraid :( and I agree secondary CPU should work on all of
>> Exynos4210. But I'm still think about the method...
>>
>> > What about the following patch?
>> >
>> Uhm...this is really hack but I'd like to use another normal way...?
>
> Oh, no question about the hack status. The trouble is, unless there is a
> sure way to tell which SoC revision we're running on, there's little
> else we can do than poke both locations and pray.
>
> Is there such a way to identify the SoC revision?
It's also required for OneNAND. as you know C210 EVT0 OneNAND DMA has
bug and need to workaround.
platform codes should provide the these function. please see the OMAP
codes. how to handle it.
Thank you,
Kyungmin Park
>
>> >> From c27e75b86e1ee181987a9364286a888421e76205 Mon Sep 17 00:00:00 2001
>> > From: Marc Zyngier
>> > Date: Fri, 20 May 2011 14:38:25 +0100
>> > Subject: [PATCH] ARM: exynos4: fix secondary CPU boot on early SoC
>> > revisions
>> >
>> > It appears that the system-wide flags register that used to be at
>> > 0x02025000 on the first revision of Exynos4 has moved to 0x0202.
>> >
>> > The kernel has been updated accordingly, but this unfortunately leaves
>> > early boards without SMP support (the secondary CPU spins endlessly
>> > in BL0 waiting for an address to be written at that memory location).
>> >
>> > Try to solve the problem by poking both locations. This should be
>> > safe as this is done early enough in the kernel boot process, and nobody
>> > should be using the SRAM yet.
>> >
>> > Tested on a vintage SMDK-v310.
>>
>> vintage ;)
>
> Well, I thought I was the uber-cool guy in the office because of that
> shiny blue board on my desk, only to discover that it's sooo last
> year... ;-)
>
>> >
>> > Cc: Kukjin Kim
>> > Signed-off-by: Marc Zyngier
>> > ---
>> > arch/arm/mach-exynos4/include/mach/map.h | 1 +
>> > arch/arm/mach-exynos4/platsmp.c | 14 ++
>> > 2 files changed, 15 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/arch/arm/mach-exynos4/include/mach/map.h
>> > b/arch/arm/mach-exynos4/include/mach/map.h
>> > index 0009e77..781e149 100644
>> > --- a/arch/arm/mach-exynos4/include/mach/map.h
>> > +++ b/arch/arm/mach-exynos4/include/mach/map.h
>> > @@ -24,6 +24,7 @@
>> > #include
>> >
>> > #define EXYNOS4_PA_SYSRAM 0x0202
>> > +#define EXYNOS4_PA_SYSRAM_EVT0 0x02025000
>> >
>> > #define EXYNOS4_PA_FIMC0 0x1180
>> > #define EXYNOS4_PA_FIMC1 0x1181
>> > diff --git a/arch/arm/mach-exynos4/platsmp.c
>> > b/arch/arm/mach-exynos4/platsmp.c
>> > index c5e65a0..f261c34 100644
>> > --- a/arch/arm/mach-exynos4/platsmp.c
>> > +++ b/arch/arm/mach-exynos4/platsmp.c
>> > @@ -155,6 +155,7 @@ void __init smp_init_cpus(void)
>> > void __init platform_smp_prepare_cpus(unsigned int max_cpus)
>> > {
>> > int i;
>> > + void __iomem *sysram_evt0;
>> >
>> > /*
>> > * Initialise the present map, which describes the set of CPUs
>> > @@ -172,4 +173,17 @@ void __init platform_smp_prepare_cpus(unsigned int
>> > max_cpus)
>> > * secondary CPU branches to this address.
>> > */
>> > __raw_writel(BSYM(virt_to_phys(exynos4_secondary_startup)),
>> > S5P_VA_SYSRAM);
>> > +
>> > + /*
>> > + * EVT0 has the system-wide flags register at a different address.
>> > + * Poke it as well, in case we're running on an old SoC revision.
>> > + */
>> > + sysram_evt0 = ioremap(EXYNOS4_PA_SYSRAM_EVT0, SZ_4K);
>>
>> Hmm...first of all, need to check whether can ioremap the area on newer
>> one but I'm out off office now so will check it after backing.
>
> The only documentation I have access to refers t
Re: [PATCH] [CPUFREQ] Move ARM Samsung cpufreq drivers to drivers/cpufreq/
Hi, I think you already saw the same patchs[1] at mailing list and even worse you commented it[2] One different is kconfig handling. and these can be handled easily as you did. Please respect others works. Thank you, Kyungmin Park 1. http://www.gossamer-threads.com/lists/linux/kernel/1385739?page=last 2. http://www.spinics.net/lists/cpufreq/msg02262.html On Thu, Jun 2, 2011 at 6:18 AM, Kukjin Kim wrote: > According to discussion of the ARM arch subsystem migration, > ARM cpufreq drivers move to drivers/cpufreq. So this patch > adds Kconfig.arm for ARM like x86 and adds Samsung S5PV210 > and EXYNOS4210 cpufreq driver compile in there. > As a note, otherw will be moved. > > Cc: Dave Jones > Signed-off-by: Kukjin Kim > --- > arch/arm/mach-exynos4/Makefile | 1 - > arch/arm/mach-s5pv210/Makefile | 1 - > drivers/cpufreq/Kconfig | 5 > drivers/cpufreq/Kconfig.arm | 23 > > drivers/cpufreq/Makefile | 2 + > .../cpufreq/exynos4210-cpufreq.c | 3 +- > .../cpufreq.c => drivers/cpufreq/s5pv210-cpufreq.c | 3 +- > 7 files changed, 32 insertions(+), 6 deletions(-) > create mode 100644 drivers/cpufreq/Kconfig.arm > rename arch/arm/mach-exynos4/cpufreq.c => > drivers/cpufreq/exynos4210-cpufreq.c (99%) > rename arch/arm/mach-s5pv210/cpufreq.c => drivers/cpufreq/s5pv210-cpufreq.c > (99%) > > diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile > index a9bb94f..0cebfa7 100644 > --- a/arch/arm/mach-exynos4/Makefile > +++ b/arch/arm/mach-exynos4/Makefile > @@ -15,7 +15,6 @@ obj- := > obj-$(CONFIG_CPU_EXYNOS4210) += cpu.o init.o clock.o irq-combiner.o > obj-$(CONFIG_CPU_EXYNOS4210) += setup-i2c0.o irq-eint.o dma.o > obj-$(CONFIG_PM) += pm.o sleep.o > -obj-$(CONFIG_CPU_FREQ) += cpufreq.o > obj-$(CONFIG_CPU_IDLE) += cpuidle.o > > obj-$(CONFIG_SMP) += platsmp.o headsmp.o > diff --git a/arch/arm/mach-s5pv210/Makefile b/arch/arm/mach-s5pv210/Makefile > index 50907ac..599a3c0 100644 > --- a/arch/arm/mach-s5pv210/Makefile > +++ b/arch/arm/mach-s5pv210/Makefile > @@ -15,7 +15,6 @@ obj- := > obj-$(CONFIG_CPU_S5PV210) += cpu.o init.o clock.o dma.o > obj-$(CONFIG_CPU_S5PV210) += setup-i2c0.o > obj-$(CONFIG_S5PV210_PM) += pm.o sleep.o > -obj-$(CONFIG_CPU_FREQ) += cpufreq.o > > # machine support > > diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig > index 9fb8485..e898215 100644 > --- a/drivers/cpufreq/Kconfig > +++ b/drivers/cpufreq/Kconfig > @@ -184,5 +184,10 @@ depends on X86 > source "drivers/cpufreq/Kconfig.x86" > endmenu > > +menu "ARM CPU frequency scaling drivers" > +depends on ARM > +source "drivers/cpufreq/Kconfig.arm" > +endmenu > + > endif > endmenu > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm > new file mode 100644 > index 000..fafdbb8 > --- /dev/null > +++ b/drivers/cpufreq/Kconfig.arm > @@ -0,0 +1,23 @@ > +# > +# ARM CPU Frequency scaling drivers > +# > + > +config ARM_S5PV210_CPUFREQ > + bool "Samsung S5PV210 and S5PC110" > + depends on CPU_S5PV210 > + default y > + help > + This adds the CPUFreq driver for Samsung S5PV210 and > + S5PC110 SoCs. > + > + If in doubt, say N. > + > +config ARM_EXYNOS4210_CPUFREQ > + bool "Samsung EXYNOS4210" > + depends on CPU_EXYNOS4210 > + default y > + help > + This adds the CPUFreq driver for Samsung EXYNOS4210 > + SoC (S5PV310 or S5PC210). > + > + If in doubt, say N. > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile > index e2fc2d2..864a27c 100644 > --- a/drivers/cpufreq/Makefile > +++ b/drivers/cpufreq/Makefile > @@ -41,3 +41,5 @@ obj-$(CONFIG_X86_CPUFREQ_NFORCE2) += cpufreq-nforce2.o > > # ARM SoC drivers > obj-$(CONFIG_UX500_SOC_DB8500) += db8500-cpufreq.o > +obj-$(CONFIG_ARM_S5PV210_CPUFREQ) += s5pv210-cpufreq.o > +obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o > diff --git a/arch/arm/mach-exynos4/cpufreq.c > b/drivers/cpufreq/exynos4210-cpufreq.c > similarity index 99% > rename from arch/arm/mach-exynos4/cpufreq.c > rename to drivers/cpufreq/exynos4210-cpufreq.c > index a1bd258..54025fc 100644 > --- a/arch/arm/mach-exynos4/cpufreq.c > +++ b/drivers/cpufreq/exynos4210-cpufreq.c > @@ -1,5 +1,4 @@ > -/* linux/arch/arm/mach-exynos4/cpufreq.c > - * > +/*
Re: [PATCH v2 7/7] ARM: Exynos4: Add clkdev support
On Sat, May 28, 2011 at 11:33 AM, Kyungmin Park wrote:
> On Sat, May 28, 2011 at 11:14 AM, Kukjin Kim wrote:
>>
>>
>> On 05/27/11 18:53, Kyungmin Park wrote:
>>>
>>> On Sat, May 28, 2011 at 12:26 AM, Thomas Abraham
>>> wrote:
>>>>
>>>> Add clkdev support for Samsung's Exynos4 platform and fixes the
>>>> incorrect clock name for the dw_mmc controller.
>>>>
>>>> Signed-off-by: Thomas Abraham
>>>> ---
>>>> arch/arm/Kconfig | 1 +
>>>> arch/arm/mach-exynos4/clock.c | 178
>>>> +--
>>>> arch/arm/mach-exynos4/include/mach/clkdev.h | 7 +
>>>> arch/arm/mach-exynos4/time.c | 2 +
>>>> 4 files changed, 67 insertions(+), 121 deletions(-)
>>>> create mode 100644 arch/arm/mach-exynos4/include/mach/clkdev.h
>>
>> (snip)
>>
>>>> diff --git a/arch/arm/mach-exynos4/include/mach/clkdev.h
>>>> b/arch/arm/mach-exynos4/include/mach/clkdev.h
>>>> new file mode 100644
>>>> index 000..1247f5e
>>>> --- /dev/null
>>>> +++ b/arch/arm/mach-exynos4/include/mach/clkdev.h
>>>> @@ -0,0 +1,7 @@
>>>> +#ifndef __MACH_EXYNOS4_CLKDEV_H__
>>>> +#define __MACH_EXYNOS4_CLKDEV_H__
>>>> +
>>>> +#define __clk_get(clk) ({ 1; })
>>>> +#define __clk_put(clk) do { } while (0)
>>>> +
>>>> +#endif
>>>
>>> Looks good to me.
>>>
>>> One nitpick
>>> How about to just create the one clkdev.h at plat-samsung with proper
>>> ifdef endif config.
>>> I think don't need to create clkdev.h for each SoCs.
>>
>> No, basically the "mach/clkdev.h" should be added, please see
>> arch/arm/include/asm/clkdev.h.
>
> Okay it's required,
> but also see the others.
> http://git.infradead.org/linux-2.6.git/blob/HEAD:/arch/arm/mach-omap2/include/mach/clkdev.h
>
> 1 /*
> 2 * arch/arm/mach-omap2/include/mach/clkdev.h
> 3 */
> 4
> 5 #include
and
http://git.infradead.org/linux-2.6.git/blob/HEAD:/arch/arm/plat-omap/include/plat/clkdev.h
1 #ifndef __MACH_CLKDEV_H
2 #define __MACH_CLKDEV_H
3
4 static inline int __clk_get(struct clk *clk)
5 {
6 return 1;
7 }
8
9 static inline void __clk_put(struct clk *clk)
10 {
11 }
12
13 #endif
To Arnd,
in case of ARM, it has almost same form. then how about to move the
arm generic one?
>
> Thank you,
> Kyungmin Park
>
--
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 7/7] ARM: Exynos4: Add clkdev support
On Sat, May 28, 2011 at 11:14 AM, Kukjin Kim wrote:
>
>
> On 05/27/11 18:53, Kyungmin Park wrote:
>>
>> On Sat, May 28, 2011 at 12:26 AM, Thomas Abraham
>> wrote:
>>>
>>> Add clkdev support for Samsung's Exynos4 platform and fixes the
>>> incorrect clock name for the dw_mmc controller.
>>>
>>> Signed-off-by: Thomas Abraham
>>> ---
>>> arch/arm/Kconfig | 1 +
>>> arch/arm/mach-exynos4/clock.c | 178
>>> +--
>>> arch/arm/mach-exynos4/include/mach/clkdev.h | 7 +
>>> arch/arm/mach-exynos4/time.c | 2 +
>>> 4 files changed, 67 insertions(+), 121 deletions(-)
>>> create mode 100644 arch/arm/mach-exynos4/include/mach/clkdev.h
>
> (snip)
>
>>> diff --git a/arch/arm/mach-exynos4/include/mach/clkdev.h
>>> b/arch/arm/mach-exynos4/include/mach/clkdev.h
>>> new file mode 100644
>>> index 000..1247f5e
>>> --- /dev/null
>>> +++ b/arch/arm/mach-exynos4/include/mach/clkdev.h
>>> @@ -0,0 +1,7 @@
>>> +#ifndef __MACH_EXYNOS4_CLKDEV_H__
>>> +#define __MACH_EXYNOS4_CLKDEV_H__
>>> +
>>> +#define __clk_get(clk) ({ 1; })
>>> +#define __clk_put(clk) do { } while (0)
>>> +
>>> +#endif
>>
>> Looks good to me.
>>
>> One nitpick
>> How about to just create the one clkdev.h at plat-samsung with proper
>> ifdef endif config.
>> I think don't need to create clkdev.h for each SoCs.
>
> No, basically the "mach/clkdev.h" should be added, please see
> arch/arm/include/asm/clkdev.h.
Okay it's required,
but also see the others.
http://git.infradead.org/linux-2.6.git/blob/HEAD:/arch/arm/mach-omap2/include/mach/clkdev.h
1 /*
2 * arch/arm/mach-omap2/include/mach/clkdev.h
3 */
4
5 #include
Thank you,
Kyungmin Park
--
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 7/7] ARM: Exynos4: Add clkdev support
= {
> .name = "sclk_cam",
> - .id = 0,
> + .devname = "exynos4-fimc.0",
> .enable = exynos4_clksrc_mask_cam_ctrl,
> .ctrlbit = (1 << 16),
> },
> @@ -919,7 +858,7 @@ static struct clksrc_clk clksrcs[] = {
> }, {
> .clk = {
> .name = "sclk_cam",
> - .id = 1,
> + .devname = "exynos4-fimc.1",
> .enable = exynos4_clksrc_mask_cam_ctrl,
> .ctrlbit = (1 << 20),
> },
> @@ -929,7 +868,7 @@ static struct clksrc_clk clksrcs[] = {
> }, {
> .clk = {
> .name = "sclk_fimc",
> - .id = 0,
> + .devname = "exynos4-fimc.0",
> .enable = exynos4_clksrc_mask_cam_ctrl,
> .ctrlbit = (1 << 0),
> },
> @@ -939,7 +878,7 @@ static struct clksrc_clk clksrcs[] = {
> }, {
> .clk = {
> .name = "sclk_fimc",
> - .id = 1,
> + .devname = "exynos4-fimc.1",
> .enable = exynos4_clksrc_mask_cam_ctrl,
> .ctrlbit = (1 << 4),
> },
> @@ -949,7 +888,7 @@ static struct clksrc_clk clksrcs[] = {
> }, {
> .clk = {
> .name = "sclk_fimc",
> - .id = 2,
> + .devname = "exynos4-fimc.2",
> .enable = exynos4_clksrc_mask_cam_ctrl,
> .ctrlbit = (1 << 8),
> },
> @@ -959,7 +898,7 @@ static struct clksrc_clk clksrcs[] = {
> }, {
> .clk = {
> .name = "sclk_fimc",
> - .id = 3,
> + .devname = "exynos4-fimc.3",
> .enable = exynos4_clksrc_mask_cam_ctrl,
> .ctrlbit = (1 << 12),
> },
> @@ -969,7 +908,7 @@ static struct clksrc_clk clksrcs[] = {
> }, {
> .clk = {
> .name = "sclk_fimd",
> - .id = 0,
> + .devname = "s5pv310-fb.0",
> .enable = exynos4_clksrc_mask_lcd0_ctrl,
> .ctrlbit = (1 << 0),
> },
> @@ -979,7 +918,7 @@ static struct clksrc_clk clksrcs[] = {
> }, {
> .clk = {
> .name = "sclk_fimd",
> - .id = 1,
> + .devname = "s5pv310-fb.1",
> .enable = exynos4_clksrc_mask_lcd1_ctrl,
> .ctrlbit = (1 << 0),
> },
> @@ -989,7 +928,6 @@ static struct clksrc_clk clksrcs[] = {
> }, {
> .clk = {
> .name = "sclk_sata",
> - .id = -1,
> .enable = exynos4_clksrc_mask_fsys_ctrl,
> .ctrlbit = (1 << 24),
> },
> @@ -999,7 +937,7 @@ static struct clksrc_clk clksrcs[] = {
> }, {
> .clk = {
> .name = "sclk_spi",
> - .id = 0,
> + .devname = "s3c64xx-spi.0",
> .enable = exynos4_clksrc_mask_peril1_ctrl,
> .ctrlbit = (1 << 16),
> },
> @@ -1009,7 +947,7 @@ static struct clksrc_clk clksrcs[] = {
> }, {
> .clk = {
> .name = "sclk_spi",
> - .id = 1,
> + .devname = "s3c64xx-spi.1",
> .enable = exynos4_clksrc_mask_peril1_ctrl,
> .ctrlbi
Re: Cleanup Samsung stuff
On Tue, Apr 19, 2011 at 10:46 AM, Kukjin Kim wrote:
> Hi all,
>
> I think, you know about current situation of Linux ARM world.
>
> So...
>
> As Russell suggested, I also will focus on consolidations and bug fixes for
> Samsung stuff for a while so don't complain about missing new stuff. In my
> opinion, we can keep going it later...
>
> As a note, I'm doing(or preparing) following at the moment.
>
> - Removing some "mach-s5p"s
Why not mach-s3c series? don't you think too much plat-{s3c, s5p,
samsung}? how about to use the plat-samsung only?
> - Removing useless header files in include/{mach,plat} of Samsung
> - Samsung GPIO stuff cleanup/consolidation
> - Samsung DMA stuff consolidation?
-> Move to dmaengine and use it.
> - Device tree (with Linaro)
> - and so on...
- Strange Samsung Clock and names consolidation.
- IRQ stuff (some parts are done by tglx but need to use the
generic IRQ base instead of odd +32 magic)
- generic IOMMU consolidation.
BTW, who works on this at LSI?
Thank you,
Kyungmin Park
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Samsung fixes for 2.6.39-rc4
Hi, Can you check this patch also? http://lists.arm.linux.org.uk/lurker/message/20110329.064902.fb2f620c.en.html Fix cpuinit section mismatch(es). WARNING: modpost: Found 2 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' Thank you, Kyungmin Park On Mon, Apr 18, 2011 at 6:22 AM, Kukjin Kim wrote: > Hi Linus, > > Please pull Samsung fixes from: > > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > s5p-fixes-for-linus > > These things are small fixes for 2.6.39-rc4. > If any problems, please let me know. > > Thanks. > > Best regards, > Kgene. > -- > Kukjin Kim , Senior Engineer, > SW Solution Development Team, Samsung Electronics Co., Ltd. > > The following changes since commit a6360dd37e1a144ed11e6548371bade559a1e4df: > > Linux 2.6.39-rc3 (2011-04-11 17:21:51 -0700) > > are available in the git repository at: > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > s5p-fixes-for-linus > > Abhilash Kesavan (2): > ARM: S5P: Remove unused s3c_pm_check_resume_pin > ARM: SAMSUNG: Fix build failure in PM CRC check code > > Maurus Cuelenaere (1): > ARM: SAMSUNG: Fix warning 's3c_pm_show_resume_irqs' defined but not > used > > arch/arm/plat-s5p/pm.c | 11 --- > arch/arm/plat-samsung/pm-check.c | 6 -- > arch/arm/plat-samsung/pm.c | 5 +++-- > 3 files changed, 3 insertions(+), 19 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] ARM: SAMSUNG: Add clkdev support for exynos4
.enable = exynos4_clksrc_mask_peril1_ctrl,
> .ctrlbit = (1 << 16),
> @@ -1009,6 +1059,7 @@ static struct clksrc_clk clksrcs[] = {
> }, {
> .clk = {
> .name = "sclk_spi",
> + .devname = "s3c64xx-spi.1",
> .id = 1,
> .enable = exynos4_clksrc_mask_peril1_ctrl,
> .ctrlbit = (1 << 20),
> @@ -1019,6 +1070,7 @@ static struct clksrc_clk clksrcs[] = {
> }, {
> .clk = {
> .name = "sclk_spi",
> + .devname = "s3c64xx-spi.2",
> .id = 2,
> .enable = exynos4_clksrc_mask_peril1_ctrl,
> .ctrlbit = (1 << 24),
> @@ -1037,6 +1089,7 @@ static struct clksrc_clk clksrcs[] = {
> }, {
> .clk = {
> .name = "sclk_mmc",
> + .devname = "s3c-sdhci.0",
> .id = 0,
> .parent = &clk_dout_mmc0.clk,
> .enable = exynos4_clksrc_mask_fsys_ctrl,
> @@ -1046,6 +1099,7 @@ static struct clksrc_clk clksrcs[] = {
> }, {
> .clk = {
> .name = "sclk_mmc",
> + .devname = "s3c-sdhci.1",
> .id = 1,
> .parent = &clk_dout_mmc1.clk,
> .enable = exynos4_clksrc_mask_fsys_ctrl,
> @@ -1055,6 +1109,7 @@ static struct clksrc_clk clksrcs[] = {
> }, {
> .clk = {
> .name = "sclk_mmc",
> + .devname = "s3c-sdhci.2",
> .id = 2,
> .parent = &clk_dout_mmc2.clk,
> .enable = exynos4_clksrc_mask_fsys_ctrl,
> @@ -1064,6 +1119,7 @@ static struct clksrc_clk clksrcs[] = {
> }, {
> .clk = {
> .name = "sclk_mmc",
> + .devname = "s3c-sdhci.3",
> .id = 3,
> .parent = &clk_dout_mmc3.clk,
> .enable = exynos4_clksrc_mask_fsys_ctrl,
> @@ -1073,6 +1129,7 @@ static struct clksrc_clk clksrcs[] = {
> }, {
> .clk = {
> .name = "sclk_mmc",
> + .devname = "s3c-sdhci.4",
> .id = 4,
> .parent = &clk_dout_mmc4.clk,
> .enable = exynos4_clksrc_mask_fsys_ctrl,
> diff --git a/arch/arm/mach-exynos4/include/mach/clkdev.h
> b/arch/arm/mach-exynos4/include/mach/clkdev.h
> new file mode 100644
> index 000..1247f5e
> --- /dev/null
> +++ b/arch/arm/mach-exynos4/include/mach/clkdev.h
> @@ -0,0 +1,7 @@
> +#ifndef __MACH_EXYNOS4_CLKDEV_H__
> +#define __MACH_EXYNOS4_CLKDEV_H__
> +
> +#define __clk_get(clk) ({ 1; })
> +#define __clk_put(clk) do { } while (0)
> +
> +#endif
> diff --git a/arch/arm/mach-exynos4/time.c b/arch/arm/mach-exynos4/time.c
> index 86b9fa0..cb63f97 100644
> --- a/arch/arm/mach-exynos4/time.c
> +++ b/arch/arm/mach-exynos4/time.c
> @@ -262,6 +262,7 @@ static void __init exynos4_timer_resources(void)
> clk_enable(timerclk);
>
> tmpdev.id = 2;
> + tmpdev.dev.init_name = "s3c24xx-pwm.2";
what's this? why does it need at here?
Thank you,
Kyungmin Park
> tin2 = clk_get(&tmpdev.dev, "pwm-tin");
> if (IS_ERR(tin2))
> panic("failed to get pwm-tin2 clock for system timer");
> @@ -272,6 +273,7 @@ static void __init exynos4_timer_resources(void)
> clk_enable(tin2);
>
> tmpdev.id = 4;
> + tmpdev.dev.init_name = "s3c24xx-pwm.4";
> tin4 = clk_get(&tmpdev.dev, "pwm-tin");
> if (IS_ERR(tin4))
> panic("failed to get pwm-tin4 clock for system timer");
> diff --git a/arch/arm/plat-samsung/pwm-clock.c
> b/arch/arm/plat-samsung/pwm-clock.c
> index 46c9381..f1bba88 100644
> --- a/arch/arm/plat-samsung/pwm-clock.c
> +++ b/arc
Re: [PATCH 0/2] ARM: EXYNOS4: Enhancement of System MMU
On Tue, Mar 15, 2011 at 10:35 PM, Kukjin Kim wrote: > KyongHo Cho wrote: >> >> This patch includes the following enhancements for System MMU: >> - Enhanced readability >> - Removal of unused data structures or their members >> - Simplified function definitions >> - Corrections of some logical errors >> - Full compliance with Linux coding style >> - Simpler way of registering callback functions of System MMU faults >> - Add clock gating for System MMU >> >> [PATCH 1/2] ARM: EXYNOS4: Enhancement of System MMU driver >> [PATCH 2/2] ARM: EXYNOS4: Implement Clock gating for System MMU > > Cc'ed Marek. > > As I said before, Marek's SystemMMU driver has some problems. > > One is that it allocates 4MB virtual memory at once. It is really a problem > because, the device memory manager must knows the peculiarity and handles > it. Otherwise, page tables can be overwritten... Are there device drivers using system MMU at mainline? or example codes? In case of Marek's patches, he posted drivers codes and tested at multimedia stack. Another one is what's the difference between MFC drivers case and SystemMMU one? and I hope you read this mail thread. http://www.mentby.com/Group/linux-kernel/patch-maintainers-update-msm-maintainers.html Cite from Linus words. Actually, "the community" (not that there really is any such cohesive thing) generally asks that vendors be "involved". Not that vendors be "exclusively in control". There's a big difference. I feel you control the s5p codes for vendor purpose. Thank you, Kyungmin Park > > Anyway, I think Marek's initial idea is good esp., clock handling. > But now, this looks better for its enhancement and as we know if required, > we can improve this later. > > Applied, 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: EXYNOS4: CPUIDLE Support
On Tue, Mar 15, 2011 at 10:57 PM, Kukjin Kim wrote:
> Jaecheol Lee wrote:
>>
>> This patch supports cpuidle framework for EXYNOS4210. Currently,
>> Only one idle state is possible to use, but more idle states can
>> be added following by this patch.
>>
>> Signed-off-by: Jaecheol Lee
>> ---
>> arch/arm/mach-exynos4/Makefile | 1 +
>> arch/arm/mach-exynos4/cpuidle.c | 87
>> +++
>> 2 files changed, 88 insertions(+), 0 deletions(-)
>> create mode 100644 arch/arm/mach-exynos4/cpuidle.c
>>
>> diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-
> exynos4/Makefile
>> index 461ae57..bf206fa 100644
>> --- a/arch/arm/mach-exynos4/Makefile
>> +++ b/arch/arm/mach-exynos4/Makefile
>> @@ -16,6 +16,7 @@ obj-$(CONFIG_CPU_EXYNOS4210) += cpu.o init.o
> clock.o
>> irq-combiner.o
>> obj-$(CONFIG_CPU_EXYNOS4210) += cpu.o init.o clock.o irq-combiner.o
>> obj-$(CONFIG_CPU_EXYNOS4210) += setup-i2c0.o time.o gpiolib.o irq-eint.o
>> dma.o
>> obj-$(CONFIG_CPU_FREQ) += cpufreq.o
>> +obj-$(CONFIG_CPU_IDLE) += cpuidle.o
>>
>> obj-$(CONFIG_SMP) += platsmp.o headsmp.o
>> obj-$(CONFIG_LOCAL_TIMERS) += localtimer.o
>> diff --git a/arch/arm/mach-exynos4/cpuidle.c b/arch/arm/mach-
>> exynos4/cpuidle.c
>> new file mode 100644
>> index 000..a543a18
>> --- /dev/null
>> +++ b/arch/arm/mach-exynos4/cpuidle.c
>> @@ -0,0 +1,87 @@
>> +/* linux/arch/arm/mach-exynos4/cpuidle.c
>> + *
>> + * Copyright (c) 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
>> +
>> +static int exynos4_enter_idle(struct cpuidle_device *dev,
>> + struct cpuidle_state *state);
>> +
>> +static struct cpuidle_state exynos4_cpuidle_set[] = {
>> + [0] = {
>> + .enter = exynos4_enter_idle,
>> + .exit_latency = 1,
>> + .target_residency = 10,
>> + .flags = CPUIDLE_FLAG_TIME_VALID,
>> + .name = "IDLE",
>> + .desc = "ARM clock gating(WFI)",
>> + },
>> +};
>> +
>> +static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
>> +
>> +static struct cpuidle_driver exynos4_idle_driver = {
>> + .name = "exynos4_idle",
>> + .owner = THIS_MODULE,
>> +};
>> +
>> +static int exynos4_enter_idle(struct cpuidle_device *dev,
>> + struct cpuidle_state *state)
>> +{
>> + struct timeval before, after;
>> + int idle_time;
>> +
>> + local_irq_disable();
>> + do_gettimeofday(&before);
>> +
>> + cpu_do_idle();
>> +
>> + do_gettimeofday(&after);
>> + local_irq_enable();
>> + idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
>> + (after.tv_usec - before.tv_usec);
>> +
>> + return idle_time;
>> +}
>> +
>> +static int __init exynos4_init_cpuidle(void)
>> +{
>> + int i, max_cpuidle_state, cpu_id;
>> + struct cpuidle_device *device;
>> +
>> + cpuidle_register_driver(&exynos4_idle_driver);
>> +
>> + for_each_cpu(cpu_id, cpu_online_mask) {
>> + device = &per_cpu(exynos4_cpuidle_device, cpu_id);
>> + device->cpu = cpu_id;
>> +
>> + device->state_count = (sizeof(exynos4_cpuidle_set) /
>> + sizeof(struct
> cpuidle_state));
>> +
>> + max_cpuidle_state = device->state_count;
>> +
>> + for (i = 0; i < max_cpuidle_state; i++) {
>> + memcpy(&device->states[i], &exynos4_cpuidle_set[i],
>> + sizeof(struct cpuidle_state));
>> + }
>> +
>> + if (cpuidle_register_device(device)) {
>> + printk(KERN_ERR "CPUidle register device
> failed\n,");
>> + return -EIO;
>> +
Re: [PATCH v2 0/6] HDMI driver for Samsung S5PV310 platform
On Wed, Mar 9, 2011 at 9:11 PM, Kukjin Kim wrote: > Hi all, > > As I know, S5P-TV(HDMI) stuff needs more discussion. > > I don't want to just merge platform devices which is not used anywhere. > Besides, there are two schemes for it in mailing list now. It's different one, which scheme is used at multimedia, platform devices are same. > > I think we have to improve this next time and need to focus more on its > driver now. As you said, arch supports the platform devices, we focus on only driver itself. > > Thanks. > > Best regards, > Kgene. > -- > Kukjin Kim , Senior Engineer, > SW Solution Development Team, Samsung Electronics Co., Ltd. > > Tomasz Stanislawski wrote: >> >> From: Marek Szyprowski >> >> Hello, >> >> I would like to present the second version of HDMI driver for S5PC210 >> platform. >> The driver is under a heavy development. The most recent changes are: >> >> 1. Minor bugs and fixes: >> - pink line on left side of display >> - premature start of VP's streaming >> - usage of free memory >> - usage of non-initialized variables >> - fixed sequence of power setup >> - dependencies in Kconfig >> >> 2. Integration with Runtime Power Managment and Power Domain driver. >> >> 3. The CMA was substituted by the SYSMMU driver. >> >> 4. Applying existing frameworks: >> - activation of HDMIPHY using clock API >> - control of power on HDMI-5V pin using regulator API >> >> 5. Moving all clocks and regulator management from platform to the > drivers' >> code. >> >> 6. Redesigned the control of mixer's debugging. >> >> 7. Added a watchdog to deal with HW failures. >> >> Original HDMI driver RFC: >> >> == >> Introduction >> == >> >> The purpose of this RFC is to discuss the driver for a TV output interface >> available in upcoming Samsung SoC. The HW is able to generate digital and >> analog signals. Current version of the driver supports only digital > output. >> >> Internally the driver uses videobuf2 framework, and CMA memory allocator. >> Not >> all of them are merged by now, but I decided to post the sources to start >> discussion driver's design. >> >> == >> Hardware description >> == >> >> The SoC contains a few HW sub-blocks: >> >> 1. Video Processor (VP). It is used for processing of NV12 data. An image >> stored in RAM is accessed by DMA. Pixels are cropped, scaled. > Additionally, >> post processing operations like brightness, sharpness and contrast >> adjustments >> could be performed. The output in YCbCr444 format is send to Mixer. >> >> 2. Mixer (MXR). The piece of hardware responsible for mixing and blending >> multiple data inputs before passing it to an output device. The MXR is >> capable >> of handling up to three image layers. One is the output of VP. Other two > are >> images in RGB format (multiple variants are supported). The layers are >> scaled, >> cropped and blended with background color. The blending factor, and > layers' >> priority are controlled by MXR's registers. The output is passed either to >> HDMI >> or TVOUT. >> >> 3. HDMI. The piece of HW responsible for generation of HDMI packets. It > takes >> pixel data from mixer and transforms it into data frames. The output is > send >> to HDMIPHY interface. >> >> 4. HDMIPHY. Physical interface for HDMI. Its duties are sending HDMI > packets >> to >> HDMI connector. Basically, it contains a PLL that produces source clock > for >> Mixer, VP and HDMI during streaming. >> >> 5. TVOUT. Generation of TV analog signal. (driver not implemented) >> >> 6. VideoDAC. Modulator for TVOUT signal. (driver not implemented) >> >> >> The diagram below depicts connection between all HW pieces. >> +---+ >> NV12 data ---dma--->| Video | >> | Processor | >> +---+ >> | >> V >> +---+ >> RGB data ---dma--->| | >> | Mixer | >> RGB data ---dma--->| | >> +---+ >> | >> * dmux >> / >> +-* *--+ >> | | >> V V >> +---+ +---+ >> | HDMI | | TVOUT | >> +---+ +---+ >> | | >> V V >> +---+ +---+ >> | HDMIPHY | | VideoDAC | >> +---+ +---+ >> | | >> V V >> HDMI Composite >> connector connector >> >> >> == >> Driver interface >> == >> >> The posted driver implements three V4L2 nodes. Every video node implements >> V4L2 >> output bu
Re: [PATCH 2/6] universal: i2c: add I2C controller 8 (HDMIPHY)
On Wed, Mar 9, 2011 at 9:00 PM, Kukjin Kim wrote:
> Tomasz Stanislawski wrote:
>>
>> Signed-off-by: Tomasz Stanislawski
>> Signed-off-by: Kyungmin Park
>> ---
>> arch/arm/mach-s5pv310/clock.c | 6 +++
>> arch/arm/mach-s5pv310/include/mach/irqs.h | 4 ++
>> arch/arm/mach-s5pv310/include/mach/map.h | 1 +
>> arch/arm/plat-samsung/Kconfig | 5 ++
>> arch/arm/plat-samsung/Makefile | 1 +
>> arch/arm/plat-samsung/dev-i2c8.c | 68
>> +
>> arch/arm/plat-samsung/include/plat/devs.h | 1 +
>> arch/arm/plat-samsung/include/plat/iic.h | 1 +
>> 8 files changed, 87 insertions(+), 0 deletions(-)
>> create mode 100644 arch/arm/plat-samsung/dev-i2c8.c
>>
>> diff --git a/arch/arm/mach-s5pv310/clock.c b/arch/arm/mach-s5pv310/clock.c
>> index d28fa6f..465beb9 100644
>> --- a/arch/arm/mach-s5pv310/clock.c
>> +++ b/arch/arm/mach-s5pv310/clock.c
>> @@ -685,6 +685,12 @@ static struct clk init_clocks_off[] = {
>> .parent = &clk_aclk_100.clk,
>> .enable = s5pv310_clk_ip_peril_ctrl,
>> .ctrlbit = (1 << 13),
>> + }, {
>> + .name = "i2c",
>> + .id = 8,
>> + .parent = &clk_aclk_100.clk,
>> + .enable = s5pv310_clk_ip_peril_ctrl,
>> + .ctrlbit = (1 << 14),
>> },
>> };
>>
>> diff --git a/arch/arm/mach-s5pv310/include/mach/irqs.h b/arch/arm/mach-
>> s5pv310/include/mach/irqs.h
>> index f6b99c6..f7ddc98 100644
>> --- a/arch/arm/mach-s5pv310/include/mach/irqs.h
>> +++ b/arch/arm/mach-s5pv310/include/mach/irqs.h
>> @@ -77,6 +77,9 @@
>> #define IRQ_PDMA0 COMBINER_IRQ(21, 0)
>> #define IRQ_PDMA1 COMBINER_IRQ(21, 1)
>>
>> +#define IRQ_HDMI COMBINER_IRQ(16, 0)
>> +#define IRQ_HDMI_I2C COMBINER_IRQ(16, 1)
>> +
>> #define IRQ_TIMER0_VIC COMBINER_IRQ(22, 0)
>> #define IRQ_TIMER1_VIC COMBINER_IRQ(22, 1)
>> #define IRQ_TIMER2_VIC COMBINER_IRQ(22, 2)
>> @@ -100,6 +103,7 @@
>> #define IRQ_IIC5 COMBINER_IRQ(27, 5)
>> #define IRQ_IIC6 COMBINER_IRQ(27, 6)
>> #define IRQ_IIC7 COMBINER_IRQ(27, 7)
>> +#define IRQ_IIC8 IRQ_HDMI_I2C
>>
>> #define IRQ_HSMMC0 COMBINER_IRQ(29, 0)
>> #define IRQ_HSMMC1 COMBINER_IRQ(29, 1)
>> diff --git a/arch/arm/mach-s5pv310/include/mach/map.h b/arch/arm/mach-
>> s5pv310/include/mach/map.h
>> index 576ba55..0aa0171 100644
>> --- a/arch/arm/mach-s5pv310/include/mach/map.h
>> +++ b/arch/arm/mach-s5pv310/include/mach/map.h
>> @@ -120,6 +120,7 @@
>> #define S3C_PA_IIC5 S5PV310_PA_IIC(5)
>> #define S3C_PA_IIC6 S5PV310_PA_IIC(6)
>> #define S3C_PA_IIC7 S5PV310_PA_IIC(7)
>> +#define S3C_PA_IIC8 S5PV310_PA_IIC(8)
>> #define S3C_PA_RTC S5PV310_PA_RTC
>> #define S3C_PA_WDT S5PV310_PA_WATCHDOG
>>
>> diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
>> index 32be05c..dd1fd15 100644
>> --- a/arch/arm/plat-samsung/Kconfig
>> +++ b/arch/arm/plat-samsung/Kconfig
>> @@ -211,6 +211,11 @@ config S3C_DEV_I2C7
>> help
>> Compile in platform device definition for I2C controller 7
>>
>> +config S3C_DEV_I2C8
>> + bool
>> + help
>> + Compile in platform device definitions for I2C channel 8 (HDMIPHY)
>> +
>> config S3C_DEV_FB
>> bool
>> help
>> diff --git a/arch/arm/plat-samsung/Makefile
> b/arch/arm/plat-samsung/Makefile
>> index 7e92457..826ae4f 100644
>> --- a/arch/arm/plat-samsung/Makefile
>> +++ b/arch/arm/plat-samsung/Makefile
>> @@ -46,6 +46,7 @@ obj-$(CONFIG_S3C_DEV_I2C4) += dev-i2c4.o
>> obj-$(CONFIG_S3C_DEV_I2C5) += dev-i2c5.o
>> obj-$(CONFIG_S3C_DEV_I2C6) += dev-i2c6.o
>> obj-$(CONFIG_S3C_DEV_I2C7) += dev-i2c7.o
>> +obj-$(CONFIG_S3C_DEV_I2C8) += dev-i2c8.o
>> obj-$(CONFIG_S3C_DEV_FB) += dev-fb.o
>> obj-y += dev-uart.o
>> obj-$(CONFIG_S3C_DEV_USB_HOST) += dev-usb.o
>> diff --git a/arch/arm/plat-samsung/dev-i2c8.c b/arch/arm/plat-samsung/dev-
>> i2c8.c
>> new file mode 100644
>> index 000..8edba7f
>> --- /dev/null
>> +++ b/arch/arm
Re: [GIT PULL] Samsung fixes for 2.6.38-rc8
Hi, Can you also add this one? ARM: Samsung: change suspend/resume code to depend on CONFIG_SUSPEND http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg04141.html Even though suspend is not implemented at exynos4, we can use the runtime pm feature. Also without this patch, we can't compile the exynos4 when turn on PM. Thank you, Kyungmin Park On Tue, Mar 8, 2011 at 7:57 AM, Kukjin Kim wrote: > Hi Linus, > > Please pull Samsung fixes from: > > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > s5p-fixes-for-linus > > These things are for small fixes on 2.6.38-rc8. > If any problems, please let me know. > > Thanks. > > Best regards, > Kgene. > -- > Kukjin Kim , Senior Engineer, > SW Solution Development Team, Samsung Electronics Co., Ltd. > > The following changes since commit dd9c1549edef02290edced639f67b54a25abbe0e: > > Linux 2.6.38-rc7 (2011-03-01 13:55:12 -0800) > > are available in the git repository at: > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > s5p-fixes-for-linus > > Banajit Goswami (1): > ARM: S5P64X0: Fix number of GPIO lines in Bank F > > Ben Dooks (3): > ARM: S3C64XX: Fix keypad setup to configure correct number of rows > ARM: S3C64XX: Add clock for i2c1 > ARM: S3C64XX: Reduce output of s3c64xx_dma_init1() > > Lars-Peter Clausen (2): > ARM: S3C2440: Select missing S3C_DEV_USB_HOST on GTA02 > ARM: S3C2440: Fix usage gpio bank j pin definitions on GTA02 > > Mark Brown (5): > ARM: SAMSUNG: Include devs.h in dev-uart.c to prototype devices > ARM: S3C64XX: Staticise non-exported GPIO to interrupt functions > ARM: S3C64XX: Tone down SDHCI debugging > ARM: S3C64XX: Fix build with WM1190 disabled and WM1192 enabled on > SMDK6410 > ARM: S3C64XX: Update regulator names for debugfs compatiblity on > SMDK6410 > > arch/arm/mach-s3c2440/Kconfig | 1 + > arch/arm/mach-s3c2440/include/mach/gta02.h | 26 > +- > arch/arm/mach-s3c64xx/clock.c | 6 ++ > arch/arm/mach-s3c64xx/dma.c | 11 ++- > arch/arm/mach-s3c64xx/gpiolib.c | 4 ++-- > arch/arm/mach-s3c64xx/mach-smdk6410.c | 13 +++-- > arch/arm/mach-s3c64xx/setup-keypad.c | 2 +- > arch/arm/mach-s3c64xx/setup-sdhci.c | 2 +- > arch/arm/mach-s5p64x0/include/mach/gpio.h | 4 ++-- > arch/arm/plat-samsung/dev-uart.c | 2 ++ > 10 files changed, 41 insertions(+), 30 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/3] ARM: S5P: Add s5p_timer support for HRT
On Fri, Mar 4, 2011 at 2:21 PM, Sangbeom Kim wrote:
> This patch adds support HR-Timer(High Resolution Timer) and dynamic
> tick system for S5P SoCs. There are many clock sources for HR-Timer
> on S5P SoCs. The PWM timer, RTC, System Timer, and MCT can be used
> for clock source.
> This patch can only support PWM timer for clocksource of
> S5P64x0 and S5PV210.
>
> Signed-off-by: Sangbeom Kim
> ---
> arch/arm/plat-s5p/Makefile | 1 +
> arch/arm/plat-s5p/include/plat/s5p-time.h | 40 +++
> arch/arm/plat-s5p/s5p-time.c | 452
> +
> 3 files changed, 493 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/plat-s5p/include/plat/s5p-time.h
> create mode 100644 arch/arm/plat-s5p/s5p-time.c
>
> diff --git a/arch/arm/plat-s5p/Makefile b/arch/arm/plat-s5p/Makefile
> index 4bd5cf9..3b8cc2f 100644
> --- a/arch/arm/plat-s5p/Makefile
> +++ b/arch/arm/plat-s5p/Makefile
> @@ -22,6 +22,7 @@ obj-$(CONFIG_S5P_GPIO_INT) += irq-gpioint.o
> obj-$(CONFIG_S5P_SYSTEM_MMU) += sysmmu.o
> obj-$(CONFIG_PM) += pm.o
> obj-$(CONFIG_PM) += irq-pm.o
> +obj-$(CONFIG_GENERIC_CLOCKEVENTS) += s5p-time.o
Do you test it with exynos4 configuration? it's affect the exynos compile.
First select SAMSUNG_DEV_PWM, it can't compile it since no init_sched_clock
Second select HAVE_SCHED_CLOCK, it can't boot.
I used the for-exynos4 branch.
Thank you,
Kyungmin Park
>
> # devices
>
> diff --git a/arch/arm/plat-s5p/include/plat/s5p-time.h
> b/arch/arm/plat-s5p/include/plat/s5p-time.h
> new file mode 100644
> index 000..9956136
> --- /dev/null
> +++ b/arch/arm/plat-s5p/include/plat/s5p-time.h
> @@ -0,0 +1,40 @@
> +/* linux/arch/arm/plat-s5p/include/plat/s5p-time.h
> + *
> + * Copyright 2011 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com/
> + *
> + * Header file for s5p time support
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +#ifndef __ASM_PLAT_S5P_TIME_H
> +#define __ASM_PLAT_S5P_TIME_H __FILE__
> +
> +/* S5P HR-Timer Clock mode */
> +enum s5p_timer_mode {
> + S5P_PWM0,
> + S5P_PWM1,
> + S5P_PWM2,
> + S5P_PWM3,
> + S5P_PWM4,
> +};
> +
> +struct s5p_timer_source {
> + unsigned int event_id;
> + unsigned int source_id;
> +};
> +
> +/* Be able to sleep for atleast 4 seconds (usually more) */
> +#define S5PTIMER_MIN_RANGE 4
> +
> +#define TCNT_MAX 0x
> +#define NON_PERIODIC 0
> +#define PERIODIC 1
> +
> +extern void __init s5p_set_timer_source(enum s5p_timer_mode event,
> + enum s5p_timer_mode source);
> +extern struct sys_timer s5p_timer;
> +#endif /* __ASM_PLAT_S5P_TIME_H */
> diff --git a/arch/arm/plat-s5p/s5p-time.c b/arch/arm/plat-s5p/s5p-time.c
> new file mode 100644
> index 000..1d2447e
> --- /dev/null
> +++ b/arch/arm/plat-s5p/s5p-time.c
> @@ -0,0 +1,452 @@
> +/* linux/arch/arm/plat-s5p/s5p-time.c
> + *
> + * Copyright (c) 2011 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com/
> + *
> + * S5P - Common hr-timer support
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +static struct clk *tin_event;
> +static struct clk *tin_source;
> +static struct clk *tdiv_event;
> +static struct clk *tdiv_source;
> +static struct clk *timerclk;
> +static struct s5p_timer_source timer_source;
> +static unsigned long clock_count_per_tick;
> +static void s5p_timer_resume(void);
> +
> +static void s5p_time_stop(enum s5p_timer_mode mode)
> +{
> + unsigned long tcon;
> +
> + tcon = __raw_readl(S3C2410_TCON);
> +
> + switch (mode) {
> + case S5P_PWM0:
> + tcon &= ~S3C2410_TCON_T0START;
> + break;
> +
> + case S5P_PWM1:
> + tcon &= ~S3C2410_TCON_T1START;
> + break;
> +
> + case S5P_PWM2:
> + tcon &= ~S3C2410_TCON_T2START;
> + break;
> +
> + case S5P_PWM3:
> +
Re: [PATCH] ARM: Samsung: change suspend/resume code to depend on CONFIG_SUSPEND
Marek,
Can you rebase the patch on the for-exynos4?
Or kgene fix it since it's posted before the renamefrom s5pv310 to exynos4.
To Kgene,
It's required for test the runtime PM on exynos4.
Another one, when we expect the PM feature for exynos4? Please specify
the date instead of plan.
Thank you,
Kyungmin Park
On Tue, Feb 15, 2011 at 6:15 PM, Marek Szyprowski
wrote:
> Most suspend/resume code depends on CONFIG_PM. This causes problems
> if one wants to enable Runtime PM (to control power domains for example),
> but doesn't need system suspend/resume feature. This also enables to use
> Runtime PM feature on S5PV310 which doesn't implement system suspend/resume
> callbacks yet.
>
> Signed-off-by: Marek Szyprowski
> Signed-off-by: Kyungmin Park
> ---
> arch/arm/mach-s3c2410/mach-bast.c | 2 +-
> arch/arm/mach-s3c2412/mach-jive.c | 2 +-
> arch/arm/mach-s3c2440/mach-osiris.c | 2 +-
> arch/arm/mach-s3c2440/s3c244x.c | 2 +-
> arch/arm/mach-s3c64xx/Makefile | 6 +++---
> arch/arm/mach-s5pv210/cpufreq.c | 4 ++--
> arch/arm/mach-s5pv310/cpufreq.c | 4 ++--
> arch/arm/mach-s5pv310/irq-eint.c | 2 +-
> arch/arm/plat-s3c24xx/Makefile | 6 +++---
> arch/arm/plat-s3c24xx/cpu-freq.c | 2 +-
> arch/arm/plat-s3c24xx/dma.c | 2 +-
> arch/arm/plat-s3c24xx/include/plat/irq.h | 2 +-
> arch/arm/plat-s5p/Makefile | 4 ++--
> arch/arm/plat-s5p/irq-eint.c | 4 ++--
> arch/arm/plat-samsung/Makefile | 4 ++--
> arch/arm/plat-samsung/adc.c | 2 +-
> arch/arm/plat-samsung/gpio.c | 2 +-
> arch/arm/plat-samsung/include/plat/gpio-core.h | 6 +++---
> arch/arm/plat-samsung/include/plat/pm.h | 4 ++--
> arch/arm/plat-samsung/pwm.c | 2 +-
> 20 files changed, 32 insertions(+), 32 deletions(-)
>
> diff --git a/arch/arm/mach-s3c2410/mach-bast.c
> b/arch/arm/mach-s3c2410/mach-bast.c
> index 2970ea9..18187a4 100644
> --- a/arch/arm/mach-s3c2410/mach-bast.c
> +++ b/arch/arm/mach-s3c2410/mach-bast.c
> @@ -213,7 +213,7 @@ static struct s3c2410_uartcfg bast_uartcfgs[] __initdata
> = {
>
> /* NAND Flash on BAST board */
>
> -#ifdef CONFIG_PM
> +#ifdef CONFIG_SUSPEND
> static int bast_pm_suspend(struct sys_device *sd, pm_message_t state)
> {
> /* ensure that an nRESET is not generated on resume. */
> diff --git a/arch/arm/mach-s3c2412/mach-jive.c
> b/arch/arm/mach-s3c2412/mach-jive.c
> index 923e01b..10643ef8 100644
> --- a/arch/arm/mach-s3c2412/mach-jive.c
> +++ b/arch/arm/mach-s3c2412/mach-jive.c
> @@ -485,7 +485,7 @@ static struct s3c2410_udc_mach_info jive_udc_cfg
> __initdata = {
>
> /* Jive power management device */
>
> -#ifdef CONFIG_PM
> +#ifdef CONFIG_SUSPEND
> static int jive_pm_suspend(struct sys_device *sd, pm_message_t state)
> {
> /* Write the magic value u-boot uses to check for resume into
> diff --git a/arch/arm/mach-s3c2440/mach-osiris.c
> b/arch/arm/mach-s3c2440/mach-osiris.c
> index 14dc678..06d115a 100644
> --- a/arch/arm/mach-s3c2440/mach-osiris.c
> +++ b/arch/arm/mach-s3c2440/mach-osiris.c
> @@ -281,7 +281,7 @@ static struct platform_device osiris_pcmcia = {
>
> /* Osiris power management device */
>
> -#ifdef CONFIG_PM
> +#ifdef CONFIG_SUSPEND
> static unsigned char pm_osiris_ctrl0;
>
> static int osiris_pm_suspend(struct sys_device *sd, pm_message_t state)
> diff --git a/arch/arm/mach-s3c2440/s3c244x.c b/arch/arm/mach-s3c2440/s3c244x.c
> index 90c1707..7e693a0 100644
> --- a/arch/arm/mach-s3c2440/s3c244x.c
> +++ b/arch/arm/mach-s3c2440/s3c244x.c
> @@ -134,7 +134,7 @@ void __init s3c244x_init_clocks(int xtal)
> s3c2410_baseclk_add();
> }
>
> -#ifdef CONFIG_PM
> +#ifdef CONFIG_SUSPEND
>
> static struct sleep_save s3c244x_sleep[] = {
> SAVE_ITEM(S3C2440_DSC0),
> diff --git a/arch/arm/mach-s3c64xx/Makefile b/arch/arm/mach-s3c64xx/Makefile
> index 4657363..183ebb3 100644
> --- a/arch/arm/mach-s3c64xx/Makefile
> +++ b/arch/arm/mach-s3c64xx/Makefile
> @@ -43,9 +43,9 @@ obj-$(CONFIG_S3C64XX_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
>
> # PM
>
> -obj-$(CONFIG_PM) += pm.o
> -obj-$(CONFIG_PM) += sleep.o
> -obj-$(CONFIG_PM) += irq-pm.o
> +obj-$(CONFIG_SUSPEND) += pm.o
> +obj-$(CONFIG_SUSPEND) += sleep.o
> +obj-$(CONFIG_SUSPEND) += irq-pm.o
>
> # Machine support
>
> diff --git a/arch/arm/mach-s5pv210/cpufreq.c b/arch/arm/mach-s5pv210/c
Re: [PATCH] ARM: EXYNOS4: Add ARMLEX4210 Board support file
On Thu, Mar 3, 2011 at 4:27 PM, ALIM AKHTAR wrote:
> This patch is based on 'for-next' branch of kgene tree.
>
> This patch adds Samsung ARMLEX4210 board support file
> which is based on Exynos4210.
>
> Signed-off-by: Alim Akhtar
> ---
> arch/arm/mach-exynos4/Kconfig | 13 ++
> arch/arm/mach-exynos4/Makefile | 1 +
> arch/arm/mach-exynos4/mach-armlex4210.c | 213
> +++
> 3 files changed, 227 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-exynos4/mach-armlex4210.c
>
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index ad03840..a12bddf 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -109,6 +109,19 @@ config MACH_SMDKV310
> help
> Machine support for Samsung SMDKV310
>
> +config MACH_ARMLEX4210
> + bool "ARMLEX4210"
> + select CPU_EXYNOS4210
> + select S3C_DEV_RTC
> + select S3C_DEV_WDT
> + select S3C_DEV_HSMMC
> + select S3C_DEV_HSMMC2
> + select S3C_DEV_HSMMC3
> + select EXYNOS4_DEV_SYSMMU
> + select EXYNOS4_SETUP_SDHCI
> + help
> + Machine support for Samsung ARMLEX4210 based on EXYNOS4210
> +
> config MACH_UNIVERSAL_C210
> bool "Mobile UNIVERSAL_C210 Board"
> select CPU_EXYNOS4210
> diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
> index 0558235..2860af8 100644
> --- a/arch/arm/mach-exynos4/Makefile
> +++ b/arch/arm/mach-exynos4/Makefile
> @@ -24,6 +24,7 @@ obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
>
> obj-$(CONFIG_MACH_SMDKC210) += mach-smdkc210.o
> obj-$(CONFIG_MACH_SMDKV310) += mach-smdkv310.o
> +obj-$(CONFIG_MACH_ARMLEX4210) += mach-armlex4210.o
> obj-$(CONFIG_MACH_UNIVERSAL_C210) += mach-universal_c210.o
>
> # device support
> diff --git a/arch/arm/mach-exynos4/mach-armlex4210.c
> b/arch/arm/mach-exynos4/mach-armlex4210.c
> new file mode 100644
> index 000..856ab6e
> --- /dev/null
> +++ b/arch/arm/mach-exynos4/mach-armlex4210.c
> @@ -0,0 +1,213 @@
> +/* linux/arch/arm/mach-exynos4/mach-armlex4210.c
> + *
> + * Copyright (c) 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
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +/* Following are default values for UCON, ULCON and UFCON UART registers */
> +#define ARMLEX4210_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
> + S3C2410_UCON_RXILEVEL | \
> + S3C2410_UCON_TXIRQMODE | \
> + S3C2410_UCON_RXIRQMODE | \
> + S3C2410_UCON_RXFIFO_TOI | \
> + S3C2443_UCON_RXERR_IRQEN)
> +
> +#define ARMLEX4210_ULCON_DEFAULT S3C2410_LCON_CS8
> +
> +#define ARMLEX4210_UFCON_DEFAULT (S3C2410_UFCON_FIFOMODE | \
> + S5PV210_UFCON_TXTRIG4 | \
> + S5PV210_UFCON_RXTRIG4)
> +
> +static struct s3c2410_uartcfg armlex4210_uartcfgs[] __initdata = {
> + [0] = {
> + .hwport = 0,
> + .flags = 0,
> + .ucon = ARMLEX4210_UCON_DEFAULT,
> + .ulcon = ARMLEX4210_ULCON_DEFAULT,
> + .ufcon = ARMLEX4210_UFCON_DEFAULT,
> + },
> + [1] = {
> + .hwport = 1,
> + .flags = 0,
> + .ucon = ARMLEX4210_UCON_DEFAULT,
> + .ulcon = ARMLEX4210_ULCON_DEFAULT,
> + .ufcon = ARMLEX4210_UFCON_DEFAULT,
> + },
> + [2] = {
> + .hwport = 2,
> + .flags = 0,
> + .ucon = ARMLEX4210_UCON_DEFAULT,
> + .ulcon = ARMLEX4210_ULCON_DEFAULT,
> + .ufcon = ARMLEX4210_UFCON_DEFAULT,
> + },
> + [3] = {
> + .hwport = 3,
> + .flags = 0,
> + .ucon = ARMLEX4210_UCON_DEFAULT,
> + .ulcon = ARMLEX4210_ULCON_DEFAULT,
> + .ufcon = ARMLEX4210_UFCON_DEFAULT,
> + },
> +};
> +
> +static struct s3c_sdhci_platdata armlex4210_hsmmc0_pdata __initdata = {
> + .cd_type = S3C_SDHCI_CD_PERMANENT,
> + .clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
> +#ifdef CONFIG_EXYNOS4_SDHCI_CH0_8BIT
> + .max_width = 8,
> +
Re: [PATCH] ARM: S5PC210: add support for i2c PMICs on Universal_C210 board
On Tue, Feb 15, 2011 at 8:35 PM, Russell King - ARM Linux wrote: > On Tue, Feb 15, 2011 at 11:59:15AM +0100, Marek Szyprowski wrote: >> #include >> +#include > > Need I say anything about this? Hi Russell, How about to prevent it as compiler error? It's frequent mistake. At each mach/gpio.h #ifndef __LINUX_GPIO_H #error "You should include instead of ." #endif Thank you, Kyungmin Park > -- > 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] ARM: EXYNOS4: Implement kernel timers using MCT
On Wed, Mar 2, 2011 at 4:29 PM, Kukjin Kim wrote: > Kyungmin Park wrote: >> >> Hi, >> >> MCT is only possible from EVT1.0 or later. The current universal_c210 >> used the EVT0 version. >> So can you remove the ifdef and board can select which timer is used? >> Please refer the omap implementation and how to use it. >> > Basically, "CONFIG_EXYNOS4_MCT" can be selected in kernel menuconfig. > It means default one is using local timer which is included in every > Exynos4210. > >> If we use the same configuration, It will be boot failed at >> universal_c210 board. >> > No, see as above. > > One more basically, each machine specific CONFIGs should be selected in > kernel menuconfig after "make exynos4_defconfig". Because each machine > supports different components on each one now. > > As a note, however, I don't want to add each machine's defconfig. Maybe > Russell also. I agree, but there are better way, make it compile both and select timer for each board. Of course no need to add any statement if default timer is used. BTW, What's the purpose of exynos4_defconfig? as you said, If I want to use the MCT for EVT1 board, then make defconfig and select it again? why do the these job? Thank you, Kyungmin Park -- 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] ARM: EXYNOS4: Implement kernel timers using MCT
Hi,
MCT is only possible from EVT1.0 or later. The current universal_c210
used the EVT0 version.
So can you remove the ifdef and board can select which timer is used?
Please refer the omap implementation and how to use it.
If we use the same configuration, It will be boot failed at
universal_c210 board.
Thank you,
Kyungmin Park
On Mon, Feb 28, 2011 at 2:16 PM, Kukjin Kim wrote:
> From: Changhwan Youn
>
> The Multi-Core Timer(MCT) of EXYNOS4 is designed for implementing
> clock source timer and clock event timers. This patch implements
> 1 clock source timer with 64 bit free running counter of MCT and
> 2 clock event timers with two of 31-bit tick counters.
>
> Signed-off-by: Changhwan Youn
> Cc: Ben Dooks
> Cc: Russell King
> Signed-off-by: Kukjin Kim
> ---
> Changes since v3:
> - Re-worked based on exynos4
> - Changed member of clock_evetn_device like following
> struct mct_clock_event_device {
> struct clock_event_device *evt;
> ...
> - Address comments from Russell King
> Added static into "irqreturn_t exynos4_mct_comp_isr()"
> Added .dev_id member into "struct irqaction mct_comp_event_irq"
>
> Changes since v2:
> - Addressed comments from Russell King
> Added mct_clock_event_device structure
> - Removed suspend()/resume() which are not used now
>
> Changes since v1:
> - Addressed comments from Russell King
> (implemented global timer, used local timer and so on)
> - Fixed small things
>
> arch/arm/Kconfig | 2 +-
> arch/arm/mach-exynos4/Kconfig | 5 +
> arch/arm/mach-exynos4/Makefile | 11 +-
> arch/arm/mach-exynos4/include/mach/regs-mct.h | 52 +++
> arch/arm/mach-exynos4/mct.c | 421
> +
> 5 files changed, 488 insertions(+), 3 deletions(-)
> create mode 100644 arch/arm/mach-exynos4/include/mach/regs-mct.h
> create mode 100644 arch/arm/mach-exynos4/mct.c
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index ec3bf98..b4db99b 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1366,7 +1366,7 @@ config LOCAL_TIMERS
> bool "Use local timer interrupts"
> depends on SMP
> default y
> - select HAVE_ARM_TWD if !ARCH_MSM_SCORPIONMP
> + select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
> help
> Enable support for local timers on SMP platforms, rather then the
> legacy IPI broadcast method. Local timers allows the system
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index ad03840..77b5d93 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -15,6 +15,11 @@ config CPU_EXYNOS4210
> help
> Enable EXYNOS4210 CPU support
>
> +config EXYNOS4_MCT
> + bool "Kernel timer support by MCT"
> + help
> + Use MCT (Multi Core Timer) as kernel timers
> +
> config EXYNOS4_DEV_PD
> bool
> help
> diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
> index 0558235..de20b91 100644
> --- a/arch/arm/mach-exynos4/Makefile
> +++ b/arch/arm/mach-exynos4/Makefile
> @@ -13,11 +13,18 @@ obj- :=
> # Core support for EXYNOS4 system
>
> obj-$(CONFIG_CPU_EXYNOS4210) += cpu.o init.o clock.o irq-combiner.o
> -obj-$(CONFIG_CPU_EXYNOS4210) += setup-i2c0.o time.o gpiolib.o irq-eint.o
> dma.o
> +obj-$(CONFIG_CPU_EXYNOS4210) += setup-i2c0.o gpiolib.o irq-eint.o dma.o
> obj-$(CONFIG_CPU_FREQ) += cpufreq.o
>
> obj-$(CONFIG_SMP) += platsmp.o headsmp.o
> -obj-$(CONFIG_LOCAL_TIMERS) += localtimer.o
> +
> +ifeq ($(CONFIG_EXYNOS4_MCT),y)
> +obj-y += mct.o
> +else
> +obj-y += time.o
> +obj-$(CONFIG_LOCAL_TIMERS) += localtimer.o
> +endif
> +
> obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
>
> # machine support
> diff --git a/arch/arm/mach-exynos4/include/mach/regs-mct.h
> b/arch/arm/mach-exynos4/include/mach/regs-mct.h
> new file mode 100644
> index 000..ca9c843
> --- /dev/null
> +++ b/arch/arm/mach-exynos4/include/mach/regs-mct.h
> @@ -0,0 +1,52 @@
> +/* arch/arm/mach-exynos4/include/mach/regs-mct.h
> + *
> + * Copyright (c) 2011 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * EXYNOS4 MCT configutation
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +#ifndef __ASM_ARCH_REGS_MCT_H
Re: [PATCH 6/6] ARM: S5PV210: Add PWM backlight support on SMDKV210
Hi,
On Sat, Feb 26, 2011 at 1:29 PM, Banajit Goswami wrote:
> This patch adds support for LCD backlight control using PWM timer
> for Samsung's SMDKV210 board.
>
> Signed-off-by: Banajit Goswami
> ---
> arch/arm/mach-s5pv210/Kconfig | 1 +
> arch/arm/mach-s5pv210/mach-smdkv210.c | 46
> +
> 2 files changed, 47 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
> index 53aabef..d7fd031 100644
> --- a/arch/arm/mach-s5pv210/Kconfig
> +++ b/arch/arm/mach-s5pv210/Kconfig
> @@ -130,6 +130,7 @@ config MACH_SMDKV210
> select SAMSUNG_DEV_ADC
> select SAMSUNG_DEV_IDE
> select SAMSUNG_DEV_KEYPAD
> + select SAMSUNG_DEV_PWM
> select SAMSUNG_DEV_TS
> select S5PV210_SETUP_FB_24BPP
> select S5PV210_SETUP_I2C1
> diff --git a/arch/arm/mach-s5pv210/mach-smdkv210.c
> b/arch/arm/mach-s5pv210/mach-smdkv210.c
> index bc9fdb5..8833e7b 100644
> --- a/arch/arm/mach-s5pv210/mach-smdkv210.c
> +++ b/arch/arm/mach-s5pv210/mach-smdkv210.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -43,6 +44,7 @@
> #include
> #include
> #include
> +#include
>
> /* Following are default values for UCON, ULCON and UFCON UART registers */
> #define SMDKV210_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
> @@ -208,6 +210,45 @@ static struct s3c_fb_platdata smdkv210_lcd0_pdata
> __initdata = {
> .setup_gpio = s5pv210_fb_gpio_setup_24bpp,
> };
>
> +static int smdkv210_backlight_init(struct device *dev)
> +{
> + int ret;
> +
> + ret = gpio_request(S5PV210_GPD0(3), "Backlight");
> + if (ret) {
> + printk(KERN_ERR "failed to request GPD for PWM-OUT 3\n");
> + return ret;
> + }
> +
> + /* Configure GPIO pin with S5PV210_GPD_0_3_TOUT_3 */
> + s3c_gpio_cfgpin(S5PV210_GPD0(3), (0x2 << 12));
what's (0x2 << 12)? Do you mean S3C_GPIO_SFN(2)?
please use the macro and other patches are same usage.
> +
> + return 0;
> +}
> +
> +static void smdkv210_backlight_exit(struct device *dev)
> +{
> + s3c_gpio_cfgpin(S5PV210_GPD0(3), S3C_GPIO_OUTPUT);
> + gpio_free(S5PV210_GPD0(3));
> +}
> +
> +static struct platform_pwm_backlight_data smdkv210_backlight_data = {
> + .pwm_id = 3,
> + .max_brightness = 255,
> + .dft_brightness = 255,
> + .pwm_period_ns = 78770,
> + .init = smdkv210_backlight_init,
> + .exit = smdkv210_backlight_exit,
> +};
> +
> +static struct platform_device smdkv210_backlight_device = {
> + .name = "pwm-backlight",
> + .dev = {
> + .parent = &s3c_device_timer[3].dev,
> + .platform_data = &smdkv210_backlight_data,
> + },
> +};
> +
> static struct platform_device *smdkv210_devices[] __initdata = {
> &s3c_device_adc,
> &s3c_device_cfcon,
> @@ -229,6 +270,11 @@ static struct platform_device *smdkv210_devices[]
> __initdata = {
> &samsung_device_keypad,
> &smdkv210_dm9000,
> &smdkv210_lcd_lte480wv,
> + &s3c_device_timer[0],
> + &s3c_device_timer[1],
> + &s3c_device_timer[2],
> + &s3c_device_timer[3],
Why do you register timer[0...2] at here? it's only use the timer[3]
at this patch.
Other patches are same usage.
Thank you,
Kyungmin Park
> + &smdkv210_backlight_device,
> };
>
> static void __init smdkv210_dm9000_init(void)
> --
> 1.6.5.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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/3] ARM: S5P: Add s5p_timer support for HRT
On Sat, Feb 26, 2011 at 11:45 AM, Sangbeom Kim wrote:
> This patch adds support HR-Timer(High Resolution Timer) and dynamic
> tick system for S5P SoCs. There are many clock sources for HR-Timer
> on S5P SoCs. The PWM timer, RTC, System Timer, and MCT can be used
> for clock source.
> This patch can only support PWM timer for clocksource of
> S5P64x0 and S5PV210.
>
> Signed-off-by: Sangbeom Kim
> ---
> arch/arm/plat-s5p/Makefile | 1 +
> arch/arm/plat-s5p/include/plat/s5p-time.h | 37 +++
> arch/arm/plat-s5p/s5p-time.c | 395
> +
> 3 files changed, 433 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/plat-s5p/include/plat/s5p-time.h
> create mode 100644 arch/arm/plat-s5p/s5p-time.c
>
> diff --git a/arch/arm/plat-s5p/Makefile b/arch/arm/plat-s5p/Makefile
> index 4bd5cf9..3b8cc2f 100644
> --- a/arch/arm/plat-s5p/Makefile
> +++ b/arch/arm/plat-s5p/Makefile
> @@ -22,6 +22,7 @@ obj-$(CONFIG_S5P_GPIO_INT) += irq-gpioint.o
> obj-$(CONFIG_S5P_SYSTEM_MMU) += sysmmu.o
> obj-$(CONFIG_PM) += pm.o
> obj-$(CONFIG_PM) += irq-pm.o
> +obj-$(CONFIG_GENERIC_CLOCKEVENTS) += s5p-time.o
>
> # devices
>
> diff --git a/arch/arm/plat-s5p/include/plat/s5p-time.h
> b/arch/arm/plat-s5p/include/plat/s5p-time.h
> new file mode 100644
> index 000..e478f0c
> --- /dev/null
> +++ b/arch/arm/plat-s5p/include/plat/s5p-time.h
> @@ -0,0 +1,37 @@
> +/* linux/arch/arm/plat-s5p/include/plat/s5p-time.h
> + *
> + * Copyright 2011 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com/
> + *
> + * Header file for s5p time support
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +#ifndef __ASM_PLAT_S5P_TIME_H
> +#define __ASM_PLAT_S5P_TIME_H __FILE__
> +
> +/* S5P HR-Timer Clock mode */
> +enum s5p_timer_mode {
> + S5P_PWM0,
> + S5P_PWM1,
> + S5P_PWM2,
> + S5P_PWM3,
> + S5P_PWM4,
> +};
> +
> +struct s5p_timer_source {
> + unsigned int event_id;
> + unsigned int source_id;
> +};
> +
> +#define TCNT_MAX 0x
> +#define NON_PERIODIC 0
> +#define PERIODIC 1
> +
> +extern void __init s5p_set_timer_source(enum s5p_timer_mode event,
> + enum s5p_timer_mode source);
> +extern struct sys_timer s5p_timer;
> +#endif /* __ASM_PLAT_S5P_TIME_H */
> diff --git a/arch/arm/plat-s5p/s5p-time.c b/arch/arm/plat-s5p/s5p-time.c
> new file mode 100644
> index 000..4691728
> --- /dev/null
> +++ b/arch/arm/plat-s5p/s5p-time.c
> @@ -0,0 +1,395 @@
> +/* linux/arch/arm/plat-s5p/s5p-time.c
> + *
> + * Copyright (c) 2011 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com/
> + *
> + * S5P - Common hr-timer support
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> +*/
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +static struct clk *tin_event;
> +static struct clk *tin_source;
> +static struct clk *tdiv_event;
> +static struct clk *tdiv_source;
> +static struct clk *timerclk;
> +static struct s5p_timer_source timer_source;
> +static unsigned long clock_count_per_tick;
> +static void s5p_timer_resume(void);
> +
> +static void s5p_time_stop(enum s5p_timer_mode mode)
> +{
> + unsigned long tcon;
> +
> + tcon = __raw_readl(S3C2410_TCON);
> +
> + switch (mode) {
> + case S5P_PWM0:
> + tcon &= ~S3C2410_TCON_T0START;
> + break;
> +
> + case S5P_PWM1:
> + tcon &= ~S3C2410_TCON_T1START;
> + break;
> +
> + case S5P_PWM2:
> + tcon &= ~S3C2410_TCON_T2START;
> + break;
> +
> + case S5P_PWM3:
> + tcon &= ~S3C2410_TCON_T3START;
> + break;
> +
> + case S5P_PWM4:
> + tcon &= ~S3C2410_TCON_T4START;
> + break;
> +
> + default:
> + printk(KERN_ERR "Invalid Timer %d\n", mode);
> + break;
> + }
> + __raw_writel(tcon, S3C2410_TCON);
> +}
> +
> +static void s5p_time_setup(enum s5p_timer_mode mode, unsigned long tcnt)
> +{
> + unsigned long tcon;
> +
> + tcon = __raw_readl(S3C2410_TCON);
> +
> + tcnt--;
> +
> + switch (mode) {
> + case S5P_PWM0:
> + tcon &= ~(0x0f << 0);
> + tcon |= S3C2410_TCON_T0MANUALUPD;
> + break;
> +
> + case S5P_PWM1:
> + tcon &= ~(0x0f << 8);
> + tcon |= S3C2410_TCON_T1MANUALUPD;
> + break;
>
Re: [PATCH 2/3] ARM: S5P: Update machine initialization for HRT
Acked-by: Kyungmin Park It's just curious. Are there any reason to use PWM2 & 4. Theoretically it's possible to use PWM2 for other purpose as it's connected with external devices such as haptic or PWM backlight. But in case of PWM3 doesn't, it's only used for internal purpose. no external output pin. I just wonder it. If you know the history reason, please let me know. Thank you, Kyungmin Park On Sat, Feb 26, 2011 at 11:45 AM, Sangbeom Kim wrote: > This patch update mach-s5p64x0 and mach-s5pv210 > machine initialization for hrt support > > Signed-off-by: Sangbeom Kim > --- > arch/arm/mach-s5p64x0/mach-smdk6440.c | 4 +++- > arch/arm/mach-s5p64x0/mach-smdk6450.c | 4 +++- > arch/arm/mach-s5pv210/mach-aquila.c | 4 +++- > arch/arm/mach-s5pv210/mach-goni.c | 4 +++- > arch/arm/mach-s5pv210/mach-smdkc110.c | 4 +++- > arch/arm/mach-s5pv210/mach-smdkv210.c | 4 +++- > arch/arm/mach-s5pv210/mach-torbreck.c | 4 +++- > 7 files changed, 21 insertions(+), 7 deletions(-) > > diff --git a/arch/arm/mach-s5p64x0/mach-smdk6440.c > b/arch/arm/mach-s5p64x0/mach-smdk6440.c > index e5beb84..f967736 100644 > --- a/arch/arm/mach-s5p64x0/mach-smdk6440.c > +++ b/arch/arm/mach-s5p64x0/mach-smdk6440.c > @@ -43,6 +43,7 @@ > #include > #include > #include > +#include > > #define SMDK6440_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \ > S3C2410_UCON_RXILEVEL | \ > @@ -136,6 +137,7 @@ static void __init smdk6440_map_io(void) > s5p_init_io(NULL, 0, S5P64X0_SYS_ID); > s3c24xx_init_clocks(1200); > s3c24xx_init_uarts(smdk6440_uartcfgs, ARRAY_SIZE(smdk6440_uartcfgs)); > + s5p_set_timer_source(S5P_PWM2, S5P_PWM4); > } > > static void __init smdk6440_machine_init(void) > @@ -159,5 +161,5 @@ MACHINE_START(SMDK6440, "SMDK6440") > .init_irq = s5p6440_init_irq, > .map_io = smdk6440_map_io, > .init_machine = smdk6440_machine_init, > - .timer = &s3c24xx_timer, > + .timer = &s5p_timer, > MACHINE_END > diff --git a/arch/arm/mach-s5p64x0/mach-smdk6450.c > b/arch/arm/mach-s5p64x0/mach-smdk6450.c > index 3a20de0..686ec56 100644 > --- a/arch/arm/mach-s5p64x0/mach-smdk6450.c > +++ b/arch/arm/mach-s5p64x0/mach-smdk6450.c > @@ -43,6 +43,7 @@ > #include > #include > #include > +#include > > #define SMDK6450_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \ > S3C2410_UCON_RXILEVEL | \ > @@ -155,6 +156,7 @@ static void __init smdk6450_map_io(void) > s5p_init_io(NULL, 0, S5P64X0_SYS_ID); > s3c24xx_init_clocks(1920); > s3c24xx_init_uarts(smdk6450_uartcfgs, ARRAY_SIZE(smdk6450_uartcfgs)); > + s5p_set_timer_source(S5P_PWM2, S5P_PWM4); > } > > static void __init smdk6450_machine_init(void) > @@ -178,5 +180,5 @@ MACHINE_START(SMDK6450, "SMDK6450") > .init_irq = s5p6450_init_irq, > .map_io = smdk6450_map_io, > .init_machine = smdk6450_machine_init, > - .timer = &s3c24xx_timer, > + .timer = &s5p_timer, > MACHINE_END > diff --git a/arch/arm/mach-s5pv210/mach-aquila.c > b/arch/arm/mach-s5pv210/mach-aquila.c > index 557add4..fab84f3 100644 > --- a/arch/arm/mach-s5pv210/mach-aquila.c > +++ b/arch/arm/mach-s5pv210/mach-aquila.c > @@ -39,6 +39,7 @@ > #include > #include > #include > +#include > > /* Following are default values for UCON, ULCON and UFCON UART registers */ > #define AQUILA_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \ > @@ -664,6 +665,7 @@ static void __init aquila_map_io(void) > s5p_init_io(NULL, 0, S5P_VA_CHIPID); > s3c24xx_init_clocks(2400); > s3c24xx_init_uarts(aquila_uartcfgs, ARRAY_SIZE(aquila_uartcfgs)); > + s5p_set_timer_source(S5P_PWM2, S5P_PWM4); > } > > static void __init aquila_machine_init(void) > @@ -698,5 +700,5 @@ MACHINE_START(AQUILA, "Aquila") > .init_irq = s5pv210_init_irq, > .map_io = aquila_map_io, > .init_machine = aquila_machine_init, > - .timer = &s3c24xx_timer, > + .timer = &s5p_timer, > MACHINE_END > diff --git a/arch/arm/mach-s5pv210/mach-goni.c > b/arch/arm/mach-s5pv210/mach-goni.c > index 056f5c7..5eda4a1 100644 > --- a/arch/arm/mach-s5pv210/mach-goni.c > +++ b/arch/arm/mach-s5pv210/mach-goni.c > @@ -45,6 +45,7 @@ > #include > #include > #include > +#include > > /* Following are default values for UCON, ULCON and UFCON UART registers */ > #define GONI_UCON
Re: [PATCH] ARM: EXYNOS4: Fix wrong constants in the hotplug assembly code.
Hi, At that time Russell modified the s5cv310, tegra, and realview also. I think you also modify it. Thank you, Kyungmin Park On Wed, Feb 23, 2011 at 4:03 PM, Kukjin Kim wrote: > This patch fixes wrong constants in the hotplug assembly code for > Exynos4 such as Russell's changing in vexpress hotplug and fixes > hard-coded control register constatns also. > > Reported-by: Changhwan Youn > Cc: Russell King > Signed-off-by: Kukjin Kim > --- > arch/arm/mach-exynos4/hotplug.c | 8 > 1 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/mach-exynos4/hotplug.c b/arch/arm/mach-exynos4/hotplug.c > index 4c42f9c..2b5909e 100644 > --- a/arch/arm/mach-exynos4/hotplug.c > +++ b/arch/arm/mach-exynos4/hotplug.c > @@ -30,13 +30,13 @@ static inline void cpu_enter_lowpower(void) > * Turn off coherency > */ > " mrc p15, 0, %0, c1, c0, 1\n" > - " bic %0, %0, #0x20\n" > + " bic %0, %0, %3\n" > " mcr p15, 0, %0, c1, c0, 1\n" > " mrc p15, 0, %0, c1, c0, 0\n" > " bic %0, %0, %2\n" > " mcr p15, 0, %0, c1, c0, 0\n" > : "=&r" (v) > - : "r" (0), "Ir" (CR_C) > + : "r" (0), "Ir" (CR_C), "Ir" (0x40) > : "cc"); > } > > @@ -49,10 +49,10 @@ static inline void cpu_leave_lowpower(void) > " orr %0, %0, %1\n" > " mcr p15, 0, %0, c1, c0, 0\n" > " mrc p15, 0, %0, c1, c0, 1\n" > - " orr %0, %0, #0x20\n" > + " orr %0, %0, %2\n" > " mcr p15, 0, %0, c1, c0, 1\n" > : "=&r" (v) > - : "Ir" (CR_C) > + : "Ir" (CR_C), "Ir" (0x40) > : "cc"); > } > > -- > 1.7.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 > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/11] ARM: EXYNOS4: Change ARCH name, ARCH_EXYNOS4 from ARCH_S5PV310
On Tue, Feb 15, 2011 at 10:52 AM, Sangbeom Kim wrote: > Hi, > > On Monday, February 14, 2011 8:16 PM, Kyungmin Park wrote: >> > Hi, >> > I answer your questions in detail. >> > >> >> On Monday, February 14, 2011 8:16 PM, Kyungmin Park wrote: >> >> >> >> Hi, >> >> >> >> Wow, fast move, but need to more explanation. >> >> what's the exact meaning of exynos4210? >> >> Exynos4 is prefix and remaining are variants? >> > >> > Exynos4210 means below. >> > >> > 1st digit means ARM core version. In this case, 4 means Cortex A9. >> > (If we release cortex A15, it will be Exynos5xxx) >> > 2nd digit means number of core. 2 mean dual core. >> > 3rd digit means application category(LSI internal category). >> > 4th digit means design rule (generation or shrink version) >> >> Nice, I want these rules. >> > >> >> Now you changed all s5pv310 to exynos4. if new exynos4xxx chip are >> >> comes then how to handle this one? >> >> e.g., exynos4220 or later. >> >> it's also conflict with mach-exynos4. do you handle all exynos4 series >> >> at this mach directory? >> >> historically there's no rules of the base RAM address at least samsung >> >> chips. >> > >> > Yes, we will handle all exynos4 series at mach-exynos4 directory. >> > In the past, there is no rule. >> > But now, we are making consistent rules with AP design team. >> > So, new version of exynos4 series will have same base RAM address. >> >> Okay, no problem with base ram address, >> >> Another one is how do you handle the GPIOs? >> Now it's also changed as EXYNOS4_GPXX, I think it's difficult to use >> the same banks as exynos4210 has if new chips are introduced. >> maybe IRQ also has similar issue. > > We already had reviewed your concern before. > S5P6450 and S5P6440 is basically same processor. > But GPIO, IRQ and some peripheral is little different. > We can handle that by checking each processors chipid. > > Please check the below patch. > http://www.spinics.net/lists/linux-samsung-soc/msg03530.html Right, in this patch it used the S5P64XX, S5P6440, and S5P6450 is used. but EXYNOS patches used the EXYNOS4 prefix instead of EXYNOS4210 at least at GPIO patch. maybe you will rename it as EXYNOS4210 and use the EXYNOS4 as representative prefix. Anyway it means it will use the cpu_is_exynos4210 or similar style to detect each cpu. and assign proper data structure Then I recommend that create the cpu.h header file as other SOC does and use a common macro if new one comes. Thank you, Kyungmin Park > > Thanks and regards, > Sangbeom Kim >> >> Now these patches assumes all exynos4 has same gpios, irqs and so on. >> >> How do you think about it? >> >> Thank you, >> Kyungmin Park >> > >> > Thanks and regards, >> > Sangbeom Kim >> > >> >> >> >> Thank you, >> >> Kyungmin Park >> >> >> >> On Mon, Feb 14, 2011 at 5:22 PM, Kukjin Kim >> wrote: >> >> > This patch set changes to ARCH_EXYNOS4 from ARCH_S5PV310 for >> supporting >> >> Samsung's >> >> > new brand name EXYNOS. Samsung officially announced about the brand >> name >> >> of EXYNOS >> >> > at MWC 2011 and The EXYNOS4 integrates a ARM Cortex A9 microporcessor >> >> with several >> >> > other peripherals to support features such as multimedai, storage, >> >> graphics and gaming. >> >> > Especially, the EXYNOS4210 CPU which is one of EXYNOS4 SoC series can >> be >> >> used in >> >> > products such as Mobile devices. >> >> > >> >> > This patch set consists of the following patches. >> >> > >> >> > [PATCH 01/11] ARM: EXYNOS4: Add EXYNOS4 CPU initialization support >> >> > [PATCH 02/11] ARM: EXYNOS4: Update Clock part >> >> > [PATCH 03/11] ARM: EXYNOS4: Update IRQ part >> >> > [PATCH 04/11] ARM: EXYNOS4: Update Timer part >> >> > [PATCH 05/11] ARM: EXYNOS4: Update device support >> >> > [PATCH 06/11] ARM: EXYNOS4: Moved board support files >> >> > [PATCH 07/11] ARM: EXYNOS4: Update Kconfig and Makefile for the new >> >> ARCH_EXYNOS4 >> >> > [PATCH 08/11] ARM: exynos4_defconfig: Add defconfig for EXYNOS4 >> >> > [PATCH 09/11] mtd: OneNAND: Change dependency of ARCH_EXYNOS4 >> >
Re: [PATCH 0/11] ARM: EXYNOS4: Change ARCH name, ARCH_EXYNOS4 from ARCH_S5PV310
On Tue, Feb 15, 2011 at 8:53 AM, Sangbeom Kim wrote: > Hi, > I answer your questions in detail. > >> On Monday, February 14, 2011 8:16 PM, Kyungmin Park wrote: >> >> Hi, >> >> Wow, fast move, but need to more explanation. >> what's the exact meaning of exynos4210? >> Exynos4 is prefix and remaining are variants? > > Exynos4210 means below. > > 1st digit means ARM core version. In this case, 4 means Cortex A9. > (If we release cortex A15, it will be Exynos5xxx) > 2nd digit means number of core. 2 mean dual core. > 3rd digit means application category(LSI internal category). > 4th digit means design rule (generation or shrink version) Nice, I want these rules. > >> Now you changed all s5pv310 to exynos4. if new exynos4xxx chip are >> comes then how to handle this one? >> e.g., exynos4220 or later. >> it's also conflict with mach-exynos4. do you handle all exynos4 series >> at this mach directory? >> historically there's no rules of the base RAM address at least samsung >> chips. > > Yes, we will handle all exynos4 series at mach-exynos4 directory. > In the past, there is no rule. > But now, we are making consistent rules with AP design team. > So, new version of exynos4 series will have same base RAM address. Okay, no problem with base ram address, Another one is how do you handle the GPIOs? Now it's also changed as EXYNOS4_GPXX, I think it's difficult to use the same banks as exynos4210 has if new chips are introduced. maybe IRQ also has similar issue. Now these patches assumes all exynos4 has same gpios, irqs and so on. How do you think about it? Thank you, Kyungmin Park > > Thanks and regards, > Sangbeom Kim > >> >> Thank you, >> Kyungmin Park >> >> On Mon, Feb 14, 2011 at 5:22 PM, Kukjin Kim wrote: >> > This patch set changes to ARCH_EXYNOS4 from ARCH_S5PV310 for supporting >> Samsung's >> > new brand name EXYNOS. Samsung officially announced about the brand name >> of EXYNOS >> > at MWC 2011 and The EXYNOS4 integrates a ARM Cortex A9 microporcessor >> with several >> > other peripherals to support features such as multimedai, storage, >> graphics and gaming. >> > Especially, the EXYNOS4210 CPU which is one of EXYNOS4 SoC series can be >> used in >> > products such as Mobile devices. >> > >> > This patch set consists of the following patches. >> > >> > [PATCH 01/11] ARM: EXYNOS4: Add EXYNOS4 CPU initialization support >> > [PATCH 02/11] ARM: EXYNOS4: Update Clock part >> > [PATCH 03/11] ARM: EXYNOS4: Update IRQ part >> > [PATCH 04/11] ARM: EXYNOS4: Update Timer part >> > [PATCH 05/11] ARM: EXYNOS4: Update device support >> > [PATCH 06/11] ARM: EXYNOS4: Moved board support files >> > [PATCH 07/11] ARM: EXYNOS4: Update Kconfig and Makefile for the new >> ARCH_EXYNOS4 >> > [PATCH 08/11] ARM: exynos4_defconfig: Add defconfig for EXYNOS4 >> > [PATCH 09/11] mtd: OneNAND: Change dependency of ARCH_EXYNOS4 >> > [PATCH 10/11] ASoC: Change dependency of ARCH_EXYNOS4 >> > [PATCH 11/11] tty: Change dependency of ARCH_EXYNOS4 >> > >> > ___ >> > linux-arm-kernel mailing list >> > linux-arm-ker...@lists.infradead.org >> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> > >> -- >> 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/11] ARM: EXYNOS4: Change ARCH name, ARCH_EXYNOS4 from ARCH_S5PV310
Hi, Wow, fast move, but need to more explanation. what's the exact meaning of exynos4210? Exynos4 is prefix and remaining are variants? Now you changed all s5pv310 to exynos4. if new exynos4xxx chip are comes then how to handle this one? e.g., exynos4220 or later. it's also conflict with mach-exynos4. do you handle all exynos4 series at this mach directory? historically there's no rules of the base RAM address at least samsung chips. Thank you, Kyungmin Park On Mon, Feb 14, 2011 at 5:22 PM, Kukjin Kim wrote: > This patch set changes to ARCH_EXYNOS4 from ARCH_S5PV310 for supporting > Samsung's > new brand name EXYNOS. Samsung officially announced about the brand name of > EXYNOS > at MWC 2011 and The EXYNOS4 integrates a ARM Cortex A9 microporcessor with > several > other peripherals to support features such as multimedai, storage, graphics > and gaming. > Especially, the EXYNOS4210 CPU which is one of EXYNOS4 SoC series can be used > in > products such as Mobile devices. > > This patch set consists of the following patches. > > [PATCH 01/11] ARM: EXYNOS4: Add EXYNOS4 CPU initialization support > [PATCH 02/11] ARM: EXYNOS4: Update Clock part > [PATCH 03/11] ARM: EXYNOS4: Update IRQ part > [PATCH 04/11] ARM: EXYNOS4: Update Timer part > [PATCH 05/11] ARM: EXYNOS4: Update device support > [PATCH 06/11] ARM: EXYNOS4: Moved board support files > [PATCH 07/11] ARM: EXYNOS4: Update Kconfig and Makefile for the new > ARCH_EXYNOS4 > [PATCH 08/11] ARM: exynos4_defconfig: Add defconfig for EXYNOS4 > [PATCH 09/11] mtd: OneNAND: Change dependency of ARCH_EXYNOS4 > [PATCH 10/11] ASoC: Change dependency of ARCH_EXYNOS4 > [PATCH 11/11] tty: Change dependency of ARCH_EXYNOS4 > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- 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: S5PV210: Add supplies for CIF camera on GONI board
On Fri, Jan 28, 2011 at 6:32 PM, Kukjin Kim wrote:
> Sylwester Nawrocki wrote:
>>
>> Add regulator supplies required for NOON010PC30 CIF sensor.
>>
>> Signed-off-by: Sylwester Nawrocki
>> Signed-off-by: Kyungmin Park
>> ---
>> arch/arm/mach-s5pv210/mach-goni.c | 24 +---
>> 1 files changed, 21 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-s5pv210/mach-goni.c
> b/arch/arm/mach-s5pv210/mach-
>> goni.c
>> index fc34575..2051cee 100644
>> --- a/arch/arm/mach-s5pv210/mach-goni.c
>> +++ b/arch/arm/mach-s5pv210/mach-goni.c
>> @@ -273,6 +273,18 @@ static struct regulator_consumer_supply
>> goni_ldo5_consumers[] = {
>> REGULATOR_SUPPLY("vmmc", "s3c-sdhci.0"),
>> };
>>
>> +static struct regulator_consumer_supply goni_ldo11_consumers[] = {
>> + REGULATOR_SUPPLY("vddio", "0-0030"), /* "CAM_IO_2.8V" */
>> +};
>
> Need array in goni_ldo11_consumers?
Yes, it's required for consistency and most consumers use this style.
Look smdk board file
http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git;a=blob;f=arch/arm/mach-s3c64xx/mach-smdk6410.c;h=e85192a86fbe1a9f51bb9da15f20899bf0b4ab3e;hb=refs/heads/for-next
303 #ifdef CONFIG_REGULATOR
304 /* ARM core */
305 static struct regulator_consumer_supply smdk6410_vddarm_consumers[] = {
306 {
307 .supply = "vddarm",
308 }
309 };
310
311 /* VDDARM, BUCK1 on J5 */
312 static struct regulator_init_data smdk6410_vddarm = {
313 .constraints = {
314 .name = "PVDD_ARM",
315 .min_uV = 100,
316 .max_uV = 130,
317 .always_on = 1,
318 .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
319 },
320 .num_consumer_supplies = ARRAY_SIZE(smdk6410_vddarm_consumers),
321 .consumer_supplies = smdk6410_vddarm_consumers,
322 };
>
> +static struct regulator_consumer_supply goni_ldo11_consumers =
> + REGULATOR_SUPPLY("vddio", "0-0030"); /* "CAM_IO_2.8V" */
>
>> +
>> +static struct regulator_consumer_supply goni_ldo13_consumers[] = {
>> + REGULATOR_SUPPLY("vdda", "0-0030"), /* "CAM_A_2.8V" */
>> +};
>
> Same above.
>
>> +
>> +static struct regulator_consumer_supply goni_ldo14_consumers[] = {
>> + REGULATOR_SUPPLY("vdd_core", "0-0030"), /* "CAM_CIF_1.8V" */
>> +};
>
> Same above.
>
>> +
>> static struct regulator_init_data goni_ldo2_data = {
>> .constraints = {
>> .name = "VALIVE_1.1V",
>> @@ -371,8 +383,10 @@ static struct regulator_init_data goni_ldo11_data = {
>> .min_uV = 280,
>> .max_uV = 280,
>> .apply_uV = 1,
>> - .always_on = 1,
>> + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
>> },
>> + .num_consumer_supplies = ARRAY_SIZE(goni_ldo11_consumers),
>> + .consumer_supplies = goni_ldo11_consumers,
>
> If you modify as per my suggestion, then need to change this like following.
Same, I want to use the same style even though it has one consumer.
and If it has one consumer, ARRAY_SIZE(some_consumers) has 1 at
compile time.
>
> + .num_consumer_supplies = 1,
> + .consumer_supplies = &goni_ldo11_consumers,
>
>> };
>>
>> static struct regulator_init_data goni_ldo12_data = {
>> @@ -391,8 +405,10 @@ static struct regulator_init_data goni_ldo13_data = {
>> .min_uV = 280,
>> .max_uV = 280,
>> .apply_uV = 1,
>> - .always_on = 1,
>> + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
>> },
>> + .num_consumer_supplies = ARRAY_SIZE(goni_ldo13_consumers),
>> + .consumer_supplies = goni_ldo13_consumers,
>
> Same above.
>
>> };
>>
>> static struct regulator_init_data goni_ldo14_data = {
>> @@ -401,8 +417,10 @@ static struct regulator_init_data goni_ldo14_data = {
>> .min_uV = 180,
>> .max_uV = 180,
>> .apply_uV = 1,
>> - .always_on = 1,
>> + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
>> },
>> + .num_consumer_supplies = ARRAY_SIZE(goni_ldo14_consumers),
>> + .consumer_supplies = goni_ldo14_consumers,
>
> Same above.
Re: [PATCH v4 2/2] sdhci-s3c: Add support no internal clock divider in host controller
On Mon, Dec 20, 2010 at 4:06 PM, Chris Ball wrote: > Hi Kyungmin, Ben, > > On Mon, Dec 20, 2010 at 11:08:00AM +0900, Kyungmin Park wrote: >> Hi Chris, >> >> Unfortunately it's not merged your tree. >> It's required for s5pc210 board. can you merge it for 37-rc6 or later? > > I'm not comfortable slipping this into .37 (-rc6 has already been > released) without an ACK from Ben, but I will accept it into mmc-next > for the .38 merge window, and Ben can yell sometime before the merge > if he doesn't agree. Does that work okay for you? It's actually bug fix for s5pc210. If there are another rc please include it if possible. But it's okay to merge .38. Thank you, Kyungmin Park -- 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] sdhci-s3c: Add support no internal clock divider in host controller
Hi Chris,
Unfortunately it's not merged your tree.
It's required for s5pc210 board. can you merge it for 37-rc6 or later?
Thank you,
Kyungmin Park
On Mon, Oct 11, 2010 at 2:47 PM, Kukjin Kim wrote:
> From: Jeongbae Seo
>
> This patch adds to support no internal clock divider in SDHCI.
> The external clock divider can be used to make a proper clock
> because SDHCI doesn't support internal clock divider by itself.
>
> If external clock divider type is selected, some functions related
> with clock control will be overridened by other functions.
>
> The current clock control index is added to let you know which
> clock bus is used for SDHCI when using overriding functions.
>
> The checking functions is added into sdhci_s3c_consider_clock,
> because clock divider step is different from that of host controller.
>
> Signed-off-by: Jeongbae Seo
> Cc: Jaehoon Chung
> Cc: Kyungmin Park
> Cc: Ben Dooks
> Signed-off-by: Kukjin Kim
> ---
> Changes since v3:
> - Modified comparision condition as per Kyungmin Park's suggestion
>
> Changes since v2:
> - Changed clock control method to overriding from using quirk
> - This patch is referred from that of Jaehoon Chung's support non-standard
> clock setting
>
> Changes since v1:
> - Separated to each topic
>
> NOTE :
> - This patch depends on following.
> [PATCH 4/5] ARM: SAMSUNG : Add clock types into platform data
>
> drivers/mmc/host/sdhci-s3c.c | 62
> ++
> 1 files changed, 62 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index a7710f5..e7208f6 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -130,6 +130,15 @@ static unsigned int sdhci_s3c_consider_clock(struct
> sdhci_s3c *ourhost,
> if (!clksrc)
> return UINT_MAX;
>
> + /*
> + * Clock divider's step is different as 1 from that of host controller
> + * when 'clk_type' is S3C_SDHCI_CLK_DIV_EXTERNAL.
> + */
> + if (ourhost->pdata->clk_type == S3C_SDHCI_CLK_DIV_EXTERNAL) {
> + rate = clk_round_rate(clksrc, wanted);
> + return wanted - rate;
> + }
> +
> rate = clk_get_rate(clksrc);
>
> for (div = 1; div < 256; div *= 2) {
> @@ -232,6 +241,42 @@ static unsigned int sdhci_s3c_get_min_clock(struct
> sdhci_host *host)
> return min;
> }
>
> +/* sdhci_cmu_get_max_clk - callback to get maximum clock frequency.*/
> +static unsigned int sdhci_cmu_get_max_clock(struct sdhci_host *host)
> +{
> + struct sdhci_s3c *ourhost = to_s3c(host);
> +
> + return clk_round_rate(ourhost->clk_bus[ourhost->cur_clk], UINT_MAX);
> +}
> +
> +/* sdhci_cmu_get_min_clock - callback to get minimal supported clock value.
> */
> +static unsigned int sdhci_cmu_get_min_clock(struct sdhci_host *host)
> +{
> + struct sdhci_s3c *ourhost = to_s3c(host);
> +
> + /*
> + * initial clock can be in the frequency range of
> + * 100KHz-400KHz, so we set it as max value.
> + */
> + return clk_round_rate(ourhost->clk_bus[ourhost->cur_clk], 40);
> +}
> +
> +/* sdhci_cmu_set_clock - callback on clock change.*/
> +static void sdhci_cmu_set_clock(struct sdhci_host *host, unsigned int clock)
> +{
> + struct sdhci_s3c *ourhost = to_s3c(host);
> +
> + /* don't bother if the clock is going off */
> + if (clock == 0)
> + return;
> +
> + sdhci_s3c_set_clock(host, clock);
> +
> + clk_set_rate(ourhost->clk_bus[ourhost->cur_clk], clock);
> +
> + host->clock = clock;
> +}
> +
> static struct sdhci_ops sdhci_s3c_ops = {
> .get_max_clock = sdhci_s3c_get_max_clk,
> .set_clock = sdhci_s3c_set_clock,
> @@ -361,6 +406,13 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
>
> clks++;
> sc->clk_bus[ptr] = clk;
> +
> + /*
> + * save current clock index to know which clock bus
> + * is used later in overriding functions.
> + */
> + sc->cur_clk = ptr;
> +
> clk_enable(clk);
>
> dev_info(dev, "clock source %d: %s (%ld Hz)\n",
> @@ -427,6 +479,16 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
> /* HSMMC on Samsung SoCs uses SDCLK as timeout clock */
> host->quirks |= SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK;
>
> + /*
> +
Re: [PATCH] [media] s5p-fimc: fix main scaler SFRs depends on FIMC version
caler_ext(struct fimc_ctx *ctx)
> +{
> + struct fimc_dev *dev = ctx->fimc_dev;
> + struct fimc_scaler *sc = &ctx->scaler;
> + u32 cfg, cfg_ext;
> +
> + dbg("main_hratio= 0x%X main_vratio= 0x%X",
> + sc->main_hratio, sc->main_vratio);
> +
> + fimc_hw_set_scaler(ctx);
> +
> + cfg = readl(dev->regs + S5P_CISCCTRL);
> + cfg &= ~S5P_CISCCTRL_SC_HORRATIO_MASK;
> + cfg &= ~S5P_CISCCTRL_SC_VERRATIO_MASK;
> + cfg |= S5P_CISCCTRL_SC_HORRATIO_EXT(sc->main_hratio);
> + cfg |= S5P_CISCCTRL_SC_VERRATIO_EXT(sc->main_vratio);
> +
> + writel(cfg, dev->regs + S5P_CISCCTRL);
> +
> + cfg_ext = readl(dev->regs + S5P_CIEXTEN);
> + cfg_ext &= ~S5P_CIEXTEN_MAINHORRATIO_EXT_MASK;
> + cfg_ext &= ~S5P_CIEXTEN_MAINVERRATIO_EXT_MASK;
> + cfg_ext |= S5P_CIEXTEN_MAINHORRATIO_EXT(sc->main_hratio);
> + cfg_ext |= S5P_CIEXTEN_MAINVERRATIO_EXT(sc->main_vratio);
> +
> + writel(cfg_ext, dev->regs + S5P_CIEXTEN);
> +}
> +
> void fimc_hw_en_capture(struct fimc_ctx *ctx)
> {
> struct fimc_dev *dev = ctx->fimc_dev;
> diff --git a/drivers/media/video/s5p-fimc/regs-fimc.h
> b/drivers/media/video/s5p-fimc/regs-fimc.h
> index 57e33f8..4d1abd1 100644
> --- a/drivers/media/video/s5p-fimc/regs-fimc.h
> +++ b/drivers/media/video/s5p-fimc/regs-fimc.h
> @@ -141,6 +141,10 @@
> #define S5P_CISCCTRL_ONE2ONE (1 << 9)
> #define S5P_CISCCTRL_SC_HORRATIO(x) ((x) << 16)
> #define S5P_CISCCTRL_SC_VERRATIO(x) ((x) << 0)
> +#define S5P_CISCCTRL_SC_HORRATIO_MASK (0x1ff << 16)
> +#define S5P_CISCCTRL_SC_VERRATIO_MASK (0x1ff << 0)
> +#define S5P_CISCCTRL_SC_HORRATIO_EXT(x) ((x >> 6) << 16)
> +#define S5P_CISCCTRL_SC_VERRATIO_EXT(x) ((x >> 6) << 0)
>
> /* Target area */
> #define S5P_CITAREA 0x5c
> @@ -262,7 +266,11 @@
> #define S5P_ORIG_SIZE_HOR(x) ((x) << 0)
>
> /* Real output DMA image size (extension register) */
> -#define S5P_CIEXTEN 0x188
> +#define S5P_CIEXTEN 0x188
> +#define S5P_CIEXTEN_MAINHORRATIO_EXT(x) (((x) & 0x3f) << 10)
> +#define S5P_CIEXTEN_MAINVERRATIO_EXT(x) ((x) & 0x3f)
> +#define S5P_CIEXTEN_MAINHORRATIO_EXT_MASK (0x3f << 10)
> +#define S5P_CIEXTEN_MAINVERRATIO_EXT_MASK (0x3f)
>
> #define S5P_CIDMAPARAM 0x18c
> #define S5P_CIDMAPARAM_R_LINEAR (0 << 29)
> --
> 1.6.2.5
Thank you,
Kyungmin Park
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v4 0/4] Multi Format Codec 5.0 driver for S5PC110 SoC
On Fri, Dec 10, 2010 at 12:40 PM, Kukjin Kim wrote: > Kyungmin Park wrote: >> >> On Fri, Dec 10, 2010 at 11:32 AM, Kukjin Kim > wrote: >> > Kamil Debski wrote: >> >> >> >> Hello, >> >> >> >> Last week v3 of this driver has been posted. Since then the driver was >> >> changed >> >> to use the newest videobuf2 version - v6. Two very long functions have >> > been >> >> split to make the code more readible. Minor changes include tidying the >> >> comments and replacing remaining magic numbers with defines. >> >> >> >> I would be grateful for your comments. Original cover letter ant > detailed >> >> change >> >> log has been attached below. >> >> >> >> Best regards, >> >> Kamil Debski >> >> >> >> * Changelog: >> >> >> >> == >> >> Changes since v3 >> >> == >> >> >> >> 1) Update to the v6 videobuf2 API (here thanks go to Marek Szyprowski) >> >> - s5p_mfc_buf_negotiate and s5p_mfc_buf_setup_plane functions >> >> have been merged >> >> - queue initialization has been adapted to the new API >> >> - use of the allocator memops has been changed, now there are single >> >> memops for all the allocator contexts >> >> >> >> 2) Split of the s5p_mfc_try_run and s5p_mfc_handle_frame_int functions >> >> - parts of the s5p_mfc_try_run function have been moved to separate >> >> functions (s5p_mfc_get_new_ctx, s5p_mfc_run_dec_last_frames, >> >> s5p_mfc_run_dec_frame, s5p_mfc_run_get_inst_no, s5p_mfc_run_return_inst >> >> s5p_mfc_run_init_dec,s5p_mfc_run_init_dec_buffers) >> >> - s5p_mfc_handle_frame_int has been split to the following functions: >> >> s5p_mfc_handle_frame_all_extracted, s5p_mfc_handle_frame_new >> >> and s5p_mfc_handle_frame to handle different cases >> >> >> >> 3) Remove remaining magic numbers and tidy up comments >> >> >> >> == >> >> Changes since v2 >> >> == >> >> >> >> 1) Update to newest videobuf2 API >> >> This is the major change from v2. The videobuf2 API will hopefully have > no >> >> more >> >> major API changes. Buffer initialization has been moved from > buf_prepare >> >> callback to buf_init to simplify the process. Locking mechanism has > been >> >> modified to the requirements of new videobuf2 version. >> >> 2) Code cleanup >> >> Removed more magic contants and replaced them with appropriate defines. >> >> Changed >> >> code to use unlocked_ioctl instead of ioctl in v4l2 file ops. >> >> 3) Allocators >> >> All internal buffer allocations are done using the selected vb2 > allocator, >> >> instead of using CMA functions directly. >> >> >> >> == >> >> Changes since v1 >> >> == >> >> >> >> 1) Cleanup accoridng to Peter Oh suggestions on the mailing list > (Thanks). >> >> >> >> * Original cover letter: >> >> >> >> == >> >> Introduction >> >> == >> >> >> >> The purpose of this RFC is to discuss the driver for a hw video codec >> >> embedded in the new Samusng's SoCs. Multi Format Codec 5.0 is able to >> >> handle video decoding of in a range of formats. >> >> >> >> So far no hardware codec was supported in V4L2 and this would be the >> >> first one. I guess there are more similar device that would benefit > from >> >> a V4L2 unified interface. I suggest a separate control class for codec >> >> devices - V4L2_CTRL_CLASS_CODEC. >> >> >> >> Internally the driver uses videobuf2 framework and CMA memory > allocator. >> >> I am aware that those have not yet been merged, but I wanted to start >> >> discussion about the driver earlier so it could be merged sooner. The >> >> driver posted here is the initial version, so I suppose it will require >> >> more work. >> >> >> >> == >> >> Device interface >> >> == >> >> >> >> The driver principle is based on the idea of memory-to-memory devices: >> >> it provides a singl
Re: [RFC/PATCH v4 0/4] Multi Format Codec 5.0 driver for S5PC110 SoC
>> == >> >> First the OUTPUT queue is initialized. With S_FMT the application >> chooses which video format to decode and what size should be the input >> buffer. Fourcc values have been defined for different codecs e.g. >> V4L2_PIX_FMT_H264 for h264. Then the OUTPUT buffers are requested and >> mmaped. The stream header frame is loaded into the first buffer, queued >> and streaming is enabled. At this point the hardware is able to start >> processing the stream header and afterwards it will have information >> about the video dimensions and the size of the buffers with raw video >> data. >> >> The next step is setting up the CAPTURE queue and buffers. The width, >> height, buffer size and minimum number of buffers can be read with G_FMT >> call. The application can request more output buffer if necessary. After >> requesting and mmaping buffers the device is ready to decode video >> stream. >> >> The stream frames (ES frames) are written to the OUTPUT buffers, and >> decoded video frames can be read from the CAPTURE buffers. When no more >> source frames are present a single buffer with bytesused set to 0 should >> be queued. This will inform the driver that processing should be >> finished and it can dequeue all video frames that are still left. The >> number of such frames is dependent on the stream and its internal >> structure (how many frames had to be kept as reference frames for >> decoding, etc). >> >> === >> Usage summary >> === >> >> This is a step by step summary of the video decoding (from user >> application point of view, with 2 treads and blocking api): >> >> 01. S_FMT(OUTPUT, V4L2_PIX_FMT_H264, ...) >> 02. REQ_BUFS(OUTPUT, n) >> 03. for i=1..n MMAP(OUTPUT, i) >> 04. put stream header to buffer #1 >> 05. QBUF(OUTPUT, #1) >> 06. STREAM_ON(OUTPUT) >> 07. G_FMT(CAPTURE) >> 08. REQ_BUFS(CAPTURE, m) >> 09. for j=1..m MMAP(CAPTURE, j) >> 10. for j=1..m QBUF(CAPTURE, #j) >> 11. STREAM_ON(CAPTURE) >> >> display thread: >> 12. DQBUF(CAPTURE) -> got decoded video data in buffer #j >> 13. display buffer #j >> 14. QBUF(CAPTURE, #j) >> 15. goto 12 >> >> parser thread: >> 16. put next ES frame to buffer #i >> 17. QBUF(OUTPUT, #i) >> 18. DQBUF(OUTPUT) -> get next empty buffer #i 19. goto 16 >> >> ... >> >> Similar usage sequence can be achieved with single threaded application >> and non-blocking api with poll() call. >> >> Branch with MFC, CMA and videobuf2 will be soon available at >> http://git.infradead.org/users/kmpark/linux-2.6- >> samsung/shortlog/refs/heads/vb2-mfc-fimc >> This tree is based on 2.6.37 rc4. >> >> Please have a look at the code and the idea of how to introduce codec >> devices to V4L2. Comments will be very much appreciated. >> >> Patch summary: >> >> Kamil Debski (4): >> Changes in include/linux/videodev2.h for MFC >> MFC: Add MFC 5.1 driver to plat-s5p, mach-s5pv210 and mach-s5pv210 >> MFC: Added MFC 5.1 V4L2 driver >> s5pv210: Enable MFC on Goni >> >> arch/arm/mach-s5pv210/Kconfig | 1 + >> arch/arm/mach-s5pv210/clock.c | 6 + >> arch/arm/mach-s5pv210/include/mach/map.h | 4 + >> arch/arm/mach-s5pv210/mach-goni.c | 1 + >> arch/arm/plat-s5p/Kconfig | 5 + >> arch/arm/plat-s5p/Makefile | 1 + >> arch/arm/plat-s5p/dev-mfc5.c | 37 + >> arch/arm/plat-samsung/include/plat/devs.h | 2 + >> drivers/media/video/Kconfig | 8 + >> drivers/media/video/Makefile | 1 + >> drivers/media/video/s5p-mfc/Makefile | 3 + >> drivers/media/video/s5p-mfc/regs-mfc5.h | 335 >> drivers/media/video/s5p-mfc/s5p_mfc.c | 2031 >> +++ >> drivers/media/video/s5p-mfc/s5p_mfc_common.h | 222 +++ >> drivers/media/video/s5p-mfc/s5p_mfc_ctrls.h | 173 ++ >> drivers/media/video/s5p-mfc/s5p_mfc_debug.h | 47 + >> drivers/media/video/s5p-mfc/s5p_mfc_intr.c | 92 + >> drivers/media/video/s5p-mfc/s5p_mfc_intr.h | 26 + >> drivers/media/video/s5p-mfc/s5p_mfc_memory.h | 43 + >> drivers/media/video/s5p-mfc/s5p_mfc_opr.c | 870 ++ >> drivers/media/video/s5p-mfc/s5p_mfc_opr.h | 131 ++ >> include/linux/videodev2.h | 48 + >> 25 files changed, 4136 insertions(+), 1 deletions(-) >> create mode 100644 arch/arm/plat-s5p/dev-mfc5.c >> create mode 100644 drivers/media/video/s5p-mfc/Makefile >> create mode 100644 drivers/media/video/s5p-mfc/regs-mfc5.h >> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc.c >> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_common.h >> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_ctrls.h >> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_debug.h >> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_intr.c >> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_intr.h >> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_memory.h >> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr.c >> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr.h >> > > Hi Kamil, > > I think, should be added my e-mail in Cc... No need to cc all, only machine specific only. and I hope minimal modification at machine specific and move to media if possible. Thank you, Kyungmin Park -- 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/4] plat-s5p: Add platform support for MIPI-CSI2 devices
On Fri, Dec 3, 2010 at 2:14 PM, Jassi Brar wrote: > On Fri, Dec 3, 2010 at 1:37 AM, Sylwester Nawrocki > wrote: >> There may be up to 2 MIPI-CSI2 interfaces depending on SoC version. >> >> Signed-off-by: Sylwester Nawrocki >> Signed-off-by: Kyungmin Park >> --- >> arch/arm/plat-s5p/Kconfig | 10 >> arch/arm/plat-s5p/Makefile | 2 + >> arch/arm/plat-s5p/dev-csis0.c | 34 >> + >> arch/arm/plat-s5p/dev-csis1.c | 33 >> >> arch/arm/plat-samsung/include/plat/csis.h | 28 +++ >> arch/arm/plat-samsung/include/plat/devs.h | 3 ++ >> 6 files changed, 110 insertions(+), 0 deletions(-) >> create mode 100644 arch/arm/plat-s5p/dev-csis0.c >> create mode 100644 arch/arm/plat-s5p/dev-csis1.c >> create mode 100644 arch/arm/plat-samsung/include/plat/csis.h >> >> diff --git a/arch/arm/plat-s5p/Kconfig b/arch/arm/plat-s5p/Kconfig >> index 65dbfa8..2fb0c88 100644 >> --- a/arch/arm/plat-s5p/Kconfig >> +++ b/arch/arm/plat-s5p/Kconfig >> @@ -56,3 +56,13 @@ config S5P_DEV_ONENAND >> bool >> help >> Compile in platform device definition for OneNAND controller >> + >> +config S5P_DEV_CSIS0 >> + bool >> + help >> + Compile in platform device definitions for MIPI-CSI2 interface 0 >> + >> +config S5P_DEV_CSIS1 >> + bool >> + help >> + Compile in platform device definitions for MIPI-CSI2 interface 1 >> diff --git a/arch/arm/plat-s5p/Makefile b/arch/arm/plat-s5p/Makefile >> index de65238..2b73173 100644 >> --- a/arch/arm/plat-s5p/Makefile >> +++ b/arch/arm/plat-s5p/Makefile >> @@ -28,3 +28,5 @@ obj-$(CONFIG_S5P_DEV_FIMC0) += dev-fimc0.o >> obj-$(CONFIG_S5P_DEV_FIMC1) += dev-fimc1.o >> obj-$(CONFIG_S5P_DEV_FIMC2) += dev-fimc2.o >> obj-$(CONFIG_S5P_DEV_ONENAND) += dev-onenand.o >> +obj-$(CONFIG_S5P_DEV_CSIS0) += dev-csis0.o >> +obj-$(CONFIG_S5P_DEV_CSIS1) += dev-csis1.o > > When we do have defines for each device, why not have both in one file > with each contained in ifdef for it's define ? That will reduce file count. To Jassi, Please make a conclusion from LSI first, I'm confused, I insisted it as you, but kgene rejected it. > -- > 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 2/4] mach-s5pv310: Add resource definitions for mipi-csis
On Fri, Dec 3, 2010 at 1:59 PM, Jassi Brar wrote: > On Fri, Dec 3, 2010 at 1:36 PM, Kukjin Kim wrote: >> Sylwester Nawrocki wrote: >>> >>> Add IRQ and register base address definitions for mipi-csis devices. >>> >>> Signed-off-by: Sylwester Nawrocki >>> Signed-off-by: Kyungmin Park >>> --- >>> arch/arm/mach-s5pv310/include/mach/irqs.h | 3 +++ >>> arch/arm/mach-s5pv310/include/mach/map.h | 5 + >>> 2 files changed, 8 insertions(+), 0 deletions(-) >>> >>> diff --git a/arch/arm/mach-s5pv310/include/mach/irqs.h b/arch/arm/mach- >>> s5pv310/include/mach/irqs.h >>> index 99e7dad..db63773 100644 >>> --- a/arch/arm/mach-s5pv310/include/mach/irqs.h >>> +++ b/arch/arm/mach-s5pv310/include/mach/irqs.h >>> @@ -83,6 +83,9 @@ >>> #define IRQ_HSMMC2 COMBINER_IRQ(29, 2) >>> #define IRQ_HSMMC3 COMBINER_IRQ(29, 3) >>> >>> +#define IRQ_MIPICSI0 COMBINER_IRQ(30, 0) >>> +#define IRQ_MIPICSI1 COMBINER_IRQ(30, 1) >>> + >>> #define IRQ_ONENAND_AUDI COMBINER_IRQ(34, 0) >>> >>> #define IRQ_EINT4 COMBINER_IRQ(37, 0) >>> diff --git a/arch/arm/mach-s5pv310/include/mach/map.h b/arch/arm/mach- >>> s5pv310/include/mach/map.h >>> index 7acf4e7..9905bfe 100644 >>> --- a/arch/arm/mach-s5pv310/include/mach/map.h >>> +++ b/arch/arm/mach-s5pv310/include/mach/map.h >>> @@ -56,6 +56,9 @@ >>> #define S5PV310_PA_GPIO2 (0x1100) >>> #define S5PV310_PA_GPIO3 (0x0386) >>> >>> +#define S5PV310_PA_CSIS0 (0x1188) >>> +#define S5PV310_PA_CSIS1 (0x1189) > > Let us please not contain constants in brackets. I think consistency is more higher than your comment normally. if you think these, then make a cleanup first. > -- > 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 1/4] mach-s5pv210: Add platform definitions for mipi-csis
On Fri, Dec 3, 2010 at 1:22 PM, Kukjin Kim wrote: > Sylwester Nawrocki wrote: >> >> Added resource definitions for mipi-csis interface, naming >> changed for consistency with s5pv310 where there are two >> instances of the device. >> >> Signed-off-by: Sylwester Nawrocki >> Signed-off-by: Kyungmin Park >> --- >> arch/arm/mach-s5pv210/include/mach/irqs.h | 2 +- >> arch/arm/mach-s5pv210/include/mach/map.h | 4 >> arch/arm/mach-s5pv210/include/mach/regs-clock.h | 5 + >> 3 files changed, 6 insertions(+), 5 deletions(-) >> >> diff --git a/arch/arm/mach-s5pv210/include/mach/irqs.h b/arch/arm/mach- >> s5pv210/include/mach/irqs.h >> index 119b95f..8b5994c 100644 >> --- a/arch/arm/mach-s5pv210/include/mach/irqs.h >> +++ b/arch/arm/mach-s5pv210/include/mach/irqs.h >> @@ -65,7 +65,7 @@ >> #define IRQ_HSMMC0 S5P_IRQ_VIC1(26) >> #define IRQ_HSMMC1 S5P_IRQ_VIC1(27) >> #define IRQ_HSMMC2 S5P_IRQ_VIC1(28) >> -#define IRQ_MIPICSI S5P_IRQ_VIC1(29) >> +#define IRQ_MIPICSI0 S5P_IRQ_VIC1(29) > > Firstly don't use directly IRQ_MIPICSI0 which is used in platform device. > Because it can be confused that there would be another MIPICSI such as > MIPICSI1. > In that case, just use like following. For example, Hi, First respect others work. my impression is that you forced the developers to work as you want. okay who summit this code? If you think name is odd, then you check it before you submitted. When you commit the code is okay, but other should be considered as yours. > > --- > @@ -132,5 +132,6 @@ > #define IRQ_LCD_FIFO IRQ_LCD0 > #define IRQ_LCD_VSYNC IRQ_LCD1 > #define IRQ_LCD_SYSTEM IRQ_LCD2 > +#define IRQ_MIPI_CSIS0 IRQ_MIPICSI > > #endif /* ASM_ARCH_IRQS_H */ > --- > > And I'm confused about the name of MIPI-CSI... > Hmm...used MIPICSI or MIPI_CSI, sometimes MIPICSIS or MIPI_CSIS. > > Maybe the meaning is Camera Serial Interface Slave... > So...how about to use just one such as "IRQ_MIPI_CSIS" and > "S5PV210_PA_MIPI_CSIS". I think it's better use the common word, CSI. I can't find CSIS word at googling. > > --- > @@ -65,7 +65,7 @@ > #define IRQ_HSMMC0 S5P_IRQ_VIC1(26) > #define IRQ_HSMMC1 S5P_IRQ_VIC1(27) > #define IRQ_HSMMC2 S5P_IRQ_VIC1(28) > -#define IRQ_MIPICSI S5P_IRQ_VIC1(29) > +#define IRQ_MIPI_CSIS S5P_IRQ_VIC1(29) > #define IRQ_MIPIDSI S5P_IRQ_VIC1(30) > #define IRQ_ONENAND_AUDI S5P_IRQ_VIC1(31) > > @@ -132,5 +132,6 @@ > #define IRQ_LCD_FIFO IRQ_LCD0 > #define IRQ_LCD_VSYNC IRQ_LCD1 > #define IRQ_LCD_SYSTEM IRQ_LCD2 > +#define IRQ_MIPI_CSIS0 IRQ_MIPI_CSIS In this case, I can't find any good reason since it's first used. as s3c series used the different names compare to s5p series. it's okay make these wrapper. but it's new one and not used previous time. Thank you, Kyungmin Park > > #endif /* ASM_ARCH_IRQS_H */ > --- > >> #define IRQ_MIPIDSI S5P_IRQ_VIC1(30) >> #define IRQ_ONENAND_AUDI S5P_IRQ_VIC1(31) >> >> diff --git a/arch/arm/mach-s5pv210/include/mach/map.h b/arch/arm/mach- >> s5pv210/include/mach/map.h >> index 861d7fe..8f376f1 100644 >> --- a/arch/arm/mach-s5pv210/include/mach/map.h >> +++ b/arch/arm/mach-s5pv210/include/mach/map.h >> @@ -107,6 +107,9 @@ >> #define S5PV210_PA_DMC0 (0xF000) >> #define S5PV210_PA_DMC1 (0xF140) >> >> +/* MIPI CSI */ > > No need comment. > >> +#define S5PV210_PA_CSIS 0xFA60 >> + >> /* compatibiltiy defines. */ >> #define S3C_PA_UART S5PV210_PA_UART >> #define S3C_PA_HSMMC0 S5PV210_PA_HSMMC(0) >> @@ -123,6 +126,7 @@ >> #define S5P_PA_FIMC0 S5PV210_PA_FIMC0 >> #define S5P_PA_FIMC1 S5PV210_PA_FIMC1 >> #define S5P_PA_FIMC2 S5PV210_PA_FIMC2 >> +#define S5P_PA_CSIS0 S5PV210_PA_CSIS >> > Same as above. > >> #define SAMSUNG_PA_ADC S5PV210_PA_ADC >> #define SAMSUNG_PA_CFCON S5PV210_PA_CFCON >> diff --git a/arch/arm/mach-s5pv210/include/mach/regs-clock.h > b/arch/arm/mach- >> s5pv210/include/mach/regs-clock.h >> index ebaabe0..4c45b74 100644 >> --- a/arch/arm/mach-s5pv210/include/mach/regs-clock.h >> +++ b/arch/arm/mach-s5pv210/include/mach/regs-clock.h >> @@ -161,7 +161,7 @@ >> #define S5P_MDNIE_SEL S5P_CLKREG(0x7008) >> #define S5P_
Re: [PATCH 1/3] rtc: rtc-s3c: Fix return type and argument of s3c_rtc_setaie
Hi,
It's same patch early.
I used the email address by ./script/get_maintainer.sh
http://groups.google.com/group/linux.kernel/browse_thread/thread/953c417a31756ab9?pli=1
Thank you,
Kyungmin Park
On Tue, Nov 16, 2010 at 9:02 AM, Kukjin Kim wrote:
> According to struct rtc_class_ops, this patch fixes return type
> and argument of s3c_rtc_setaie().
>
> int (*alarm_irq_enable)(struct device *, unsigned int enabled);
>
> Cc: Ben Dooks
> Cc: Wan ZongShun
> Cc: Alessandro Zummo
> Signed-off-by: Kukjin Kim
> ---
> drivers/rtc/rtc-s3c.c | 13 +++--
> 1 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
> index cf953ec..e2636ff 100644
> --- a/drivers/rtc/rtc-s3c.c
> +++ b/drivers/rtc/rtc-s3c.c
> @@ -76,19 +76,20 @@ static irqreturn_t s3c_rtc_tickirq(int irq, void *id)
> return IRQ_HANDLED;
> }
>
> -/* Update control registers */
> -static void s3c_rtc_setaie(int to)
> +static int s3c_rtc_setaie(struct device *dev, unsigned int enabled)
> {
> unsigned int tmp;
>
> - pr_debug("%s: aie=%d\n", __func__, to);
> + pr_debug("%s: aie=%d\n", __func__, enabled);
>
> tmp = readb(s3c_rtc_base + S3C2410_RTCALM) & ~S3C2410_RTCALM_ALMEN;
>
> - if (to)
> + if (enabled)
> tmp |= S3C2410_RTCALM_ALMEN;
>
> writeb(tmp, s3c_rtc_base + S3C2410_RTCALM);
> +
> + return 0;
> }
>
> static int s3c_rtc_setpie(struct device *dev, int enabled)
> @@ -308,7 +309,7 @@ static int s3c_rtc_setalarm(struct device *dev, struct
> rtc_wkalrm *alrm)
>
> writeb(alrm_en, base + S3C2410_RTCALM);
>
> - s3c_rtc_setaie(alrm->enabled);
> + s3c_rtc_setaie(dev, alrm->enabled);
>
> return 0;
> }
> @@ -440,7 +441,7 @@ static int __devexit s3c_rtc_remove(struct
> platform_device *dev)
> rtc_device_unregister(rtc);
>
> s3c_rtc_setpie(&dev->dev, 0);
> - s3c_rtc_setaie(0);
> + s3c_rtc_setaie(&dev->dev, 0);
>
> clk_disable(rtc_clk);
> clk_put(rtc_clk);
> --
> 1.6.2.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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] ARM: SAMSUNG: Add to enable/disable clock on S3C PL330
On Thu, Oct 21, 2010 at 11:36 AM, Kukjin Kim wrote: > Kyungmin Park wrote: >> >> On Thu, Oct 21, 2010 at 9:58 AM, Kukjin Kim wrote: >> > From: Seungwhan Youn >> > >> > This patch adds to enable/disable DMA operation clock on S3C-PL330 >> > DMA controller driver. >> >> The title and description seems to clock gating but actual code is >> just enable at probe and disable at remove. >> >> Can you make it REAL clock gating, enable clock only when using? >> > > This is just to move DMA enable/disable clock into DMA driver(S3C PL330). > So it would be better if we could discuss about what you said next time. > > Basically, I prefer most clocks should be registered as disabled, then if > required enable, just should be controlled in each driver. And support clock & block gating basically at drivers. > > 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 > -- 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] ARM: SAMSUNG: Add to enable/disable clock on S3C PL330
On Thu, Oct 21, 2010 at 10:54 AM, Jassi Brar wrote: > On Thu, Oct 21, 2010 at 10:49 AM, Kyungmin Park wrote: >>>> Can you make it REAL clock gating, enable clock only when using? >>> >>> Of course we can. But that will need some intrusive changes. >>> Later, we'll implement that desirable feature. >>> For now, many SoCs don't detect PL330 since the clocks are gated >>> by default and we don't enable them in driver. So, this is just to get >>> latest SoCs' PL330 working. >> >> I see even though I don't know "later" is how much > > We (apparently) don't have fixed policy about which devices have their clocks > enabled by default and which don't. > So, by default PL330 clock is enabled on some platforms and not on others. > This patch only makes sure the PL330 works on all platforms at boot-time. > > >> and include the s5pc210 code also at this patchset. > Yes, all platforms should be enabled for PL330 driver. BTW, what's the id of mdma and which clock at c210? > -- > 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 5/5] ARM: SAMSUNG: Add to enable/disable clock on S3C PL330
On Thu, Oct 21, 2010 at 10:45 AM, Jassi Brar wrote: > On Thu, Oct 21, 2010 at 10:32 AM, Kyungmin Park wrote: >> On Thu, Oct 21, 2010 at 9:58 AM, Kukjin Kim wrote: >>> From: Seungwhan Youn >>> >>> This patch adds to enable/disable DMA operation clock on S3C-PL330 >>> DMA controller driver. >> >> The title and description seems to clock gating but actual code is >> just enable at probe and disable at remove. >> >> Can you make it REAL clock gating, enable clock only when using? > > Of course we can. But that will need some intrusive changes. > Later, we'll implement that desirable feature. > For now, many SoCs don't detect PL330 since the clocks are gated > by default and we don't enable them in driver. So, this is just to get > latest SoCs' PL330 working. I see even though I don't know "later" is how much and include the s5pc210 code also at this patchset. > -- > 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 5/5] ARM: SAMSUNG: Add to enable/disable clock on S3C PL330
On Thu, Oct 21, 2010 at 9:58 AM, Kukjin Kim wrote:
> From: Seungwhan Youn
>
> This patch adds to enable/disable DMA operation clock on S3C-PL330
> DMA controller driver.
The title and description seems to clock gating but actual code is
just enable at probe and disable at remove.
Can you make it REAL clock gating, enable clock only when using?
Thank you,
Kyungmin Park
>
> Signed-off-by: Seungwhan Youn
> Acked-by: Jassi Brar
> Signed-off-by: Kukjin Kim
> ---
> arch/arm/plat-samsung/s3c-pl330.c | 34 +++---
> 1 files changed, 27 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/s3c-pl330.c
> b/arch/arm/plat-samsung/s3c-pl330.c
> index a91305a..b4ff8d7 100644
> --- a/arch/arm/plat-samsung/s3c-pl330.c
> +++ b/arch/arm/plat-samsung/s3c-pl330.c
> @@ -15,6 +15,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
>
> @@ -27,6 +29,7 @@
> * @node: To attach to the global list of DMACs.
> * @pi: PL330 configuration info for the DMAC.
> * @kmcache: Pool to quickly allocate xfers for all channels in the dmac.
> + * @clk: Pointer of DMAC operation clock.
> */
> struct s3c_pl330_dmac {
> unsigned busy_chan;
> @@ -34,6 +37,7 @@ struct s3c_pl330_dmac {
> struct list_head node;
> struct pl330_info *pi;
> struct kmem_cache *kmcache;
> + struct clk *clk;
> };
>
> /**
> @@ -1072,16 +1076,25 @@ static int pl330_probe(struct platform_device *pdev)
> if (ret)
> goto probe_err4;
>
> - ret = pl330_add(pl330_info);
> - if (ret)
> - goto probe_err5;
> -
> /* Allocate a new DMAC */
> s3c_pl330_dmac = kmalloc(sizeof(*s3c_pl330_dmac), GFP_KERNEL);
> if (!s3c_pl330_dmac) {
> ret = -ENOMEM;
> + goto probe_err5;
> + }
> +
> + /* Get operation clock and enable it */
> + s3c_pl330_dmac->clk = clk_get(&pdev->dev, "pdma");
> + if (IS_ERR(s3c_pl330_dmac->clk)) {
> + dev_err(&pdev->dev, "Cannot get operation clock.\n");
> + ret = -EINVAL;
> goto probe_err6;
> }
> + clk_enable(s3c_pl330_dmac->clk);
> +
> + ret = pl330_add(pl330_info);
> + if (ret)
> + goto probe_err7;
>
> /* Hook the info */
> s3c_pl330_dmac->pi = pl330_info;
> @@ -1094,7 +1107,7 @@ static int pl330_probe(struct platform_device *pdev)
>
> if (!s3c_pl330_dmac->kmcache) {
> ret = -ENOMEM;
> - goto probe_err7;
> + goto probe_err8;
> }
>
> /* Get the list of peripherals */
> @@ -1120,10 +1133,13 @@ static int pl330_probe(struct platform_device *pdev)
>
> return 0;
>
> +probe_err8:
> + pl330_del(pl330_info);
> probe_err7:
> - kfree(s3c_pl330_dmac);
> + clk_disable(s3c_pl330_dmac->clk);
> + clk_put(s3c_pl330_dmac->clk);
> probe_err6:
> - pl330_del(pl330_info);
> + kfree(s3c_pl330_dmac);
> probe_err5:
> free_irq(irq, pl330_info);
> probe_err4:
> @@ -1188,6 +1204,10 @@ static int pl330_remove(struct platform_device *pdev)
> }
> }
>
> + /* Disable operation clock */
> + clk_disable(dmac->clk);
> + clk_put(dmac->clk);
> +
> /* Remove the DMAC */
> list_del(&dmac->node);
> kfree(dmac);
> --
> 1.6.2.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] ARM: S5P: Add initial map for GPIO2 and GPIO3
On Thu, Oct 14, 2010 at 2:24 PM, Kukjin Kim wrote:
> Sangbeom Kim wrote:
>>
>> From: Jongpill Lee
>>
>> This patch adds initial map for GPIO2 and GPIO3.
>> S5PV310/S5PC210 has separated GPIO1, GPIO2 and GPIO3.
>>
>> Signed-off-by: Jongpill Lee
>> Signed-off-by: Sangbeom Kim
>> ---
>> Changes since v1:
>> - Rebased on latest for-next from Kukjin Kim's git tree
>> - Added S5P_VA_GPIO1 according to S5PV310_PA_GPIO1
>>
>> arch/arm/mach-s5pv310/cpu.c | 12 +++-
>> arch/arm/plat-s5p/include/plat/map-s5p.h | 3 +++
>> 2 files changed, 14 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-s5pv310/cpu.c b/arch/arm/mach-s5pv310/cpu.c
>> index 3345cf6..ffed262 100644
>> --- a/arch/arm/mach-s5pv310/cpu.c
>> +++ b/arch/arm/mach-s5pv310/cpu.c
>> @@ -57,11 +57,21 @@ static struct map_desc s5pv310_iodesc[] __initdata = {
>> .length = SZ_4K,
>> .type = MT_DEVICE,
>> }, {
>> - .virtual = (unsigned long)S5P_VA_GPIO,
>> + .virtual = (unsigned long)S5P_VA_GPIO1,
>> .pfn = __phys_to_pfn(S5PV310_PA_GPIO1),
>> .length = SZ_4K,
>> .type = MT_DEVICE,
>> }, {
>> + .virtual = (unsigned long)S5P_VA_GPIO2,
>> + .pfn = __phys_to_pfn(S5PV310_PA_GPIO2),
>> + .length = SZ_4K,
>> + .type = MT_DEVICE,
>> + }, {
>> + .virtual = (unsigned long)S5P_VA_GPIO3,
>> + .pfn = __phys_to_pfn(S5PV310_PA_GPIO3),
>> + .length = SZ_256K,
Why 256K?
>> + .type = MT_DEVICE,
>> + }, {
>> .virtual = (unsigned long)S5P_VA_DMC0,
>> .pfn = __phys_to_pfn(S5PV310_PA_DMC0),
>> .length = SZ_4K,
>> diff --git a/arch/arm/plat-s5p/include/plat/map-s5p.h b/arch/arm/plat-
>> s5p/include/plat/map-s5p.h
>> index ec96a19..fef353d 100644
>> --- a/arch/arm/plat-s5p/include/plat/map-s5p.h
>> +++ b/arch/arm/plat-s5p/include/plat/map-s5p.h
>> @@ -16,6 +16,9 @@
>> #define S5P_VA_CHIPID S3C_ADDR(0x0200)
>> #define S5P_VA_CMU S3C_ADDR(0x0210)
>> #define S5P_VA_GPIO S3C_ADDR(0x0220)
>> +#define S5P_VA_GPIO1 S5P_VA_GPIO
>> +#define S5P_VA_GPIO2 S3C_ADDR(0x0224)
>> +#define S5P_VA_GPIO3 S3C_ADDR(0x0228)
>>
>> #define S5P_VA_SYSRAM S3C_ADDR(0x0240)
>> #define S5P_VA_DMC0 S3C_ADDR(0x0244)
>> --
>
> Looks ok to me...will apply.
>
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim , Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
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: S5PV210: Add init code of audio to Goni and Aquila board
On Thu, Oct 14, 2010 at 10:07 AM, Jassi Brar wrote: > On Thu, Oct 14, 2010 at 9:32 AM, Kukjin Kim wrote: >> Chanwoo Choi wrote: >>> >>> This patch add initializtion code of audio and I2S platform drivers >>> to Goni and Aquila board. > > GONI and AQUILA are mostly similar devices with different CPUs. > I have already merged the ASoC machine drivers for them into one. > Maybe you could compress code for other susystems as well ? It's not exactly. GPIO pins are different. Thank you, Kyungmin Park > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/2] sdhci-s3c: Add support no internal clock divider in host controller
Hi Chris,
we make a conclusion use this patch. Can you merge it for 2.6.37?
Acked-by: Kyungmin Park
On Mon, Oct 11, 2010 at 4:50 PM, Kukjin Kim wrote:
> From: Jeongbae Seo
>
> This patch adds to support no internal clock divider in SDHCI.
> The external clock divider can be used to make a proper clock
> because SDHCI doesn't support internal clock divider by itself.
>
> If external clock divider type is selected, some functions related
> with clock control will be overridened by other functions.
>
> The current clock control index is added to let you know which
> clock bus is used for SDHCI when using overriding functions.
>
> The checking functions is added into sdhci_s3c_consider_clock,
> because clock divider step is different from that of host controller.
>
> Signed-off-by: Jeongbae Seo
> Cc: Jaehoon Chung
> Cc: Kyungmin Park
> Cc: Ben Dooks
> Signed-off-by: Kukjin Kim
> ---
> Changes since v4:
> - Added missing change
>
> Changes since v3:
> - Modified comparision condition as per Kyungmin Park's suggestion
>
> Changes since v2:
> - Changed clock control method to overriding from using quirk
> - This patch is referred from that of Jaehoon Chung's support non-standard
> clock setting
>
> Changes since v1:
> - Separated to each topic
>
> NOTE :
> - This patch depends on following.
> [PATCH 4/5] ARM: SAMSUNG : Add clock types into platform data
>
> drivers/mmc/host/sdhci-s3c.c | 62
> ++
> 1 files changed, 62 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index a7710f5..e7208f6 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -130,6 +130,15 @@ static unsigned int sdhci_s3c_consider_clock(struct
> sdhci_s3c *ourhost,
> if (!clksrc)
> return UINT_MAX;
>
> + /*
> + * Clock divider's step is different as 1 from that of host controller
> + * when 'clk_type' is S3C_SDHCI_CLK_DIV_EXTERNAL.
> + */
> + if (ourhost->pdata->clk_type == S3C_SDHCI_CLK_DIV_EXTERNAL) {
> + rate = clk_round_rate(clksrc, wanted);
> + return wanted - rate;
> + }
> +
> rate = clk_get_rate(clksrc);
>
> for (div = 1; div < 256; div *= 2) {
> @@ -232,6 +241,42 @@ static unsigned int sdhci_s3c_get_min_clock(struct
> sdhci_host *host)
> return min;
> }
>
> +/* sdhci_cmu_get_max_clk - callback to get maximum clock frequency.*/
> +static unsigned int sdhci_cmu_get_max_clock(struct sdhci_host *host)
> +{
> + struct sdhci_s3c *ourhost = to_s3c(host);
> +
> + return clk_round_rate(ourhost->clk_bus[ourhost->cur_clk], UINT_MAX);
> +}
> +
> +/* sdhci_cmu_get_min_clock - callback to get minimal supported clock value.
> */
> +static unsigned int sdhci_cmu_get_min_clock(struct sdhci_host *host)
> +{
> + struct sdhci_s3c *ourhost = to_s3c(host);
> +
> + /*
> + * initial clock can be in the frequency range of
> + * 100KHz-400KHz, so we set it as max value.
> + */
> + return clk_round_rate(ourhost->clk_bus[ourhost->cur_clk], 40);
> +}
> +
> +/* sdhci_cmu_set_clock - callback on clock change.*/
> +static void sdhci_cmu_set_clock(struct sdhci_host *host, unsigned int clock)
> +{
> + struct sdhci_s3c *ourhost = to_s3c(host);
> +
> + /* don't bother if the clock is going off */
> + if (clock == 0)
> + return;
> +
> + sdhci_s3c_set_clock(host, clock);
> +
> + clk_set_rate(ourhost->clk_bus[ourhost->cur_clk], clock);
> +
> + host->clock = clock;
> +}
> +
> static struct sdhci_ops sdhci_s3c_ops = {
> .get_max_clock = sdhci_s3c_get_max_clk,
> .set_clock = sdhci_s3c_set_clock,
> @@ -361,6 +406,13 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
>
> clks++;
> sc->clk_bus[ptr] = clk;
> +
> + /*
> + * save current clock index to know which clock bus
> + * is used later in overriding functions.
> + */
> + sc->cur_clk = ptr;
> +
> clk_enable(clk);
>
> dev_info(dev, "clock source %d: %s (%ld Hz)\n",
> @@ -427,6 +479,16 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
> /* HSMMC on Samsung SoCs uses SDCLK as timeout clock */
> host->quirks |= SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK;
>
> + /*
> + *
