Re: [PATCH v9 1/2] regulator: Add driver for max77802 PMIC PMIC regulators

[Yuvaraj Cd]

On Mon, Aug 18, 2014 at 2:02 PM, Javier Martinez Canillas
 wrote:
> The MAX77802 PMIC has 10 high-efficiency Buck and 32 Low-dropout
> (LDO) regulators. This patch adds support for all these regulators
> found on the MAX77802 PMIC and is based on a driver added by Simon
> Glass to the Chrome OS kernel 3.8 tree.
>
> Signed-off-by: Javier Martinez Canillas 
> Tested-by: Naveen Krishna Chatradhi 
> ---
>
> Changes since v7:
>  - Remove DVS support since that can be added as a follow up.
>
> Changes since v6: None
>
> Changes since v5:
>  - Take out the mfd changes from v4 that were squashed by mistake.
>Suggested by Lee Jones.
>
> Changes since v4: None
>
> Changes since v3:
>  - Set the supply_name for regulators to lookup their parent supply node.
>Suggested by Mark Brown.
>  - Change Exyno5 for Exynos5420/Exynos5800 in regulator driver Kconfig.
>Suggested by Doug Anderson.
> ---
>  drivers/regulator/Kconfig|   9 +
>  drivers/regulator/Makefile   |   1 +
>  drivers/regulator/max77802.c | 578 
> +++
>  3 files changed, 588 insertions(+)
>  create mode 100644 drivers/regulator/max77802.c
>
> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
> index 2dc8289..8134a99 100644
> --- a/drivers/regulator/Kconfig
> +++ b/drivers/regulator/Kconfig
> @@ -387,6 +387,15 @@ config REGULATOR_MAX77693
>   and one current regulator 'CHARGER'. This is suitable for
>   Exynos-4x12 chips.
>
> +config REGULATOR_MAX77802
> +   tristate "Maxim 77802 regulator"
> +   depends on MFD_MAX77686
> +   help
> + This driver controls a Maxim 77802 regulator
> + via I2C bus. The provided regulator is suitable for
> + Exynos5420/Exynos5800 SoCs to control various voltages.
> + It includes support for control of voltage and ramp speed.
> +
>  config REGULATOR_MC13XXX_CORE
> tristate
>
> diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
> index aa4a6aa..b4ec6c8 100644
> --- a/drivers/regulator/Makefile
> +++ b/drivers/regulator/Makefile
> @@ -52,6 +52,7 @@ obj-$(CONFIG_REGULATOR_MAX8997) += max8997.o
>  obj-$(CONFIG_REGULATOR_MAX8998) += max8998.o
>  obj-$(CONFIG_REGULATOR_MAX77686) += max77686.o
>  obj-$(CONFIG_REGULATOR_MAX77693) += max77693.o
> +obj-$(CONFIG_REGULATOR_MAX77802) += max77802.o
>  obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
>  obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
>  obj-$(CONFIG_REGULATOR_MC13XXX_CORE) +=  mc13xxx-regulator-core.o
> diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
> new file mode 100644
> index 000..5f022f8
> --- /dev/null
> +++ b/drivers/regulator/max77802.c
> @@ -0,0 +1,578 @@
> +/*
> + * max77802.c - Regulator driver for the Maxim 77802
> + *
> + * Copyright (C) 2013-2014 Google, Inc
> + * Simon Glass 
> + *
> + * Copyright (C) 2012 Samsung Electronics
> + * Chiwoong Byun 
> + * Jonghwa Lee 
> + *
> + * 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.
> + *
> + * 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.
> + *
> + * This driver is based on max8997.c
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Default ramp delay in case it is not manually set */
> +#define MAX77802_RAMP_DELAY10  /* uV/us */
> +
> +#define MAX77802_OPMODE_SHIFT_LDO  6
> +#define MAX77802_OPMODE_BUCK234_SHIFT  4
> +#define MAX77802_OPMODE_MASK   0x3
> +
> +#define MAX77802_VSEL_MASK 0x3F
> +#define MAX77802_DVS_VSEL_MASK 0xFF
> +
> +#define MAX77802_RAMP_RATE_MASK_2BIT   0xC0
> +#define MAX77802_RAMP_RATE_SHIFT_2BIT  6
> +#define MAX77802_RAMP_RATE_MASK_4BIT   0xF0
> +#define MAX77802_RAMP_RATE_SHIFT_4BIT  4
> +
> +/* MAX77802 has two register formats: 2-bit and 4-bit */
> +static const unsigned int ramp_table_77802_2bit[] = {
> +   12500,
> +   25000,
> +   5,
> +   10,
> +};
> +
> +static unsigned int ramp_table_77802_4bit[] = {
> +   1000,   2000,   3030,   4000,
> +   5000,   5880,   7140,   8330,
> +   9090,   1,  0,  12500,
> +   16670,  25000,  5,  10,
> +};
> +
> +struct max77802_regulator_prv {
> +   int num_regulators;
> +   struct regulator_dev *rdev[MAX77802_REG_MAX];
> +   unsigned int opmode[MAX77802_REG_MAX];
> +};
> +
> +static int max77802_get_opmode_shift(int id)
> +{
> +   if (id == MAX77802_BUCK1 || (id >= MAX77802_BUCK5 &&
> + 

[PATCH V2] vb2: fix plane index sanity check in vb2_plane_cookie()

[Zhaowei Yuan]

It's also invalid that plane_no equals to vb->num_planes

Signed-off-by: Zhaowei Yuan 
---
 drivers/media/v4l2-core/videobuf2-core.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index c359006..1ae4e57 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1130,7 +1130,7 @@ EXPORT_SYMBOL_GPL(vb2_plane_vaddr);
  */
 void *vb2_plane_cookie(struct vb2_buffer *vb, unsigned int plane_no)
 {
-   if (plane_no > vb->num_planes || !vb->planes[plane_no].mem_priv)
+   if (plane_no >= vb->num_planes || !vb->planes[plane_no].mem_priv)
return NULL;

return call_ptr_memop(vb, cookie, vb->planes[plane_no].mem_priv);
--
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 04/11] arm: Support restart through restart handler call chain

[Guenter Roeck]

On Fri, Aug 22, 2014 at 03:32:42AM +0200, Andreas Färber wrote:
> Hi,
> 
> Am 20.08.2014 02:45, schrieb Guenter Roeck:
> > The kernel core now supports a restart handler call chain for system
> > restart functions.
> > 
> > With this change, the arm_pm_restart callback is now optional, so
> > drop its initialization and check if it is set before calling it.
> > Only call the kernel restart handler if arm_pm_restart is not set.
> [...]
> > diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> > index 81ef686..ea279f7 100644
> > --- a/arch/arm/kernel/process.c
> > +++ b/arch/arm/kernel/process.c
> > @@ -114,17 +114,13 @@ void soft_restart(unsigned long addr)
> > BUG();
> >  }
> >  
> > -static void null_restart(enum reboot_mode reboot_mode, const char *cmd)
> > -{
> > -}
> > -
> >  /*
> >   * Function pointers to optional machine specific functions
> >   */
> >  void (*pm_power_off)(void);
> >  EXPORT_SYMBOL(pm_power_off);
> >  
> > -void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd) = 
> > null_restart;
> > +void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
> 
> Stupid newbie question maybe, but isn't this variable uninitialized now,
> like any non-static variable in C99? Or does the kernel assure that all
> such "fields" are zero-initialized?
> 
It is initialized with NULL, like all other global and static variables in the
kernel (and like pm_power_off a few lines above).

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-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 04/11] arm: Support restart through restart handler call chain

[Andreas Färber]

Hi,

Am 20.08.2014 02:45, schrieb Guenter Roeck:
> The kernel core now supports a restart handler call chain for system
> restart functions.
> 
> With this change, the arm_pm_restart callback is now optional, so
> drop its initialization and check if it is set before calling it.
> Only call the kernel restart handler if arm_pm_restart is not set.
[...]
> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> index 81ef686..ea279f7 100644
> --- a/arch/arm/kernel/process.c
> +++ b/arch/arm/kernel/process.c
> @@ -114,17 +114,13 @@ void soft_restart(unsigned long addr)
>   BUG();
>  }
>  
> -static void null_restart(enum reboot_mode reboot_mode, const char *cmd)
> -{
> -}
> -
>  /*
>   * Function pointers to optional machine specific functions
>   */
>  void (*pm_power_off)(void);
>  EXPORT_SYMBOL(pm_power_off);
>  
> -void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd) = 
> null_restart;
> +void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);

Stupid newbie question maybe, but isn't this variable uninitialized now,
like any non-static variable in C99? Or does the kernel assure that all
such "fields" are zero-initialized?

>  EXPORT_SYMBOL_GPL(arm_pm_restart);

(This doesn't seem to be affecting the value of arm_pm_restart, just
redeclaring it extern and adding further derived symbols.)

>  
>  /*
> @@ -230,7 +226,10 @@ void machine_restart(char *cmd)
>   local_irq_disable();
>   smp_send_stop();
>  
> - arm_pm_restart(reboot_mode, cmd);
> + if (arm_pm_restart)

Here we seem to be relying on arm_pm_restart to be NULL when not
callable. I.e., wondering whether it's ruled out that the following line
is triggered due to non-zero garbage in arm_pm_restart?

Thanks,
Andreas

> + arm_pm_restart(reboot_mode, cmd);
> + else
> + do_kernel_restart(cmd);
>  
>   /* Give a grace period for failure to restart of 1s */
>   mdelay(1000);

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
To unsubscribe from this list: send the line "unsubscribe linux-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 02/11] power/restart: Call machine_restart instead of arm_pm_restart

[Sebastian Reichel]

Hi,

On Tue, Aug 19, 2014 at 05:45:29PM -0700, Guenter Roeck wrote:
> machine_restart is supported on non-ARM platforms, and and ultimately calls
> arm_pm_restart, so dont call arm_pm_restart directly but use the more
> generic function.
> 
> Cc: Russell King 
> Signed-off-by: Guenter Roeck 
> Acked-by: Catalin Marinas 
> Acked-by: Heiko Stuebner 

Acked-by: Sebastian Reichel 

Do you want me to take the patch via battery-2.6.git?

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v7 02/11] power/restart: Call machine_restart instead of arm_pm_restart

[Guenter Roeck]

On Thu, Aug 21, 2014 at 12:30:44PM -0700, Doug Anderson wrote:
> Guenter,
> 
> On Wed, Aug 20, 2014 at 9:42 PM, Guenter Roeck  wrote:
> > On Wed, Aug 20, 2014 at 09:10:31PM -0700, Doug Anderson wrote:
> >> Guenter,
> >>
> >> On Tue, Aug 19, 2014 at 5:45 PM, Guenter Roeck  wrote:
> >> > machine_restart is supported on non-ARM platforms, and and ultimately 
> >> > calls
> >> > arm_pm_restart, so dont call arm_pm_restart directly but use the more
> >> > generic function.
> >> >
> >> > Cc: Russell King 
> >>
> >> Do you need to submit this to his patch tracker to get him to pick it
> >> up?  How are you envisioning that this series land?  It crosses a lot
> >> of boundaries so I guess will need a reasonable amount of coordination
> >> between maintainers...
> >>
> >>
> > If I get an Acked-by: from all maintainers, I could send a pull request
> > to Linus directly. How do I send a patch to Russell's patch tracker ?
> > I thought I copied all mailing lists suggested by get_maintainer.pl,
> > but maybe I missed one.
> 
> Ah, OK.  Perhaps it's best to ignore me, then.  ;)  FYI: Russell's

No, I appreciate the information.

> Patch System is at 
> and is used for getting individual patches into branches maintained by
> Russel.  If you're just going to send a pull request for the series
> then I don't think you need it.
> 
I copied both linux-arm-kernel and Russell himself, so hopefully he is aware
of the series and can let me know if he wants me to make any further changes
to it, if it is ready to go, or if I need to do anything else.

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-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 04/29] drivers: base: add notifier for failed driver bind

[Laurent Pinchart]

Hi Marek,

Thank you for the patch.

On Tuesday 05 August 2014 12:47:32 Marek Szyprowski wrote:
> This patch adds support for getting a notify for failed device driver
> bind, so all the items done in BUS_NOTIFY_BIND_DRIVER event can be
> cleaned if the driver fails to bind.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/base/dd.c  | 10 +++---
>  include/linux/device.h |  4 +++-
>  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index e4ffbcf..541a41f 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -237,10 +237,14 @@ static int driver_sysfs_add(struct device *dev)
>   return ret;
>  }
> 
> -static void driver_sysfs_remove(struct device *dev)
> +static void driver_sysfs_remove(struct device *dev, int failed)
>  {
>   struct device_driver *drv = dev->driver;
> 
> + if (failed && dev->bus)
> + blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
> +  BUS_NOTIFY_DRVBIND_FAILED, dev);

This might be a stupid question, but as you only call driver_sysfs_remove with 
failed set to true in a single location (in the failure path of really_probe), 
how about moving the blocking_notifier_call_chain to that location ? The code 
seems to be a bit out of place here.

> +
>   if (drv) {
>   sysfs_remove_link(&drv->p->kobj, kobject_name(&dev->kobj));
>   sysfs_remove_link(&dev->kobj, "driver");
> @@ -316,7 +320,7 @@ static int really_probe(struct device *dev, struct
> device_driver *drv)
> 
>  probe_failed:
>   devres_release_all(dev);
> - driver_sysfs_remove(dev);
> + driver_sysfs_remove(dev, true);
>   dev->driver = NULL;
>   dev_set_drvdata(dev, NULL);
> 
> @@ -509,7 +513,7 @@ static void __device_release_driver(struct device *dev)
>   if (drv) {
>   pm_runtime_get_sync(dev);
> 
> - driver_sysfs_remove(dev);
> + driver_sysfs_remove(dev, false);
> 
>   if (dev->bus)
>   blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
> diff --git a/include/linux/device.h b/include/linux/device.h
> index b387710..92daded 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -176,7 +176,7 @@ extern int bus_register_notifier(struct bus_type *bus,
>  extern int bus_unregister_notifier(struct bus_type *bus,
>  struct notifier_block *nb);
> 
> -/* All 4 notifers below get called with the target struct device *
> +/* All 7 notifers below get called with the target struct device *
>   * as an argument. Note that those functions are likely to be called
>   * with the device lock held in the core, so be careful.
>   */
> @@ -189,6 +189,8 @@ extern int bus_unregister_notifier(struct bus_type *bus,
> unbound */
>  #define BUS_NOTIFY_UNBOUND_DRIVER0x0006 /* driver is unbound
> from the device */
> +#define BUS_NOTIFY_DRVBIND_FAILED0x0007 /* driver failed to bind
> +   to device */
> 
>  extern struct kset *bus_get_kset(struct bus_type *bus);
>  extern struct klist *bus_get_device_klist(struct bus_type *bus);

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 02/11] power/restart: Call machine_restart instead of arm_pm_restart

[Doug Anderson]

Guenter,

On Wed, Aug 20, 2014 at 9:42 PM, Guenter Roeck  wrote:
> On Wed, Aug 20, 2014 at 09:10:31PM -0700, Doug Anderson wrote:
>> Guenter,
>>
>> On Tue, Aug 19, 2014 at 5:45 PM, Guenter Roeck  wrote:
>> > machine_restart is supported on non-ARM platforms, and and ultimately calls
>> > arm_pm_restart, so dont call arm_pm_restart directly but use the more
>> > generic function.
>> >
>> > Cc: Russell King 
>>
>> Do you need to submit this to his patch tracker to get him to pick it
>> up?  How are you envisioning that this series land?  It crosses a lot
>> of boundaries so I guess will need a reasonable amount of coordination
>> between maintainers...
>>
>>
> If I get an Acked-by: from all maintainers, I could send a pull request
> to Linus directly. How do I send a patch to Russell's patch tracker ?
> I thought I copied all mailing lists suggested by get_maintainer.pl,
> but maybe I missed one.

Ah, OK.  Perhaps it's best to ignore me, then.  ;)  FYI: Russell's
Patch System is at 
and is used for getting individual patches into branches maintained by
Russel.  If you're just going to send a pull request for the series
then I don't think you need 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

Re: [PATCHv3] thermal: exynos: Add support for TRIM_RELOAD feature at Exynos3250

[Chanwoo Choi]

Dear Andreas,

On Thu, Aug 21, 2014 at 7:32 PM, Andreas Färber  wrote:
> Hello,
>
> Am 21.08.2014 03:38, schrieb Chanwoo Choi:
>> On 08/20/2014 10:38 PM, edubez...@gmail.com wrote:
>>> On Tue, Aug 19, 2014 at 7:52 PM, Chanwoo Choi  wrote:
 diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
 b/drivers/thermal/samsung/exynos_tmu_data.c
 index aa8e0de..8cd609c 100644
 --- a/drivers/thermal/samsung/exynos_tmu_data.c
 +++ b/drivers/thermal/samsung/exynos_tmu_data.c
 @@ -95,6 +95,8 @@ static const struct exynos_tmu_registers 
 exynos3250_tmu_registers = {
 .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
 .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
 .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
 +   .triminfo_ctrl[0] = EXYNOS_TMU_TRIMINFO_CON1,
 +   .triminfo_ctrl[1] = EXYNOS_TMU_TRIMINFO_CON2,
 .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
 .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
 .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
 @@ -160,8 +162,11 @@ static const struct exynos_tmu_registers 
 exynos3250_tmu_registers = {
 .temp_level = 95, \
 }, \
 .freq_tab_count = 2, \
 +   .triminfo_reload[0] = 0x1, \
 +   .triminfo_reload[1] = 0x11, \
>>>
>>> What does 0x1 mean? How about 0x11?
>>
>> The bit of 'RELOAD' field in TRIMINFO_CONTROL register is [0].
>> and The bit of 'AC Time' field in TRIMINFO_CONTROL register is [5:4].
>>
>> 0x1 means that set RELOAD field.
>> 0x11 means that set RELOAD field and ACTIME field.
>
> Might be a good idea to use #defines for 0x1 and 0x10 then?

I agree. I'm implementing it to use 'define' keyword.

Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-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 3/4] ARM: EXYNOS: Add platform driver support for Exynos PMU

[Tomasz Figa]

On 21.08.2014 16:07, Pankaj Dubey wrote:
> +Arnd, Lee Jones
> 
> Hi Tomasz,
> 
> On Tuesday, August 19, 2014 Tomasz Figa wrote:
> 
>>
>> Hi Bart,
>>
>> On 18.08.2014 19:42, Bartlomiej Zolnierkiewicz wrote:
>>>
>>> Hi,
>>>
>>> On Monday, July 28, 2014 08:40:52 AM Pankaj Dubey wrote:
 Hi Tomasz,

 On Friday, July 25, 2014 Tomasz Figa wrote:

> To: Pankaj Dubey; 'Kukjin Kim';
> linux-arm-ker...@lists.infradead.org;
 linux-
> samsung-...@vger.kernel.org; linux-ker...@vger.kernel.org
> Cc: li...@arm.linux.org.uk; t.f...@samsung.com;
> vikas.saj...@samsung.com; jo...@samsung.com; naus...@samsung.com;
> thomas...@samsung.com; chow@samsung.com
> Subject: Re: [PATCH v7 3/4] ARM: EXYNOS: Add platform driver support
> for Exynos PMU
>
> Hi Pankaj, Kukjin,
>
> On 25.07.2014 07:32, Pankaj Dubey wrote:
>> Hi Kukjin,
>>
>> On Friday, July 25, 2014 Kukjin Kim wrote:
>
> [snip]
>

>>> Looks good to me, will apply this and 4/4.
>>>
>>
>> We need to hold these two patches until dependent patch [1] from
>> Tomasz Figa gets merged.
>>
>> [1]: mfd: syscon: Decouple syscon interface from syscon devices
>>   https://lkml.org/lkml/2014/6/24/188
>
> That RFC patch had few comments from Arnd needed to be addressed, so
> it
 needs a
> new revision.
>
> Pankaj, If I remember correctly, we had talked about this and the
 conclusion was that
> you would take care of addressing the comments and sending new
> version of
 the
> patch. Any update on this or have I missed something?
>

 Well, I don't think we concluded as such anything.
 Since this patch needs to get in so that Exynos PMU and PM related
 changes can go in, I discussed with you saying that I am not able to
 understand about Arnd's comments and if possible and time permits I
 will look into it. Meanwhile I got busy with some other official
 work, so could not get time to look into it.
>>>
>>> Tomasz/Pankaj, could we please get some agreement on what needs to be
>>> done and who should do the pending work?
>>>
>>> syscon patch is blocking PMU cleanup patches which in turn are
>>> blocking PMU support additions for new SoCs (Exynos5420/5800 and
>>> Exynos3250 PMU patches).
>>
>> Leaving alone the matter who is going to take care of it for now, the
> remaining work
>> to do is to further decouple syscon from struct device, which means
> providing of_
>> API to register a syscon provider on a device tree node even before driver
> model is
>> available yet.
>>
> 
> As per Arnd's comment on your RFC patch he mentioned -
> "I believe the part you are missing is that with the approach I suggested,
> there would be no registration function at all."
> 
> I think he is not in favor of adding such registration function at all. So
> do you think
> adding such function will really solve the problem?
> 
> Further even Lee Jones agreed to Arnd's point of making syscon independent
> of device,
> but he also mentioned that it can be done in subsequent patch.

Let's look again at the original thread then...

I believe Lee agreed with my proposed solution or at least he quoted my
e-mail and pointed that further work addressing Arnd's comments could be
done in follow up patches. I also think that we should rather make one
step as a time, especially this patch is required for further clean-up
of Exynos.

However there was also a reply from Michal Simek, which pointed out that
even with my patch the syscon is still bound to driver model and for his
use case he would need a purely OF-based version of the API. That's why
I think my patch should be re-spun with changes I mentioned in my
previous message in this thread.

>   
> So in IMHO, your RFC patch can be taken as is, and any further improvement
> suggested
> by Arnd can be done in subsequent patches,  because as I can see in 3.17-rc1
> still
> has user of syscon_regmap_lookup_by_pdevname (clps711x.c) so we can't
> completely
> make it independent of platform_device as of now and also the changes
> required
> as per Arnd's suggestions requires considerable effort and time.

Agreed. However we can still provide OF-only syscon registration
function and modify look-up functions to allow syscons without struct
device pointer, just with OF node.

Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 0/4] Fine tune USB 3.0 PHY on exynos5420

[Vivek Gautam]

This series is based on Heikki's patches for simpliefied phy lookup table:
[PATCHv3 0/6] phy: simplified phy lookup [1], applied against 'usb-next' branch
alongwith Sergei's patch for adding generic phy support to usb hcd [2].

Changes since v4:
 - Rebased on latest patches by Heikki.
 - Took care of handling -EPROBE_DEFER error number while getting PHY in
   xhci plat.

Changes from v3:
 - Modified error message as per review comments from Julius.

Changes since v2:
 - Removed any check for DWC3 in xhci-plat for getting usb2-phy and usb3-phy,
   in order to make it more generic.
 - Moved the phy_calibration calls to core/hcd.c to enable a more generic
   solution for issues of calibrating the PHYs.

Changes since v1:
 - Using 'gen_phy' member of 'hcd' instead of declaring more variables
   to hold phys.
 - Added a check for compatible match for 'Synopsys-dwc3' controller,
   since the 'gen_phy' member of 'hcd' already gets the 'usb' PHY
   in core/hcd.c; but XHCI on Synopsys-dwc3 doesn't need that,
   instead two separate PHYs for UTMI+ and PIPE3 for the two HCDs
   (main hcd and shared hcd).
 - Restructured the code in 'xhci_plat_setup()' and 'xhci_plat_resume()'
   to use hcd->gen_phy directly. Also added the check for Synopsys's DWC3
   controller while trying to calibrate the PHY.

Explanation for the need of this patch-series:
"The DWC3-exynos eXtensible host controller present on Exynos5420/5800
SoCs is quirky. The PHY serving this controller operates at High-Speed
by default, so it detects even Super-speed devices as high-speed ones.
Certain PHY parameters like Tx LOS levels and Boost levels need to be
calibrated further post initialization of xHCI controller, to get
SuperSpeed operations working."

[1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg710094.html
[2] http://comments.gmane.org/gmane.linux.ports.sh.devel/35932

Vivek Gautam (4):
  phy: Add provision for calibrating phy.
  usb: host: xhci-plat: Get PHYs for xhci's hcds
  usb: hcd: Caibrate PHY post hcd reset
  phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

 drivers/phy/phy-core.c   |   36 
 drivers/phy/phy-exynos5-usbdrd.c |  169 ++
 drivers/usb/core/hcd.c   |   22 +
 drivers/usb/host/xhci-plat.c |   23 ++
 include/linux/phy/phy.h  |8 ++
 5 files changed, 258 insertions(+)

-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 1/4] phy: Add provision for calibrating phy.

[Vivek Gautam]

Some PHY controllers may need to calibrate certain
PHY settings after initialization of the controller and
sometimes even after initializing the PHY-consumer too.
Add support for the same in order to let consumers do so in need.

Signed-off-by: vivek Gautam 
---
 drivers/phy/phy-core.c  |   36 
 include/linux/phy/phy.h |8 
 2 files changed, 44 insertions(+)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 834b337..c8cb3de 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -393,6 +393,42 @@ int phy_power_off(struct phy *phy)
 EXPORT_SYMBOL_GPL(phy_power_off);
 
 /**
+ * phy_calibrate - calibrate a phy post initialization
+ * @phy: Pointer to 'phy' from consumer
+ *
+ * For certain PHYs, it may be needed to calibrate few phy parameters
+ * post initialization. The need to calibrate may arise after the
+ * initialization of consumer itself, in order to prevent further any
+ * loss of phy settings post consumer-initialization.
+ * example: USB 3.0 DRD PHY on Exynos5420/5800 systems is one such
+ * phy which needs calibration after the host controller reset
+ * has happened.
+ */
+int phy_calibrate(struct phy *phy)
+{
+   int ret = -ENOTSUPP;
+
+   if (!phy)
+   return 0;
+
+   mutex_lock(&phy->mutex);
+   if (phy->ops->calibrate) {
+   ret =  phy->ops->calibrate(phy);
+   if (ret < 0) {
+   dev_err(&phy->dev,
+   "phy calibration failed --> %d\n", ret);
+   goto out;
+   }
+   }
+
+out:
+   mutex_unlock(&phy->mutex);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(phy_calibrate);
+
+/**
  * _of_phy_get() - lookup and obtain a reference to a phy by phandle
  * @np: device_node for which to get the phy
  * @index: the index of the phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index d983051..c70a311 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -28,6 +28,7 @@ struct phy;
  * @exit: operation to be performed while exiting
  * @power_on: powering on the phy
  * @power_off: powering off the phy
+ * @calibrate: calibrate the phy post init
  * @owner: the module owner containing the ops
  */
 struct phy_ops {
@@ -35,6 +36,7 @@ struct phy_ops {
int (*exit)(struct phy *phy);
int (*power_on)(struct phy *phy);
int (*power_off)(struct phy *phy);
+   int (*calibrate)(struct phy *phy);
struct module *owner;
 };
 
@@ -126,6 +128,7 @@ int phy_init(struct phy *phy);
 int phy_exit(struct phy *phy);
 int phy_power_on(struct phy *phy);
 int phy_power_off(struct phy *phy);
+int phy_calibrate(struct phy *phy);
 static inline int phy_get_bus_width(struct phy *phy)
 {
return phy->attrs.bus_width;
@@ -231,6 +234,11 @@ static inline int phy_power_off(struct phy *phy)
return -ENOSYS;
 }
 
+static inline int phy_calibrate(struct phy *phy)
+{
+   return -ENOSYS;
+}
+
 static inline int phy_get_bus_width(struct phy *phy)
 {
return -ENOSYS;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds

[Vivek Gautam]

The host controller by itself may sometimes need to handle PHY
and/or calibrate some of the PHY settings to get full support out
of the PHY controller. The PHY core provides a calibration
funtionality now to do so.
Therefore, facilitate getting the two possible PHYs, viz.
USB 2.0 type (UTMI+) and USB 3.0 type (PIPE3).

Signed-off-by: Vivek Gautam 
---
 drivers/usb/host/xhci-plat.c |   23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 1a0cf9f..56ef9cf 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -180,6 +181,17 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto put_hcd;
}
 
+   /* Get possile USB 2.0 type PHY (UTMI+) available with xhci */
+   hcd->gen_phy = devm_phy_get(&pdev->dev, "usb2-phy");
+   if (IS_ERR(hcd->gen_phy)) {
+   ret = PTR_ERR(hcd->gen_phy);
+   if (ret == -EPROBE_DEFER)
+   return ret;
+   else if (ret != -ENOSYS && ret != -ENODEV)
+   dev_warn(&pdev->dev,
+"Error retrieving usb2 phy: %d\n", ret);
+   }
+
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto disable_clk;
@@ -209,6 +221,17 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
xhci->shared_hcd->can_do_streams = 1;
 
+   /* Get possile USB 3.0 type PHY (PIPE3) available with xhci */
+   xhci->shared_hcd->gen_phy = devm_phy_get(&pdev->dev, "usb3-phy");
+   if (IS_ERR(xhci->shared_hcd->gen_phy)) {
+   ret = PTR_ERR(xhci->shared_hcd->gen_phy);
+   if (ret == -EPROBE_DEFER)
+   return ret;
+   else if (ret != -ENOSYS && ret != -ENODEV)
+   dev_warn(&pdev->dev,
+"Error retrieving usb3 phy: %d\n", ret);
+   }
+
ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
if (ret)
goto put_usb3_hcd;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 3/4] usb: hcd: Caibrate PHY post hcd reset

[Vivek Gautam]

Some quirky PHYs may require to be calibrated post the
hcd initialization.
The USB 3.0 DRD PHY on Exynos5420/5800 systems, coming along
with Synopsys's DWC3 controller, is one such PHY which needs
to be calibrated post xhci's reset at initialization time and
at resume time, to get the controller work at SuperSpeed.
So facilitating the HCDs to calibrate the PHY.

Signed-off-by: Vivek Gautam 
---
 drivers/usb/core/hcd.c |   22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index c4ed66c..a42b448 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2202,6 +2202,7 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t 
msg)
struct usb_hcd  *hcd = container_of(rhdev->bus, struct usb_hcd, self);
int status;
int old_state = hcd->state;
+   int ret;
 
dev_dbg(&rhdev->dev, "usb %sresume\n",
(PMSG_IS_AUTO(msg) ? "auto-" : ""));
@@ -2216,6 +2217,17 @@ int hcd_bus_resume(struct usb_device *rhdev, 
pm_message_t msg)
 
hcd->state = HC_STATE_RESUMING;
status = hcd->driver->bus_resume(hcd);
+
+   /* calibrate the phy here */
+   if (!IS_ERR(hcd->gen_phy)) {
+   ret = phy_calibrate(hcd->gen_phy);
+   if (ret < 0 && ret != -ENOTSUPP) {
+   dev_err(hcd->self.controller,
+   "failed to calibrate USB PHY\n");
+   return ret;
+   }
+   }
+
clear_bit(HCD_FLAG_WAKEUP_PENDING, &hcd->flags);
if (status == 0) {
struct usb_device *udev;
@@ -2738,6 +2750,16 @@ int usb_add_hcd(struct usb_hcd *hcd,
}
hcd->rh_pollable = 1;
 
+   /* calibrate the phy here */
+   if (!IS_ERR(hcd->gen_phy)) {
+   retval = phy_calibrate(hcd->gen_phy);
+   if (retval < 0 && retval != -ENOTSUPP) {
+   dev_err(hcd->self.controller,
+   "failed to calibrate USB PHY\n");
+   return retval;
+   }
+   }
+
/* NOTE: root hub and controller capabilities may not be the same */
if (device_can_wakeup(hcd->self.controller)
&& device_can_wakeup(&hcd->self.root_hub->dev))
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

[Vivek Gautam]

Adding phy calibrate callback, which facilitates setting certain
PHY settings post initialization of the PHY controller.
Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which
the Loss-of-Signal (LOS) Detector Threshold Level as well as
Tx-Vboost-Level should be controlled for Super-Speed operations.

Additionally set proper time to wait for RxDetect measurement,
for desired PHY reference clock, so as to solve issue with enumeration
of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive
on the controller.
We are using CR_port for this purpose to send required data
to override the LOS values.

On testing with USB 3.0 devices on USB 3.0 port present on
SMDK5420, and peach-pit boards should see following message:
usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd

and without this patch, should see below shown message:
usb 1-1: new high-speed USB device number 2 using xhci-hcd

Signed-off-by: Vivek Gautam 
---
 drivers/phy/phy-exynos5-usbdrd.c |  169 ++
 1 file changed, 169 insertions(+)

diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index 47f47fe..fa13784 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -89,8 +89,20 @@
 #define PHYCLKRST_COMMONONNBIT(0)
 
 #define EXYNOS5_DRD_PHYREG00x14
+
+#define EXYNOS5_DRD_PHYREG0_SSC_REF_CLK_SELBIT(21)
+#define EXYNOS5_DRD_PHYREG0_SSC_RANGE  BIT(20)
+#define EXYNOS5_DRD_PHYREG0_CR_WRITE   BIT(19)
+#define EXYNOS5_DRD_PHYREG0_CR_READBIT(18)
+#define EXYNOS5_DRD_PHYREG0_CR_DATA_IN(_x) ((_x) << 2)
+#define EXYNOS5_DRD_PHYREG0_CR_CAP_DATABIT(1)
+#define EXYNOS5_DRD_PHYREG0_CR_CAP_ADDRBIT(0)
+
 #define EXYNOS5_DRD_PHYREG10x18
 
+#define EXYNOS5_DRD_PHYREG1_CR_DATA_OUT(_x)((_x) << 1)
+#define EXYNOS5_DRD_PHYREG1_CR_ACK BIT(0)
+
 #define EXYNOS5_DRD_PHYPARAM0  0x1c
 
 #define PHYPARAM0_REF_USE_PAD  BIT(31)
@@ -118,6 +130,26 @@
 #define EXYNOS5_DRD_PHYRESUME  0x34
 #define EXYNOS5_DRD_LINKPORT   0x44
 
+/* USB 3.0 DRD PHY SS Function Control Reg; accessed by CR_PORT */
+#define EXYNOS5_DRD_PHYSS_LOSLEVEL_OVRD_IN (0x15)
+
+#define LOSLEVEL_OVRD_IN_LOS_BIAS_5420 (0x5 << 13)
+#define LOSLEVEL_OVRD_IN_LOS_BIAS_DEFAULT  (0x0 << 13)
+#define LOSLEVEL_OVRD_IN_EN(0x1 << 10)
+#define LOSLEVEL_OVRD_IN_LOS_LEVEL_DEFAULT (0x9 << 0)
+
+#define EXYNOS5_DRD_PHYSS_TX_VBOOSTLEVEL_OVRD_IN   (0x12)
+#define TX_VBOOSTLEVEL_OVRD_IN_VBOOST_5420 (0x5 << 13)
+#define TX_VBOOSTLEVEL_OVRD_IN_VBOOST_DEFAULT  (0x4 << 13)
+
+#define EXYNOS5_DRD_PHYSS_LANE0_TX_DEBUG   (0x1010)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_19M2_20M(0x4 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_24M (0x8 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_25M_26M (0x8 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_48M_50M_52M (0x20 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_62M5(0x20 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_96M_100M(0x40 << 4)
+
 #define KHZ1000
 #define MHZ(KHZ * KHZ)
 
@@ -135,12 +167,14 @@ struct exynos5_usbdrd_phy_config {
void (*phy_isol)(struct phy_usb_instance *inst, u32 on);
void (*phy_init)(struct exynos5_usbdrd_phy *phy_drd);
unsigned int (*set_refclk)(struct phy_usb_instance *inst);
+   int (*phy_calibrate)(struct phy_usb_instance *inst);
 };
 
 struct exynos5_usbdrd_phy_drvdata {
const struct exynos5_usbdrd_phy_config *phy_cfg;
u32 pmu_offset_usbdrd0_phy;
u32 pmu_offset_usbdrd1_phy;
+   void (*calibrate)(struct exynos5_usbdrd_phy *phy_drd);
 };
 
 /**
@@ -487,6 +521,138 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
return 0;
 }
 
+static void crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
+   u32 val, u32 cmd)
+{
+   u32 usec = 100;
+   u32 result;
+
+   writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
+
+   do {
+   result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
+   if (result & EXYNOS5_DRD_PHYREG1_CR_ACK)
+   break;
+
+   udelay(1);
+   } while (usec-- > 0);
+
+   if (!usec)
+   dev_err(phy_drd->dev,
+   "CRPORT handshake timeout1 (0x%08x)\n", val);
+
+   usec = 100;
+
+   writel(val, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
+
+   do {
+   result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
+   if (!(result & EXYNOS5_DRD_PHYREG1_CR_ACK))
+   break;
+
+   udelay(1);
+   } while (usec-- > 0);
+
+   if (!usec)
+   dev_err(phy_drd->dev

Re: [RESEND PATCH 5/7] mfd: cros_ec: wait for completion of commands that return IN_PROGRESS

[Lee Jones]

On Wed, 20 Aug 2014, Javier Martinez Canillas wrote:

> From: Andrew Bresticker 
> 
> When an EC command returns EC_RES_IN_PROGRESS, we need to query
> the state of the EC until it indicates that it is no longer busy.
> Do this in cros_ec_cmd_xfer() under the EC's mutex so that other
> commands (e.g. keyboard, I2C passtru) aren't issued to the EC while
> it is working on the in-progress command.
> 
> Signed-off-by: Andrew Bresticker 
> Reviewed-by: Simon Glass 
> Signed-off-by: Javier Martinez Canillas 
> ---
>  drivers/mfd/cros_ec.c | 35 ++-
>  1 file changed, 34 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index c53804a..634c434 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -23,6 +23,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +#define EC_COMMAND_RETRIES   50
> +#define EC_RETRY_DELAY_MS10
>  
>  int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
>  struct cros_ec_command *msg)
> @@ -65,10 +69,39 @@ EXPORT_SYMBOL(cros_ec_check_result);
>  int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
>struct cros_ec_command *msg)
>  {
> - int ret;
> + int ret, i;
>  
>   mutex_lock(&ec_dev->lock);
>   ret = ec_dev->cmd_xfer(ec_dev, msg);
> + if (ret == -EAGAIN && msg->result == EC_RES_IN_PROGRESS) {
> + /*
> +  * Query the EC's status until it's no longer busy or
> +  * we encounter an error.
> +  */
> + for (i = 0; i < EC_COMMAND_RETRIES; i++) {
> + struct cros_ec_command status_msg;
> + struct ec_response_get_comms_status status;
> +
> + msleep(EC_RETRY_DELAY_MS);
> +
> + status_msg.version = 0;
> + status_msg.command = EC_CMD_GET_COMMS_STATUS;
> + status_msg.outdata = NULL;
> + status_msg.outsize = 0;
> + status_msg.indata = (uint8_t *)&status;
> + status_msg.insize = sizeof(status);
> +
> + ret = ec_dev->cmd_xfer(ec_dev, &status_msg);
> + if (ret < 0)
> + break;
> +
> + msg->result = status_msg.result;
> + if (status_msg.result != EC_RES_SUCCESS)
> + break;
> + if (!(status.flags & EC_COMMS_STATUS_PROCESSING))
> + break;
> + }
> + }

Wow!  Things just got ugly real fast.

Do the *xfer() calls fiddle with msg passed into cros_ec_cmd_xfer()?
If not, why is it necessary to keep populating it?

If all this stuff is necessary (and I really hope that it's not) I
think it would be better to have the for() loop as the outer layer.
Then we only have one instance of cmd_xfer() invocation and we save a
layer of tabbing. 

>   mutex_unlock(&ec_dev->lock);
>  
>   return ret;

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH 6/7] mfd: cros_ec: Instantiate sub-devices from device tree

[Lee Jones]

On Wed, 20 Aug 2014, Javier Martinez Canillas wrote:

> From: Todd Broch 
> 
> If the EC device tree node has sub-nodes, try to instantiate them as
> MFD sub-devices.  We can configure the EC features provided by the board.
> 
> Signed-off-by: Todd Broch 
> Signed-off-by: Javier Martinez Canillas 
> ---
>  drivers/mfd/cros_ec.c | 40 ++--
>  1 file changed, 30 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index 634c434..96c926c 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -109,22 +110,16 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
>  EXPORT_SYMBOL(cros_ec_cmd_xfer);
>  
>  static const struct mfd_cell cros_devs[] = {
> - {
> - .name = "cros-ec-keyb",
> - .id = 1,
> - .of_compatible = "google,cros-ec-keyb",
> - },
> - {
> - .name = "cros-ec-i2c-tunnel",
> - .id = 2,
> - .of_compatible = "google,cros-ec-i2c-tunnel",
> - },
>  };

Why are you keeping this round if it's empty?

>  int cros_ec_register(struct cros_ec_device *ec_dev)
>  {
>   struct device *dev = ec_dev->dev;
>   int err = 0;
> +#ifdef CONFIG_OF
> + struct device_node *node;
> + int id = ARRAY_SIZE(cros_devs);
> +#endif
>  
>   if (ec_dev->din_size) {
>   ec_dev->din = devm_kzalloc(dev, ec_dev->din_size, GFP_KERNEL);
> @@ -146,6 +141,31 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
>   dev_err(dev, "failed to add mfd devices\n");
>   return err;
>   }
> +#ifdef CONFIG_OF
> + /*
> +  * Add sub-devices declared in the device tree.  NOTE they should NOT be
> +  * declared in cros_devs
> +  */
> + for_each_child_of_node(dev->of_node, node) {
> + char name[128];
> + struct mfd_cell cell = {
> + .id = 0,
> + .name = name,
> + };
> +
> + if (of_modalias_node(node, name, sizeof(name)) < 0) {
> + dev_err(dev, "modalias failure on %s\n",
> + node->full_name);
> + continue;
> + }
> + dev_dbg(dev, "adding MFD sub-device %s\n", node->name);
> + cell.of_compatible = of_get_property(node, "compatible", NULL);
> + err = mfd_add_devices(dev, ++id, &cell, 1, NULL, ec_dev->irq,
> +   NULL);
> + if (err)
> + dev_err(dev, "fail to add %s\n", node->full_name);
> + }
> +#endif

This is grim!

Why don't you use of_platform_populate()?

>   dev_info(dev, "Chrome EC device registered\n");
>  

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH 4/7] mfd: cros_ec: move locking into cros_ec_cmd_xfer

[Lee Jones]

On Wed, 20 Aug 2014, Javier Martinez Canillas wrote:

> From: Andrew Bresticker 
> 
> Now that there's a central cros_ec_cmd_xfer(), move the locking
> out of the SPI and LPC drivers.
> 
> Signed-off-by: Andrew Bresticker 
> Reviewed-by: Simon Glass 
> Signed-off-by: Javier Martinez Canillas 
> ---
>  drivers/mfd/cros_ec.c | 10 +-
>  drivers/mfd/cros_ec_spi.c | 11 ---
>  2 files changed, 9 insertions(+), 12 deletions(-)

Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH 3/7] mfd: cros_ec: stop calling ->cmd_xfer() directly

[Lee Jones]

On Wed, 20 Aug 2014, Javier Martinez Canillas wrote:

> From: Andrew Bresticker 
> 
> Instead of having users of the ChromeOS EC call the interface-specific
> cmd_xfer() callback directly, introduce a central cros_ec_cmd_xfer()
> to use instead.  This will allow us to put all the locking and retry
> logic in one place instead of duplicating it across the different
> drivers.
> 
> Signed-off-by: Andrew Bresticker 
> Reviewed-by: Simon Glass 
> Signed-off-by: Javier Martinez Canillas 
> ---
>  drivers/i2c/busses/i2c-cros-ec-tunnel.c |  2 +-
>  drivers/input/keyboard/cros_ec_keyb.c   |  2 +-
>  drivers/mfd/cros_ec.c   |  7 +++
>  include/linux/mfd/cros_ec.h | 24 ++--
>  4 files changed, 27 insertions(+), 8 deletions(-)

Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v7 3/4] ARM: EXYNOS: Add platform driver support for Exynos PMU

[Pankaj Dubey]

+Arnd, Lee Jones

Hi Tomasz,

On Tuesday, August 19, 2014 Tomasz Figa wrote:

> 
> Hi Bart,
> 
> On 18.08.2014 19:42, Bartlomiej Zolnierkiewicz wrote:
> >
> > Hi,
> >
> > On Monday, July 28, 2014 08:40:52 AM Pankaj Dubey wrote:
> >> Hi Tomasz,
> >>
> >> On Friday, July 25, 2014 Tomasz Figa wrote:
> >>
> >>> To: Pankaj Dubey; 'Kukjin Kim';
> >>> linux-arm-ker...@lists.infradead.org;
> >> linux-
> >>> samsung-...@vger.kernel.org; linux-ker...@vger.kernel.org
> >>> Cc: li...@arm.linux.org.uk; t.f...@samsung.com;
> >>> vikas.saj...@samsung.com; jo...@samsung.com; naus...@samsung.com;
> >>> thomas...@samsung.com; chow@samsung.com
> >>> Subject: Re: [PATCH v7 3/4] ARM: EXYNOS: Add platform driver support
> >>> for Exynos PMU
> >>>
> >>> Hi Pankaj, Kukjin,
> >>>
> >>> On 25.07.2014 07:32, Pankaj Dubey wrote:
>  Hi Kukjin,
> 
>  On Friday, July 25, 2014 Kukjin Kim wrote:
> >>>
> >>> [snip]
> >>>
> >>
> > Looks good to me, will apply this and 4/4.
> >
> 
>  We need to hold these two patches until dependent patch [1] from
>  Tomasz Figa gets merged.
> 
>  [1]: mfd: syscon: Decouple syscon interface from syscon devices
>    https://lkml.org/lkml/2014/6/24/188
> >>>
> >>> That RFC patch had few comments from Arnd needed to be addressed, so
> >>> it
> >> needs a
> >>> new revision.
> >>>
> >>> Pankaj, If I remember correctly, we had talked about this and the
> >> conclusion was that
> >>> you would take care of addressing the comments and sending new
> >>> version of
> >> the
> >>> patch. Any update on this or have I missed something?
> >>>
> >>
> >> Well, I don't think we concluded as such anything.
> >> Since this patch needs to get in so that Exynos PMU and PM related
> >> changes can go in, I discussed with you saying that I am not able to
> >> understand about Arnd's comments and if possible and time permits I
> >> will look into it. Meanwhile I got busy with some other official
> >> work, so could not get time to look into it.
> >
> > Tomasz/Pankaj, could we please get some agreement on what needs to be
> > done and who should do the pending work?
> >
> > syscon patch is blocking PMU cleanup patches which in turn are
> > blocking PMU support additions for new SoCs (Exynos5420/5800 and
> > Exynos3250 PMU patches).
> 
> Leaving alone the matter who is going to take care of it for now, the
remaining work
> to do is to further decouple syscon from struct device, which means
providing of_
> API to register a syscon provider on a device tree node even before driver
model is
> available yet.
> 

As per Arnd's comment on your RFC patch he mentioned -
"I believe the part you are missing is that with the approach I suggested,
there would be no registration function at all."

I think he is not in favor of adding such registration function at all. So
do you think
adding such function will really solve the problem?

Further even Lee Jones agreed to Arnd's point of making syscon independent
of device,
but he also mentioned that it can be done in subsequent patch.
  
So in IMHO, your RFC patch can be taken as is, and any further improvement
suggested
by Arnd can be done in subsequent patches,  because as I can see in 3.17-rc1
still
has user of syscon_regmap_lookup_by_pdevname (clps711x.c) so we can't
completely
make it independent of platform_device as of now and also the changes
required
as per Arnd's suggestions requires considerable effort and time.

> I believe it should be quite straightforward on top of my RFC and should
require only
> saving syscon's of_node directly in syscon struct, adding appropriate API
and
> extending the look-up loops to handle cases when syscon's dev is NULL.
> 
> Best regards,
> Tomasz

Thanks,
Pankaj Dubey

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH 1/7] mfd: cros_ec: Delay for 50ms when we see EC_CMD_REBOOT_EC

[Javier Martinez Canillas]

Hello Lee,

On 08/21/2014 03:37 PM, Lee Jones wrote:
> On Wed, 20 Aug 2014, Javier Martinez Canillas wrote:
>> From: Doug Anderson 
>> 
>> If someone sends a EC_CMD_REBOOT_EC to the EC, the EC will likely be
>> unresponsive for quite a while.  Add a delay to the end of the command
>> to prevent random failures of future commands.
>> 
>> NOTES:
>> * This could be optimized a bit by simply delaying the next command
>>   sent, but EC_CMD_REBOOT_EC is such a rare command that the extra
>>   complexity doesn't seem worth it.
>> * This is a bit of an "ugly hack" since the SPI driver is effectively
>>   snooping on the communication and making a lot of assumptions.  It
>>   would be nice to architect in some better solution long term.
> 
> Are you planning on doing that?
> 

Yes, I'll add to my TO-DO list to look how better solve this after the
remaining functionality that is present in downstream but is still not in
mainline gets merged.

>> * This same logic probably needs to be applied to the i2c driver.
>> 
>> Signed-off-by: Doug Anderson 
>> Reviewed-by: Randall Spangler 
>> Reviewed-by: Vadim Bendebury 
>> Signed-off-by: Javier Martinez Canillas 
>> ---
>>  drivers/mfd/cros_ec_spi.c | 9 +
>>  1 file changed, 9 insertions(+)
> 
> I'm willing to accept this as a stand-in.
> 

Thanks.

> Acked-by: Lee Jones 
> 

Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-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 1/7] mfd: cros_ec: Delay for 50ms when we see EC_CMD_REBOOT_EC

[Lee Jones]

On Wed, 20 Aug 2014, Javier Martinez Canillas wrote:
> From: Doug Anderson 
> 
> If someone sends a EC_CMD_REBOOT_EC to the EC, the EC will likely be
> unresponsive for quite a while.  Add a delay to the end of the command
> to prevent random failures of future commands.
> 
> NOTES:
> * This could be optimized a bit by simply delaying the next command
>   sent, but EC_CMD_REBOOT_EC is such a rare command that the extra
>   complexity doesn't seem worth it.
> * This is a bit of an "ugly hack" since the SPI driver is effectively
>   snooping on the communication and making a lot of assumptions.  It
>   would be nice to architect in some better solution long term.

Are you planning on doing that?

> * This same logic probably needs to be applied to the i2c driver.
> 
> Signed-off-by: Doug Anderson 
> Reviewed-by: Randall Spangler 
> Reviewed-by: Vadim Bendebury 
> Signed-off-by: Javier Martinez Canillas 
> ---
>  drivers/mfd/cros_ec_spi.c | 9 +
>  1 file changed, 9 insertions(+)

I'm willing to accept this as a stand-in.

Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/3] ARM: exynos: Add exynos5800-pmu compatible entry

[Vikas Sajjan]

Adds exynos5800-pmu compatible string entry in the pmu table.

Signed-off-by: Vikas Sajjan 
---
 arch/arm/mach-exynos/exynos.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 6a24e11..90377c9 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -255,6 +255,7 @@ static const struct of_device_id exynos_dt_pmu_match[] = {
{ .compatible = "samsung,exynos5260-pmu" },
{ .compatible = "samsung,exynos5410-pmu" },
{ .compatible = "samsung,exynos5420-pmu" },
+   { .compatible = "samsung,exynos5800-pmu" },
{ /*sentinel*/ },
 };
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/3] ARM: exynos: Add PMU and S2R support for exynos5800 SoC

[Vikas Sajjan]

Adds PMU and S2R support for exynos5800 SoC.

Signed-off-by: Vikas Sajjan 
---
 arch/arm/mach-exynos/pm.c   |3 +++
 arch/arm/mach-exynos/pmu.c  |   22 ++
 arch/arm/mach-exynos/regs-pmu.h |3 ++-
 3 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index acdcf0b..41fc1c3 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -646,6 +646,9 @@ static struct of_device_id exynos_pmu_of_device_ids[] = {
}, {
.compatible = "samsung,exynos5420-pmu",
.data = &exynos5420_pm_data,
+   }, {
+   .compatible = "samsung,exynos5800-pmu",
+   .data = &exynos5420_pm_data,
},
{ /*sentinel*/ },
 };
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index f8ced42..c1cd31c 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -719,6 +719,19 @@ static void exynos5420_pmu_init(void)
pr_info("EXYNOS5420 PMU initialized\n");
 }
 
+static void exynos5800_pmu_init(void)
+{
+   unsigned int value;
+
+   exynos5420_pmu_init();
+
+   value = pmu_raw_readl(EXYNOS5420_LPI_MASK);
+   value |= EXYNOS5800_POWER_GATE_CTRL;
+   pmu_raw_writel(value, EXYNOS5420_LPI_MASK);
+
+   pr_info("EXYNOS5800 PMU initialized\n");
+}
+
 
 static const struct exynos_pmu_data exynos4210_pmu_data = {
.pmu_config = exynos4210_pmu_config,
@@ -745,6 +758,12 @@ static struct exynos_pmu_data exynos5420_pmu_data = {
.powerdown_conf = exynos5420_powerdown_conf,
 };
 
+static struct exynos_pmu_data exynos5800_pmu_data = {
+   .pmu_config = exynos5420_pmu_config,
+   .pmu_init   = exynos5800_pmu_init,
+   .powerdown_conf = exynos5420_powerdown_conf,
+};
+
 static const struct regmap_config pmu_regmap_config = {
.reg_bits = 32,
.val_bits = 32,
@@ -770,6 +789,9 @@ static const struct of_device_id exynos_pmu_of_device_ids[] 
= {
}, {
.compatible = "samsung,exynos5420-pmu",
.data = &exynos5420_pmu_data,
+   }, {
+   .compatible = "samsung,exynos5800-pmu",
+   .data = &exynos5800_pmu_data,
},
{ /*sentinel*/ },
 };
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 3a6a559..3a0140c 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -555,5 +555,6 @@ static inline unsigned int exynos_pmu_cpunr(unsigned int 
mpidr)
 | EXYNOS5420_KFC_USE_STANDBY_WFI1  \
 | EXYNOS5420_KFC_USE_STANDBY_WFI2  \
 | EXYNOS5420_KFC_USE_STANDBY_WFI3)
-
+/* for exynos5800 only */
+#define EXYNOS5800_POWER_GATE_CTRL  (1 << 15)
 #endif /* __ASM_ARCH_REGS_PMU_H */
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/3] ARM: dts: Add pmu node for exynos5800 SoC

[Vikas Sajjan]

Adds pmu node for exynos5800 SoC.

Signed-off-by: Vikas Sajjan 
---
 .../devicetree/bindings/arm/samsung/pmu.txt|1 +
 arch/arm/boot/dts/exynos5800.dtsi  |4 
 2 files changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt 
b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
index 1e1979b..9647317 100644
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -10,6 +10,7 @@ Properties:
   - "samsung,exynos5260-pmu" - for Exynos5260 SoC.
   - "samsung,exynos5410-pmu" - for Exynos5410 SoC,
   - "samsung,exynos5420-pmu" - for Exynos5420 SoC.
+  - "samsung,exynos5800-pmu" - for Exynos5800 SoC.
second value must be always "syscon".
 
  - reg : offset and length of the register set.
diff --git a/arch/arm/boot/dts/exynos5800.dtsi 
b/arch/arm/boot/dts/exynos5800.dtsi
index c0bb356..2009b9c 100644
--- a/arch/arm/boot/dts/exynos5800.dtsi
+++ b/arch/arm/boot/dts/exynos5800.dtsi
@@ -26,3 +26,7 @@
 &mfc {
compatible = "samsung,mfc-v8";
 };
+
+&pmu_system_controller {
+   compatible = "samsung,exynos5800-pmu", "syscon";
+};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/3] Adds PMU and S2R support for exynos5800

[Vikas Sajjan]

Rebased on
1] Kukjin Kim's tree, master branch
http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/
2] My 5420 PMU Series :
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35699.html

Tested on Exynos5800 based chromebook (peach-pi board) with help of
http://www.spinics.net/lists/linux-samsung-soc/msg33750.html (modified to 
support 5800)

Below procedures were followed to test S2R:
Procedure A:
1. make multi_v7_defconfig 
2  enable MCPM for 5420
3. enable S3C RTC
4. pass "no_console_suspend" in bootargs
5. echo +20 > /sys/class/rtc/rtc0/wakealarm && echo mem > 
/sys/power/state
Procedure B:
1. make exynos_defconfig 
2  disable BL_SWITCHER
3. pass "no_console_suspend" in bootargs
4. echo +20 > /sys/class/rtc/rtc0/wakealarm && echo mem > 
/sys/power/state

Vikas Sajjan (3):
  ARM: dts: Add pmu node for exynos5800 SoC
  ARM: exynos: Add exynos5800-pmu compatible entry
  ARM: exynos: Add PMU and S2R support for exynos5800 SoC

 .../devicetree/bindings/arm/samsung/pmu.txt|1 +
 arch/arm/boot/dts/exynos5800.dtsi  |4 
 arch/arm/mach-exynos/exynos.c  |1 +
 arch/arm/mach-exynos/pm.c  |3 +++
 arch/arm/mach-exynos/pmu.c |   22 
 arch/arm/mach-exynos/regs-pmu.h|3 ++-
 6 files changed, 33 insertions(+), 1 deletion(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 1/2] ARM: exynos5: Add PMU support for 5420

[Vikas Sajjan]

From: Abhilash Kesavan 

Add intial PMU settings for exynos5420. This is required for
future S2R and Switching support.

Signed-off-by: Thomas Abraham 
Signed-off-by: Abhilash Kesavan 
Signed-off-by: Vikas Sajjan 
---
 arch/arm/mach-exynos/pmu.c  |  288 +++
 arch/arm/mach-exynos/regs-pmu.h |  229 +++
 2 files changed, 517 insertions(+)

diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index d667f3a..f8ced42 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -14,6 +14,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#include 
 
 #include "exynos-pmu.h"
 #include "regs-pmu.h"
@@ -350,6 +353,151 @@ static const struct exynos_pmu_conf 
exynos5250_pmu_config[] = {
{ PMU_TABLE_END,},
 };
 
+static struct exynos_pmu_conf exynos5420_pmu_config[] = {
+   /* { .offset = offset, .val = { AFTR, LPA, SLEEP } */
+   { EXYNOS5_ARM_CORE0_SYS_PWR_REG,{ 0x0, 0x0, 
0x0} },
+   { EXYNOS5_DIS_IRQ_ARM_CORE0_LOCAL_SYS_PWR_REG,  { 0x0, 0x0, 
0x0} },
+   { EXYNOS5_DIS_IRQ_ARM_CORE0_CENTRAL_SYS_PWR_REG,{ 0x0, 0x0, 
0x0} },
+   { EXYNOS5_ARM_CORE1_SYS_PWR_REG,{ 0x0, 0x0, 
0x0} },
+   { EXYNOS5_DIS_IRQ_ARM_CORE1_LOCAL_SYS_PWR_REG,  { 0x0, 0x0, 
0x0} },
+   { EXYNOS5_DIS_IRQ_ARM_CORE1_CENTRAL_SYS_PWR_REG,{ 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_ARM_CORE2_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_ARM_CORE2_LOCAL_SYS_PWR_REG,   { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_ARM_CORE2_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_ARM_CORE3_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_ARM_CORE3_LOCAL_SYS_PWR_REG,   { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_ARM_CORE3_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_KFC_CORE0_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE0_LOCAL_SYS_PWR_REG,   { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_KFC_CORE1_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE1_LOCAL_SYS_PWR_REG,   { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_KFC_CORE2_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE2_LOCAL_SYS_PWR_REG,   { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE2_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_KFC_CORE3_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE3_LOCAL_SYS_PWR_REG,   { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE3_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 
0x0} },
+   { EXYNOS5_ISP_ARM_SYS_PWR_REG,  { 0x1, 0x0, 
0x0} },
+   { EXYNOS5_DIS_IRQ_ISP_ARM_LOCAL_SYS_PWR_REG,{ 0x1, 0x0, 
0x0} },
+   { EXYNOS5_DIS_IRQ_ISP_ARM_CENTRAL_SYS_PWR_REG,  { 0x1, 0x0, 
0x0} },
+   { EXYNOS5420_ARM_COMMON_SYS_PWR_REG,{ 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_KFC_COMMON_SYS_PWR_REG,{ 0x0, 0x0, 
0x0} },
+   { EXYNOS5_ARM_L2_SYS_PWR_REG,   { 0x0, 0x0, 
0x0} },
+   { EXYNOS5420_KFC_L2_SYS_PWR_REG,{ 0x0, 0x0, 
0x0} },
+   { EXYNOS5_CMU_ACLKSTOP_SYS_PWR_REG, { 0x1, 0x0, 
0x0} },
+   { EXYNOS5_CMU_SCLKSTOP_SYS_PWR_REG, { 0x1, 0x0, 
0x1} },
+   { EXYNOS5_CMU_RESET_SYS_PWR_REG,{ 0x1, 0x1, 
0x0} },
+   { EXYNOS5_CMU_ACLKSTOP_SYSMEM_SYS_PWR_REG,  { 0x1, 0x0, 
0x0} },
+   { EXYNOS5_CMU_SCLKSTOP_SYSMEM_SYS_PWR_REG,  { 0x1, 0x0, 
0x1} },
+   { EXYNOS5_CMU_RESET_SYSMEM_SYS_PWR_REG, { 0x1, 0x1, 
0x0} },
+   { EXYNOS5_DRAM_FREQ_DOWN_SYS_PWR_REG,   { 0x1, 0x0, 
0x1} },
+   { EXYNOS5_DDRPHY_DLLOFF_SYS_PWR_REG,{ 0x1, 0x1, 
0x1} },
+   { EXYNOS5_DDRPHY_DLLLOCK_SYS_PWR_REG,   { 0x1, 0x0, 
0x1} },
+   { EXYNOS5_APLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 
0x0} },
+   { EXYNOS5_MPLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 
0x0} },
+   { EXYNOS5_VPLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 
0x0} },
+   { EXYNOS5_EPLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x1, 
0x0} },
+   { EXYNOS5_BPLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 
0x0} },
+   { EXYNOS5_CPLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 
0x0} },
+   { EXYNOS5420_DPLL_SYSCLK_SYS_PWR_REG,   { 0x1, 0x0, 
0x0} },
+   { EXYNOS5420_IPLL_SYSCLK_SYS_PWR_REG,   { 

[PATCH v7 2/2] ARM: exynos5: Add Suspend-to-RAM support for 5420

[Vikas Sajjan]

From: Abhilash Kesavan 

Adds Suspend-to-RAM support for EXYNOS5420

Signed-off-by: Vikas Sajjan 
Signed-off-by: Abhilash Kesavan 
---
 arch/arm/mach-exynos/pm.c |  149 -
 1 file changed, 148 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 4153b5d..b6a957d 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -39,6 +39,8 @@
 
 #define REG_TABLE_END (-1U)
 
+#define EXYNOS5420_CPU_STATE   0x28
+
 /**
  * struct exynos_wkup_irq - Exynos GIC to PMU IRQ mapping
  * @hwirq: Hardware IRQ signal of the GIC
@@ -77,6 +79,9 @@ struct exynos_pm_data {
 
 struct exynos_pm_data *pm_data;
 
+static int exynos5420_cpu_state;
+static unsigned int exynos_pmu_spare3;
+
 /*
  * GIC wake-up support
  */
@@ -106,6 +111,23 @@ unsigned int exynos_release_ret_regs[] = {
REG_TABLE_END,
 };
 
+unsigned int exynos5420_release_ret_regs[] = {
+   EXYNOS_PAD_RET_DRAM_OPTION,
+   EXYNOS_PAD_RET_MAUDIO_OPTION,
+   EXYNOS_PAD_RET_JTAG_OPTION,
+   EXYNOS5420_PAD_RET_GPIO_OPTION,
+   EXYNOS5420_PAD_RET_UART_OPTION,
+   EXYNOS5420_PAD_RET_MMCA_OPTION,
+   EXYNOS5420_PAD_RET_MMCB_OPTION,
+   EXYNOS5420_PAD_RET_MMCC_OPTION,
+   EXYNOS5420_PAD_RET_HSI_OPTION,
+   EXYNOS_PAD_RET_EBIA_OPTION,
+   EXYNOS_PAD_RET_EBIB_OPTION,
+   EXYNOS5420_PAD_RET_SPI_OPTION,
+   EXYNOS5420_PAD_RET_DRAM_COREBLK_OPTION,
+   REG_TABLE_END,
+};
+
 static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
 {
const struct exynos_wkup_irq *wkup_irq;
@@ -266,10 +288,22 @@ static int exynos_cpu_do_idle(void)
return 1; /* Aborting suspend */
 }
 
-static int exynos_cpu_suspend(unsigned long arg)
+static void exynos_flush_cache_all(void)
 {
flush_cache_all();
outer_flush_all();
+}
+
+static int exynos_cpu_suspend(unsigned long arg)
+{
+   exynos_flush_cache_all();
+   return exynos_cpu_do_idle();
+}
+
+static int exynos5420_cpu_suspend(unsigned long arg)
+{
+   exynos_flush_cache_all();
+   __raw_writel(0x0, sysram_base_addr + EXYNOS5420_CPU_STATE);
return exynos_cpu_do_idle();
 }
 
@@ -304,6 +338,49 @@ static void exynos_pm_prepare(void)
exynos_pm_enter_sleep_mode();
 }
 
+static void exynos5420_pm_prepare(void)
+{
+   unsigned int tmp;
+
+   /* Set wake-up mask registers */
+   exynos_pm_set_wakeup_mask();
+
+   s3c_pm_do_save(exynos_core_save, ARRAY_SIZE(exynos_core_save));
+
+   exynos_pmu_spare3 = pmu_raw_readl(S5P_PMU_SPARE3);
+   /*
+* The cpu state needs to be saved and restored so that the
+* secondary CPUs will enter low power start. Though the U-Boot
+* is setting the cpu state with low power flag, the kernel
+* needs to restore it back in case, the primary cpu fails to
+* suspend for any reason.
+*/
+   exynos5420_cpu_state = __raw_readl(sysram_base_addr +
+   EXYNOS5420_CPU_STATE);
+
+   exynos_pm_enter_sleep_mode();
+
+   tmp = pmu_raw_readl(EXYNOS5_ARM_L2_OPTION);
+   tmp &= ~EXYNOS5_USE_RETENTION;
+   pmu_raw_writel(tmp, EXYNOS5_ARM_L2_OPTION);
+
+   tmp = pmu_raw_readl(EXYNOS5420_SFR_AXI_CGDIS1);
+   tmp |= EXYNOS5420_UFS;
+   pmu_raw_writel(tmp, EXYNOS5420_SFR_AXI_CGDIS1);
+
+   tmp = pmu_raw_readl(EXYNOS5420_ARM_COMMON_OPTION);
+   tmp &= ~EXYNOS5420_L2RSTDISABLE_VALUE;
+   pmu_raw_writel(tmp, EXYNOS5420_ARM_COMMON_OPTION);
+
+   tmp = pmu_raw_readl(EXYNOS5420_FSYS2_OPTION);
+   tmp |= EXYNOS5420_EMULATION;
+   pmu_raw_writel(tmp, EXYNOS5420_FSYS2_OPTION);
+
+   tmp = pmu_raw_readl(EXYNOS5420_PSGEN_OPTION);
+   tmp |= EXYNOS5420_EMULATION;
+   pmu_raw_writel(tmp, EXYNOS5420_PSGEN_OPTION);
+}
+
 static int exynos_pm_suspend(void)
 {
unsigned long tmp;
@@ -321,6 +398,24 @@ static int exynos_pm_suspend(void)
return 0;
 }
 
+static int exynos5420_pm_suspend(void)
+{
+   u32 this_cluster;
+
+   exynos_pm_central_suspend();
+
+   /* Setting SEQ_OPTION register */
+
+   this_cluster = MPIDR_AFFINITY_LEVEL(read_cpuid_mpidr(), 1);
+   if (!this_cluster)
+   pmu_raw_writel(EXYNOS5420_ARM_USE_STANDBY_WFI0,
+   S5P_CENTRAL_SEQ_OPTION);
+   else
+   pmu_raw_writel(EXYNOS5420_KFC_USE_STANDBY_WFI0,
+   S5P_CENTRAL_SEQ_OPTION);
+   return 0;
+}
+
 static void exynos_pm_release_retention(void)
 {
unsigned int i;
@@ -356,6 +451,45 @@ early_wakeup:
pmu_raw_writel(0x0, S5P_INFORM1);
 }
 
+static void exynos5420_pm_resume(void)
+{
+   unsigned long tmp;
+
+   /* Restore the sysram cpu state register */
+   __raw_writel(exynos5420_cpu_state,
+   sysram_base_addr + EXYNOS5420_CPU_STATE);
+
+   pmu_raw_writel(EXYNOS5420_USE_STANDBY_WFI_ALL,
+   S5P_CENTRAL

[PATCH v7 0/2] Adds PMU and S2R support for exynos5420

[Vikas Sajjan]

Rebased on
1] Kukjin Kim's tree, master branch
http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/
2] Pankaj Dubey's v7 PMU patchset
https://lkml.org/lkml/2014/7/9/2
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/270655.html
3] My pm.c refactoring patchset
http://www.spinics.net/lists/linux-samsung-soc/msg35740.html

changes since v6:
- rebased on 3.17.rc1.

changes since v5:
- Refactored pm.c to use DT based lookup as suggested by Tomasz Figa.

changes since v4:
- Adressed comments from Tomasz figa and rebased on Pankaj Dubey's v5 
PMU patchset

changes since v3:
Addressed the following comments from Pankaj Dubey, Bartlomiej Zolnierkiewicz,
Tomasz Figa and Alim Akhtar:
- Moved EXYNOS5420_USE_STANDBY_WFI_ALL define to regs-pmu.h.
- Merged exynos5420_set_core_flag function into powerdown_conf.
- Removed XXTI_DURATION3 register setting.
- Updated the commit message and ordered the clock registers in clock
  patch.
- Removed the code for SYS_DISP1_BLK_CFG handling.
- Modified SoC checks to A9 specific checks in PM code.
- Updated some comments in the code and added macros for register 
offsets.
- Fixed code which was changing pad retention code for older SoCs.

changes since v2:
- Addressed comments from Tomasz figa
- rebased on Pankaj's V3 patchset https://lkml.org/lkml/2014/5/2/612
- dropped patch "ARM: dts: Add node for GPIO keys on SMDK5420",
  will be sent separately.

changes since v1:
- Addressed comments from Tomasz figa.
- restructured/consolidated as per Tomasz figa's PM consolidations for 
exynos

Tested on Kukjin Kim's tree, master branch + 
http://www.spinics.net/lists/linux-samsung-soc/msg33750.html

on Exynos5420 based chromebook (peach-pit board)

PS : Not tested on exynos4 based boards.

Tested-by for exynos4 would be appreciated.

Below procedures were followed to test S2R:
Procedure A:
1. make multi_v7_defconfig 
2  enable MCPM for 5420
3. enable S3C RTC
4. pass "no_console_suspend" in bootargs
5. echo +20 > /sys/class/rtc/rtc0/wakealarm && echo mem > 
/sys/power/state
Procedure B:
1. make exynos_defconfig 
2  disable BL_SWITCHER
3. pass "no_console_suspend" in bootargs
4. echo +20 > /sys/class/rtc/rtc0/wakealarm && echo mem > 
/sys/power/state

Abhilash Kesavan (2):
  ARM: exynos5: Add PMU support for 5420
  ARM: exynos5: Add Suspend-to-RAM support for 5420

 arch/arm/mach-exynos/pm.c   |  149 +++-
 arch/arm/mach-exynos/pmu.c  |  288 +++
 arch/arm/mach-exynos/regs-pmu.h |  229 +++
 3 files changed, 665 insertions(+), 1 deletion(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drm: exynos: Make of_device_id array const

[Kiran Padwal]

Make of_device_id array const, because all OF functions handle it as const.

Signed-off-by: Kiran Padwal 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c|2 +-
 drivers/gpu/drm/exynos/exynos_mixer.c   |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 442aa2d..2f96fb7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -310,7 +310,7 @@ static struct exynos_dsi_driver_data 
exynos5_dsi_driver_data = {
.plltmr_reg = 0x58,
 };
 
-static struct of_device_id exynos_dsi_of_match[] = {
+static const struct of_device_id exynos_dsi_of_match[] = {
{ .compatible = "samsung,exynos4210-mipi-dsi",
  .data = &exynos4_dsi_driver_data },
{ .compatible = "samsung,exynos5410-mipi-dsi",
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 562966d..fc44a91 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2278,7 +2278,7 @@ err_data:
return NULL;
 }
 
-static struct of_device_id hdmi_match_types[] = {
+static const struct of_device_id hdmi_match_types[] = {
{
.compatible = "samsung,exynos5-hdmi",
.data = &exynos5_hdmi_driver_data,
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index e8b4ec8..637aa8f 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1225,7 +1225,7 @@ static struct platform_device_id mixer_driver_types[] = {
}
 };
 
-static struct of_device_id mixer_match_types[] = {
+static const struct of_device_id mixer_match_types[] = {
{
.compatible = "samsung,exynos4210-mixer",
.data   = &exynos4210_mxr_drv_data,
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] pinctrl: exynos: Lock GPIOs as interrupts when used as EINTs

[Linus Walleij]

On Fri, Aug 8, 2014 at 6:48 PM, Javier Martinez Canillas
 wrote:

> From: Tomasz Figa 
>
> Currently after configuring a GPIO pin as an interrupt related pinmux
> registers are changed, but there is no protection from calling
> gpio_direction_*() in a badly written driver, which would cause the same
> pinmux register to be reconfigured for regular input/output and this
> disabling interrupt capability of the pin.
>
> This patch addresses this issue by moving pinmux reconfiguration to
> .irq_{request,release}_resources() callback of irq_chip and calling
> gpio_lock_as_irq() helper to prevent reconfiguration of pin direction.
>
> Setting up a GPIO interrupt on Samsung SoCs is a two-step operation -
> in addition to trigger configuration in a dedicated register, the pinmux
> must be also reconfigured to GPIO interrupt, which is a different function
> than normal GPIO input, although I/O-wise they both behave in the same way
> and gpio_get_value() can be used on a pin configured as IRQ as well.
>
> Such design implies subtleties such as gpio_direction_input() not having
> to fail if a pin is already configured as an interrupt nor change the
> configuration to normal input. But the FLAG_USED_AS_IRQ set in gpiolib by
> gpio_lock_as_irq() is only used to check that gpio_direction_output() is
> not called, it's not used to prevent gpio_direction_input() to be called.
> So this is not a complete solution for Samsung SoCs but it's definitely a
> move in the right direction.
>
> Signed-off-by: Tomasz Figa 
> [javier: use request resources instead of startup and expand commit message]
> Signed-off-by: Javier Martinez Canillas 

OK patch applied for fixes, sorry for missing to follow up on this.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] usb: host: ohci-exynos: Remove unnecessary usb-phy support

[Vivek Gautam]

Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.
This should fix the issue on ohci-exynos, wherein in the absence of
SAMSUNG_USB2PHY config symbol, we ended up getting the NOP_USB_XCEIV phy
when the same is enabled. And thus the PHYs are not configured properly.

Reported-by: Sachin Kamat 
Signed-off-by: Vivek Gautam 
Acked-by: Alan Stern 
Reviewed-by: Jingoo Han 
---

 - This patch was part of the series "[PATCH 0/7] usb-phy: samsung: Cleanup the 
unused drivers"
   https://lkml.org/lkml/2014/8/14/235. I have dropped the phy cleanup patches 
from that series-
   Patches 1-5.
 - Rebased this patch on top of 3.17-rc1.

 drivers/usb/host/ohci-exynos.c |   64 ++--
 1 file changed, 9 insertions(+), 55 deletions(-)

diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index a72ab8f..0199a8b 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -19,11 +19,8 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
-#include 
 
 #include "ohci.h"
 
@@ -38,9 +35,7 @@ static struct hc_driver __read_mostly exynos_ohci_hc_driver;
 
 struct exynos_ohci_hcd {
struct clk *clk;
-   struct usb_phy *phy;
-   struct usb_otg *otg;
-   struct phy *phy_g[PHY_NUMBER];
+   struct phy *phy[PHY_NUMBER];
 };
 
 static int exynos_ohci_get_phy(struct device *dev,
@@ -51,28 +46,7 @@ static int exynos_ohci_get_phy(struct device *dev,
int phy_number;
int ret = 0;
 
-   exynos_ohci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(exynos_ohci->phy)) {
-   ret = PTR_ERR(exynos_ohci->phy);
-   if (ret != -ENXIO && ret != -ENODEV) {
-   dev_err(dev, "no usb2 phy configured\n");
-   return ret;
-   }
-   dev_dbg(dev, "Failed to get usb2 phy\n");
-   } else {
-   exynos_ohci->otg = exynos_ohci->phy->otg;
-   }
-
-   /*
-* Getting generic phy:
-* We are keeping both types of phys as a part of transiting OHCI
-* to generic phy framework, so as to maintain backward compatibilty
-* with old DTB.
-* If there are existing devices using DTB files built from them,
-* to remove the support for old bindings in this driver,
-* we need to make sure that such devices have their DTBs
-* updated to ones built from new DTS.
-*/
+   /* Get the generic phys */
for_each_available_child_of_node(dev->of_node, child) {
ret = of_property_read_u32(child, "reg", &phy_number);
if (ret) {
@@ -97,7 +71,7 @@ static int exynos_ohci_get_phy(struct device *dev,
}
dev_dbg(dev, "Failed to get usb2 phy\n");
}
-   exynos_ohci->phy_g[phy_number] = phy;
+   exynos_ohci->phy[phy_number] = phy;
}
 
return ret;
@@ -110,16 +84,13 @@ static int exynos_ohci_phy_enable(struct device *dev)
int i;
int ret = 0;
 
-   if (!IS_ERR(exynos_ohci->phy))
-   return usb_phy_init(exynos_ohci->phy);
-
for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ohci->phy_g[i]))
-   ret = phy_power_on(exynos_ohci->phy_g[i]);
+   if (!IS_ERR(exynos_ohci->phy[i]))
+   ret = phy_power_on(exynos_ohci->phy[i]);
if (ret)
for (i--; i >= 0; i--)
-   if (!IS_ERR(exynos_ohci->phy_g[i]))
-   phy_power_off(exynos_ohci->phy_g[i]);
+   if (!IS_ERR(exynos_ohci->phy[i]))
+   phy_power_off(exynos_ohci->phy[i]);
 
return ret;
 }
@@ -130,14 +101,9 @@ static void exynos_ohci_phy_disable(struct device *dev)
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
int i;
 
-   if (!IS_ERR(exynos_ohci->phy)) {
-   usb_phy_shutdown(exynos_ohci->phy);
-   return;
-   }
-
for (i = 0; i < PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ohci->phy_g[i]))
-   phy_power_off(exynos_ohci->phy_g[i]);
+   if (!IS_ERR(exynos_ohci->phy[i]))
+   phy_power_off(exynos_ohci->phy[i]);
 }
 
 static int exynos_ohci_probe(struct platform_device *pdev)
@@ -209,9 +175,6 @@ skip_phy:
goto fail_io;
}
 
-   if (exynos_ohci->otg)
-   exynos_ohci->otg->set_host(exynos_ohci->otg, &hcd->self);
-
platform_set_drvdata(pdev, hcd);
 
err = exynos_ohci_phy_enable(&pdev->dev);
@@ -244,9 +207,6 @@ static int exynos_ohci_remove(struct platform_device *pdev)
 
usb_remove_hcd(hcd);
 
- 

[PATCH v2 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support

[Vivek Gautam]

Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.
This should fix the issue on ehci-exynos, wherein in the absence of
SAMSUNG_USB2PHY config symbol, we ended up getting the NOP_USB_XCEIV phy
when the same is enabled. And thus the PHYs are not configured properly.

Reported-by: Sachin Kamat 
Signed-off-by: Vivek Gautam 
Acked-by: Alan Stern 
Reviewed-by: Jingoo Han 
---

 - This patch was part of the series "[PATCH 0/7] usb-phy: samsung: Cleanup the 
unused drivers"
   https://lkml.org/lkml/2014/8/14/235. I have dropped the phy cleanup patches 
from that series-
   Patches 1-5.
 - Rebased this patch on top of 3.17-rc1.

 drivers/usb/host/ehci-exynos.c |   53 ++--
 1 file changed, 8 insertions(+), 45 deletions(-)

diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index cda0a2f..54944cc 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -21,11 +21,8 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
-#include 
 
 #include "ehci.h"
 
@@ -47,9 +44,7 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
 
 struct exynos_ehci_hcd {
struct clk *clk;
-   struct usb_phy *phy;
-   struct usb_otg *otg;
-   struct phy *phy_g[PHY_NUMBER];
+   struct phy *phy[PHY_NUMBER];
 };
 
 #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)->priv)
@@ -62,18 +57,6 @@ static int exynos_ehci_get_phy(struct device *dev,
int phy_number;
int ret = 0;
 
-   exynos_ehci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(exynos_ehci->phy)) {
-   ret = PTR_ERR(exynos_ehci->phy);
-   if (ret != -ENXIO && ret != -ENODEV) {
-   dev_err(dev, "no usb2 phy configured\n");
-   return ret;
-   }
-   dev_dbg(dev, "Failed to get usb2 phy\n");
-   } else {
-   exynos_ehci->otg = exynos_ehci->phy->otg;
-   }
-
for_each_available_child_of_node(dev->of_node, child) {
ret = of_property_read_u32(child, "reg", &phy_number);
if (ret) {
@@ -98,7 +81,7 @@ static int exynos_ehci_get_phy(struct device *dev,
}
dev_dbg(dev, "Failed to get usb2 phy\n");
}
-   exynos_ehci->phy_g[phy_number] = phy;
+   exynos_ehci->phy[phy_number] = phy;
}
 
return ret;
@@ -111,16 +94,13 @@ static int exynos_ehci_phy_enable(struct device *dev)
int i;
int ret = 0;
 
-   if (!IS_ERR(exynos_ehci->phy))
-   return usb_phy_init(exynos_ehci->phy);
-
for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ehci->phy_g[i]))
-   ret = phy_power_on(exynos_ehci->phy_g[i]);
+   if (!IS_ERR(exynos_ehci->phy[i]))
+   ret = phy_power_on(exynos_ehci->phy[i]);
if (ret)
for (i--; i >= 0; i--)
-   if (!IS_ERR(exynos_ehci->phy_g[i]))
-   phy_power_off(exynos_ehci->phy_g[i]);
+   if (!IS_ERR(exynos_ehci->phy[i]))
+   phy_power_off(exynos_ehci->phy[i]);
 
return ret;
 }
@@ -131,14 +111,9 @@ static void exynos_ehci_phy_disable(struct device *dev)
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
int i;
 
-   if (!IS_ERR(exynos_ehci->phy)) {
-   usb_phy_shutdown(exynos_ehci->phy);
-   return;
-   }
-
for (i = 0; i < PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ehci->phy_g[i]))
-   phy_power_off(exynos_ehci->phy_g[i]);
+   if (!IS_ERR(exynos_ehci->phy[i]))
+   phy_power_off(exynos_ehci->phy[i]);
 }
 
 static void exynos_setup_vbus_gpio(struct device *dev)
@@ -231,9 +206,6 @@ skip_phy:
goto fail_io;
}
 
-   if (exynos_ehci->otg)
-   exynos_ehci->otg->set_host(exynos_ehci->otg, &hcd->self);
-
err = exynos_ehci_phy_enable(&pdev->dev);
if (err) {
dev_err(&pdev->dev, "Failed to enable USB phy\n");
@@ -273,9 +245,6 @@ static int exynos_ehci_remove(struct platform_device *pdev)
 
usb_remove_hcd(hcd);
 
-   if (exynos_ehci->otg)
-   exynos_ehci->otg->set_host(exynos_ehci->otg, &hcd->self);
-
exynos_ehci_phy_disable(&pdev->dev);
 
clk_disable_unprepare(exynos_ehci->clk);
@@ -298,9 +267,6 @@ static int exynos_ehci_suspend(struct device *dev)
if (rc)
return rc;
 
-   if (exynos_ehci->otg)
-   exynos_ehci->otg->set_host(exynos_ehci->otg, &hcd->self);
-
exynos_ehci_phy_disable(de

Re: [PATCHv3] thermal: exynos: Add support for TRIM_RELOAD feature at Exynos3250

[Andreas Färber]

Hello,

Am 21.08.2014 03:38, schrieb Chanwoo Choi:
> On 08/20/2014 10:38 PM, edubez...@gmail.com wrote:
>> On Tue, Aug 19, 2014 at 7:52 PM, Chanwoo Choi  wrote:
>>> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
>>> b/drivers/thermal/samsung/exynos_tmu_data.c
>>> index aa8e0de..8cd609c 100644
>>> --- a/drivers/thermal/samsung/exynos_tmu_data.c
>>> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
>>> @@ -95,6 +95,8 @@ static const struct exynos_tmu_registers 
>>> exynos3250_tmu_registers = {
>>> .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
>>> .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
>>> .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
>>> +   .triminfo_ctrl[0] = EXYNOS_TMU_TRIMINFO_CON1,
>>> +   .triminfo_ctrl[1] = EXYNOS_TMU_TRIMINFO_CON2,
>>> .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
>>> .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
>>> .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
>>> @@ -160,8 +162,11 @@ static const struct exynos_tmu_registers 
>>> exynos3250_tmu_registers = {
>>> .temp_level = 95, \
>>> }, \
>>> .freq_tab_count = 2, \
>>> +   .triminfo_reload[0] = 0x1, \
>>> +   .triminfo_reload[1] = 0x11, \
>>
>> What does 0x1 mean? How about 0x11?
> 
> The bit of 'RELOAD' field in TRIMINFO_CONTROL register is [0].
> and The bit of 'AC Time' field in TRIMINFO_CONTROL register is [5:4].
> 
> 0x1 means that set RELOAD field.
> 0x11 means that set RELOAD field and ACTIME field.

Might be a good idea to use #defines for 0x1 and 0x10 then?

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
To unsubscribe from this list: send the line "unsubscribe linux-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 4/7] mfd: cros_ec: move locking into cros_ec_cmd_xfer

[Javier Martinez Canillas]

Hello Doug,

On 08/21/2014 12:36 AM, Doug Anderson wrote:
> Javier,
> 
> On Wed, Aug 20, 2014 at 5:13 AM, Javier Martinez Canillas
>  wrote:
>> From: Andrew Bresticker 
>>
>> Now that there's a central cros_ec_cmd_xfer(), move the locking
>> out of the SPI and LPC drivers.
> 
> Slight nit that the LPC driver doesn't exist upstream.  This is in
> prep for adding the LPC driver, though.
> 

Right, the downstream commit was also touching the LPC driver and I
stripped that part but forget to update the commit message, sorry about
that. I'll fix it and do a re-spin.

> 
>> Signed-off-by: Andrew Bresticker 
>> Reviewed-by: Simon Glass 
>> Signed-off-by: Javier Martinez Canillas 
>> ---
>>  drivers/mfd/cros_ec.c | 10 +-
>>  drivers/mfd/cros_ec_spi.c | 11 ---
>>  2 files changed, 9 insertions(+), 12 deletions(-)
> 
> After comment nitfix:
> 
> Reviewed-by: Doug Anderson 
> 

Thanks and best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-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 4/9] drm/exynos: add exynos_dp_panel driver registration to drm driver

[Thierry Reding]

On Thu, Aug 21, 2014 at 02:57:21PM +0530, Ajay kumar wrote:
> On Thu, Aug 21, 2014 at 1:55 PM, Stéphane Marchesin
>  wrote:
> > On Thu, Aug 21, 2014 at 12:36 AM, Thierry Reding
> >  wrote:
> >> On Tue, Aug 19, 2014 at 09:02:39PM -0700, Stéphane Marchesin wrote:
> >>> On Tue, Apr 22, 2014 at 8:26 AM, Thierry Reding
> >>>  wrote:
> >>> > On Tue, Apr 22, 2014 at 08:33:23PM +0530, Ajay kumar wrote:
> >>> >> Hi Thierry,
> >>> >>
> >>> >> On Tue, Apr 22, 2014 at 2:03 PM, Thierry Reding
> >>> >>  wrote:
> >>> >> > On Tue, Apr 22, 2014 at 04:09:13AM +0530, Ajay Kumar wrote:
> >>> >> >> Register exynos_dp_panel before the list of exynos crtcs and
> >>> >> >> connectors are probed.
> >>> >> >>
> >>> >> >> This is needed because exynos_dp_panel should be registered to
> >>> >> >> the drm_panel list via panel-exynos-dp probe, i.e much before
> >>> >> >> exynos_dp_bind calls of_drm_find_panel().
> >>> >> >>
> >>> >> >> Signed-off-by: Ajay Kumar 
> >>> >> >> ---
> >>> >> >> Changes since V1:
> >>> >> >>   Added platform_driver_unregister(&exynos_dp_panel_driver) to
> >>> >> >>   exynos_drm_platform_remove as per Jingoo Han's correction
> >>> >> >>
> >>> >> >>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   15 +++
> >>> >> >>  drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
> >>> >> >>  2 files changed, 16 insertions(+)
> >>> >> >>
> >>> >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> >>> >> >> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> >>> >> >> index 1d653f8..2db7f67 100644
> >>> >> >> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> >>> >> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> >>> >> >> @@ -530,12 +530,23 @@ static int exynos_drm_platform_probe(struct 
> >>> >> >> platform_device *pdev)
> >>> >> >>   goto err_unregister_ipp_drv;
> >>> >> >>  #endif
> >>> >> >>
> >>> >> >> +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP
> >>> >> >> + ret = platform_driver_register(&exynos_dp_panel_driver);
> >>> >> >> + if (ret < 0)
> >>> >> >> + goto err_unregister_dp_panel;
> >>> >> >> +#endif
> >>> >> >
> >>> >> > No, this is not how you're supposed to use DRM panel drivers. The 
> >>> >> > idea
> >>> >> > is that you write a standalone driver for a given panel.
> >>> >> >
> >>> >> > What you do here has a number of problems. For one it's a driver 
> >>> >> > that's
> >>> >> > tightly coupled to Exynos SoCs. But if I have a different SoC that 
> >>> >> > uses
> >>> >> > the same panel I want to be able to use the same driver, and not 
> >>> >> > have to
> >>> >> > rewrite the driver for my SoC.
> >>> >> >
> >>> >> > Another problem is that you're assuming here that the driver is 
> >>> >> > built in
> >>> >> > and it will break if you try to build either Exynos DRM or the panel
> >>> >> > driver as a module. This is perhaps nothing you care about right now,
> >>> >> > but eventually people will want to ship a single kernel that can run 
> >>> >> > on
> >>> >> > a number of SoCs. But if we keep adding things like this, that kernel
> >>> >> > will keep growing in size until it no longer fits in any kind of 
> >>> >> > memory.
> >>> >> >
> >>> >> > Thierry
> >>> >>
> >>> >> I completely agree with you in this!
> >>> >>
> >>> >> Yes, this is not acceptable, but I want to know an "acceptable"
> >>> >> workaround for the situation below:
> >>> >> I register the driver using module_init().
> >>> >> And, exynos_drm gets probed much before the panel driver probe happens.
> >>> >> So, the panel driver hasn't probed yet, but exynos_dp via exynos_drm
> >>> >> tries to call
> >>> >> "of_drm_find_panel" which always returns NULL.
> >>> >
> >>> > That's a situation that your driver needs to be able to deal with. The
> >>> > driver registration order doesn't matter one bit. It may happen to work
> >>> > most of the time, but as soon as one of the resources that your panel
> >>> > driver needs isn't there when the panel is probed, then it won't be
> >>> > registered and of_drm_find_panel() will still return NULL.
> >>> >
> >>> > Usually the right thing to do in that case would be to return (and
> >>> > propagate) -EPROBE_DEFER so that your driver's probe is deferred and
> >>> > retried when other drivers have been probed. That way it should
> >>> > eventually get a non-NULL panel.
> >>>
> >>> So I just gave this (drm_panel + probe deferring) a shot on exynos,
> >>> and correctly reacting to -EPROBE_DEFER postpones DP initialization by
> >>> approximately 1.5 second. Is there a good way to handle that? As it
> >>> stands, this isn't usable.
> >>
> >> How much is 1.5 seconds compared to the overall boot time of the device?
> >
> > 1.5s is 15-20% of my boot time (if you count the boot time from
> > firmware start to login prompt, otherwise it's more). Note that on
> > other platforms, we've seen this take as much as 5 or 6s, but for the
> > exynos case it is "only" 1.5s.
> >
> >> What exactly is causing this 1.5 second delay?
> >
> > A regulator isn't ready, and then drm_panel returns defe

Re: [PATCH V2 4/9] drm/exynos: add exynos_dp_panel driver registration to drm driver

[Thierry Reding]

Adding Boris and Ludovic since this topic came up in a different thread
as well.

On Thu, Aug 21, 2014 at 01:25:07AM -0700, Stéphane Marchesin wrote:
> On Thu, Aug 21, 2014 at 12:36 AM, Thierry Reding
>  wrote:
> > On Tue, Aug 19, 2014 at 09:02:39PM -0700, Stéphane Marchesin wrote:
> >> On Tue, Apr 22, 2014 at 8:26 AM, Thierry Reding
> >>  wrote:
> >> > On Tue, Apr 22, 2014 at 08:33:23PM +0530, Ajay kumar wrote:
> >> >> Hi Thierry,
> >> >>
> >> >> On Tue, Apr 22, 2014 at 2:03 PM, Thierry Reding
> >> >>  wrote:
> >> >> > On Tue, Apr 22, 2014 at 04:09:13AM +0530, Ajay Kumar wrote:
> >> >> >> Register exynos_dp_panel before the list of exynos crtcs and
> >> >> >> connectors are probed.
> >> >> >>
> >> >> >> This is needed because exynos_dp_panel should be registered to
> >> >> >> the drm_panel list via panel-exynos-dp probe, i.e much before
> >> >> >> exynos_dp_bind calls of_drm_find_panel().
> >> >> >>
> >> >> >> Signed-off-by: Ajay Kumar 
> >> >> >> ---
> >> >> >> Changes since V1:
> >> >> >>   Added platform_driver_unregister(&exynos_dp_panel_driver) to
> >> >> >>   exynos_drm_platform_remove as per Jingoo Han's correction
> >> >> >>
> >> >> >>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   15 +++
> >> >> >>  drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
> >> >> >>  2 files changed, 16 insertions(+)
> >> >> >>
> >> >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> >> >> >> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> >> >> >> index 1d653f8..2db7f67 100644
> >> >> >> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> >> >> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> >> >> >> @@ -530,12 +530,23 @@ static int exynos_drm_platform_probe(struct 
> >> >> >> platform_device *pdev)
> >> >> >>   goto err_unregister_ipp_drv;
> >> >> >>  #endif
> >> >> >>
> >> >> >> +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP
> >> >> >> + ret = platform_driver_register(&exynos_dp_panel_driver);
> >> >> >> + if (ret < 0)
> >> >> >> + goto err_unregister_dp_panel;
> >> >> >> +#endif
> >> >> >
> >> >> > No, this is not how you're supposed to use DRM panel drivers. The idea
> >> >> > is that you write a standalone driver for a given panel.
> >> >> >
> >> >> > What you do here has a number of problems. For one it's a driver 
> >> >> > that's
> >> >> > tightly coupled to Exynos SoCs. But if I have a different SoC that 
> >> >> > uses
> >> >> > the same panel I want to be able to use the same driver, and not have 
> >> >> > to
> >> >> > rewrite the driver for my SoC.
> >> >> >
> >> >> > Another problem is that you're assuming here that the driver is built 
> >> >> > in
> >> >> > and it will break if you try to build either Exynos DRM or the panel
> >> >> > driver as a module. This is perhaps nothing you care about right now,
> >> >> > but eventually people will want to ship a single kernel that can run 
> >> >> > on
> >> >> > a number of SoCs. But if we keep adding things like this, that kernel
> >> >> > will keep growing in size until it no longer fits in any kind of 
> >> >> > memory.
> >> >> >
> >> >> > Thierry
> >> >>
> >> >> I completely agree with you in this!
> >> >>
> >> >> Yes, this is not acceptable, but I want to know an "acceptable"
> >> >> workaround for the situation below:
> >> >> I register the driver using module_init().
> >> >> And, exynos_drm gets probed much before the panel driver probe happens.
> >> >> So, the panel driver hasn't probed yet, but exynos_dp via exynos_drm
> >> >> tries to call
> >> >> "of_drm_find_panel" which always returns NULL.
> >> >
> >> > That's a situation that your driver needs to be able to deal with. The
> >> > driver registration order doesn't matter one bit. It may happen to work
> >> > most of the time, but as soon as one of the resources that your panel
> >> > driver needs isn't there when the panel is probed, then it won't be
> >> > registered and of_drm_find_panel() will still return NULL.
> >> >
> >> > Usually the right thing to do in that case would be to return (and
> >> > propagate) -EPROBE_DEFER so that your driver's probe is deferred and
> >> > retried when other drivers have been probed. That way it should
> >> > eventually get a non-NULL panel.
> >>
> >> So I just gave this (drm_panel + probe deferring) a shot on exynos,
> >> and correctly reacting to -EPROBE_DEFER postpones DP initialization by
> >> approximately 1.5 second. Is there a good way to handle that? As it
> >> stands, this isn't usable.
> >
> > How much is 1.5 seconds compared to the overall boot time of the device?
> 
> 1.5s is 15-20% of my boot time (if you count the boot time from
> firmware start to login prompt, otherwise it's more). Note that on
> other platforms, we've seen this take as much as 5 or 6s, but for the
> exynos case it is "only" 1.5s.
> 
> > What exactly is causing this 1.5 second delay?
> 
> A regulator isn't ready, and then drm_panel returns defer. Then the
> whole drm driver init is deferred.

That is the correct way to do this currently. 

Re: [PATCH V2 4/9] drm/exynos: add exynos_dp_panel driver registration to drm driver

[Ajay kumar]

On Thu, Aug 21, 2014 at 1:55 PM, Stéphane Marchesin
 wrote:
> On Thu, Aug 21, 2014 at 12:36 AM, Thierry Reding
>  wrote:
>> On Tue, Aug 19, 2014 at 09:02:39PM -0700, Stéphane Marchesin wrote:
>>> On Tue, Apr 22, 2014 at 8:26 AM, Thierry Reding
>>>  wrote:
>>> > On Tue, Apr 22, 2014 at 08:33:23PM +0530, Ajay kumar wrote:
>>> >> Hi Thierry,
>>> >>
>>> >> On Tue, Apr 22, 2014 at 2:03 PM, Thierry Reding
>>> >>  wrote:
>>> >> > On Tue, Apr 22, 2014 at 04:09:13AM +0530, Ajay Kumar wrote:
>>> >> >> Register exynos_dp_panel before the list of exynos crtcs and
>>> >> >> connectors are probed.
>>> >> >>
>>> >> >> This is needed because exynos_dp_panel should be registered to
>>> >> >> the drm_panel list via panel-exynos-dp probe, i.e much before
>>> >> >> exynos_dp_bind calls of_drm_find_panel().
>>> >> >>
>>> >> >> Signed-off-by: Ajay Kumar 
>>> >> >> ---
>>> >> >> Changes since V1:
>>> >> >>   Added platform_driver_unregister(&exynos_dp_panel_driver) to
>>> >> >>   exynos_drm_platform_remove as per Jingoo Han's correction
>>> >> >>
>>> >> >>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   15 +++
>>> >> >>  drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
>>> >> >>  2 files changed, 16 insertions(+)
>>> >> >>
>>> >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
>>> >> >> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> >> >> index 1d653f8..2db7f67 100644
>>> >> >> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> >> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> >> >> @@ -530,12 +530,23 @@ static int exynos_drm_platform_probe(struct 
>>> >> >> platform_device *pdev)
>>> >> >>   goto err_unregister_ipp_drv;
>>> >> >>  #endif
>>> >> >>
>>> >> >> +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP
>>> >> >> + ret = platform_driver_register(&exynos_dp_panel_driver);
>>> >> >> + if (ret < 0)
>>> >> >> + goto err_unregister_dp_panel;
>>> >> >> +#endif
>>> >> >
>>> >> > No, this is not how you're supposed to use DRM panel drivers. The idea
>>> >> > is that you write a standalone driver for a given panel.
>>> >> >
>>> >> > What you do here has a number of problems. For one it's a driver that's
>>> >> > tightly coupled to Exynos SoCs. But if I have a different SoC that uses
>>> >> > the same panel I want to be able to use the same driver, and not have 
>>> >> > to
>>> >> > rewrite the driver for my SoC.
>>> >> >
>>> >> > Another problem is that you're assuming here that the driver is built 
>>> >> > in
>>> >> > and it will break if you try to build either Exynos DRM or the panel
>>> >> > driver as a module. This is perhaps nothing you care about right now,
>>> >> > but eventually people will want to ship a single kernel that can run on
>>> >> > a number of SoCs. But if we keep adding things like this, that kernel
>>> >> > will keep growing in size until it no longer fits in any kind of 
>>> >> > memory.
>>> >> >
>>> >> > Thierry
>>> >>
>>> >> I completely agree with you in this!
>>> >>
>>> >> Yes, this is not acceptable, but I want to know an "acceptable"
>>> >> workaround for the situation below:
>>> >> I register the driver using module_init().
>>> >> And, exynos_drm gets probed much before the panel driver probe happens.
>>> >> So, the panel driver hasn't probed yet, but exynos_dp via exynos_drm
>>> >> tries to call
>>> >> "of_drm_find_panel" which always returns NULL.
>>> >
>>> > That's a situation that your driver needs to be able to deal with. The
>>> > driver registration order doesn't matter one bit. It may happen to work
>>> > most of the time, but as soon as one of the resources that your panel
>>> > driver needs isn't there when the panel is probed, then it won't be
>>> > registered and of_drm_find_panel() will still return NULL.
>>> >
>>> > Usually the right thing to do in that case would be to return (and
>>> > propagate) -EPROBE_DEFER so that your driver's probe is deferred and
>>> > retried when other drivers have been probed. That way it should
>>> > eventually get a non-NULL panel.
>>>
>>> So I just gave this (drm_panel + probe deferring) a shot on exynos,
>>> and correctly reacting to -EPROBE_DEFER postpones DP initialization by
>>> approximately 1.5 second. Is there a good way to handle that? As it
>>> stands, this isn't usable.
>>
>> How much is 1.5 seconds compared to the overall boot time of the device?
>
> 1.5s is 15-20% of my boot time (if you count the boot time from
> firmware start to login prompt, otherwise it's more). Note that on
> other platforms, we've seen this take as much as 5 or 6s, but for the
> exynos case it is "only" 1.5s.
>
>> What exactly is causing this 1.5 second delay?
>
> A regulator isn't ready, and then drm_panel returns defer. Then the
> whole drm driver init is deferred.
>
>>
>> This really is a fundamental issue with deferred probing and the issue
>> has come up several times in the past. A couple of possible solutions
>> have been proposed, with the latest being here[0] I think. That ended in
>> a bit of a debacle, unfortunatel

Re: [PATCH V2 4/9] drm/exynos: add exynos_dp_panel driver registration to drm driver

[Stéphane Marchesin]

On Thu, Aug 21, 2014 at 12:36 AM, Thierry Reding
 wrote:
> On Tue, Aug 19, 2014 at 09:02:39PM -0700, Stéphane Marchesin wrote:
>> On Tue, Apr 22, 2014 at 8:26 AM, Thierry Reding
>>  wrote:
>> > On Tue, Apr 22, 2014 at 08:33:23PM +0530, Ajay kumar wrote:
>> >> Hi Thierry,
>> >>
>> >> On Tue, Apr 22, 2014 at 2:03 PM, Thierry Reding
>> >>  wrote:
>> >> > On Tue, Apr 22, 2014 at 04:09:13AM +0530, Ajay Kumar wrote:
>> >> >> Register exynos_dp_panel before the list of exynos crtcs and
>> >> >> connectors are probed.
>> >> >>
>> >> >> This is needed because exynos_dp_panel should be registered to
>> >> >> the drm_panel list via panel-exynos-dp probe, i.e much before
>> >> >> exynos_dp_bind calls of_drm_find_panel().
>> >> >>
>> >> >> Signed-off-by: Ajay Kumar 
>> >> >> ---
>> >> >> Changes since V1:
>> >> >>   Added platform_driver_unregister(&exynos_dp_panel_driver) to
>> >> >>   exynos_drm_platform_remove as per Jingoo Han's correction
>> >> >>
>> >> >>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   15 +++
>> >> >>  drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
>> >> >>  2 files changed, 16 insertions(+)
>> >> >>
>> >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
>> >> >> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> >> >> index 1d653f8..2db7f67 100644
>> >> >> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> >> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>> >> >> @@ -530,12 +530,23 @@ static int exynos_drm_platform_probe(struct 
>> >> >> platform_device *pdev)
>> >> >>   goto err_unregister_ipp_drv;
>> >> >>  #endif
>> >> >>
>> >> >> +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP
>> >> >> + ret = platform_driver_register(&exynos_dp_panel_driver);
>> >> >> + if (ret < 0)
>> >> >> + goto err_unregister_dp_panel;
>> >> >> +#endif
>> >> >
>> >> > No, this is not how you're supposed to use DRM panel drivers. The idea
>> >> > is that you write a standalone driver for a given panel.
>> >> >
>> >> > What you do here has a number of problems. For one it's a driver that's
>> >> > tightly coupled to Exynos SoCs. But if I have a different SoC that uses
>> >> > the same panel I want to be able to use the same driver, and not have to
>> >> > rewrite the driver for my SoC.
>> >> >
>> >> > Another problem is that you're assuming here that the driver is built in
>> >> > and it will break if you try to build either Exynos DRM or the panel
>> >> > driver as a module. This is perhaps nothing you care about right now,
>> >> > but eventually people will want to ship a single kernel that can run on
>> >> > a number of SoCs. But if we keep adding things like this, that kernel
>> >> > will keep growing in size until it no longer fits in any kind of memory.
>> >> >
>> >> > Thierry
>> >>
>> >> I completely agree with you in this!
>> >>
>> >> Yes, this is not acceptable, but I want to know an "acceptable"
>> >> workaround for the situation below:
>> >> I register the driver using module_init().
>> >> And, exynos_drm gets probed much before the panel driver probe happens.
>> >> So, the panel driver hasn't probed yet, but exynos_dp via exynos_drm
>> >> tries to call
>> >> "of_drm_find_panel" which always returns NULL.
>> >
>> > That's a situation that your driver needs to be able to deal with. The
>> > driver registration order doesn't matter one bit. It may happen to work
>> > most of the time, but as soon as one of the resources that your panel
>> > driver needs isn't there when the panel is probed, then it won't be
>> > registered and of_drm_find_panel() will still return NULL.
>> >
>> > Usually the right thing to do in that case would be to return (and
>> > propagate) -EPROBE_DEFER so that your driver's probe is deferred and
>> > retried when other drivers have been probed. That way it should
>> > eventually get a non-NULL panel.
>>
>> So I just gave this (drm_panel + probe deferring) a shot on exynos,
>> and correctly reacting to -EPROBE_DEFER postpones DP initialization by
>> approximately 1.5 second. Is there a good way to handle that? As it
>> stands, this isn't usable.
>
> How much is 1.5 seconds compared to the overall boot time of the device?

1.5s is 15-20% of my boot time (if you count the boot time from
firmware start to login prompt, otherwise it's more). Note that on
other platforms, we've seen this take as much as 5 or 6s, but for the
exynos case it is "only" 1.5s.

> What exactly is causing this 1.5 second delay?

A regulator isn't ready, and then drm_panel returns defer. Then the
whole drm driver init is deferred.

>
> This really is a fundamental issue with deferred probing and the issue
> has come up several times in the past. A couple of possible solutions
> have been proposed, with the latest being here[0] I think. That ended in
> a bit of a debacle, unfortunately, but on of the outcomes was that a lot
> of the ordering problems could be fixed by using phandle references to
> track dependencies. I'm not aware of anyone working on that right now,
> presumably be

Re: [PATCH v7 11/11] clk: rockchip: add restart handler

[Heiko Stübner]

Am Mittwoch, 20. August 2014, 21:15:10 schrieb Doug Anderson:
> Guenter / Heiko,
> 
> On Tue, Aug 19, 2014 at 5:45 PM, Guenter Roeck  wrote:
> > From: Heiko Stübner 
> > 
> > Add infrastructure to write the correct value to the restart register and
> > register the restart notifier for both rk3188 (including rk3066) and
> > rk3288.
> > 
> > Signed-off-by: Heiko Stuebner 
> > Signed-off-by: Guenter Roeck 
> > ---
> > v7: Added patch to series.
> > 
> >  drivers/clk/rockchip/clk-rk3188.c |  2 ++
> >  drivers/clk/rockchip/clk-rk3288.c |  2 ++
> >  drivers/clk/rockchip/clk.c| 25 +
> >  drivers/clk/rockchip/clk.h|  1 +
> >  4 files changed, 30 insertions(+)
> 
> This patch doesn't apply cleanly with the in-flight (clk: rockchip:
> protect critical clocks from getting disabled) patch from Heiko.  It's
> trivial to resolve and unclear which will land first, so I think it's
> fine...

This should be expected :-) .

The patch about critical clocks will (hopefully soon) go through Mike's tree, 
while this series will most likely go through somewhere else (Linus' tree 
directly or something), so I guess the merge conflic will be resolved by Linus 
when both trees meet each other during the merge window.
So both this patch as well as the other one should stay independent of each 
other.


Heiko
--
To unsubscribe from this list: send the line "unsubscribe linux-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 4/9] drm/exynos: add exynos_dp_panel driver registration to drm driver

[Thierry Reding]

On Tue, Aug 19, 2014 at 09:02:39PM -0700, Stéphane Marchesin wrote:
> On Tue, Apr 22, 2014 at 8:26 AM, Thierry Reding
>  wrote:
> > On Tue, Apr 22, 2014 at 08:33:23PM +0530, Ajay kumar wrote:
> >> Hi Thierry,
> >>
> >> On Tue, Apr 22, 2014 at 2:03 PM, Thierry Reding
> >>  wrote:
> >> > On Tue, Apr 22, 2014 at 04:09:13AM +0530, Ajay Kumar wrote:
> >> >> Register exynos_dp_panel before the list of exynos crtcs and
> >> >> connectors are probed.
> >> >>
> >> >> This is needed because exynos_dp_panel should be registered to
> >> >> the drm_panel list via panel-exynos-dp probe, i.e much before
> >> >> exynos_dp_bind calls of_drm_find_panel().
> >> >>
> >> >> Signed-off-by: Ajay Kumar 
> >> >> ---
> >> >> Changes since V1:
> >> >>   Added platform_driver_unregister(&exynos_dp_panel_driver) to
> >> >>   exynos_drm_platform_remove as per Jingoo Han's correction
> >> >>
> >> >>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   15 +++
> >> >>  drivers/gpu/drm/exynos/exynos_drm_drv.h |1 +
> >> >>  2 files changed, 16 insertions(+)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> >> >> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> >> >> index 1d653f8..2db7f67 100644
> >> >> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> >> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> >> >> @@ -530,12 +530,23 @@ static int exynos_drm_platform_probe(struct 
> >> >> platform_device *pdev)
> >> >>   goto err_unregister_ipp_drv;
> >> >>  #endif
> >> >>
> >> >> +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP
> >> >> + ret = platform_driver_register(&exynos_dp_panel_driver);
> >> >> + if (ret < 0)
> >> >> + goto err_unregister_dp_panel;
> >> >> +#endif
> >> >
> >> > No, this is not how you're supposed to use DRM panel drivers. The idea
> >> > is that you write a standalone driver for a given panel.
> >> >
> >> > What you do here has a number of problems. For one it's a driver that's
> >> > tightly coupled to Exynos SoCs. But if I have a different SoC that uses
> >> > the same panel I want to be able to use the same driver, and not have to
> >> > rewrite the driver for my SoC.
> >> >
> >> > Another problem is that you're assuming here that the driver is built in
> >> > and it will break if you try to build either Exynos DRM or the panel
> >> > driver as a module. This is perhaps nothing you care about right now,
> >> > but eventually people will want to ship a single kernel that can run on
> >> > a number of SoCs. But if we keep adding things like this, that kernel
> >> > will keep growing in size until it no longer fits in any kind of memory.
> >> >
> >> > Thierry
> >>
> >> I completely agree with you in this!
> >>
> >> Yes, this is not acceptable, but I want to know an "acceptable"
> >> workaround for the situation below:
> >> I register the driver using module_init().
> >> And, exynos_drm gets probed much before the panel driver probe happens.
> >> So, the panel driver hasn't probed yet, but exynos_dp via exynos_drm
> >> tries to call
> >> "of_drm_find_panel" which always returns NULL.
> >
> > That's a situation that your driver needs to be able to deal with. The
> > driver registration order doesn't matter one bit. It may happen to work
> > most of the time, but as soon as one of the resources that your panel
> > driver needs isn't there when the panel is probed, then it won't be
> > registered and of_drm_find_panel() will still return NULL.
> >
> > Usually the right thing to do in that case would be to return (and
> > propagate) -EPROBE_DEFER so that your driver's probe is deferred and
> > retried when other drivers have been probed. That way it should
> > eventually get a non-NULL panel.
> 
> So I just gave this (drm_panel + probe deferring) a shot on exynos,
> and correctly reacting to -EPROBE_DEFER postpones DP initialization by
> approximately 1.5 second. Is there a good way to handle that? As it
> stands, this isn't usable.

How much is 1.5 seconds compared to the overall boot time of the device?
What exactly is causing this 1.5 second delay?

This really is a fundamental issue with deferred probing and the issue
has come up several times in the past. A couple of possible solutions
have been proposed, with the latest being here[0] I think. That ended in
a bit of a debacle, unfortunately, but on of the outcomes was that a lot
of the ordering problems could be fixed by using phandle references to
track dependencies. I'm not aware of anyone working on that right now,
presumably because everyone is busy getting features merged rather than
optimizing boot speed.

Thierry

[0]: https://lkml.org/lkml/2014/5/12/452


pgpl7GgpoqF36.pgp
Description: PGP signature