Re: [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
On Wednesday, November 21, 2012 02:52:26 PM Tomasz Figa wrote:
> On Tuesday 13 of November 2012 10:26:12 Tomasz Figa wrote:
> > On Exynos SoCs all cores share the same frequency setting, so changing
> > frequency of one core will affect rest of cores.
> >
> > This patch modifies the exynos-cpufreq driver to inform cpufreq core
> > about this behavior and broadcast frequency change notifications for all
> > cores.
> >
> > Signed-off-by: Tomasz Figa
> > Signed-off-by: Kyungmin Park
> > ---
> > drivers/cpufreq/exynos-cpufreq.c | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/cpufreq/exynos-cpufreq.c
> > b/drivers/cpufreq/exynos-cpufreq.c index af2d81e..c0d54a8 100644
> > --- a/drivers/cpufreq/exynos-cpufreq.c
> > +++ b/drivers/cpufreq/exynos-cpufreq.c
> > @@ -100,7 +100,8 @@ static int exynos_target(struct cpufreq_policy
> > *policy, }
> > arm_volt = volt_table[index];
> >
> > - cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
> > + for_each_cpu(freqs.cpu, policy->cpus)
> > + cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
> >
> > /* When the new frequency is higher than current frequency */
> > if ((freqs.new > freqs.old) && !safe_arm_volt) {
> > @@ -115,7 +116,8 @@ static int exynos_target(struct cpufreq_policy
> > *policy, if (freqs.new != freqs.old)
> > exynos_info->set_freq(old_index, index);
> >
> > - cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> > + for_each_cpu(freqs.cpu, policy->cpus)
> > + cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> >
> > /* When the new frequency is lower than current frequency */
> > if ((freqs.new < freqs.old) ||
> > @@ -235,6 +237,7 @@ static int exynos_cpufreq_cpu_init(struct
> > cpufreq_policy *policy) cpumask_copy(policy->related_cpus,
> > cpu_possible_mask);
> > cpumask_copy(policy->cpus, cpu_online_mask);
> > } else {
> > + policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
> > cpumask_setall(policy->cpus);
> > }
>
> Ping.
Am I supposed to handle this?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 2/3] ARM: S3C64XX: Enabling samsung-usbphy driver
Hi Praveen,
On Wednesday 14 of November 2012 16:15:37 Praveen Paneri wrote:
> Adding platform device for samsung-usbphy driver. Enabling it for
> s3c64xx based machines using s3c-hsotg.
>
> Signed-off-by: Praveen Paneri
> ---
> arch/arm/mach-s3c64xx/include/mach/map.h |2 +
> arch/arm/mach-s3c64xx/mach-crag6410.c|7 ++
> arch/arm/mach-s3c64xx/mach-smartq.c |8 +++
> arch/arm/mach-s3c64xx/mach-smdk6410.c|7 ++
> arch/arm/mach-s3c64xx/setup-usb-phy.c| 14 +
> arch/arm/plat-samsung/devs.c | 28
> ++ arch/arm/plat-samsung/include/plat/devs.h
> |1 +
> arch/arm/plat-samsung/include/plat/usb-phy.h |1 +
> 8 files changed, 68 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-s3c64xx/include/mach/map.h
> b/arch/arm/mach-s3c64xx/include/mach/map.h index 8e2097b..dc482bb
> 100644
> --- a/arch/arm/mach-s3c64xx/include/mach/map.h
> +++ b/arch/arm/mach-s3c64xx/include/mach/map.h
> @@ -65,6 +65,7 @@
>
> #define S3C64XX_PA_NAND (0x7020)
> #define S3C64XX_PA_FB(0x7710)
> +#define S3C64XX_PA_USB_HSPHY (0x7C10)
> #define S3C64XX_PA_USB_HSOTG (0x7C00)
> #define S3C64XX_PA_WATCHDOG (0x7E004000)
> #define S3C64XX_PA_RTC (0x7E005000)
> @@ -113,6 +114,7 @@
> #define S3C_PA_FBS3C64XX_PA_FB
> #define S3C_PA_USBHOST S3C64XX_PA_USBHOST
> #define S3C_PA_USB_HSOTG S3C64XX_PA_USB_HSOTG
> +#define S3C_PA_USB_PHY S3C64XX_PA_USB_HSPHY
> #define S3C_PA_RTC S3C64XX_PA_RTC
> #define S3C_PA_WDT S3C64XX_PA_WATCHDOG
> #define S3C_PA_SPI0 S3C64XX_PA_SPI0
> diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c
> b/arch/arm/mach-s3c64xx/mach-crag6410.c index 48f4a2d..c602379 100644
> --- a/arch/arm/mach-s3c64xx/mach-crag6410.c
> +++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
> @@ -31,6 +31,7 @@
> #include
>
> #include
> +#include
>
> #include
>
> @@ -69,6 +70,7 @@
> #include
> #include
> #include
> +#include
>
> #include "common.h"
>
> @@ -353,6 +355,7 @@ static struct platform_device wallvdd_device = {
> };
>
> static struct platform_device *crag6410_devices[] __initdata = {
> + &samsung_device_usbphy,
> &s3c_device_hsmmc0,
> &s3c_device_hsmmc2,
> &s3c_device_i2c0,
> @@ -804,6 +807,9 @@ static const struct gpio_led_platform_data
> gpio_leds_pdata = { .num_leds = ARRAY_SIZE(gpio_leds),
> };
>
> +static struct samsung_usbphy_data crag6410_usbphy_pdata __initdata = {
> + .pmu_isolation = s5p_usb_phy_pmu_isolation,
> +};
Why not define default platform data somewhere and always use it for
s3c64xx, without redefining the same structure in all boards?
> static void __init crag6410_machine_init(void)
> {
> @@ -829,6 +835,7 @@ static void __init crag6410_machine_init(void)
> s3c_i2c0_set_platdata(&i2c0_pdata);
> s3c_i2c1_set_platdata(&i2c1_pdata);
> s3c_fb_set_platdata(&crag6410_lcd_pdata);
> + samsung_usbphy_set_pdata(&crag6410_usbphy_pdata);
>
> i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
> i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
> diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c
> b/arch/arm/mach-s3c64xx/mach-smartq.c index 59bb34c..f18a0ab 100644
> --- a/arch/arm/mach-s3c64xx/mach-smartq.c
> +++ b/arch/arm/mach-s3c64xx/mach-smartq.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -36,6 +37,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -234,6 +236,7 @@ static struct i2c_board_info smartq_i2c_devs[]
> __initdata = { };
>
> static struct platform_device *smartq_devices[] __initdata = {
> + &samsung_device_usbphy,
> &s3c_device_hsmmc1, /* Init iNAND first, ... */
> &s3c_device_hsmmc0, /* ... then the external SD card */
> &s3c_device_hsmmc2,
> @@ -380,9 +383,14 @@ void __init smartq_map_io(void)
> smartq_lcd_mode_set();
> }
>
> +static struct samsung_usbphy_data smartq_usbphy_pdata __initdata = {
> + .pmu_isolation = s5p_usb_phy_pmu_isolation,
> +};
> +
> void __init smartq_machine_init(void)
> {
> s3c_i2c0_set_platdata(NULL);
> + samsung_usbphy_set_pdata(&smartq_usbphy_pdata);
> s3c_hwmon_set_platdata(&smartq_hwmon_pdata);
> s3c_sdhci1_set_platdata(&smartq_internal_hsmmc_pdata);
> s3c_sdhci2_set_platdata(&smartq_internal_hsmmc_pdata);
> diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c
> b/arch/arm/mach-s3c64xx/mach-smdk6410.c index 123f452..00e46a6 100644
> --- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
> +++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include
>
> #ifdef CONFIG_SMDK6410_WM1190_EV1
> #include
> @@ -72,6 +73,7 @@
> #include
> #include
> #include
> +#include
>
> #include "common.h"
>
> @@ -263,6
Re: [PATCH v8 1/3] ARM: S3C64XX: Removing old phy setup code
Hi Praveen,
On Wednesday 14 of November 2012 16:15:36 Praveen Paneri wrote:
> This patch removes old phy code from platform side. 'setup-usb-phy.c'
> will be used for providing transceiver platform data in next
> patch. Not all of the platform data code is removed as there are others
> making use of platform_data defined for hsotg. That can be removed once
> all the SoCs start using the new transceiver for usb phy setup.
>
> Signed-off-by: Praveen Paneri
> ---
> arch/arm/mach-s3c64xx/mach-crag6410.c |3 -
> arch/arm/mach-s3c64xx/mach-smartq.c |3 -
> arch/arm/mach-s3c64xx/mach-smdk6410.c |3 -
> arch/arm/mach-s3c64xx/setup-usb-phy.c | 79
> - 4 files changed, 0 insertions(+), 88
> deletions(-)
>
> diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c
> b/arch/arm/mach-s3c64xx/mach-crag6410.c index 2abe95d..48f4a2d 100644
> --- a/arch/arm/mach-s3c64xx/mach-crag6410.c
> +++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
> @@ -31,7 +31,6 @@
> #include
>
> #include
> -#include
>
> #include
>
> @@ -805,7 +804,6 @@ static const struct gpio_led_platform_data
> gpio_leds_pdata = { .num_leds = ARRAY_SIZE(gpio_leds),
> };
>
> -static struct s3c_hsotg_plat crag6410_hsotg_pdata;
>
> static void __init crag6410_machine_init(void)
> {
> @@ -831,7 +829,6 @@ static void __init crag6410_machine_init(void)
> s3c_i2c0_set_platdata(&i2c0_pdata);
> s3c_i2c1_set_platdata(&i2c1_pdata);
> s3c_fb_set_platdata(&crag6410_lcd_pdata);
> - s3c_hsotg_set_platdata(&crag6410_hsotg_pdata);
>
> i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
> i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
> diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c
> b/arch/arm/mach-s3c64xx/mach-smartq.c index c6d7390..59bb34c 100644
> --- a/arch/arm/mach-s3c64xx/mach-smartq.c
> +++ b/arch/arm/mach-s3c64xx/mach-smartq.c
> @@ -18,7 +18,6 @@
> #include
> #include
> #include
> -#include
>
> #include
> #include
> @@ -187,7 +186,6 @@ static struct s3c_hwmon_pdata smartq_hwmon_pdata
> __initdata = { },
> };
>
> -static struct s3c_hsotg_plat smartq_hsotg_pdata;
>
> static int __init smartq_lcd_setup_gpio(void)
> {
> @@ -385,7 +383,6 @@ void __init smartq_map_io(void)
> void __init smartq_machine_init(void)
> {
> s3c_i2c0_set_platdata(NULL);
> - s3c_hsotg_set_platdata(&smartq_hsotg_pdata);
> s3c_hwmon_set_platdata(&smartq_hwmon_pdata);
> s3c_sdhci1_set_platdata(&smartq_internal_hsmmc_pdata);
> s3c_sdhci2_set_platdata(&smartq_internal_hsmmc_pdata);
> diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c
> b/arch/arm/mach-s3c64xx/mach-smdk6410.c index da1a771..123f452 100644
> --- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
> +++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
> @@ -30,7 +30,6 @@
> #include
> #include
> #include
> -#include
>
> #ifdef CONFIG_SMDK6410_WM1190_EV1
> #include
> @@ -627,7 +626,6 @@ static struct platform_pwm_backlight_data
> smdk6410_bl_data = { .pwm_id = 1,
> };
>
> -static struct s3c_hsotg_plat smdk6410_hsotg_pdata;
>
> static void __init smdk6410_map_io(void)
> {
> @@ -657,7 +655,6 @@ static void __init smdk6410_machine_init(void)
> s3c_i2c0_set_platdata(NULL);
> s3c_i2c1_set_platdata(NULL);
> s3c_fb_set_platdata(&smdk6410_lcd_pdata);
> - s3c_hsotg_set_platdata(&smdk6410_hsotg_pdata);
>
> samsung_keypad_set_platdata(&smdk6410_keypad_data);
>
> diff --git a/arch/arm/mach-s3c64xx/setup-usb-phy.c
> b/arch/arm/mach-s3c64xx/setup-usb-phy.c index f6757e0..7a09553 100644
> --- a/arch/arm/mach-s3c64xx/setup-usb-phy.c
> +++ b/arch/arm/mach-s3c64xx/setup-usb-phy.c
> @@ -9,82 +9,3 @@
> *
> */
>
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -static int s3c_usb_otgphy_init(struct platform_device *pdev)
> -{
> - struct clk *xusbxti;
> - u32 phyclk;
> -
> - writel(readl(S3C64XX_OTHERS) | S3C64XX_OTHERS_USBMASK,
> S3C64XX_OTHERS); -
> - /* set clock frequency for PLL */
> - phyclk = readl(S3C_PHYCLK) & ~S3C_PHYCLK_CLKSEL_MASK;
> -
> - xusbxti = clk_get(&pdev->dev, "xusbxti");
> - if (xusbxti && !IS_ERR(xusbxti)) {
> - switch (clk_get_rate(xusbxti)) {
> - case 12 * MHZ:
> - phyclk |= S3C_PHYCLK_CLKSEL_12M;
> - break;
> - case 24 * MHZ:
> - phyclk |= S3C_PHYCLK_CLKSEL_24M;
> - break;
> - default:
> - case 48 * MHZ:
> - /* default reference clock */
> - break;
> - }
> - clk_put(xusbxti);
> - }
> -
> - /* TODO: select external clock/oscillator */
> - writel(phyclk | S3C_PHYCLK_CLK_FORCE, S3C_PHYCLK);
> -
> - /* set to normal OTG PHY */
> - writel((readl(S3C_PHYPWR) & ~S3C_PHYPWR_NORMAL_MASK), S3C_PHYPWR);
> - mdelay(1);
> -
Re: [PATCH v8 2/2] usb: s3c-hsotg: Adding phy driver support
Hi Praveen,
On Wednesday 14 of November 2012 15:57:16 Praveen Paneri wrote:
> Adding the transceiver to hsotg driver. Keeping the platform data
> for continuing the smooth operation for boards which still uses it
>
> Signed-off-by: Praveen Paneri
> Acked-by: Kyungmin Park
> ---
> drivers/usb/gadget/s3c-hsotg.c | 37
> +++-- 1 files changed, 27
> insertions(+), 10 deletions(-)
>
> diff --git a/drivers/usb/gadget/s3c-hsotg.c
> b/drivers/usb/gadget/s3c-hsotg.c index 6f696ee..bc30a2d 100644
> --- a/drivers/usb/gadget/s3c-hsotg.c
> +++ b/drivers/usb/gadget/s3c-hsotg.c
> @@ -32,6 +32,7 @@
>
> #include
> #include
> +#include
> #include
>
> #include
> @@ -133,7 +134,9 @@ struct s3c_hsotg_ep {
> * struct s3c_hsotg - driver state.
> * @dev: The parent device supplied to the probe function
> * @driver: USB gadget driver
> - * @plat: The platform specific configuration data.
> + * @phy: The otg phy transceiver structure for phy control.
> + * @plat: The platform specific configuration data. This can be removed
> once + * all SoCs support usb transceiver.
> * @regs: The memory area mapped for accessing registers.
> * @irq: The IRQ number we are using
> * @supplies: Definition of USB power supplies
> @@ -153,6 +156,7 @@ struct s3c_hsotg_ep {
> struct s3c_hsotg {
> struct device*dev;
> struct usb_gadget_driver *driver;
> + struct usb_phy *phy;
> struct s3c_hsotg_plat*plat;
>
> spinlock_t lock;
> @@ -2854,7 +2858,10 @@ static void s3c_hsotg_phy_enable(struct s3c_hsotg
> *hsotg) struct platform_device *pdev = to_platform_device(hsotg->dev);
>
> dev_dbg(hsotg->dev, "pdev 0x%p\n", pdev);
> - if (hsotg->plat->phy_init)
> +
> + if (hsotg->phy)
> + usb_phy_init(hsotg->phy);
> + else if (hsotg->plat->phy_init)
> hsotg->plat->phy_init(pdev, hsotg->plat->phy_type);
> }
>
> @@ -2869,7 +2876,9 @@ static void s3c_hsotg_phy_disable(struct s3c_hsotg
> *hsotg) {
> struct platform_device *pdev = to_platform_device(hsotg->dev);
>
> - if (hsotg->plat->phy_exit)
> + if (hsotg->phy)
> + usb_phy_shutdown(hsotg->phy);
> + else if (hsotg->plat->phy_exit)
> hsotg->plat->phy_exit(pdev, hsotg->plat->phy_type);
> }
>
> @@ -3493,6 +3502,7 @@ static void s3c_hsotg_release(struct device *dev)
> static int __devinit s3c_hsotg_probe(struct platform_device *pdev)
> {
> struct s3c_hsotg_plat *plat = pdev->dev.platform_data;
> + struct usb_phy *phy;
> struct device *dev = &pdev->dev;
> struct s3c_hsotg_ep *eps;
> struct s3c_hsotg *hsotg;
> @@ -3501,20 +3511,27 @@ static int __devinit s3c_hsotg_probe(struct
> platform_device *pdev) int ret;
> int i;
>
> - plat = pdev->dev.platform_data;
> - if (!plat) {
> - dev_err(&pdev->dev, "no platform data defined\n");
> - return -EINVAL;
> - }
> -
> hsotg = devm_kzalloc(&pdev->dev, sizeof(struct s3c_hsotg),
> GFP_KERNEL); if (!hsotg) {
> dev_err(dev, "cannot get memory\n");
> return -ENOMEM;
> }
>
> + phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> + if (IS_ERR_OR_NULL(phy)) {
> + /* Fallback for pdata */
> + plat = pdev->dev.platform_data;
> + if (!plat) {
> + dev_err(&pdev->dev, "no platform data or transceiver
defined\n");
> + return -EPROBE_DEFER;
> + } else {
> + hsotg->plat = plat;
> + }
nitpick: The hsotg->plat = plat; assignment can be made without the else
statement as well.
Best regards,
Tomasz Figa
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 1/2] usb: phy: samsung: Introducing usb phy driver for hsotg
Hi Praveen, See some minor comments inline. On Wednesday 14 of November 2012 15:57:15 Praveen Paneri wrote: > This driver uses usb_phy interface to interact with s3c-hsotg. Supports > phy_init and phy_shutdown functions to enable/disable usb phy. Support > will be extended to host controllers and more Samsung SoCs. > > Signed-off-by: Praveen Paneri > Acked-by: Heiko Stuebner > Acked-by: Kyungmin Park > --- > .../devicetree/bindings/usb/samsung-usbphy.txt | 11 + > drivers/usb/phy/Kconfig|8 + > drivers/usb/phy/Makefile |1 + > drivers/usb/phy/samsung-usbphy.c | 360 > include/linux/platform_data/samsung-usbphy.h > | 27 ++ > 5 files changed, 407 insertions(+), 0 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/usb/samsung-usbphy.txt create mode > 100644 drivers/usb/phy/samsung-usbphy.c > create mode 100644 include/linux/platform_data/samsung-usbphy.h > > diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt > b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt new file > mode 100644 > index 000..7b26e2d > --- /dev/null > +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt > @@ -0,0 +1,11 @@ > +* Samsung's usb phy transceiver > + > +The Samsung's phy transceiver is used for controlling usb otg phy for > +s3c-hsotg usb device controller. > +TODO: Adding the PHY binding with controller(s) according to the under > +developement generic PHY driver. > + > +Required properties: > +- compatible : should be "samsung,exynos4210-usbphy" > +- reg : base physical address of the phy registers and length of memory > mapped + region. > diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig > index 7eb73c5..17ad743 100644 > --- a/drivers/usb/phy/Kconfig > +++ b/drivers/usb/phy/Kconfig > @@ -44,3 +44,11 @@ config USB_RCAR_PHY > > To compile this driver as a module, choose M here: the > module will be called rcar-phy. > + > +config SAMSUNG_USBPHY > + bool "Samsung USB PHY controller Driver" > + depends on USB_S3C_HSOTG > + select USB_OTG_UTILS > + help > + Enable this to support Samsung USB phy controller for samsung > + SoCs. > diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile > index 1a579a8..ec304f6 100644 > --- a/drivers/usb/phy/Makefile > +++ b/drivers/usb/phy/Makefile > @@ -9,3 +9,4 @@ obj-$(CONFIG_USB_ISP1301) += isp1301.o > obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o > obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o > obj-$(CONFIG_USB_RCAR_PHY) += rcar-phy.o > +obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o > diff --git a/drivers/usb/phy/samsung-usbphy.c > b/drivers/usb/phy/samsung-usbphy.c new file mode 100644 > index 000..3c84aab > --- /dev/null > +++ b/drivers/usb/phy/samsung-usbphy.c > @@ -0,0 +1,360 @@ > +/* linux/drivers/usb/phy/samsung-usbphy.c > + * > + * Copyright (c) 2012 Samsung Electronics Co., Ltd. > + * http://www.samsung.com > + * > + * Author: Praveen Paneri > + * > + * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG > controller + * > + * 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. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* Register definitions */ > + > +#define SAMSUNG_PHYPWR (0x00) > + > +#define PHYPWR_NORMAL_MASK (0x19 << 0) > +#define PHYPWR_OTG_DISABLE (0x1 << 4) > +#define PHYPWR_ANALOG_POWERDOWN (0x1 << 3) > +#define PHYPWR_FORCE_SUSPEND (0x1 << 1) > +/* For Exynos4 */ > +#define PHYPWR_NORMAL_MASK_PHY0 (0x39 << 0) > +#define PHYPWR_SLEEP_PHY0(0x1 << 5) > + > +#define SAMSUNG_PHYCLK (0x04) > + > +#define PHYCLK_MODE_USB11(0x1 << 6) > +#define PHYCLK_EXT_OSC (0x1 << 5) > +#define PHYCLK_COMMON_ON_N (0x1 << 4) > +#define PHYCLK_ID_PULL (0x1 << 2) > +#define PHYCLK_CLKSEL_MASK (0x3 << 0) > +#define PHYCLK_CLKSEL_48M(0x0 << 0) > +#define PHYCLK_CLKSEL_12M(0x2 << 0) > +#define PHYCLK_CLKSEL_24M(0x3 << 0) > + > +#define SAMSUNG_RSTCON (0x08) > + > +#define RSTCON_PHYLINK_SWRST (0x1 << 2)
Re: [PATCH v8 3/3] ARM: EXYNOS: Enabling samsung-usbphy driver for EXYNOS4210
Hi Praveen,
On Wednesday 14 of November 2012 16:15:38 Praveen Paneri wrote:
> Adding usbphy node for Exynos4210 along with the platform data.
>
> Signed-off-by: Praveen Paneri
> ---
> arch/arm/boot/dts/exynos4210-smdkv310.dts |5 +
> arch/arm/mach-exynos/Kconfig |1 +
> arch/arm/mach-exynos/include/mach/map.h |1 +
> arch/arm/mach-exynos/mach-exynos4-dt.c|8
> arch/arm/mach-exynos/setup-usb-phy.c | 13 +
> 5 files changed, 28 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4210-smdkv310.dts
> b/arch/arm/boot/dts/exynos4210-smdkv310.dts index 9b23a82..550903a
> 100644
> --- a/arch/arm/boot/dts/exynos4210-smdkv310.dts
> +++ b/arch/arm/boot/dts/exynos4210-smdkv310.dts
> @@ -59,6 +59,11 @@
> status = "okay";
> };
>
> + usbphy@125B {
> + compatible = "samsung,exynos4210-usbphy";
> + reg = <0x125B 0x100>;
> + };
> +
> keypad@100A {
> samsung,keypad-num-rows = <2>;
> samsung,keypad-num-columns = <8>;
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index bb3b09a..315308c 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -410,6 +410,7 @@ config MACH_EXYNOS4_DT
> select PINCTRL
> select PINCTRL_EXYNOS4
> select USE_OF
> + select EXYNOS4_SETUP_USB_PHY
> help
> Machine support for Samsung Exynos4 machine with device tree
> enabled. Select this if a fdt blob is available for the Exynos4 SoC
> based board. diff --git a/arch/arm/mach-exynos/include/mach/map.h
> b/arch/arm/mach-exynos/include/mach/map.h index ef4958b..e64fe1c 100644
> --- a/arch/arm/mach-exynos/include/mach/map.h
> +++ b/arch/arm/mach-exynos/include/mach/map.h
> @@ -244,6 +244,7 @@
> #define S3C_PA_SPI1 EXYNOS4_PA_SPI1
> #define S3C_PA_SPI2 EXYNOS4_PA_SPI2
> #define S3C_PA_USB_HSOTG EXYNOS4_PA_HSOTG
> +#define S3C_PA_USB_PHY EXYNOS4_PA_HSPHY
>
> #define S5P_PA_EHCI EXYNOS4_PA_EHCI
> #define S5P_PA_FIMC0 EXYNOS4_PA_FIMC0
> diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c
> b/arch/arm/mach-exynos/mach-exynos4-dt.c index 8858068..f7887e5 100644
> --- a/arch/arm/mach-exynos/mach-exynos4-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
> @@ -13,6 +13,7 @@
>
> #include
> #include
> +#include
>
> #include
> #include
> @@ -20,9 +21,14 @@
>
> #include
> #include
> +#include
>
> #include "common.h"
>
> +static struct samsung_usbphy_data exynos4_usbphy_pdata = {
> + .pmu_isolation = s5p_usb_phy_pmu_isolation,
> +};
> +
> /*
> * The following lookup table is used to override device names when
> devices * are registered from device tree. This is temporarily added to
> enable @@ -79,6 +85,8 @@ static const struct of_dev_auxdata
> exynos4_auxdata_lookup[] __initconst = { OF_DEV_AUXDATA("arm,pl330",
> EXYNOS4_PA_PDMA1, "dma-pl330.1", NULL),
> OF_DEV_AUXDATA("samsung,exynos4210-tmu", EXYNOS4_PA_TMU,
> "exynos-tmu", NULL),
> + OF_DEV_AUXDATA("samsung,exynos4210-usbphy", EXYNOS4_PA_HSPHY,
> + "s3c-usbphy", &exynos4_usbphy_pdata),
You should consider reworking the usb phy driver to avoid the need to
specify platform data through of auxdata, because auxdata array in mach-
exynos4-dt is going to be removed after including common clock framework
support for Exynos4.
Best regards,
Tomasz Figa
--
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] i2c: s3c2410: Get the i2c bus number from alias id
On Tue, Nov 20, 2012 at 8:09 PM, Mark Brown wrote: > On Tue, Nov 20, 2012 at 02:27:04PM -0800, Doug Anderson wrote: >> From: Padmavathi Venna >> >> Get the i2c bus number that the device is connected to using the alias >> id. This makes debugging / grokking of kernel messages much easier. > > This doesn't look like a s3c2410 specific change - it's a generic device > tree issue. This suggests that it sohuld be implemented in the > framework so that all I2C controllers with DT can use it. Good suggestion. I have posted a series with the title "Add automatic bus number support for i2c busses with device tree". It contains the i2c-core patch as well as a patch removing similar code from the pxa i2c driver. Kukjin: please consider this patch abandoned and superseded by the new i2c-core patch. As Olof said, the patch for adding aliases for exynos4 should still be fine to apply. Thanks! -Doug -- 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 1/7] Samsung cleanup for v3.8
On Wed, Nov 21, 2012 at 12:04:40AM +0900, Kukjin Kim wrote: > Hi Arnd, Olof > > Please pull Samsung cleanup for v3.8 from: > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > next/cleanup-samsung-2 > > Most of them are just removing patches, if any problems, please let me know. Pulled 1-7. Thanks, -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] i2c: pxa: Use i2c-core to get bus number now
The commit: "i2c-core: dt: Pick i2c bus number from i2c alias if
present" adds support for automatically picking the bus number based
on the alias ID. Remove the now unnecessary code from i2c-pxa that
did the same thing.
Signed-off-by: Doug Anderson
---
drivers/i2c/busses/i2c-pxa.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 1034d93..8ee9fa0 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -1053,16 +1053,10 @@ static int i2c_pxa_probe_dt(struct platform_device
*pdev, struct pxa_i2c *i2c,
struct device_node *np = pdev->dev.of_node;
const struct of_device_id *of_id =
of_match_device(i2c_pxa_dt_ids, &pdev->dev);
- int ret;
if (!of_id)
return 1;
- ret = of_alias_get_id(np, "i2c");
- if (ret < 0) {
- dev_err(&pdev->dev, "failed to get alias id, errno %d\n", ret);
- return ret;
- }
- pdev->id = ret;
+ pdev->id = -1;
if (of_get_property(np, "mrvl,i2c-polling", NULL))
i2c->use_pio = 1;
if (of_get_property(np, "mrvl,i2c-fast-mode", NULL))
--
1.7.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] i2c-core: dt: Pick i2c bus number from i2c alias if present
This allows you to get the equivalent functionality of
i2c_add_numbered_adapter() with all data in the device tree and no
special case code in your driver. This is a common device tree
technique.
For quick reference, the FDT syntax for using an alias to provide an
ID looks like:
aliases {
i2c0 = &i2c_0;
i2c1 = &i2c_1;
};
Signed-off-by: Doug Anderson
CC: Mark Brown
---
drivers/i2c/i2c-core.c | 105 +++-
1 files changed, 77 insertions(+), 28 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index a7edf98..71deb2a2 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -915,13 +915,81 @@ out_list:
}
/**
+ * i2c_get_number_from_dt - get the adapter number based on dt alias
+ * @adap: the adapter to look at
+ *
+ * Check whether there's an alias in the FDT that gives an ID for this i2c
+ * device. Use an alias like "i2c", like:
+ * aliases {
+ * i2c0 = &i2c_0;
+ * i2c1 = &i2c_1;
+ * };
+ *
+ * Returns the ID if found. If no alias is found returns -1.
+ */
+static int i2c_get_number_from_dt(struct i2c_adapter *adap)
+{
+ struct device *dev = &adap->dev;
+ int id;
+
+ if (!dev->of_node)
+ return -1;
+
+ id = of_alias_get_id(dev->of_node, "i2c");
+ if (id < 0)
+ return -1;
+ return id;
+}
+
+/**
+ * _i2c_add_numbered_adapter - i2c_add_numbered_adapter where nr is never -1
+ * @adap: the adapter to register (with adap->nr initialized)
+ * Context: can sleep
+ *
+ * See i2c_add_numbered_adapter() for details.
+ */
+static int _i2c_add_numbered_adapter(struct i2c_adapter *adap)
+{
+ int id;
+ int status;
+
+ /* Handled by wrappers */
+ BUG_ON(adap->nr == -1);
+
+ if (adap->nr & ~MAX_IDR_MASK)
+ return -EINVAL;
+
+retry:
+ if (idr_pre_get(&i2c_adapter_idr, GFP_KERNEL) == 0)
+ return -ENOMEM;
+
+ mutex_lock(&core_lock);
+ /* "above" here means "above or equal to", sigh;
+* we need the "equal to" result to force the result
+*/
+ status = idr_get_new_above(&i2c_adapter_idr, adap, adap->nr, &id);
+ if (status == 0 && id != adap->nr) {
+ status = -EBUSY;
+ idr_remove(&i2c_adapter_idr, id);
+ }
+ mutex_unlock(&core_lock);
+ if (status == -EAGAIN)
+ goto retry;
+
+ if (status == 0)
+ status = i2c_register_adapter(adap);
+ return status;
+}
+
+/**
* i2c_add_adapter - declare i2c adapter, use dynamic bus number
* @adapter: the adapter to add
* Context: can sleep
*
* This routine is used to declare an I2C adapter when its bus number
- * doesn't matter. Examples: for I2C adapters dynamically added by
- * USB links or PCI plugin cards.
+ * doesn't matter or when its bus number is specified by an dt alias.
+ * Examples of bases when the bus number doesn't matter: I2C adapters
+ * dynamically added by USB links or PCI plugin cards.
*
* When this returns zero, a new bus number was allocated and stored
* in adap->nr, and the specified adapter became available for clients.
@@ -931,6 +999,12 @@ int i2c_add_adapter(struct i2c_adapter *adapter)
{
int id, res = 0;
+ id = i2c_get_number_from_dt(adapter);
+ if (id >= 0) {
+ adapter->nr = id;
+ return _i2c_add_numbered_adapter(adapter);
+ }
+
retry:
if (idr_pre_get(&i2c_adapter_idr, GFP_KERNEL) == 0)
return -ENOMEM;
@@ -977,34 +1051,9 @@ EXPORT_SYMBOL(i2c_add_adapter);
*/
int i2c_add_numbered_adapter(struct i2c_adapter *adap)
{
- int id;
- int status;
-
if (adap->nr == -1) /* -1 means dynamically assign bus id */
return i2c_add_adapter(adap);
- if (adap->nr & ~MAX_IDR_MASK)
- return -EINVAL;
-
-retry:
- if (idr_pre_get(&i2c_adapter_idr, GFP_KERNEL) == 0)
- return -ENOMEM;
-
- mutex_lock(&core_lock);
- /* "above" here means "above or equal to", sigh;
-* we need the "equal to" result to force the result
-*/
- status = idr_get_new_above(&i2c_adapter_idr, adap, adap->nr, &id);
- if (status == 0 && id != adap->nr) {
- status = -EBUSY;
- idr_remove(&i2c_adapter_idr, id);
- }
- mutex_unlock(&core_lock);
- if (status == -EAGAIN)
- goto retry;
-
- if (status == 0)
- status = i2c_register_adapter(adap);
- return status;
+ return _i2c_add_numbered_adapter(adap);
}
EXPORT_SYMBOL_GPL(i2c_add_numbered_adapter);
--
1.7.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Add automatic bus number support for i2c busses with device tree
This was suggested by Mark Brown in response to a patch for adding this functionality only for the s3c2410 bus: https://lkml.org/lkml/2012/11/20/681 I have also modified the i2c-pxa driver to use this new functionality but have no good way to test that patch. Hopefully someone else can test and ack. The patch adding the generic functionality could go in even if the i2c-pxa patch needs changes. Doug Anderson (2): i2c-core: dt: Pick i2c bus number from i2c alias if present i2c: pxa: Use i2c-core to get bus number now drivers/i2c/busses/i2c-pxa.c |8 +--- drivers/i2c/i2c-core.c | 105 ++--- 2 files changed, 78 insertions(+), 35 deletions(-) -- 1.7.7.3 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: exynos: add UART3 to DEBUG_LL ports
On Tue, Nov 20, 2012 at 11:29 PM, Olof Johansson wrote: > > On Tue, Nov 20, 2012 at 02:48:58PM -0800, Doug Anderson wrote: > > From: Olof Johansson > > > > UART3 is used for debugging on exynos5250-snow. > > > > [dianders: cleaned commit message.] > > > > Signed-off-by: Olof Johansson > > Signed-off-by: Doug Anderson > > > > > --- > > arch/arm/Kconfig.debug| 11 +++ > > arch/arm/plat-samsung/Kconfig |1 + > > 2 files changed, 12 insertions(+), 0 deletions(-) > > > > diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug > > index 33a8930..35ba7dc 100644 > > --- a/arch/arm/Kconfig.debug > > +++ b/arch/arm/Kconfig.debug > > @@ -355,6 +355,17 @@ choice > > The uncompressor code port configuration is now handled > > by CONFIG_S3C_LOWLEVEL_UART_PORT. > > > > + config DEBUG_S3C_UART3 > > + depends on PLAT_SAMSUNG > > > Sorry, the reason I hadn't re-posted this is that Kukjin had proposed > to protect users of <= 3 UART platforms to select it. An added "Depends > on ARCH_EXYNOS4 || ARCH_EXYNOS5" should cover that. Can you add and > repost, please? Doh! I hadn't even noticed that you'd already posted this--I got mine from the Chrome OS tree directly. Sorry about that... I've added an && for ARCH_EXYNOS which seems reasonable. I left PLAT_SAMSUNG as a depend though technically ARCH_EXYNOS does select PLAT_SAMSUNG through a convoluted series of other config options. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: exynos: add UART3 to DEBUG_LL ports
From: Olof Johansson Add support for using UART3 for DEBUG_LL on exynos. [dianders: added depend on ARCH_EXYNOS.] Signed-off-by: Olof Johansson Signed-off-by: Doug Anderson --- Changes in v2: - Matched Olof's commit message. - Added ARCH_EXYNOS to depend list. arch/arm/Kconfig.debug| 11 +++ arch/arm/plat-samsung/Kconfig |1 + 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 33a8930..f54f170 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -355,6 +355,17 @@ choice The uncompressor code port configuration is now handled by CONFIG_S3C_LOWLEVEL_UART_PORT. + config DEBUG_S3C_UART3 + depends on PLAT_SAMSUNG && ARCH_EXYNOS + bool "Use S3C UART 3 for low-level debug" + help + Say Y here if you want the debug print routines to direct + their output to UART 3. The port must have been initialised + by the boot-loader before use. + + The uncompressor code port configuration is now handled + by CONFIG_S3C_LOWLEVEL_UART_PORT. + config DEBUG_SOCFPGA_UART depends on ARCH_SOCFPGA bool "Use SOCFPGA UART for low-level debug" diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig index 59401e1..d342ed0 100644 --- a/arch/arm/plat-samsung/Kconfig +++ b/arch/arm/plat-samsung/Kconfig @@ -502,5 +502,6 @@ config DEBUG_S3C_UART default "0" if DEBUG_S3C_UART0 default "1" if DEBUG_S3C_UART1 default "2" if DEBUG_S3C_UART2 + default "3" if DEBUG_S3C_UART3 endif -- 1.7.7.3 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MFD: SEC: Fix reg_offset for interrupt registers
Hi Inderpal, On Wed, Oct 17, 2012 at 11:48:55AM +0530, Inderpal Singh wrote: > reg_offset is offset of the status/mask registers. Now, since status_base > and mask_base are pointing to corresponding first registers, reg_offset > should start from 0 otheriwse regmap_add_irq_chip will fail during probe. > > Signed-off-by: Inderpal Singh > --- > It is based on Samuel's for-next-merge branch of mfd-2.6 tree. > > drivers/mfd/sec-irq.c | 102 > - > 1 file changed, 51 insertions(+), 51 deletions(-) I queued this one to my for-linus branch since it basically prevents IRQs from working here. But it seems weird that such a mistake was not caught earlier. So I'd like to get Sangbeom's ACK before pushing this one upstream. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- 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 02/12] ARM: EXYNOS: Add clk_ops for gating clocks of System MMU
On 11/21/12 14:03, Cho KyongHo wrote: Touching some System MMU needs its master devices' clock to be enabled before. This commit adds clk_ops.set_parent of gating clocks of System MMU to ensure gating clocks of System MMU's mater devices are enabled when enabling gating clocks of System MMU. Change-Id: Icd58b12f599e92692c032516331a444f4703ba6b Same here, we don't need this :-) Signed-off-by: KyongHo Cho --- arch/arm/mach-exynos/clock-exynos5.c | 25 + 1 file changed, 25 insertions(+) Looks good to me, and I think, this can be applied independently from this series. Will apply with removing 'Change-Id'. 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 v3 01/12] ARM: EXYNOS: remove system mmu initialization from exynos tree
On 11/21/12 14:02, Cho KyongHo wrote: This removes System MMU initialization from arch/arm/mach-exynos/ Basically, looks OK to me, but I think, this removing change should be done after 03/12 patch :-) to move them to DT and the exynos-iommu driver except gating clock definitions. Change-Id: Ie29f587c01c645f28fc0e0b94eb3631a0170ebf5 No need 'Change-Id' here. Signed-off-by: KyongHo Cho --- arch/arm/mach-exynos/Kconfig | 5 - arch/arm/mach-exynos/Makefile | 1 - arch/arm/mach-exynos/clock-exynos4.c | 41 +++-- arch/arm/mach-exynos/clock-exynos4210.c| 9 +- arch/arm/mach-exynos/clock-exynos4212.c| 23 ++- arch/arm/mach-exynos/clock-exynos5.c | 62 --- arch/arm/mach-exynos/dev-sysmmu.c | 274 - arch/arm/mach-exynos/include/mach/sysmmu.h | 66 --- arch/arm/mach-exynos/mach-exynos4-dt.c | 34 arch/arm/mach-exynos/mach-exynos5-dt.c | 30 10 files changed, 137 insertions(+), 408 deletions(-) delete mode 100644 arch/arm/mach-exynos/dev-sysmmu.c delete mode 100644 arch/arm/mach-exynos/include/mach/sysmmu.h 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] regulator: max8997: skip gpio dvs setup if not used
On Wed, Nov 21, 2012 at 11:23 PM, Thomas Abraham wrote: > If gpio based voltage selection for buck 1/2/5 are not used, then the > execution > of gpio dvs setup code during probe can be skipped completly. Even if GPIO-DVS feature is turned off, you need to setup BUCKxDVS1 anyway. Otherwise, you may get "unspecified" behavior from the BUCK1/2/5, which may incur unstable system. Cheers, MyungJoo -- MyungJoo Ham, Ph.D. Mobile Software Platform Lab, DMC Business, Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] regulator: max8997: skip gpio dvs setup if not used
If gpio based voltage selection for buck 1/2/5 are not used, then the execution
of gpio dvs setup code during probe can be skipped completly.
Cc: MyungJoo Ham
Cc: Mark Brown
Signed-off-by: Thomas Abraham
---
drivers/regulator/max8997.c | 31 ++-
1 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/regulator/max8997.c b/drivers/regulator/max8997.c
index cea9ec9..e81a381 100644
--- a/drivers/regulator/max8997.c
+++ b/drivers/regulator/max8997.c
@@ -973,6 +973,10 @@ static int max8997_pmic_probe(struct platform_device *pdev)
memcpy(max8997->buck125_gpios, pdata->buck125_gpios, sizeof(int) * 3);
max8997->ignore_gpiodvs_side_effect = pdata->ignore_gpiodvs_side_effect;
+ if (!pdata->buck1_gpiodvs && !pdata->buck2_gpiodvs &&
+ !pdata->buck5_gpiodvs)
+ goto skip_gpiodvs;
+
for (i = 0; i < 8; i++) {
max8997->buck1_vol[i] = ret =
max8997_get_voltage_proper_val(
@@ -1019,6 +1023,19 @@ static int max8997_pmic_probe(struct platform_device
*pdev)
max_buck5, 0x3f);
}
+ /* Initialize all the DVS related BUCK registers */
+ for (i = 0; i < 8; i++) {
+ max8997_update_reg(i2c, MAX8997_REG_BUCK1DVS1 + i,
+ max8997->buck1_vol[i],
+ 0x3f);
+ max8997_update_reg(i2c, MAX8997_REG_BUCK2DVS1 + i,
+ max8997->buck2_vol[i],
+ 0x3f);
+ max8997_update_reg(i2c, MAX8997_REG_BUCK5DVS1 + i,
+ max8997->buck5_vol[i],
+ 0x3f);
+ }
+
/*
* If buck 1, 2, and 5 do not care DVS GPIO settings, ignore them.
* If at least one of them cares, set gpios.
@@ -1060,6 +1077,7 @@ static int max8997_pmic_probe(struct platform_device
*pdev)
& 0x1); /* SET3 */
}
+skip_gpiodvs:
/* DVS-GPIO disabled */
max8997_update_reg(i2c, MAX8997_REG_BUCK1CTRL, (pdata->buck1_gpiodvs) ?
(1 << 1) : (0 << 1), 1 << 1);
@@ -1068,19 +1086,6 @@ static int max8997_pmic_probe(struct platform_device
*pdev)
max8997_update_reg(i2c, MAX8997_REG_BUCK5CTRL, (pdata->buck5_gpiodvs) ?
(1 << 1) : (0 << 1), 1 << 1);
- /* Initialize all the DVS related BUCK registers */
- for (i = 0; i < 8; i++) {
- max8997_update_reg(i2c, MAX8997_REG_BUCK1DVS1 + i,
- max8997->buck1_vol[i],
- 0x3f);
- max8997_update_reg(i2c, MAX8997_REG_BUCK2DVS1 + i,
- max8997->buck2_vol[i],
- 0x3f);
- max8997_update_reg(i2c, MAX8997_REG_BUCK5DVS1 + i,
- max8997->buck5_vol[i],
- 0x3f);
- }
-
/* Misc Settings */
max8997->ramp_delay = 10; /* set 10mV/us, which is the default */
max8997_write_reg(i2c, MAX8997_REG_BUCKRAMP, (0xf << 4) | 0x9);
--
1.6.6.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
On Tuesday 13 of November 2012 10:26:12 Tomasz Figa wrote:
> On Exynos SoCs all cores share the same frequency setting, so changing
> frequency of one core will affect rest of cores.
>
> This patch modifies the exynos-cpufreq driver to inform cpufreq core
> about this behavior and broadcast frequency change notifications for all
> cores.
>
> Signed-off-by: Tomasz Figa
> Signed-off-by: Kyungmin Park
> ---
> drivers/cpufreq/exynos-cpufreq.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/exynos-cpufreq.c
> b/drivers/cpufreq/exynos-cpufreq.c index af2d81e..c0d54a8 100644
> --- a/drivers/cpufreq/exynos-cpufreq.c
> +++ b/drivers/cpufreq/exynos-cpufreq.c
> @@ -100,7 +100,8 @@ static int exynos_target(struct cpufreq_policy
> *policy, }
> arm_volt = volt_table[index];
>
> - cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
> + for_each_cpu(freqs.cpu, policy->cpus)
> + cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
>
> /* When the new frequency is higher than current frequency */
> if ((freqs.new > freqs.old) && !safe_arm_volt) {
> @@ -115,7 +116,8 @@ static int exynos_target(struct cpufreq_policy
> *policy, if (freqs.new != freqs.old)
> exynos_info->set_freq(old_index, index);
>
> - cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> + for_each_cpu(freqs.cpu, policy->cpus)
> + cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
>
> /* When the new frequency is lower than current frequency */
> if ((freqs.new < freqs.old) ||
> @@ -235,6 +237,7 @@ static int exynos_cpufreq_cpu_init(struct
> cpufreq_policy *policy) cpumask_copy(policy->related_cpus,
> cpu_possible_mask);
> cpumask_copy(policy->cpus, cpu_online_mask);
> } else {
> + policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
> cpumask_setall(policy->cpus);
> }
Ping.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/1] ARM: S3C24XX: Fix potential NULL pointer dereference error
Sachin Kamat wrote:
> > On 8 November 2012 14:31, Sachin Kamat wrote:
> >> chan->end is tested for being NULL. However in the event that it is
> NULL, the
> >> subsequent assignment statement would lead to NULL pointer dereference.
> >> Thus dereferencing it only when it is not NULL.
> >>
Logically, looks OK to me, I'm not sure this patch is right because if
(chan->end) is NULL, we do nothing for chan though...
I think, we need to sort out the dma_enqueue() later.
Will apply, thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> >> Signed-off-by: Sachin Kamat
> >> ---
> >> Based on Kukjin Kim's for-next branch. Compile tested.
> >> ---
> >> arch/arm/plat-s3c24xx/dma.c |9 +
> >> 1 files changed, 5 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/arch/arm/plat-s3c24xx/dma.c b/arch/arm/plat-s3c24xx/dma.c
> >> index db98e70..0abd1c4 100644
> >> --- a/arch/arm/plat-s3c24xx/dma.c
> >> +++ b/arch/arm/plat-s3c24xx/dma.c
> >> @@ -473,12 +473,13 @@ int s3c2410_dma_enqueue(enum dma_ch channel, void
> *id,
> >> pr_debug("dma%d: %s: buffer %p queued onto non-empty
> channel\n",
> >> chan->number, __func__, buf);
> >>
> >> - if (chan->end == NULL)
> >> + if (chan->end == NULL) {
> >> pr_debug("dma%d: %s: %p not empty, and chan-
> >end==NULL?\n",
> >> chan->number, __func__, chan);
> >> -
> >> - chan->end->next = buf;
> >> - chan->end = buf;
> >> + } else {
> >> + chan->end->next = buf;
> >> + chan->end = buf;
> >> + }
> >> }
> >>
> >> /* if necessary, update the next buffer field */
> >> --
> >> 1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/4] ARM: dts: exynos4210-origen: Device tree fixes
Tomasz Figa wrote: > > Hi Kgene, > > On Monday 19 of November 2012 15:46:32 Tomasz Figa wrote: > > This patch series fixes device tree support for Origen board: > > - memory is defined using sections of maximum allowed size > > - any pin configuration is modified to use pinctrl > > - invalid properties in sdhci nodes are replaced according to current > >mmc bindings > > - a fixed vmmc voltage regulator is added > > > > Tested on Origen board. > > > > Depends on: > > [PATCH v2 0/2] mmc: host: sdhci-s3c: Add support for pinctrl interface > > > > Tomasz Figa (4): > > ARM: dts: exynos4210-origen: Split memory sections > > ARM: dts: exynos4210-origen: Update for pinctrl-samsung driver > > ARM: dts: exynos4210-origen: Update sdhci nodes for current bindings > > ARM: dts: exynos4210-origen: Add vmmc fixed voltage regulator > > > > arch/arm/boot/dts/exynos4210-origen.dts | 54 > > - 1 file changed, 27 insertions(+), 27 > > deletions(-) > > Could you still pick these patches up for 3.8? > Looks OK to me, I want to test 1st patch on origen board with current my u-boot though. Will apply, 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 v3 RESEND 0/4] ARM: EXYNOS: Power domain DT support extension
Tomasz Figa wrote: > > Hi Kgene, > > On Tuesday 13 of November 2012 14:08:23 Tomasz Figa wrote: > > This patch series fixes two issues with existing DT support for Exynos > > power domains and extends it with the ability of binding devices to > > domains, basically making it possible to use power domains with DT. > > > > Based on for-next branch of Kgene's tree. > > > > Changes since v2: > > - Rebased to for-next of Kgene's tree. > > Changes since v1: > > - Added "samsung," prefix to "power-domain" property. > > - Added power domain nodes to Exynos4 device tree sources. > > > > Tomasz Figa (4): > > ARM: EXYNOS: pm_domain: Detect domain state on registration from DT > > ARM: EXYNOS: pm_domain: Fix power domain name initialization > > ARM: EXYNOS: pm_domain: Bind devices to power domains using DT > > ARM: dts: exynos4: Set up power domains > > > > .../bindings/arm/exynos/power_domain.txt | 15 +++- > > arch/arm/boot/dts/exynos4.dtsi | 30 +++ > > arch/arm/boot/dts/exynos4210.dtsi | 5 ++ > > arch/arm/mach-exynos/pm_domains.c | 93 > > +- 4 files changed, 135 insertions(+), 8 > > deletions(-) > > Since this version is just a rebase to your for-next and there are no > remaining comments, could you still take it for 3.8? > Well, I'm not sure 'S5P_INT_LOCAL_PWR_EN' in [1/4] patch is available on all of exynos and it can support multiple platform. But at this moment, looks OK to me. If any modification is required, we can do it later. Will apply, 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: dts: exynos4: Use drive strength 3 for SD pins
Tomasz Figa wrote: > > Hi Kgene, > > On Tuesday 20 of November 2012 20:10:25 Kukjin Kim wrote: > > Tomasz Figa wrote: > > > Hi Kgene, > > > > > > On Tuesday 20 of November 2012 18:18:44 Kukjin Kim wrote: > > > > Tomasz Figa wrote: > > > > > This patch modifies pin control groups of SD pins on Exynos4210 > > > > > and > > > > > Exynos4x12 to use drive strength 3, which corresponds to > > > > > S5P_GPIO_DRVSTR_LV4 in legacy non-DT code. > > > > > > > > Well, the value of drive strength depends on board not SoC. So if > > > > required, it should be moved to board DT stuff. > > > > > > Yes, I fully agree. > > > > > > I've been thinking whether to change the defaults or just override > > > them > > > for Origen, but I came to a conclusion that 3 (LV4) was the default in > > > non-DT code, so it probably should be also the default in DT variant. > > > > OK. > > > > > > BTW, we can use the value as a default...I need to think about that > > > > again for exynos4210 and 4x12. > > > > > > I wonder which default value is more appropriate, 0 or 3? > > > > In this case, yes, '3' is more useful...so can you re-submit this patch > > with editing commit? > > I can resubmit this patch, but I'm not sure what you expect me to edit. > Could you explain? > Hmm, I mean the commit message needs explanation is why to use '3' as a default value is more useful. OK, if you don't mind, I will edit it when I apply. > If possible, it would be nice to get this included in 3.8 as it's required > for Origen board to boot with device tree. > OK, as we discussed, I agree with this. Will apply, thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/4] [SCSI] drivers/scsi/ufs: Seggregate PCI Specific Code
On Wed, Nov 21, 2012 at 4:26 PM, James Bottomley wrote: > On Wed, 2012-11-21 at 16:02 +0530, vinayak holikatti wrote: >> On Wed, Nov 14, 2012 at 2:56 AM, James Bottomley >> wrote: >> > On Thu, 2012-10-18 at 17:37 +0530, vinayak holikatti wrote: >> >> I am Vacation will look into it when i am back to work. >> >> > This doesn't apply on 3.7-rc1. Am I missing any patches in between ? >> > >> > OK, so it doesn't apply for me either: >> > >> > patching file drivers/scsi/ufs/ufshcd.c >> > Hunk #11 FAILED at 902. >> > Hunk #15 succeeded at 1157 with fuzz 1 (offset 2 lines). >> > Hunk #16 succeeded at 1271 (offset 2 lines). >> > Hunk #17 succeeded at 1300 (offset 2 lines). >> > Hunk #18 succeeded at 1364 (offset 2 lines). >> > Hunk #19 succeeded at 1499 (offset 2 lines). >> > Hunk #20 succeeded at 1542 (offset 2 lines). >> > Hunk #21 succeeded at 1678 (offset 2 lines). >> > Hunk #22 succeeded at 1706 (offset 2 lines). >> > Hunk #23 succeeded at 1727 (offset 2 lines). >> > Hunk #24 succeeded at 1775 (offset 2 lines). >> > Hunk #25 succeeded at 1819 (offset 2 lines). >> > Hunk #26 succeeded at 1872 (offset 2 lines). >> > Hunk #27 succeeded at 1898 (offset 2 lines). >> > Hunk #28 FAILED at 2011. >> > 2 out of 28 hunks FAILED -- saving rejects to file >> > drivers/scsi/ufs/ufshcd.c.rej >> > >> I have generated patches based on linux/kernel/git/jejb/scsi.git this >> tree, Also i have >> confirmed that patches get applied successfully on this git tree. >> >> James, >> Which tree are you refering to. Let me know, which tree i should use to >> generate the patches. > > All patches for the merge window should be against the misc branch of > the scsi.git tree. > > James > Ok, I will create the patches against misc branch and resend these patches. Thanks Vinayak Holikatti -- 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 340/493] arm: remove use of __devinitdata
On Mon, Nov 19, 2012 at 01:24:49PM -0500, Bill Pemberton wrote: > arch/arm/mach-sa1100/neponset.c | 2 +- For this alone, Acked-by: Russell King -- 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 484/493] arm: remove use of __devexit
Bill Pemberton wrote: > > CONFIG_HOTPLUG is going away as an option so __devexit is no > longer needed. > > Signed-off-by: Bill Pemberton > Cc: Russell King > Cc: Eric Miao > Cc: Haojian Zhuang > Cc: Tony Lindgren > Cc: Ben Dooks > Cc: Kukjin Kim > Cc: linux-arm-ker...@lists.infradead.org > Cc: davinci-linux-open-sou...@linux.davincidsp.com > Cc: linux-o...@vger.kernel.org > Cc: linux-samsung-soc@vger.kernel.org > --- [...] > arch/arm/mach-s3c24xx/mach-osiris-dvs.c | 2 +- > arch/arm/plat-samsung/adc.c | 2 +- For above s3c24xx and samsung, Acked-by: Kukjin Kim 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 340/493] arm: remove use of __devinitdata
Bill Pemberton wrote: > > CONFIG_HOTPLUG is going away as an option so __devinitdata is no > longer needed. > > Signed-off-by: Bill Pemberton > Cc: Will Deacon > Cc: Russell King > Cc: Ben Dooks > Cc: Kukjin Kim > Cc: linux-arm-ker...@lists.infradead.org > Cc: patc...@opensource.wolfsonmicro.com > Cc: linux-samsung-soc@vger.kernel.org > Cc: linux-te...@vger.kernel.org > --- [...] > arch/arm/mach-s3c64xx/mach-crag6410-module.c | 2 +- > arch/arm/mach-s3c64xx/mach-crag6410.c| 68 ++--- > --- For above s3c64xx, Acked-by: Kukjin Kim 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 270/493] arm: remove use of __devinit
Bill Pemberton wrote: > > CONFIG_HOTPLUG is going away as an option so __devinit is no longer > needed. > > Signed-off-by: Bill Pemberton > Cc: Russell King > Cc: Will Deacon > Cc: Jason Cooper > Cc: Andrew Lunn > Cc: Sascha Hauer > Cc: Eric Miao > Cc: Haojian Zhuang > Cc: David Brown > Cc: Daniel Walker > Cc: Bryan Huntsman > Cc: Tony Lindgren > Cc: Kevin Hilman > Cc: Barry Song > Cc: Ben Dooks > Cc: Kukjin Kim > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: linux-o...@vger.kernel.org > Cc: linux-samsung-soc@vger.kernel.org > Cc: patc...@opensource.wolfsonmicro.com > Cc: linux-te...@vger.kernel.org > --- [...] > arch/arm/mach-s3c24xx/h1940-bluetooth.c | 2 +- > arch/arm/mach-s3c24xx/mach-osiris-dvs.c | 2 +- > arch/arm/mach-s3c64xx/mach-crag6410-module.c | 2 +- For above s3c24xx and s3c64xx, Acked-by: Kukjin Kim 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 032/493] arm: remove use of __devexit_p
Bill Pemberton wrote: > > CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer > needed. > > Signed-off-by: Bill Pemberton > Cc: Russell King > Cc: Tony Lindgren > Cc: Eric Miao > Cc: Haojian Zhuang > Cc: Ben Dooks > Cc: Kukjin Kim > Cc: linux-arm-ker...@lists.infradead.org > Cc: davinci-linux-open-sou...@linux.davincidsp.com > Cc: linux-o...@vger.kernel.org > Cc: linux-samsung-soc@vger.kernel.org > --- > arch/arm/mach-s3c24xx/mach-osiris-dvs.c | 2 +- > arch/arm/plat-samsung/adc.c | 2 +- For above s3c24xx and samsung, Acked-by: Kukjin Kim 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 132/493] Input: remove use of __devexit_p
On Mon, Nov 19, 2012 at 01:21:21PM -0500, Bill Pemberton wrote: > drivers/input/serio/ambakmi.c | 2 +- > drivers/input/serio/pcips2.c| 2 +- > drivers/input/serio/rpckbd.c| 2 +- > drivers/input/serio/saps2.c | 2 +- For these four, Acked-by: Russell King -- 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: host: sdhci-s3c: Add support for pinctrl
On 16 November 2012 19:58, Tomasz Figa wrote:
> This patch adds support for pin configuration using pinctrl subsystem
> to the sdhci-s3c driver.
>
> Signed-off-by: Tomasz Figa
> ---
> .../devicetree/bindings/mmc/samsung-sdhci.txt| 20
> +---
> drivers/mmc/host/sdhci-s3c.c | 12 ++--
> 2 files changed, 23 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
> b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
> index 630a7d7..97e9e31 100644
> --- a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
> +++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
> @@ -12,10 +12,6 @@ is used. The Samsung's SDHCI controller bindings extends
> this as listed below.
> [A] The property "samsung,cd-pinmux-gpio" can be used as stated in the
> "Optional Board Specific Properties" section below.
>
> -[B] If core card-detect bindings and "samsung,cd-pinmux-gpio" property
> -is not specified, it is assumed that there is no card detection
> -mechanism used.
> -
> Required SoC Specific Properties:
> - compatible: should be one of the following
>- "samsung,s3c6410-sdhci": For controllers compatible with s3c6410 sdhci
> @@ -24,14 +20,18 @@ Required SoC Specific Properties:
> controller.
>
> Required Board Specific Properties:
> -- gpios: Should specify the gpios used for clock, command and data lines. The
> - gpio specifier format depends on the gpio controller.
> +- Samsung GPIO variant (will be completely replaced by pinctrl):
> + - gpios: Should specify the gpios used for clock, command and data lines.
> The
> +gpio specifier format depends on the gpio controller.
> +- Pinctrl variant (preferred if available):
> + - pinctrl-0: Should specify pin control groups used for this controller.
> + - pinctrl-names: Should contain only one value - "default".
>
> Optional Board Specific Properties:
> - samsung,cd-pinmux-gpio: Specifies the card detect line that is routed
>through a pinmux to the card-detect pin of the card slot. This property
>should be used only if none of the mmc core card-detect properties are
> - used.
> + used. Only for Samsung GPIO variant.
>
> Example:
> sdhci@1253 {
> @@ -40,12 +40,18 @@ Example:
> interrupts = <0 75 0>;
> bus-width = <4>;
> cd-gpios = <&gpk2 2 2 3 3>;
> +
> + /* Samsung GPIO variant */
> gpios = <&gpk2 0 2 0 3>, /* clock line */
> <&gpk2 1 2 0 3>, /* command line */
> <&gpk2 3 2 3 3>, /* data line 0 */
> <&gpk2 4 2 3 3>, /* data line 1 */
> <&gpk2 5 2 3 3>, /* data line 2 */
> <&gpk2 6 2 3 3>; /* data line 3 */
> +
> + /* Pinctrl variant */
> + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4>;
> + pinctrl-names = "default";
> };
nit: there could have been one example each for gpio and pinctrl
variant instead of putting both into one example node.
>
> Note: This example shows both SoC specific and board specific
> properties
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index 75f85fd..6161162 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -57,6 +58,7 @@ struct sdhci_s3c {
> int ext_cd_irq;
> int ext_cd_gpio;
> int *gpios;
> + struct pinctrl *pctrl;
>
> struct clk *clk_io;
> struct clk *clk_bus[MAX_BUS_CLK];
> @@ -477,8 +479,9 @@ static int __devinit sdhci_s3c_parse_dt(struct device
> *dev,
> return -EINVAL;
> }
>
> - dev_info(dev, "assuming no card detect line available\n");
> - pdata->cd_type = S3C_SDHCI_CD_NONE;
> + /* assuming internal card detect that will be configured by pinctrl */
> + pdata->cd_type = S3C_SDHCI_CD_INTERNAL;
> + goto setup_bus;
>
> found_cd:
> if (pdata->cd_type == S3C_SDHCI_CD_GPIO) {
> @@ -496,6 +499,9 @@ static int __devinit sdhci_s3c_parse_dt(struct device
> *dev,
> }
>
> setup_bus:
> + if (!IS_ERR(ourhost->pctrl))
> + return 0;
> +
> /* get the gpios for command, clock and data lines */
> for (cnt = 0; cnt < NUM_GPIOS(pdata->max_width); cnt++) {
> gpio = of_get_gpio(node, cnt);
> @@ -574,6 +580,8 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
> goto err_pdata_io_clk;
> }
>
> + sc->pctrl = devm_pinctrl_get_select_default(&pdev->dev);
> +
> if (pdev->dev.of_node) {
> ret = sdhci_s3c_parse_dt(&pdev->dev, host, pdata);
>
Re: [PATCH V4 1/4] [SCSI] drivers/scsi/ufs: Seggregate PCI Specific Code
On Wed, 2012-11-21 at 16:02 +0530, vinayak holikatti wrote: > On Wed, Nov 14, 2012 at 2:56 AM, James Bottomley > wrote: > > On Thu, 2012-10-18 at 17:37 +0530, vinayak holikatti wrote: > >> I am Vacation will look into it when i am back to work. > >> > This doesn't apply on 3.7-rc1. Am I missing any patches in between ? > > > > OK, so it doesn't apply for me either: > > > > patching file drivers/scsi/ufs/ufshcd.c > > Hunk #11 FAILED at 902. > > Hunk #15 succeeded at 1157 with fuzz 1 (offset 2 lines). > > Hunk #16 succeeded at 1271 (offset 2 lines). > > Hunk #17 succeeded at 1300 (offset 2 lines). > > Hunk #18 succeeded at 1364 (offset 2 lines). > > Hunk #19 succeeded at 1499 (offset 2 lines). > > Hunk #20 succeeded at 1542 (offset 2 lines). > > Hunk #21 succeeded at 1678 (offset 2 lines). > > Hunk #22 succeeded at 1706 (offset 2 lines). > > Hunk #23 succeeded at 1727 (offset 2 lines). > > Hunk #24 succeeded at 1775 (offset 2 lines). > > Hunk #25 succeeded at 1819 (offset 2 lines). > > Hunk #26 succeeded at 1872 (offset 2 lines). > > Hunk #27 succeeded at 1898 (offset 2 lines). > > Hunk #28 FAILED at 2011. > > 2 out of 28 hunks FAILED -- saving rejects to file > > drivers/scsi/ufs/ufshcd.c.rej > > > I have generated patches based on linux/kernel/git/jejb/scsi.git this > tree, Also i have > confirmed that patches get applied successfully on this git tree. > > James, > Which tree are you refering to. Let me know, which tree i should use to > generate the patches. All patches for the merge window should be against the misc branch of the scsi.git tree. James -- 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 270/493] arm: remove use of __devinit
2012/11/20 Bill Pemberton : > CONFIG_HOTPLUG is going away as an option so __devinit is no longer > needed. > > Signed-off-by: Bill Pemberton > Cc: Russell King > Cc: Will Deacon > Cc: Jason Cooper > Cc: Andrew Lunn > Cc: Sascha Hauer > Cc: Eric Miao > Cc: Haojian Zhuang > Cc: David Brown > Cc: Daniel Walker > Cc: Bryan Huntsman > Cc: Tony Lindgren > Cc: Kevin Hilman > Cc: Barry Song > Cc: Ben Dooks > Cc: Kukjin Kim > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: linux-o...@vger.kernel.org > Cc: linux-samsung-soc@vger.kernel.org > Cc: patc...@opensource.wolfsonmicro.com > Cc: linux-te...@vger.kernel.org > --- Acked-by: Barry Song -- 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] mmc: host: sdhci-s3c: Use devm_gpio_request to request GPIOs
On 16 November 2012 19:58, Tomasz Figa wrote:
> The set of GPIO pins used by sdhci-s3c driver varies between
> configurations, such as card detect method, pinctrl availability, etc.
> This overly complicates the code requesting and freeing GPIO pins, which
> must check which pins are used, when freeing them.
>
> This patch modifies the sdhci-s3c driver to use devm_gpio_request to
> free requested pins automatically after unbinding the driver.
>
> Signed-off-by: Tomasz Figa
> ---
> drivers/mmc/host/sdhci-s3c.c | 40 +---
> 1 file changed, 9 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index 2903949..75f85fd 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -406,7 +406,7 @@ static void sdhci_s3c_setup_card_detect_gpio(struct
> sdhci_s3c *sc)
> struct s3c_sdhci_platdata *pdata = sc->pdata;
> struct device *dev = &sc->pdev->dev;
>
> - if (gpio_request(pdata->ext_cd_gpio, "SDHCI EXT CD") == 0) {
> + if (devm_gpio_request(dev, pdata->ext_cd_gpio, "SDHCI EXT CD") == 0) {
> sc->ext_cd_gpio = pdata->ext_cd_gpio;
> sc->ext_cd_irq = gpio_to_irq(pdata->ext_cd_gpio);
> if (sc->ext_cd_irq &&
> @@ -487,7 +487,7 @@ static int __devinit sdhci_s3c_parse_dt(struct device
> *dev,
> if (of_get_property(node, "cd-inverted", NULL))
> pdata->ext_cd_gpio_invert = 1;
> } else if (pdata->cd_type == S3C_SDHCI_CD_INTERNAL) {
> - ret = gpio_request(gpio, "sdhci-cd");
> + ret = devm_gpio_request(dev, gpio, "sdhci-cd");
> if (ret) {
> dev_err(dev, "card detect gpio request failed\n");
> return -EINVAL;
> @@ -501,28 +501,20 @@ static int __devinit sdhci_s3c_parse_dt(struct device
> *dev,
> gpio = of_get_gpio(node, cnt);
> if (!gpio_is_valid(gpio)) {
> dev_err(dev, "invalid gpio[%d]\n", cnt);
> - goto err_free_dt_cd_gpio;
> + return -EINVAL;
> }
> ourhost->gpios[cnt] = gpio;
> }
>
> for (cnt = 0; cnt < NUM_GPIOS(pdata->max_width); cnt++) {
> - ret = gpio_request(ourhost->gpios[cnt], "sdhci-gpio");
> + ret = devm_gpio_request(dev, ourhost->gpios[cnt],
> "sdhci-gpio");
> if (ret) {
> dev_err(dev, "gpio[%d] request failed\n", cnt);
> - goto err_free_dt_gpios;
> + return -EINVAL;
> }
> }
>
> return 0;
> -
> - err_free_dt_gpios:
> - while (--cnt >= 0)
> - gpio_free(ourhost->gpios[cnt]);
> - err_free_dt_cd_gpio:
> - if (pdata->cd_type == S3C_SDHCI_CD_INTERNAL)
> - gpio_free(ourhost->ext_cd_gpio);
> - return -EINVAL;
> }
> #else
> static int __devinit sdhci_s3c_parse_dt(struct device *dev,
> @@ -579,13 +571,13 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
> pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
> if (!pdata) {
> ret = -ENOMEM;
> - goto err_pdata;
> + goto err_pdata_io_clk;
> }
>
> if (pdev->dev.of_node) {
> ret = sdhci_s3c_parse_dt(&pdev->dev, host, pdata);
> if (ret)
> - goto err_pdata;
> + goto err_pdata_io_clk;
> } else {
> memcpy(pdata, pdev->dev.platform_data, sizeof(*pdata));
> sc->ext_cd_gpio = -1; /* invalid gpio number */
> @@ -603,7 +595,7 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
> if (IS_ERR(sc->clk_io)) {
> dev_err(dev, "failed to get io clock\n");
> ret = PTR_ERR(sc->clk_io);
> - goto err_io_clk;
> + goto err_pdata_io_clk;
> }
>
> /* enable the local io clock and keep it running for the moment. */
> @@ -765,13 +757,7 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
> clk_disable(sc->clk_io);
> clk_put(sc->clk_io);
>
> - err_io_clk:
> - for (ptr = 0; ptr < NUM_GPIOS(sc->pdata->max_width); ptr++)
> - gpio_free(sc->gpios[ptr]);
> - if (pdata->cd_type == S3C_SDHCI_CD_INTERNAL)
> - gpio_free(sc->ext_cd_gpio);
> -
> - err_pdata:
> + err_pdata_io_clk:
> sdhci_free_host(host);
>
> return ret;
> @@ -790,9 +776,6 @@ static int __devexit sdhci_s3c_remove(struct
> platform_device *pdev)
> if (sc->ext_cd_irq)
> free_irq(sc->ext_cd_irq, sc);
>
> - if (gpio_is_valid(sc->ext_cd_gpio))
> - gpio_free(sc->ext_cd_gpio);
> -
> #ifdef CONFIG_PM_RUNTIME
> clk_enable(sc-
Re: [PATCH v2 0/2] mmc: host: sdhci-s3c: Add support for pinctrl interface
Hi, On Friday 16 of November 2012 15:28:15 Tomasz Figa wrote: > This series intends to add support for pin configuration using pin > control interface. > > First patch cleans up GPIO requesting and freeing in the driver to > simplify adding pin control support. > > Second patch adds pin control support to the driver. > > Changes since v1: > - fixed build error because of incorrect merge > > Tomasz Figa (2): > mmc: host: sdhci-s3c: Use devm_gpio_request to request GPIOs > mmc: host: sdhci-s3c: Add support for pinctrl > > .../devicetree/bindings/mmc/samsung-sdhci.txt | 20 ++--- > drivers/mmc/host/sdhci-s3c.c | 52 > -- 2 files changed, 32 insertions(+), 40 > deletions(-) I know it's less than a week since I posted this series, but time is running out, while it would be nice to get this included in 3.8, because it's required for all Exynos4 boards using MMC. Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Linux Platform -- 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 RESEND 0/4] ARM: EXYNOS: Power domain DT support extension
Hi Kgene, On Tuesday 13 of November 2012 14:08:23 Tomasz Figa wrote: > This patch series fixes two issues with existing DT support for Exynos > power domains and extends it with the ability of binding devices to > domains, basically making it possible to use power domains with DT. > > Based on for-next branch of Kgene's tree. > > Changes since v2: > - Rebased to for-next of Kgene's tree. > Changes since v1: > - Added "samsung," prefix to "power-domain" property. > - Added power domain nodes to Exynos4 device tree sources. > > Tomasz Figa (4): > ARM: EXYNOS: pm_domain: Detect domain state on registration from DT > ARM: EXYNOS: pm_domain: Fix power domain name initialization > ARM: EXYNOS: pm_domain: Bind devices to power domains using DT > ARM: dts: exynos4: Set up power domains > > .../bindings/arm/exynos/power_domain.txt | 15 +++- > arch/arm/boot/dts/exynos4.dtsi | 30 +++ > arch/arm/boot/dts/exynos4210.dtsi | 5 ++ > arch/arm/mach-exynos/pm_domains.c | 93 > +- 4 files changed, 135 insertions(+), 8 > deletions(-) Since this version is just a rebase to your for-next and there are no remaining comments, could you still take it for 3.8? Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Linux Platform -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: exynos4: Use drive strength 3 for SD pins
Hi Kgene, On Tuesday 20 of November 2012 20:10:25 Kukjin Kim wrote: > Tomasz Figa wrote: > > Hi Kgene, > > > > On Tuesday 20 of November 2012 18:18:44 Kukjin Kim wrote: > > > Tomasz Figa wrote: > > > > This patch modifies pin control groups of SD pins on Exynos4210 > > > > and > > > > Exynos4x12 to use drive strength 3, which corresponds to > > > > S5P_GPIO_DRVSTR_LV4 in legacy non-DT code. > > > > > > Well, the value of drive strength depends on board not SoC. So if > > > required, it should be moved to board DT stuff. > > > > Yes, I fully agree. > > > > I've been thinking whether to change the defaults or just override > > them > > for Origen, but I came to a conclusion that 3 (LV4) was the default in > > non-DT code, so it probably should be also the default in DT variant. > > OK. > > > > BTW, we can use the value as a default...I need to think about that > > > again for exynos4210 and 4x12. > > > > I wonder which default value is more appropriate, 0 or 3? > > In this case, yes, '3' is more useful...so can you re-submit this patch > with editing commit? I can resubmit this patch, but I'm not sure what you expect me to edit. Could you explain? If possible, it would be nice to get this included in 3.8 as it's required for Origen board to boot with device tree. Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Linux Platform -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/4] [SCSI] drivers/scsi/ufs: Seggregate PCI Specific Code
On Wed, Nov 14, 2012 at 2:56 AM, James Bottomley wrote: > On Thu, 2012-10-18 at 17:37 +0530, vinayak holikatti wrote: >> I am Vacation will look into it when i am back to work. >> > This doesn't apply on 3.7-rc1. Am I missing any patches in between ? > > OK, so it doesn't apply for me either: > > patching file drivers/scsi/ufs/ufshcd.c > Hunk #11 FAILED at 902. > Hunk #15 succeeded at 1157 with fuzz 1 (offset 2 lines). > Hunk #16 succeeded at 1271 (offset 2 lines). > Hunk #17 succeeded at 1300 (offset 2 lines). > Hunk #18 succeeded at 1364 (offset 2 lines). > Hunk #19 succeeded at 1499 (offset 2 lines). > Hunk #20 succeeded at 1542 (offset 2 lines). > Hunk #21 succeeded at 1678 (offset 2 lines). > Hunk #22 succeeded at 1706 (offset 2 lines). > Hunk #23 succeeded at 1727 (offset 2 lines). > Hunk #24 succeeded at 1775 (offset 2 lines). > Hunk #25 succeeded at 1819 (offset 2 lines). > Hunk #26 succeeded at 1872 (offset 2 lines). > Hunk #27 succeeded at 1898 (offset 2 lines). > Hunk #28 FAILED at 2011. > 2 out of 28 hunks FAILED -- saving rejects to file > drivers/scsi/ufs/ufshcd.c.rej > I have generated patches based on linux/kernel/git/jejb/scsi.git this tree, Also i have confirmed that patches get applied successfully on this git tree. James, Which tree are you refering to. Let me know, which tree i should use to generate the patches. > James > > -- 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/4] ARM: dts: exynos4210-origen: Device tree fixes
Hi Kgene, On Monday 19 of November 2012 15:46:32 Tomasz Figa wrote: > This patch series fixes device tree support for Origen board: > - memory is defined using sections of maximum allowed size > - any pin configuration is modified to use pinctrl > - invalid properties in sdhci nodes are replaced according to current >mmc bindings > - a fixed vmmc voltage regulator is added > > Tested on Origen board. > > Depends on: > [PATCH v2 0/2] mmc: host: sdhci-s3c: Add support for pinctrl interface > > Tomasz Figa (4): > ARM: dts: exynos4210-origen: Split memory sections > ARM: dts: exynos4210-origen: Update for pinctrl-samsung driver > ARM: dts: exynos4210-origen: Update sdhci nodes for current bindings > ARM: dts: exynos4210-origen: Add vmmc fixed voltage regulator > > arch/arm/boot/dts/exynos4210-origen.dts | 54 > - 1 file changed, 27 insertions(+), 27 > deletions(-) Could you still pick these patches up for 3.8? Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Linux Platform -- 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 UART3 to DEBUG_LL ports
Olof Johansson wrote: > > On Tue, Nov 20, 2012 at 02:48:58PM -0800, Doug Anderson wrote: > > From: Olof Johansson > > > > UART3 is used for debugging on exynos5250-snow. > > > > [dianders: cleaned commit message.] > > > > Signed-off-by: Olof Johansson > > Signed-off-by: Doug Anderson > > > > > --- > > arch/arm/Kconfig.debug| 11 +++ > > arch/arm/plat-samsung/Kconfig |1 + > > 2 files changed, 12 insertions(+), 0 deletions(-) > > > > diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug > > index 33a8930..35ba7dc 100644 > > --- a/arch/arm/Kconfig.debug > > +++ b/arch/arm/Kconfig.debug > > @@ -355,6 +355,17 @@ choice > > The uncompressor code port configuration is now handled > > by CONFIG_S3C_LOWLEVEL_UART_PORT. > > > > + config DEBUG_S3C_UART3 > > + depends on PLAT_SAMSUNG > > > Sorry, the reason I hadn't re-posted this is that Kukjin had proposed > to protect users of <= 3 UART platforms to select it. An added "Depends > on ARCH_EXYNOS4 || ARCH_EXYNOS5" should cover that. Can you add and > repost, please? > Yes, please :-) 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 2/2] ARM: dts: snow: Add board dts file for Snow board (ARM Chromebook)
Kukjin Kim wrote: > > Olof Johansson wrote: > > [...] > > > > Acked-by: Olof Johansson > > > > Kukjin, since your pull requests came in today, can you ack this and > > I'll just apply it on top of your branches? > > > Hi Olof, yeah, I sent pull-request but there are some patches for dt and > exynos5440 stuff in my tree not sent yet. If you're ok, let me take this > with your ack. > 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
RE: [PATCH 1/2] ARM: EXYNOS: Add aliases for i2c controller for exynos4
Doug Anderson wrote:
>
> This is similar to a recent commit for exynos5250 titled:
> ARM: EXYNOS: Add aliases for i2c controller
>
> Adding aliases will be useful to prevent warnings in a future
> change. See:
> i2c: s3c2410: Get the i2c bus number from alias id
>
> Signed-off-by: Doug Anderson
>
> ---
> arch/arm/boot/dts/exynos4.dtsi | 24
> 1 files changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4.dtsi
> b/arch/arm/boot/dts/exynos4.dtsi
> index a26c3dd..824d362 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -28,6 +28,14 @@
> spi0 = &spi_0;
> spi1 = &spi_1;
> spi2 = &spi_2;
> + i2c0 = &i2c_0;
> + i2c1 = &i2c_1;
> + i2c2 = &i2c_2;
> + i2c3 = &i2c_3;
> + i2c4 = &i2c_4;
> + i2c5 = &i2c_5;
> + i2c6 = &i2c_6;
> + i2c7 = &i2c_7;
> };
>
> gic:interrupt-controller@1049 {
> @@ -121,7 +129,7 @@
> status = "disabled";
> };
>
> - i2c@1386 {
> + i2c_0: i2c@1386 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "samsung,s3c2440-i2c";
> @@ -130,7 +138,7 @@
> status = "disabled";
> };
>
> - i2c@1387 {
> + i2c_1: i2c@1387 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "samsung,s3c2440-i2c";
> @@ -139,7 +147,7 @@
> status = "disabled";
> };
>
> - i2c@1388 {
> + i2c_2: i2c@1388 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "samsung,s3c2440-i2c";
> @@ -148,7 +156,7 @@
> status = "disabled";
> };
>
> - i2c@1389 {
> + i2c_3: i2c@1389 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "samsung,s3c2440-i2c";
> @@ -157,7 +165,7 @@
> status = "disabled";
> };
>
> - i2c@138A {
> + i2c_4: i2c@138A {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "samsung,s3c2440-i2c";
> @@ -166,7 +174,7 @@
> status = "disabled";
> };
>
> - i2c@138B {
> + i2c_5: i2c@138B {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "samsung,s3c2440-i2c";
> @@ -175,7 +183,7 @@
> status = "disabled";
> };
>
> - i2c@138C {
> + i2c_6: i2c@138C {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "samsung,s3c2440-i2c";
> @@ -184,7 +192,7 @@
> status = "disabled";
> };
>
> - i2c@138D {
> + i2c_7: i2c@138D {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "samsung,s3c2440-i2c";
> --
> 1.7.7.3
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
RE: [PATCH] ARM: exynos: dt: add all i2c busses to auxdata
Doug Anderson wrote:
>
> From: Olof Johansson
>
> Needed to match device ids for clocks, etc.
>
> Signed-off-by: Olof Johansson
> Signed-off-by: Doug Anderson
>
> ---
> arch/arm/mach-exynos/mach-exynos5-dt.c | 10 ++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-
> exynos/mach-exynos5-dt.c
> index ed37273..e1491f7 100644
> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
> @@ -52,6 +52,16 @@ static const struct of_dev_auxdata
> exynos5250_auxdata_lookup[] __initconst = {
> "s3c2440-i2c.1", NULL),
> OF_DEV_AUXDATA("samsung,s3c2440-i2c", EXYNOS5_PA_IIC(2),
> "s3c2440-i2c.2", NULL),
> + OF_DEV_AUXDATA("samsung,s3c2440-i2c", EXYNOS5_PA_IIC(3),
> + "s3c2440-i2c.3", NULL),
> + OF_DEV_AUXDATA("samsung,s3c2440-i2c", EXYNOS5_PA_IIC(4),
> + "s3c2440-i2c.4", NULL),
> + OF_DEV_AUXDATA("samsung,s3c2440-i2c", EXYNOS5_PA_IIC(5),
> + "s3c2440-i2c.5", NULL),
> + OF_DEV_AUXDATA("samsung,s3c2440-i2c", EXYNOS5_PA_IIC(6),
> + "s3c2440-i2c.6", NULL),
> + OF_DEV_AUXDATA("samsung,s3c2440-i2c", EXYNOS5_PA_IIC(7),
> + "s3c2440-i2c.7", NULL),
> OF_DEV_AUXDATA("samsung,s3c2440-hdmiphy-i2c", EXYNOS5_PA_IIC(8),
> "s3c2440-hdmiphy-i2c", NULL),
> OF_DEV_AUXDATA("samsung,exynos5250-dw-mshc", EXYNOS5_PA_DWMCI0,
> --
> 1.7.7.3
Looks ok to me, 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
RE: [PATCH 2/2] i2c: s3c2410: Get the i2c bus number from alias id
Doug Anderson wrote:
>
> From: Padmavathi Venna
>
> Get the i2c bus number that the device is connected to using the alias
> id. This makes debugging / grokking of kernel messages much easier.
>
> [dianders: slight patch cleanup from Padmavathi's original.]
>
> Signed-off-by: Padmavathi Venna
> Signed-off-by: Doug Anderson
Acked-by: Kukjin Kim
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> ---
> drivers/i2c/busses/i2c-s3c2410.c | 10 +-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-
> s3c2410.c
> index 3e0335f..ca43590 100644
> --- a/drivers/i2c/busses/i2c-s3c2410.c
> +++ b/drivers/i2c/busses/i2c-s3c2410.c
> @@ -899,11 +899,19 @@ static void
> s3c24xx_i2c_parse_dt(struct device_node *np, struct s3c24xx_i2c *i2c)
> {
> struct s3c2410_platform_i2c *pdata = i2c->pdata;
> + int id;
>
> if (!np)
> return;
>
> - pdata->bus_num = -1; /* i2c bus number is dynamically assigned */
> + id = of_alias_get_id(np, "i2c");
> + if (id < 0) {
> + dev_warn(i2c->dev, "failed to get alias id:%d\n", id);
> + pdata->bus_num = -1;
> + } else {
> + /* i2c bus number is statically assigned from alias */
> + pdata->bus_num = id;
> + }
> of_property_read_u32(np, "samsung,i2c-sda-delay", &pdata-
> >sda_delay);
> of_property_read_u32(np, "samsung,i2c-slave-addr", &pdata-
> >slave_addr);
> of_property_read_u32(np, "samsung,i2c-max-bus-freq",
> --
> 1.7.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/4] thermal: Add support for interrupt based notification to thermal layer
Hi, Amit, As THERMAL_TREND_RAISE_FULL/THERMAL_TREND_DROP_FULL has been introduced to thermal next tree, I'd like to get your plan about this patch set? Thanks, Rui > -Original Message- > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- > ow...@vger.kernel.org] On Behalf Of Amit Daniel Kachhap > Sent: Thursday, November 08, 2012 12:26 PM > To: linux...@lists.linux-foundation.org > Cc: linux-samsung-soc@vger.kernel.org; linux-ker...@vger.kernel.org; R, > Durgadoss; l...@kernel.org; Zhang, Rui; linux-a...@vger.kernel.org; > amit.kach...@linaro.org; jonghwa3@samsung.com > Subject: [PATCH 0/4] thermal: Add support for interrupt based > notification to thermal layer > Importance: High > > The patch submitted by Jonghwa Lee > (https://patchwork.kernel.org/patch/1683441/) > adds support for interrupt based notification to thermal layer. This is > a good feature but the current thermal framework needs polling/regular > notification for invoking suitable cooling action. So adding 2 new > thermal trend type to implement this feature. > > All these patches are based on thermal maintainer next tree. > git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next > > Amit Daniel Kachhap (3): > thermal: Add new thermal trend type to support quick cooling > thermal: exynos: Miscellaneous fixes to support falling threshold > interrupt > thermal: exynos: Use the new thermal trend type for quick cooling > action. > > Jonghwa Lee (1): > Thermal: exynos: Add support for temperature falling interrupt. > > drivers/thermal/exynos_thermal.c | 105 +++--- > > drivers/thermal/step_wise.c | 19 - > include/linux/platform_data/exynos_thermal.h |3 + > include/linux/thermal.h |2 + > 4 files changed, 80 insertions(+), 49 deletions(-) > > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" > 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
