Re: [PATCH 2/3] Phy: Exynos: Add Exynos5250 sata phy driver
On Friday 15 November 2013 11:17 AM, Yuvaraj Kumar wrote:
> On Thu, Nov 14, 2013 at 11:18 AM, Kishon Vijay Abraham I
> wrote:
>> Hi,
>>
>> On Monday 07 October 2013 07:35 PM, Yuvaraj Cd wrote:
>>> On Tue, Oct 1, 2013 at 6:21 PM, Kishon Vijay Abraham I
>>> wrote:
On Tuesday 01 October 2013 12:03 PM, Yuvaraj Kumar C D wrote:
> This patch adds the sata phy driver for Exynos5250.Exynos5250 sata
> phy comprises of CMU and TRSV blocks which are of I2C register Map.
> So this patch also adds a i2c client driver, which is used configure
> the CMU and TRSV block of exynos5250 SATA PHY.
Why not make the Exynos5250 sata phy as a i2c client driver instead?
>
> This patch incorporates the generic phy framework to deal with sata
> phy.
>
> This patch depends on the below patch
> [1].drivers: phy: add generic PHY framework
> by Kishon Vijay Abraham I
>
> Signed-off-by: Yuvaraj Kumar C D
> Signed-off-by: Girish K S
> Signed-off-by: Vasanth Ananthan
> ---
> drivers/phy/Kconfig |6 +
> drivers/phy/Makefile |1 +
> drivers/phy/exynos/Kconfig |5 +
> drivers/phy/exynos/Makefile |5 +
> drivers/phy/exynos/exynos5250_phy_i2c.c | 53 +++
> drivers/phy/exynos/sata_phy_exynos5250.c | 248
> ++
> drivers/phy/exynos/sata_phy_exynos5250.h | 33
> 7 files changed, 351 insertions(+)
> create mode 100644 drivers/phy/exynos/Kconfig
> create mode 100644 drivers/phy/exynos/Makefile
> create mode 100644 drivers/phy/exynos/exynos5250_phy_i2c.c
> create mode 100644 drivers/phy/exynos/sata_phy_exynos5250.c
> create mode 100644 drivers/phy/exynos/sata_phy_exynos5250.h
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 5f85909..ab3d1c6 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -11,3 +11,9 @@ menuconfig GENERIC_PHY
> devices present in the kernel. This layer will have the generic
> API by which phy drivers can create PHY using the phy framework
> and
> phy users can obtain reference to the PHY.
> +
> +if GENERIC_PHY
NAK. Just select GENERIC_PHY from your driver Kconfig.
> +
> +source "drivers/phy/exynos/Kconfig"
> +
> +endif
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 9e9560f..e0223d7 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -3,3 +3,4 @@
> #
>
> obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
> +obj-$(CONFIG_PHY_SAMSUNG_SATA) += exynos/
simply have phy-exynos5250 in drivers/phy.
>>> ok.
> diff --git a/drivers/phy/exynos/Kconfig b/drivers/phy/exynos/Kconfig
> new file mode 100644
> index 000..fa125fb
> --- /dev/null
> +++ b/drivers/phy/exynos/Kconfig
> @@ -0,0 +1,5 @@
> +config PHY_SAMSUNG_SATA
> + tristate "Samsung Sata SerDes/PHY driver"
> + help
> + Support for Samsung sata SerDes/Phy found on Samsung
> + SoCs.
> diff --git a/drivers/phy/exynos/Makefile b/drivers/phy/exynos/Makefile
> new file mode 100644
> index 000..50dc7eb
> --- /dev/null
> +++ b/drivers/phy/exynos/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for the exynos phy drivers.
> +#
> +ccflags-y := -Idrivers/phy/exynos
> +obj-$(CONFIG_PHY_SAMSUNG_SATA) += sata_phy_exynos5250.o
> exynos5250_phy_i2c.o
> diff --git a/drivers/phy/exynos/exynos5250_phy_i2c.c
> b/drivers/phy/exynos/exynos5250_phy_i2c.c
> new file mode 100644
> index 000..9c75d3b
> --- /dev/null
> +++ b/drivers/phy/exynos/exynos5250_phy_i2c.c
> @@ -0,0 +1,53 @@
> +/*
> + * Copyright (C) 2013 Samsung Electronics Co.Ltd
> + * Author:
> + * Yuvaraj C D
> + *
> + * This program is free software; you can redistribute it and/or modify
> it
> + * under the terms of the GNU General Public License as published by
> the
> + * Free Software Foundation; either version 2 of the License, or (at
> your
> + * option) any later version.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include "sata_phy_exynos5250.h"
> +
> +static int exynos_sata_i2c_probe(struct i2c_client *client,
> + const struct i2c_device_id *i2c_id)
> +{
> + sataphy_attach_i2c_client(client);
> +
> + dev_info(&client->adapter->dev,
> + "attached %s into i2c adapter successfully\n",
> + client->name);
> +
> + return 0;
> +}
> +
> +static int exynos_sata_i2c_remove(struct i2c_client *client)
> +{
> + dev_info(&client->adapter->dev,
> + "detached %s from i2c
Re: [PATCH 2/3] Phy: Exynos: Add Exynos5250 sata phy driver
On Tue, Nov 19, 2013 at 3:22 PM, Kishon Vijay Abraham I wrote:
> On Friday 15 November 2013 11:17 AM, Yuvaraj Kumar wrote:
>> On Thu, Nov 14, 2013 at 11:18 AM, Kishon Vijay Abraham I
>> wrote:
>>> Hi,
>>>
>>> On Monday 07 October 2013 07:35 PM, Yuvaraj Cd wrote:
On Tue, Oct 1, 2013 at 6:21 PM, Kishon Vijay Abraham I
wrote:
> On Tuesday 01 October 2013 12:03 PM, Yuvaraj Kumar C D wrote:
>> This patch adds the sata phy driver for Exynos5250.Exynos5250 sata
>> phy comprises of CMU and TRSV blocks which are of I2C register Map.
>> So this patch also adds a i2c client driver, which is used configure
>> the CMU and TRSV block of exynos5250 SATA PHY.
>
> Why not make the Exynos5250 sata phy as a i2c client driver instead?
>>
>> This patch incorporates the generic phy framework to deal with sata
>> phy.
>>
>> This patch depends on the below patch
>> [1].drivers: phy: add generic PHY framework
>> by Kishon Vijay Abraham I
>>
>> Signed-off-by: Yuvaraj Kumar C D
>> Signed-off-by: Girish K S
>> Signed-off-by: Vasanth Ananthan
>> ---
>> drivers/phy/Kconfig |6 +
>> drivers/phy/Makefile |1 +
>> drivers/phy/exynos/Kconfig |5 +
>> drivers/phy/exynos/Makefile |5 +
>> drivers/phy/exynos/exynos5250_phy_i2c.c | 53 +++
>> drivers/phy/exynos/sata_phy_exynos5250.c | 248
>> ++
>> drivers/phy/exynos/sata_phy_exynos5250.h | 33
>> 7 files changed, 351 insertions(+)
>> create mode 100644 drivers/phy/exynos/Kconfig
>> create mode 100644 drivers/phy/exynos/Makefile
>> create mode 100644 drivers/phy/exynos/exynos5250_phy_i2c.c
>> create mode 100644 drivers/phy/exynos/sata_phy_exynos5250.c
>> create mode 100644 drivers/phy/exynos/sata_phy_exynos5250.h
>>
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 5f85909..ab3d1c6 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -11,3 +11,9 @@ menuconfig GENERIC_PHY
>> devices present in the kernel. This layer will have the generic
>> API by which phy drivers can create PHY using the phy framework
>> and
>> phy users can obtain reference to the PHY.
>> +
>> +if GENERIC_PHY
>
> NAK. Just select GENERIC_PHY from your driver Kconfig.
>> +
>> +source "drivers/phy/exynos/Kconfig"
>> +
>> +endif
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index 9e9560f..e0223d7 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -3,3 +3,4 @@
>> #
>>
>> obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
>> +obj-$(CONFIG_PHY_SAMSUNG_SATA) += exynos/
>
> simply have phy-exynos5250 in drivers/phy.
ok.
>> diff --git a/drivers/phy/exynos/Kconfig b/drivers/phy/exynos/Kconfig
>> new file mode 100644
>> index 000..fa125fb
>> --- /dev/null
>> +++ b/drivers/phy/exynos/Kconfig
>> @@ -0,0 +1,5 @@
>> +config PHY_SAMSUNG_SATA
>> + tristate "Samsung Sata SerDes/PHY driver"
>> + help
>> + Support for Samsung sata SerDes/Phy found on Samsung
>> + SoCs.
>> diff --git a/drivers/phy/exynos/Makefile b/drivers/phy/exynos/Makefile
>> new file mode 100644
>> index 000..50dc7eb
>> --- /dev/null
>> +++ b/drivers/phy/exynos/Makefile
>> @@ -0,0 +1,5 @@
>> +#
>> +# Makefile for the exynos phy drivers.
>> +#
>> +ccflags-y := -Idrivers/phy/exynos
>> +obj-$(CONFIG_PHY_SAMSUNG_SATA) += sata_phy_exynos5250.o
>> exynos5250_phy_i2c.o
>> diff --git a/drivers/phy/exynos/exynos5250_phy_i2c.c
>> b/drivers/phy/exynos/exynos5250_phy_i2c.c
>> new file mode 100644
>> index 000..9c75d3b
>> --- /dev/null
>> +++ b/drivers/phy/exynos/exynos5250_phy_i2c.c
>> @@ -0,0 +1,53 @@
>> +/*
>> + * Copyright (C) 2013 Samsung Electronics Co.Ltd
>> + * Author:
>> + * Yuvaraj C D
>> + *
>> + * This program is free software; you can redistribute it and/or
>> modify it
>> + * under the terms of the GNU General Public License as published by
>> the
>> + * Free Software Foundation; either version 2 of the License, or (at
>> your
>> + * option) any later version.
>> + *
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include "sata_phy_exynos5250.h"
>> +
>> +static int exynos_sata_i2c_probe(struct i2c_client *client,
>> + const struct i2c_device_id *i2c_id)
>> +{
>> + sataphy_attach_i2c_client(client);
>> +
>> + dev_info(&client->adapter->dev,
>> + "attached %s into i2c adapter successfully\n",
>> + client->name);
>> +
>>
Re: [PATCH 2/3] Phy: Exynos: Add Exynos5250 sata phy driver
On Tuesday 19 November 2013 03:42 PM, Yuvaraj Kumar wrote:
> On Tue, Nov 19, 2013 at 3:22 PM, Kishon Vijay Abraham I wrote:
>> On Friday 15 November 2013 11:17 AM, Yuvaraj Kumar wrote:
>>> On Thu, Nov 14, 2013 at 11:18 AM, Kishon Vijay Abraham I
>>> wrote:
Hi,
On Monday 07 October 2013 07:35 PM, Yuvaraj Cd wrote:
> On Tue, Oct 1, 2013 at 6:21 PM, Kishon Vijay Abraham I
> wrote:
>> On Tuesday 01 October 2013 12:03 PM, Yuvaraj Kumar C D wrote:
>>> This patch adds the sata phy driver for Exynos5250.Exynos5250 sata
>>> phy comprises of CMU and TRSV blocks which are of I2C register Map.
>>> So this patch also adds a i2c client driver, which is used configure
>>> the CMU and TRSV block of exynos5250 SATA PHY.
>>
>> Why not make the Exynos5250 sata phy as a i2c client driver instead?
>>>
>>> This patch incorporates the generic phy framework to deal with sata
>>> phy.
>>>
>>> This patch depends on the below patch
>>> [1].drivers: phy: add generic PHY framework
>>> by Kishon Vijay Abraham I
>>>
>>> Signed-off-by: Yuvaraj Kumar C D
>>> Signed-off-by: Girish K S
>>> Signed-off-by: Vasanth Ananthan
>>> ---
>>> drivers/phy/Kconfig |6 +
>>> drivers/phy/Makefile |1 +
>>> drivers/phy/exynos/Kconfig |5 +
>>> drivers/phy/exynos/Makefile |5 +
>>> drivers/phy/exynos/exynos5250_phy_i2c.c | 53 +++
>>> drivers/phy/exynos/sata_phy_exynos5250.c | 248
>>> ++
>>> drivers/phy/exynos/sata_phy_exynos5250.h | 33
>>> 7 files changed, 351 insertions(+)
>>> create mode 100644 drivers/phy/exynos/Kconfig
>>> create mode 100644 drivers/phy/exynos/Makefile
>>> create mode 100644 drivers/phy/exynos/exynos5250_phy_i2c.c
>>> create mode 100644 drivers/phy/exynos/sata_phy_exynos5250.c
>>> create mode 100644 drivers/phy/exynos/sata_phy_exynos5250.h
>>>
>>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>>> index 5f85909..ab3d1c6 100644
>>> --- a/drivers/phy/Kconfig
>>> +++ b/drivers/phy/Kconfig
>>> @@ -11,3 +11,9 @@ menuconfig GENERIC_PHY
>>> devices present in the kernel. This layer will have the generic
>>> API by which phy drivers can create PHY using the phy framework
>>> and
>>> phy users can obtain reference to the PHY.
>>> +
>>> +if GENERIC_PHY
>>
>> NAK. Just select GENERIC_PHY from your driver Kconfig.
>>> +
>>> +source "drivers/phy/exynos/Kconfig"
>>> +
>>> +endif
>>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>>> index 9e9560f..e0223d7 100644
>>> --- a/drivers/phy/Makefile
>>> +++ b/drivers/phy/Makefile
>>> @@ -3,3 +3,4 @@
>>> #
>>>
>>> obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
>>> +obj-$(CONFIG_PHY_SAMSUNG_SATA) += exynos/
>>
>> simply have phy-exynos5250 in drivers/phy.
> ok.
>>> diff --git a/drivers/phy/exynos/Kconfig b/drivers/phy/exynos/Kconfig
>>> new file mode 100644
>>> index 000..fa125fb
>>> --- /dev/null
>>> +++ b/drivers/phy/exynos/Kconfig
>>> @@ -0,0 +1,5 @@
>>> +config PHY_SAMSUNG_SATA
>>> + tristate "Samsung Sata SerDes/PHY driver"
>>> + help
>>> + Support for Samsung sata SerDes/Phy found on Samsung
>>> + SoCs.
>>> diff --git a/drivers/phy/exynos/Makefile b/drivers/phy/exynos/Makefile
>>> new file mode 100644
>>> index 000..50dc7eb
>>> --- /dev/null
>>> +++ b/drivers/phy/exynos/Makefile
>>> @@ -0,0 +1,5 @@
>>> +#
>>> +# Makefile for the exynos phy drivers.
>>> +#
>>> +ccflags-y := -Idrivers/phy/exynos
>>> +obj-$(CONFIG_PHY_SAMSUNG_SATA) += sata_phy_exynos5250.o
>>> exynos5250_phy_i2c.o
>>> diff --git a/drivers/phy/exynos/exynos5250_phy_i2c.c
>>> b/drivers/phy/exynos/exynos5250_phy_i2c.c
>>> new file mode 100644
>>> index 000..9c75d3b
>>> --- /dev/null
>>> +++ b/drivers/phy/exynos/exynos5250_phy_i2c.c
>>> @@ -0,0 +1,53 @@
>>> +/*
>>> + * Copyright (C) 2013 Samsung Electronics Co.Ltd
>>> + * Author:
>>> + * Yuvaraj C D
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> modify it
>>> + * under the terms of the GNU General Public License as published
>>> by the
>>> + * Free Software Foundation; either version 2 of the License, or (at
>>> your
>>> + * option) any later version.
>>> + *
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include "sata_phy_exynos5250.h"
>>> +
>>> +static int exynos_sata_i2c_probe(struct i2c_client *client,
>>> + const struct i2c_device_id *i2c_id)
>>> +{
>>> + sataphy_attach_i2c_clie
Re: [PATCH] ARM: move firmware_ops to drivers/firmware
On Mon, Nov 18, 2013 at 07:04:50PM +, Christopher Covington wrote: > On 11/18/2013 12:30 PM, Catalin Marinas wrote: > [...] > > You can't run legacy AArch32 code at EL3 and have lower levels in AArch64 > > mode (architectural constraint). > > What prevents AArch32 code from running at EL3 and then requesting a reset to > AArch64 by writing to the Reset Management Register before sliding down to > lower exception levels? You can do this for some initial code but the firmware still needs to switch to AArch64 before dropping to lower exception levels. What this thread is about is run-time calls to firmware for booting secondary CPUs, idle, l2x0. At this point, the code at EL3 must run in AArch64 mode. There is no way you can bounce between AArch32 and AArch64 modes using reset just to handle some SMCs. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: move firmware_ops to drivers/firmware
On Mon, Nov 18, 2013 at 05:52:36PM +, Stephen Warren wrote: > On 11/18/2013 10:30 AM, Catalin Marinas wrote: > > On Mon, Nov 18, 2013 at 05:03:37PM +, Stephen Warren wrote: > >> On 11/18/2013 04:58 AM, Catalin Marinas wrote: > >> ... > >>> Of course, trusted foundations interface could be plugged into cpu_ops > >>> on arm64 but I will NAK it on the grounds of not using the PSCI API, nor > >>> the SMC calling convention (and it's easy to fix when porting to ARMv8). > >>> If a supported standard API is used, then there is no need for > >>> additional code in the kernel. > >> > >> What happens when someone takes an existing working secure-mode SW stack > >> and simply re-uses it on some new ARMv8 SoC. Are you going to force > >> people working on upstream to re-write the secure mode firmware in > >> shipped hardware before allowing upstream kernel support? > > > > Don't confuse the secure stack with the secure monitor running at EL3. > > If you want AArch64 support for lower levels (EL2, EL1, EL0), your > > monitor _must_ be AArch64. You can't run legacy AArch32 code at EL3 and > > have lower levels in AArch64 mode (architectural constraint). > > I was assuming that vendors would take the existing source code and > simply rebuild it to create the AArch64 secure world. Some C code can probably be reused but not the EL3 entry/exit code, world switching and AArch64 initialisation. The main differences in ARMv8 EL3 is that it has its own MMU and it can only be entered via SMC and exit via ERET (you can no longer switch from/to secure SVC by writing to CPSR). So apart from a different instruction set, the new exception model requires a rewrite of the secure monitor logic used to handle SMCs, switch worlds, pass arguments between worlds. > As such, the same SMC IDs, same structures, etc. would be used. The > only source difference would be to perhaps change some 32-bit > registers/struct-fields up to 64-bit. Naively that sounds like the > lowest-effort way to get an AArch64 secure world, so I'm purely > guessing that that's what vendors will do. It looks simpler in theory until you hit the new exception model and realise the clear separation between EL3 (previously secure monitor) and secure EL1 (previously secure SVC). I'm not referring to the whole secure stack here, just the things I mentioned above. > > You can > > still keep the secure services at S-EL1 in AArch32, only that the SMCs > > are handled by EL3 (and that's another aspect the SMC calling convention > > spec is trying to address, mixed register-width secure/non-secure OSes). > > I'm not sure of the implications of that statement. Since you mention > SMCs being handled by EL3, I think the quick-and-dirty conversion I > mention above is still likely to be used. What I meant is that a secure OS (providing cryptography, banking etc. services) can run in secure EL1 in AArch32 mode, it does not need to be converted (though it helps from a performance perspective, new instructions). But the world switching (which is pretty tightly coupled with secure SVC on ARMv7) and SMC handling need to be rewritten. And it's usually EL3 where you would place power management firmware on ARMv8 (cache/TLB maintenance, power controller access). This is usually done by the SoC vendor and not the secure OS provider (the latter may do the final link). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: move firmware_ops to drivers/firmware
On Tue, Nov 19, 2013 at 02:46:55AM +, Alex Courbot wrote:
> On 11/18/2013 08:58 PM, Catalin Marinas wrote:
> > On Mon, Nov 18, 2013 at 03:05:59AM +, Alex Courbot wrote:
> >> On 11/18/2013 12:59 AM, Catalin Marinas wrote:
> >>> On 17 November 2013 08:49, Alexandre Courbot wrote:
> The ARM tree includes a firmware_ops interface that is designed to
> implement support for simple, TrustZone-based firmwares but could
> also cover other use-cases. It has been suggested that this
> interface might be useful to other architectures (e.g. arm64) and
> that it should be moved out of arch/arm.
> >>>
> >>> NAK. I'm for code sharing with arm via common locations but this API
> >>> goes against the ARMv8 firmware standardisation efforts like PSCI,
> >>> encouraging each platform to define there own non-standard interface.
> >>
> >> I have to say, I pretty much agree with your NAK.
> >>
> >> The reason for this patch is that the suggestion to move firmware_ops
> >> out of arch/arm is the last (I hope) thing that prevents my Trusted
> >> Foundation support series from being merged.
> >
> > Moving it into drivers shouldn't be a workaround. Nice try ;).
>
> Hehe. I thought that just sending a patch would settle the issue one way
> or the other and avoid a huge discussion. Woke up this morning to see
> how wrong I was.
It's a sensitive topic ;).
> > BTW, is legacy code the reason for not converting the SMC # to PSCI?
> > It's already supported on ARMv7, so you may not have much code left to
> > merge in the kernel ;).
>
> The problem here is twofold:
>
> 1) we are just consumers of the TrustZone secure monitor who receive a
> binary and do not have any control over its calling conventions. I agree
> that it would be trivial to make it compatible with PSCI, but it's just
> not something we can make by ourselves (TF does not even follow the SMC
> calling convention). If this problem is to be addressed, it should be
> done by forcing the TrustZone secure monitors providers to follow PSCI.
I agree and such discussions do happen ('forcing' is a bit harder, more
like 'strongly recommending'). On my side, I voice this message via the
Linux channels, so SoC vendors can also encourage their secure provider
in this direction. The benefit is that the Linux changes are minimal
afterwards, single image is easier.
But as I replied to Stephen, make sure you separate the secure OS (EL1)
from the secure firmware (EL3). The latter (or parts of it) are provided
by the SoC vendor (e.g. NVidia) and may be eventually linked into a big
blob by the secure OS provider. ARM is encouraging separation here and a
multi-stage firmware loading approach (and ARM started a public generic
firmware project, it's in the early days now).
> 2) devices have already shipped with this firmware. Are we going to just
> renounce supporting them, even though the necessary support is
> lightweight and fits within already existing interfaces?
I'm talking only about ARMv8 here. Please see my reply to Stephen for
the details of (not) reusing existing firmware.
> I certainly do hope that for ARMv8 things will be different and more
> standardized. But that's not something that can be guaranteed unless ARM
> strongly enforces it to firmware vendors. In case such a non-standard
> firmware gets used again, I *do* hope that using cpu_ops will be
> preferred over saying "this device cannot be supported in mainline, ever".
cpu_ops or firmware_ops is just a name and can be unified (TBD what
common functionality it contains). What I don't want to encourage is
each SoC registering its own firmware interface.
> The kernel already supports non-standard hardware, BIOS, ACPI through
> hacks that are *way* more horrible than that. This should certainly not
> be encouraged, but that's not a valid reason to forbid otherwise
> perfectly fine devices to run mainline IMHO.
So you say we should just stop trying to standardise anything because
people don't care anyway. Why do we even bother with DT (or ACPI) since
board files were fine in the past (with a bit more code)?
> >> * that should a need to move it (for whatever reason) occur later, it
> >> will be easy to do (as this patch hopefully demonstrates).
> >
> > I agree, it's not hard to unify this but so far I haven't seen a good
> > reason.
>
> Same here. arm64 has its own cpu_operations. Other archs have different
> needs and if we move this to a common place it will just become a messy
> placeholder for function pointers from which each arch will only use a
> subset.
That was my initial point but it turned into a thread against PSCI
(again ;)).
--
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4 v10] thermal: samsung: replace inten_ bit fields with intclr_
This patch replaces the inten_rise_shift/mask and inten_fall_shift/mask
with intclr_rise_shift/mask and intclr_fall_shift/mask respectively.
Currently, inten_rise_shift/mask and inten_fall_shift/mask bits are only used
to configure intclr related registers.
Description of H/W:
The offset for the bits in the CLEAR register are not consistent across TMU
modules in Exynso5250, 5420 and 5440.
On Exynos5250, the FALL interrupt related en, status and clear bits are
available at an offset of
16 in INTEN, INTSTAT registers and at an offset of
12 in INTCLEAR register.
On Exynos5420, the FALL interrupt related en, status and clear bits are
available at an offset of
16 in INTEN, INTSTAT and INTCLEAR registers.
On Exynos5440,
the FALL_IRQEN bits are at an offset of 4
and the RISE_IRQEN bits are at an offset of 0
Signed-off-by: Naveen Krishna Chatradhi
Acked-by: Amit Daniel Kachhap
Reviewed-by: Bartlomiej Zolnierkiewicz
---
Changes since v9:
Just respinning
Changes since v8:
1. Modified the patch description,
2. replaces the inten_rise/fall_shift/mask with intclr_rise/fall_shift/mask
drivers/thermal/samsung/exynos_tmu.c |6 +++---
drivers/thermal/samsung/exynos_tmu.h | 16
drivers/thermal/samsung/exynos_tmu_data.c | 18 +-
drivers/thermal/samsung/exynos_tmu_data.h |4 ++--
4 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 32f38b9..c493245 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -237,7 +237,7 @@ skip_calib_data:
writeb(pdata->trigger_levels[i], data->base +
reg->threshold_th0 + i * sizeof(reg->threshold_th0));
- writel(reg->inten_rise_mask, data->base + reg->tmu_intclear);
+ writel(reg->intclr_rise_mask, data->base + reg->tmu_intclear);
} else {
/* Write temperature code for rising and falling threshold */
for (i = 0;
@@ -264,8 +264,8 @@ skip_calib_data:
writel(falling_threshold,
data->base + reg->threshold_th1);
- writel((reg->inten_rise_mask << reg->inten_rise_shift) |
- (reg->inten_fall_mask << reg->inten_fall_shift),
+ writel((reg->intclr_rise_mask << reg->intclr_rise_shift) |
+ (reg->intclr_fall_mask << reg->intclr_fall_shift),
data->base + reg->tmu_intclear);
/* if last threshold limit is also present */
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index 3fb6554..980859a 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -122,10 +122,6 @@ enum soc_type {
* @threshold_th3_l0_shift: shift bits of level0 threshold temperature.
* @tmu_inten: register containing the different threshold interrupt
enable bits.
- * @inten_rise_shift: shift bits of all rising interrupt bits.
- * @inten_rise_mask: mask bits of all rising interrupt bits.
- * @inten_fall_shift: shift bits of all rising interrupt bits.
- * @inten_fall_mask: mask bits of all rising interrupt bits.
* @inten_rise0_shift: shift bits of rising 0 interrupt bits.
* @inten_rise1_shift: shift bits of rising 1 interrupt bits.
* @inten_rise2_shift: shift bits of rising 2 interrupt bits.
@@ -136,6 +132,10 @@ enum soc_type {
* @inten_fall3_shift: shift bits of falling 3 interrupt bits.
* @tmu_intstat: Register containing the interrupt status values.
* @tmu_intclear: Register for clearing the raised interrupt status.
+ * @intclr_fall_shift: shift bits for interrupt clear fall 0
+ * @intclr_rise_shift: shift bits of all rising interrupt bits.
+ * @intclr_rise_mask: mask bits of all rising interrupt bits.
+ * @intclr_fall_mask: mask bits of all rising interrupt bits.
* @emul_con: TMU emulation controller register.
* @emul_temp_shift: shift bits of emulation temperature.
* @emul_time_shift: shift bits of emulation time.
@@ -191,10 +191,6 @@ struct exynos_tmu_registers {
u32 threshold_th3_l0_shift;
u32 tmu_inten;
- u32 inten_rise_shift;
- u32 inten_rise_mask;
- u32 inten_fall_shift;
- u32 inten_fall_mask;
u32 inten_rise0_shift;
u32 inten_rise1_shift;
u32 inten_rise2_shift;
@@ -207,6 +203,10 @@ struct exynos_tmu_registers {
u32 tmu_intstat;
u32 tmu_intclear;
+ u32 intclr_fall_shift;
+ u32 intclr_rise_shift;
+ u32 intclr_fall_mask;
+ u32 intclr_rise_mask;
u32 emul_con;
u32 emul_temp_shift;
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
index 073c292..7cdb04e 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/d
[PATCH 2/4 v10] thermal: samsung: change base_common to more meaningful base_second
On Exynos5440 and Exynos5420 there are registers common
across the TMU channels.
To support that, we introduced a ADDRESS_MULTIPLE flag in the
driver and the 2nd set of register base and size are provided
in the "reg" property of the node.
As per Amit's suggestion, this patch changes the base_common
to base_second and SHARED_MEMORY to ADDRESS_MULTIPLE.
Signed-off-by: Naveen Krishna Chatradhi
Acked-by: Amit Daniel Kachhap
Reviewed-by: Bartlomiej Zolnierkiewicz
---
Changes since v9:
Just respinning
Changes since v8:
None
.../devicetree/bindings/thermal/exynos-thermal.txt |4 ++--
drivers/thermal/samsung/exynos_tmu.c | 14 +++---
drivers/thermal/samsung/exynos_tmu.h |4 ++--
drivers/thermal/samsung/exynos_tmu_data.c|2 +-
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 284f530..116cca0 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -11,8 +11,8 @@
- reg : Address range of the thermal registers. For soc's which has multiple
instances of TMU and some registers are shared across all TMU's like
interrupt related then 2 set of register has to supplied. First set
- belongs to each instance of TMU and second set belongs to common TMU
- registers.
+ belongs to each instance of TMU and second set belongs to second set
+ of common TMU registers.
- interrupts : Should contain interrupt for thermal system
- clocks : The main clock for TMU device
- clock-names : Thermal system clock name
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index c493245..bbd0fc3 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -41,7 +41,7 @@
* @id: identifier of the one instance of the TMU controller.
* @pdata: pointer to the tmu platform/configuration data
* @base: base address of the single instance of the TMU controller.
- * @base_common: base address of the common registers of the TMU controller.
+ * @base_second: base address of the common registers of the TMU controller.
* @irq: irq number of the TMU controller.
* @soc: id of the SOC type.
* @irq_work: pointer to the irq work structure.
@@ -56,7 +56,7 @@ struct exynos_tmu_data {
int id;
struct exynos_tmu_platform_data *pdata;
void __iomem *base;
- void __iomem *base_common;
+ void __iomem *base_second;
int irq;
enum soc_type soc;
struct work_struct irq_work;
@@ -297,7 +297,7 @@ skip_calib_data:
}
/*Clear the PMIN in the common TMU register*/
if (reg->tmu_pmin && !data->id)
- writel(0, data->base_common + reg->tmu_pmin);
+ writel(0, data->base_second + reg->tmu_pmin);
out:
clk_disable(data->clk);
mutex_unlock(&data->lock);
@@ -454,7 +454,7 @@ static void exynos_tmu_work(struct work_struct *work)
/* Find which sensor generated this interrupt */
if (reg->tmu_irqstatus) {
- val_type = readl(data->base_common + reg->tmu_irqstatus);
+ val_type = readl(data->base_second + reg->tmu_irqstatus);
if (!((val_type >> data->id) & 0x1))
goto out;
}
@@ -579,7 +579,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
* Check if the TMU shares some registers and then try to map the
* memory of common registers.
*/
- if (!TMU_SUPPORTS(pdata, SHARED_MEMORY))
+ if (!TMU_SUPPORTS(pdata, ADDRESS_MULTIPLE))
return 0;
if (of_address_to_resource(pdev->dev.of_node, 1, &res)) {
@@ -587,9 +587,9 @@ static int exynos_map_dt_data(struct platform_device *pdev)
return -ENODEV;
}
- data->base_common = devm_ioremap(&pdev->dev, res.start,
+ data->base_second = devm_ioremap(&pdev->dev, res.start,
resource_size(&res));
- if (!data->base_common) {
+ if (!data->base_second) {
dev_err(&pdev->dev, "Failed to ioremap memory\n");
return -ENOMEM;
}
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index 980859a..0d6b32f 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -60,7 +60,7 @@ enum soc_type {
* state(active/idle) can be checked.
* TMU_SUPPORT_EMUL_TIME - This features allows to set next temp emulation
* sample time.
- * TMU_SUPPORT_SHARED_MEMORY - This feature tells that the different TMU
+ * TMU_SUPPORT_ADDRESS_MULTIPLE - This feature tells that the different TMU
* sensors share
[PATCH 3/4 v10] thermal: samsung: Add TMU support for Exynos5420 SoCs
Exynos5420 has 5 TMU channels, the TRIMINFO register is
misplaced for TMU channels 2, 3 and 4
TRIMINFO at 0x1006c000 contains data for TMU channel 3
TRIMINFO at 0x100a contains data for TMU channel 4
TRIMINFO at 0x10068000 contains data for TMU channel 2
This patch
1 Adds the neccessary register changes and arch information
to support Exynos5420 SoCs.
2. Handles the gate clock for misplaced TRIMINFO register
3. Updates the Documentation at
Documentation/devicetree/bindings/thermal/exynos-thermal.txt
Signed-off-by: Naveen Krishna Chatradhi
Signed-off-by: Andrew Bresticker
Acked-by: Amit Daniel Kachhap
Reviewed-by: Bartlomiej Zolnierkiewicz
---
Changes since v9:
Just respinning
Changes since v8:
1. rewrote the Documentation for device tree bindings
2. Merged the https://lkml.org/lkml/2013/11/7/262 (as this is a fix)
3. introduces "samsung,exynos5420-tmu-triminfo" and
"samsung,exynos5420-tmu-triminfo-clk" to handle the TMU channels on
Exynos5420 more appropriately
.../devicetree/bindings/thermal/exynos-thermal.txt | 45 +
drivers/thermal/samsung/exynos_tmu.c | 58 ++-
drivers/thermal/samsung/exynos_tmu.h |2 +
drivers/thermal/samsung/exynos_tmu_data.c | 106
drivers/thermal/samsung/exynos_tmu_data.h |8 ++
5 files changed, 215 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 116cca0..5055b31 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -6,6 +6,11 @@
"samsung,exynos4412-tmu"
"samsung,exynos4210-tmu"
"samsung,exynos5250-tmu"
+ "samsung,exynos5420-tmu" for TMU channel 0, 1 on Exynos5420
+ "samsung,exynos5420-tmu-triminfo" for TMU channel 2 Exynos5420
+ (Must pass triminfo base)
+ "samsung,exynos5420-tmu-triminfo-clk" for TMU channel 3 and 4
+ Exynos5420 (Must pass triminfo base and triminfo clock)
"samsung,exynos5440-tmu"
- interrupt-parent : The phandle for the interrupt controller
- reg : Address range of the thermal registers. For soc's which has multiple
@@ -13,6 +18,18 @@
interrupt related then 2 set of register has to supplied. First set
belongs to each instance of TMU and second set belongs to second set
of common TMU registers.
+
+ NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
+ channels 2, 3 and 4
+ Use "samsung,exynos5420-tmu-triminfo" in cases, there is a misplaced
+ register but no need of another clock to access that base.
+ Use "samsung,exynos5420-tmu-triminfo-clk" in cases where there is a
misplaced
+ register and we need another clock to access that base.
+
+ TRIMINFO at 0x1006c000 contains data for TMU channel 3
+ TRIMINFO at 0x100a contains data for TMU channel 4
+ TRIMINFO at 0x10068000 contains data for TMU channel 2
+
- interrupts : Should contain interrupt for thermal system
- clocks : The main clock for TMU device
- clock-names : Thermal system clock name
@@ -43,6 +60,34 @@ Example 2):
clock-names = "tmu_apbif";
};
+Example 3): (In case of Exynos5420 "with misplaced TRIMINFO register")
+ /* tmu for CPU2 */
+ tmu@10068000 {
+ compatible = "samsung,exynos5420-tmu-triminfo";
+ reg = <0x10068000 0x100>, <0x1006c000 0x4>;
+ interrupts = <0 184 0>;
+ clocks = <&clock 318>;
+ clock-names = "tmu_apbif";
+ };
+
+ /* tmu for CPU3 */
+ tmu@1006c000 {
+ compatible = "samsung,exynos5420-tmu-triminfo-clk";
+ reg = <0x1006c000 0x100>, <0x100a 0x4>;
+ interrupts = <0 185 0>;
+ clocks = <&clock 318>;
+ clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+ };
+
+ /* tmu for GPU */
+ tmu@100a {
+ compatible = "samsung,exynos5420-tmu-triminfo-clk";
+ reg = <0x100a 0x100>, <0x10068000 0x4>;
+ interrupts = <0 215 0>;
+ clocks = <&clock 318>;
+ clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+ };
+
Note: For multi-instance tmu each instance should have an alias correctly
numbered in "aliases" node.
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index bbd0fc3..826647c 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -47,6 +47,7 @@
* @irq_work: pointer to the irq work structure.
* @lock: lock to implement synchronization.
* @clk: pointer to the clock structure.
+ * @clk_sec: pointer to the clock structure for accessing the base_second.
* @t
[PATCH 4/4 v4] ARM: dts: Exynos5420: Add device nodes for TMU blocks
Exynos5420 SoC has per core thermal management unit.
5 TMU channels 4 for CPUs and 5th for GPU.
This patch adds the device tree nodes to the DT device list.
Nodes carry the misplaced second base address and the second
clock to access the misplaced base address.
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Naveen Krishna Chatradhi
Signed-off-by: Andrew Bresticker
---
Changes since v3:
None, Just respinning
Changes since v2:
3. uses the new compatible strings introduced along with adding
support for Exynso5420.
Changes since v1:
1. Nodes carry the misplaced second base address and the second
clock to access the misplaced base address.
2. Correct the clock number for the TMU4
arch/arm/boot/dts/exynos5420.dtsi | 48 +
1 file changed, 48 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 6ffefd1..d736b40 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -369,4 +369,52 @@
clock-names = "gscl";
samsung,power-domain = <&gsc_pd>;
};
+
+ /* tmu for CPU0 */
+ tmu@1006 {
+ compatible = "samsung,exynos5420-tmu";
+ reg = <0x1006 0x100>;
+ interrupts = <0 65 0>;
+ clocks = <&clock 318>;
+ clock-names = "tmu_apbif";
+ };
+
+ /* tmu for CPU1 */
+ tmu@10064000 {
+ compatible = "samsung,exynos5420-tmu";
+ reg = <0x10064000 0x100>;
+ interrupts = <0 183 0>;
+ clocks = <&clock 318>;
+ clock-names = "tmu_apbif";
+ };
+
+ /* tmu for CPU2 */
+ tmu@10068000 {
+ compatible = "samsung,exynos5420-tmu-triminfo";
+ /* 2nd reg is for the misplaced TRIMINFO register */
+ reg = <0x10068000 0x100>, <0x1006c000 0x4>;
+ interrupts = <0 184 0>;
+ clocks = <&clock 318>;
+ clock-names = "tmu_apbif";
+ };
+
+ /* tmu for CPU3 */
+ tmu@1006c000 {
+ compatible = "samsung,exynos5420-tmu-triminfo-clk";
+ /* 2nd reg is for the misplaced TRIMINFO register */
+ reg = <0x1006c000 0x100>, <0x100a 0x4>;
+ interrupts = <0 185 0>;
+ clocks = <&clock 318>, <&clock 319>;
+ clock-names = "tmu_apbif", "tmu_apbif_triminfo";
+ };
+
+ /* tmu for GPU */
+ tmu@100a {
+ compatible = "samsung,exynos5420-tmu-triminfo-clk";
+ /* 2nd reg is for the misplaced TRIMINFO register */
+ reg = <0x100a 0x100>, <0x10068000 0x4>;
+ interrupts = <0 215 0>;
+ clocks = <&clock 319>, <&clock 318>;
+ clock-names = "tmu_apbif", "tmu_apbif_triminfo";
+ };
};
--
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 2/4] cpufreq: exynos: Consider hibernation in pm notifier
Frequency lock should be considered in suspend/hibernation.
Signed-off-by: Jonghwan Choi
---
drivers/cpufreq/exynos-cpufreq.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index f3c2287..cd05b0a 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -187,6 +187,7 @@ static int exynos_cpufreq_pm_notifier(struct notifier_block
*notifier,
int ret;
switch (pm_event) {
+ case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
mutex_lock(&cpufreq_lock);
frequency_locked = true;
@@ -198,6 +199,8 @@ static int exynos_cpufreq_pm_notifier(struct notifier_block
*notifier,
break;
+ case PM_POST_HIBERNATION:
+ case PM_POST_RESTORE:
case PM_POST_SUSPEND:
mutex_lock(&cpufreq_lock);
frequency_locked = false;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] PM / devfreq: Consider hibernation in pm notifier
Frequency lock should be considered in suspend/hibernation.
Signed-off-by: Jonghwan Choi
---
drivers/devfreq/exynos/exynos4_bus.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/devfreq/exynos/exynos4_bus.c
b/drivers/devfreq/exynos/exynos4_bus.c
index cede6f7..dd6947e 100644
--- a/drivers/devfreq/exynos/exynos4_bus.c
+++ b/drivers/devfreq/exynos/exynos4_bus.c
@@ -962,6 +962,7 @@ static int exynos4_busfreq_pm_notifier_event(struct
notifier_block *this,
int err = 0;
switch (event) {
+ case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
/* Set Fastest and Deactivate DVFS */
mutex_lock(&data->lock);
@@ -1005,6 +1006,7 @@ unlock:
if (err)
return err;
return NOTIFY_OK;
+ case PM_POST_HIBERNATION:
case PM_POST_RESTORE:
case PM_POST_SUSPEND:
/* Reactivate */
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] PM / devfreq: Consider hibernation in pm notifier
Frequency lock should be considered in suspend/hibernation.
Signed-off-by: Jonghwan Choi
---
drivers/devfreq/exynos/exynos5_bus.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/devfreq/exynos/exynos5_bus.c
b/drivers/devfreq/exynos/exynos5_bus.c
index a60da3c..bd672de0 100644
--- a/drivers/devfreq/exynos/exynos5_bus.c
+++ b/drivers/devfreq/exynos/exynos5_bus.c
@@ -268,6 +268,7 @@ static int exynos5_busfreq_int_pm_notifier_event(struct
notifier_block *this,
int err = 0;
switch (event) {
+ case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
/* Set Fastest and Deactivate DVFS */
mutex_lock(&data->lock);
@@ -300,6 +301,7 @@ unlock:
if (err)
return NOTIFY_BAD;
return NOTIFY_OK;
+ case PM_POST_HIBERNATION:
case PM_POST_RESTORE:
case PM_POST_SUSPEND:
/* Reactivate */
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: move firmware_ops to drivers/firmware
On Tue, Nov 19, 2013 at 9:26 PM, Catalin Marinas
wrote:
> On Tue, Nov 19, 2013 at 02:46:55AM +, Alex Courbot wrote:
>> On 11/18/2013 08:58 PM, Catalin Marinas wrote:
>> > On Mon, Nov 18, 2013 at 03:05:59AM +, Alex Courbot wrote:
>> >> On 11/18/2013 12:59 AM, Catalin Marinas wrote:
>> >>> On 17 November 2013 08:49, Alexandre Courbot wrote:
>> The ARM tree includes a firmware_ops interface that is designed to
>> implement support for simple, TrustZone-based firmwares but could
>> also cover other use-cases. It has been suggested that this
>> interface might be useful to other architectures (e.g. arm64) and
>> that it should be moved out of arch/arm.
>> >>>
>> >>> NAK. I'm for code sharing with arm via common locations but this API
>> >>> goes against the ARMv8 firmware standardisation efforts like PSCI,
>> >>> encouraging each platform to define there own non-standard interface.
>> >>
>> >> I have to say, I pretty much agree with your NAK.
>> >>
>> >> The reason for this patch is that the suggestion to move firmware_ops
>> >> out of arch/arm is the last (I hope) thing that prevents my Trusted
>> >> Foundation support series from being merged.
>> >
>> > Moving it into drivers shouldn't be a workaround. Nice try ;).
>>
>> Hehe. I thought that just sending a patch would settle the issue one way
>> or the other and avoid a huge discussion. Woke up this morning to see
>> how wrong I was.
>
> It's a sensitive topic ;).
>
>> > BTW, is legacy code the reason for not converting the SMC # to PSCI?
>> > It's already supported on ARMv7, so you may not have much code left to
>> > merge in the kernel ;).
>>
>> The problem here is twofold:
>>
>> 1) we are just consumers of the TrustZone secure monitor who receive a
>> binary and do not have any control over its calling conventions. I agree
>> that it would be trivial to make it compatible with PSCI, but it's just
>> not something we can make by ourselves (TF does not even follow the SMC
>> calling convention). If this problem is to be addressed, it should be
>> done by forcing the TrustZone secure monitors providers to follow PSCI.
>
> I agree and such discussions do happen ('forcing' is a bit harder, more
> like 'strongly recommending'). On my side, I voice this message via the
> Linux channels, so SoC vendors can also encourage their secure provider
> in this direction. The benefit is that the Linux changes are minimal
> afterwards, single image is easier.
>
> But as I replied to Stephen, make sure you separate the secure OS (EL1)
> from the secure firmware (EL3). The latter (or parts of it) are provided
> by the SoC vendor (e.g. NVidia) and may be eventually linked into a big
> blob by the secure OS provider. ARM is encouraging separation here and a
> multi-stage firmware loading approach (and ARM started a public generic
> firmware project, it's in the early days now).
Will keep that in mind and check whether that could apply to future
devices, thanks.
>
>> 2) devices have already shipped with this firmware. Are we going to just
>> renounce supporting them, even though the necessary support is
>> lightweight and fits within already existing interfaces?
>
> I'm talking only about ARMv8 here. Please see my reply to Stephen for
> the details of (not) reusing existing firmware.
>
>> I certainly do hope that for ARMv8 things will be different and more
>> standardized. But that's not something that can be guaranteed unless ARM
>> strongly enforces it to firmware vendors. In case such a non-standard
>> firmware gets used again, I *do* hope that using cpu_ops will be
>> preferred over saying "this device cannot be supported in mainline, ever".
>
> cpu_ops or firmware_ops is just a name and can be unified (TBD what
> common functionality it contains). What I don't want to encourage is
> each SoC registering its own firmware interface.
Sorry, are you talking about interface as in SMC interface, or as in
cpu_operations/firmware_ops?
>
>> The kernel already supports non-standard hardware, BIOS, ACPI through
>> hacks that are *way* more horrible than that. This should certainly not
>> be encouraged, but that's not a valid reason to forbid otherwise
>> perfectly fine devices to run mainline IMHO.
>
> So you say we should just stop trying to standardise anything because
> people don't care anyway. Why do we even bother with DT (or ACPI) since
> board files were fine in the past (with a bit more code)?
Oh no, that's not what I am saying at all. Standardization is good.
PSCI is good. Of course I would prefer that the secure monitor we use
follow established conventions - that'd be less work to support it and
less hassle to get my patches merged.
I may have misunderstood you, but I felt your mail sounded a bit like
"we won't merge support for firmwares that do not follow PSCI". I
agree that whenever it is possible to support a firmware through a
standard interface, this should be done - no discussion. But right now
I have two devices that are goo
Re: [PATCH 2/4] cpufreq: exynos: Consider hibernation in pm notifier
On 19 November 2013 18:59, Jonghwan Choi wrote:
> Frequency lock should be considered in suspend/hibernation.
These could turn out to be important logs for future. Please write
with more effort..
> Signed-off-by: Jonghwan Choi
> ---
> drivers/cpufreq/exynos-cpufreq.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/cpufreq/exynos-cpufreq.c
> b/drivers/cpufreq/exynos-cpufreq.c
> index f3c2287..cd05b0a 100644
> --- a/drivers/cpufreq/exynos-cpufreq.c
> +++ b/drivers/cpufreq/exynos-cpufreq.c
> @@ -187,6 +187,7 @@ static int exynos_cpufreq_pm_notifier(struct
> notifier_block *notifier,
> int ret;
>
> switch (pm_event) {
> + case PM_HIBERNATION_PREPARE:
> case PM_SUSPEND_PREPARE:
> mutex_lock(&cpufreq_lock);
> frequency_locked = true;
> @@ -198,6 +199,8 @@ static int exynos_cpufreq_pm_notifier(struct
> notifier_block *notifier,
>
> break;
>
> + case PM_POST_HIBERNATION:
> + case PM_POST_RESTORE:
> case PM_POST_SUSPEND:
> mutex_lock(&cpufreq_lock);
> frequency_locked = false;
@Rafael: So we have few more drivers which are already doing such
stuff (even tegra as well)..
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] PM / devfreq: Consider hibernation in pm notifier
Hi,
Are you planning to add hibernation support to ARM?
If so then this should be stated somewhere in the patch description.
OTOH if you are not going to add hibernation support to ARM I see
a little sense in adding hibernation support to ARM-only drivers..
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
On Tuesday, November 19, 2013 10:30:31 PM Jonghwan Choi wrote:
> Frequency lock should be considered in suspend/hibernation.
>
> Signed-off-by: Jonghwan Choi
> ---
> drivers/devfreq/exynos/exynos5_bus.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/devfreq/exynos/exynos5_bus.c
> b/drivers/devfreq/exynos/exynos5_bus.c
> index a60da3c..bd672de0 100644
> --- a/drivers/devfreq/exynos/exynos5_bus.c
> +++ b/drivers/devfreq/exynos/exynos5_bus.c
> @@ -268,6 +268,7 @@ static int exynos5_busfreq_int_pm_notifier_event(struct
> notifier_block *this,
> int err = 0;
>
> switch (event) {
> + case PM_HIBERNATION_PREPARE:
> case PM_SUSPEND_PREPARE:
> /* Set Fastest and Deactivate DVFS */
> mutex_lock(&data->lock);
> @@ -300,6 +301,7 @@ unlock:
> if (err)
> return NOTIFY_BAD;
> return NOTIFY_OK;
> + case PM_POST_HIBERNATION:
> case PM_POST_RESTORE:
> case PM_POST_SUSPEND:
> /* Reactivate */
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: move firmware_ops to drivers/firmware
On Tue, Nov 19, 2013 at 02:29:39PM +, Alexandre Courbot wrote: > On Tue, Nov 19, 2013 at 9:26 PM, Catalin Marinas > wrote: > > On Tue, Nov 19, 2013 at 02:46:55AM +, Alex Courbot wrote: > >> 2) devices have already shipped with this firmware. Are we going to just > >> renounce supporting them, even though the necessary support is > >> lightweight and fits within already existing interfaces? > > > > I'm talking only about ARMv8 here. Please see my reply to Stephen for > > the details of (not) reusing existing firmware. > > > >> I certainly do hope that for ARMv8 things will be different and more > >> standardized. But that's not something that can be guaranteed unless ARM > >> strongly enforces it to firmware vendors. In case such a non-standard > >> firmware gets used again, I *do* hope that using cpu_ops will be > >> preferred over saying "this device cannot be supported in mainline, ever". > > > > cpu_ops or firmware_ops is just a name and can be unified (TBD what > > common functionality it contains). What I don't want to encourage is > > each SoC registering its own firmware interface. > > Sorry, are you talking about interface as in SMC interface, or as in > cpu_operations/firmware_ops? Both. I don't want to see platforms defining their own SMC interface for no good reason. The cpu_ops/firmware_ops handling in the kernel is just some naming but the key is having standard SMC interfaces for CPU operations. > >> The kernel already supports non-standard hardware, BIOS, ACPI through > >> hacks that are *way* more horrible than that. This should certainly not > >> be encouraged, but that's not a valid reason to forbid otherwise > >> perfectly fine devices to run mainline IMHO. > > > > So you say we should just stop trying to standardise anything because > > people don't care anyway. Why do we even bother with DT (or ACPI) since > > board files were fine in the past (with a bit more code)? > > Oh no, that's not what I am saying at all. Standardization is good. > PSCI is good. Of course I would prefer that the secure monitor we use > follow established conventions - that'd be less work to support it and > less hassle to get my patches merged. > > I may have misunderstood you, but I felt your mail sounded a bit like > "we won't merge support for firmwares that do not follow PSCI". Just to clarify it: I won't merge support for _ARMv8_ firmware that does not follow a standard CPU booting/power protocol supported by Linux. Currently we only support PSCI. If there is a need for another protocol and a good proposal, I'm open for discussions. The above is all related to having no SoC code under arch/arm64 (or board files, whatever you want to call them). > I > agree that whenever it is possible to support a firmware through a > standard interface, this should be done - no discussion. But right now > I have two devices that are good representatives of Tegra 4 and > available in stores, which I would like to see supported in mainline > to satisfy requests from the community for Tegra development > platforms, and also initiate the habit to support future > NVIDIA-branded devices in mainline. Their secure monitor unfortunately > does not follow PSCI or the SMC convention and needs a custom > firmware_ops. Are they unworthy of mainline? Are they ARMv8? Since we didn't have any such rules on ARMv7 and earlier, standard secure interface is nice to have but should not prevent upstreaming. I made this clear already that it is ARMv8 only, please don't try to generalise it. > And if, by sheer misfortune, the same thing happened on an ARMv8 > device (despite the EL1/EL3 separation), what would be the outcome? If some people get it wrong and they have to work around firmware bugs for devices already in the field, we may need to bend the rules (bugs do happen, both in software and hardware). But definitely _not_ when people don't even bother. > IMHO, more devices in mainline is beneficial to everybody, and > actually *encourages* SoC vendors/firmware providers to follow > conventions. Banning devices is what triggers the kind of "screw it" > reactions mentioned earlier, By following some rules and doing things in a standard way (firmware interface in this case), it is more likely that their SoC support requires minimal kernel code and it's easier to upstream and maintain. > and on the contrary once a device is in, > you tend to make sure the next ones follow the kernel trends because > you know you will need to support them in mainline as well and it will > make your life easier. Not really. The next device won't follow the kernel trends but just the same non-standard way of doing things that were accepted in the first place. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: move firmware_ops to drivers/firmware
On Wed, Nov 20, 2013 at 12:07 AM, Catalin Marinas wrote: > On Tue, Nov 19, 2013 at 02:29:39PM +, Alexandre Courbot wrote: >> On Tue, Nov 19, 2013 at 9:26 PM, Catalin Marinas >> wrote: >> > On Tue, Nov 19, 2013 at 02:46:55AM +, Alex Courbot wrote: >> >> 2) devices have already shipped with this firmware. Are we going to just >> >> renounce supporting them, even though the necessary support is >> >> lightweight and fits within already existing interfaces? >> > >> > I'm talking only about ARMv8 here. Please see my reply to Stephen for >> > the details of (not) reusing existing firmware. >> > >> >> I certainly do hope that for ARMv8 things will be different and more >> >> standardized. But that's not something that can be guaranteed unless ARM >> >> strongly enforces it to firmware vendors. In case such a non-standard >> >> firmware gets used again, I *do* hope that using cpu_ops will be >> >> preferred over saying "this device cannot be supported in mainline, ever". >> > >> > cpu_ops or firmware_ops is just a name and can be unified (TBD what >> > common functionality it contains). What I don't want to encourage is >> > each SoC registering its own firmware interface. >> >> Sorry, are you talking about interface as in SMC interface, or as in >> cpu_operations/firmware_ops? > > Both. I don't want to see platforms defining their own SMC interface for > no good reason. The cpu_ops/firmware_ops handling in the kernel is just > some naming but the key is having standard SMC interfaces for CPU > operations. Fair enough. > >> >> The kernel already supports non-standard hardware, BIOS, ACPI through >> >> hacks that are *way* more horrible than that. This should certainly not >> >> be encouraged, but that's not a valid reason to forbid otherwise >> >> perfectly fine devices to run mainline IMHO. >> > >> > So you say we should just stop trying to standardise anything because >> > people don't care anyway. Why do we even bother with DT (or ACPI) since >> > board files were fine in the past (with a bit more code)? >> >> Oh no, that's not what I am saying at all. Standardization is good. >> PSCI is good. Of course I would prefer that the secure monitor we use >> follow established conventions - that'd be less work to support it and >> less hassle to get my patches merged. >> >> I may have misunderstood you, but I felt your mail sounded a bit like >> "we won't merge support for firmwares that do not follow PSCI". > > Just to clarify it: I won't merge support for _ARMv8_ firmware that does > not follow a standard CPU booting/power protocol supported by Linux. > Currently we only support PSCI. If there is a need for another protocol > and a good proposal, I'm open for discussions. > > The above is all related to having no SoC code under arch/arm64 (or > board files, whatever you want to call them). > >> I >> agree that whenever it is possible to support a firmware through a >> standard interface, this should be done - no discussion. But right now >> I have two devices that are good representatives of Tegra 4 and >> available in stores, which I would like to see supported in mainline >> to satisfy requests from the community for Tegra development >> platforms, and also initiate the habit to support future >> NVIDIA-branded devices in mainline. Their secure monitor unfortunately >> does not follow PSCI or the SMC convention and needs a custom >> firmware_ops. Are they unworthy of mainline? > > Are they ARMv8? Since we didn't have any such rules on ARMv7 and > earlier, standard secure interface is nice to have but should not > prevent upstreaming. I made this clear already that it is ARMv8 only, > please don't try to generalise it. Sorry, that was not my intention at all - I just misunderstood what you meant. Thanks for clarifying it. > >> And if, by sheer misfortune, the same thing happened on an ARMv8 >> device (despite the EL1/EL3 separation), what would be the outcome? > > If some people get it wrong and they have to work around firmware bugs > for devices already in the field, we may need to bend the rules (bugs do > happen, both in software and hardware). But definitely _not_ when people > don't even bother. Ok, I guess for ARMv8 there is absolutely no excuse not to follow PSCI anyways. We'll need to be careful about this one. > >> IMHO, more devices in mainline is beneficial to everybody, and >> actually *encourages* SoC vendors/firmware providers to follow >> conventions. Banning devices is what triggers the kind of "screw it" >> reactions mentioned earlier, > > By following some rules and doing things in a standard way (firmware > interface in this case), it is more likely that their SoC support > requires minimal kernel code and it's easier to upstream and maintain. > >> and on the contrary once a device is in, >> you tend to make sure the next ones follow the kernel trends because >> you know you will need to support them in mainline as well and it will >> make your life easier. > > Not really. The ne
[PATCH] pinctrl: samsung: Allow grouping multiple pinmux/pinconf nodes
One of remaining limitations of current pinctrl-samsung driver was
the inability to parse multiple pinmux/pinconf group nodes grouped
inside a single device tree node. It made defining groups of pins for
single purpose, but with different parameters very inconvenient.
This patch implements Tegra-like support for grouping multiple pinctrl
groups inside one device tree node, by completely changing the way
pin groups and functions are parsed from device tree. The code creating
pinctrl maps from DT nodes has been borrowed from pinctrl-tegra, while
the initial creation of groups and functions has been completely
rewritten with following assumptions:
- each group consists of just one pin and does not depend on data
from device tree,
- each function is represented by a device tree child node of the
pin controller, which in turn can contain multiple child nodes
for pins that need to have different configuration values.
Device Tree bindings are fully backwards compatible. New functionality
can be used by defining a new pinctrl group consisting of several child
nodes, as on following example:
sd4_bus8: sd4-bus-width8 {
part-1 {
samsung,pins = "gpk0-3", "gpk0-4",
"gpk0-5", "gpk0-6";
samsung,pin-function = <3>;
samsung,pin-pud = <3>;
samsung,pin-drv = <3>;
};
part-2 {
samsung,pins = "gpk1-3", "gpk1-4",
"gpk1-5", "gpk1-6";
samsung,pin-function = <4>;
samsung,pin-pud = <4>;
samsung,pin-drv = <3>;
};
};
Tested on Exynos4210-Trats board and a custom Exynos4212-based one.
Signed-off-by: Tomasz Figa
Acked-by: Kyungmin Park
---
.../bindings/pinctrl/samsung-pinctrl.txt | 23 +-
drivers/pinctrl/pinctrl-samsung.c | 619 -
drivers/pinctrl/pinctrl-samsung.h | 1 +
3 files changed, 392 insertions(+), 251 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index 257677d..fe34cbb 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -43,7 +43,11 @@ Required Properties:
- Pin mux/config groups as child nodes: The pin mux (selecting pin function
mode) and pin config (pull up/down, driver strength) settings are represented
as child nodes of the pin-controller node. There should be atleast one
- child node and there is no limit on the count of these child nodes.
+ child node and there is no limit on the count of these child nodes. It is
+ also possible for a child node to consist of several further child nodes
+ to allow grouping multiple pinctrl groups into one. The format of second
+ level child nodes is exactly the same as for first level ones and is
+ described below.
The child node should contain a list of pin(s) on which a particular pin
function selection or pin configuration (or both) have to applied. This
@@ -248,6 +252,23 @@ Example 1: A pin-controller node with pin groups.
samsung,pin-pud = <3>;
samsung,pin-drv = <0>;
};
+
+ sd4_bus8: sd4-bus-width8 {
+ part-1 {
+ samsung,pins = "gpk0-3", "gpk0-4",
+ "gpk0-5", "gpk0-6";
+ samsung,pin-function = <3>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <3>;
+ };
+ part-2 {
+ samsung,pins = "gpk1-3", "gpk1-4",
+ "gpk1-5", "gpk1-6";
+ samsung,pin-function = <4>;
+ samsung,pin-pud = <4>;
+ samsung,pin-drv = <3>;
+ };
+ };
};
Example 2: A pin-controller node with external wakeup interrupt controller
node.
diff --git a/drivers/pinctrl/pinctrl-samsung.c
b/drivers/pinctrl/pinctrl-samsung.c
index 47ec2e8..c752de4 100644
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -40,9 +40,9 @@
/* list of all possible config options supported */
static struct pin_config {
- char*prop_cfg;
- unsigned intcfg_type;
-} pcfgs[] = {
+ const char *property;
+ enum pincfg_type param;
+} cfg_params[] = {
{ "samsung,pin-pud", PINCFG_TYPE_PUD },
{ "samsung,pin-drv", PINCFG_TYPE_DRV },
{ "samsung,pin-con-pdn", PINCFG_TYPE_CON_PDN },
@@ -59,163 +59,242 @@ static
[PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
This patch extends the range of settings configurable via pinfunc API
to cover pin value as well. This allows configuration of default values
of pins.
Signed-off-by: Tomasz Figa
Acked-by: Kyungmin Park
---
Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt | 1 +
drivers/pinctrl/pinctrl-samsung.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index fe34cbb..ed4cc9c 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -74,6 +74,7 @@ Required Properties:
"samsung,pins" property of the child node. The following pin configuration
properties are supported.
+ - samsung,pin-val: Initial value of pin output buffer.
- samsung,pin-pud: Pull up/down configuration.
- samsung,pin-drv: Drive strength configuration.
- samsung,pin-pud-pdn: Pull up/down configuration in power down mode.
diff --git a/drivers/pinctrl/pinctrl-samsung.c
b/drivers/pinctrl/pinctrl-samsung.c
index c752de4..6b2194a 100644
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -47,6 +47,7 @@ static struct pin_config {
{ "samsung,pin-drv", PINCFG_TYPE_DRV },
{ "samsung,pin-con-pdn", PINCFG_TYPE_CON_PDN },
{ "samsung,pin-pud-pdn", PINCFG_TYPE_PUD_PDN },
+ { "samsung,pin-val", PINCFG_TYPE_DAT },
};
/* Global list of devices (struct samsung_pinctrl_drv_data) */
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On 11/19/2013 10:15 AM, Tomasz Figa wrote: > This patch extends the range of settings configurable via pinfunc API > to cover pin value as well. This allows configuration of default values > of pins. Shouldn't there be a driver that acquires the GPIO that's output to the pin, and configures the output value? IIRC there have been previous discussions re: having a list of e.g. initial GPIO output values in DT, and that was rejected, and this patch seems to be doing almost the exact same thing, just at the pinctrl level rather than GPIO level. That all said, I admit this could be a useful feature... -- 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] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren wrote: > On 11/19/2013 10:15 AM, Tomasz Figa wrote: >> This patch extends the range of settings configurable via pinfunc API >> to cover pin value as well. This allows configuration of default values >> of pins. > > Shouldn't there be a driver that acquires the GPIO that's output to the > pin, and configures the output value? IIRC there have been previous > discussions re: having a list of e.g. initial GPIO output values in DT, > and that was rejected, and this patch seems to be doing almost the exact > same thing, just at the pinctrl level rather than GPIO level. > > That all said, I admit this could be a useful feature... I haven't followed all of the previous discussions, but I know I've run into scenarios where something like this would be useful. The one that comes to mind is: * We've got GPIOs that default at bootup to a pulled up input since the default state of the pin should be "high". * These pins are really intended to be outputs, like an "enable", "reset", or "power down" line for a peripheral. The pullup is strong enough to give us a good default state but we really want outputs. * We'd like to provide this GPIO to a peripheral through device tree. ...and we'd like all the pinmux to be setup automatically so we use pinctrl-names = "default". * If we set the pinmux up as "output" then there's a chance that the line will glitch at bootup since the pinmux happens (changing the pin to output) before the driver has a chance to run. Does that sound like the same scenario you're trying to solve 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
Re: [PATCH] pinctrl: samsung: Allow grouping multiple pinmux/pinconf nodes
On 11/19/2013 10:10 AM, Tomasz Figa wrote:
> One of remaining limitations of current pinctrl-samsung driver was
> the inability to parse multiple pinmux/pinconf group nodes grouped
> inside a single device tree node. It made defining groups of pins for
> single purpose, but with different parameters very inconvenient.
>
> This patch implements Tegra-like support for grouping multiple pinctrl
> groups inside one device tree node, by completely changing the way
> pin groups and functions are parsed from device tree.
> The code creating
> pinctrl maps from DT nodes has been borrowed from pinctrl-tegra,
A lot of the Tegra code has been slightly generalized and put into
pinconf-generic.c. Can the Samsung driver be converted to use that core
code rather than adding another copy of it? Perhaps this isn't possible
given the backwards-compatibility requirements that allow either 1- or
2-level nodes though, although I imagine that could be added to the core
code. One thing you'd certainly need to do is enhance the code in
pinconf-generic.c so that you could substitute your own
pinconf_generic_parse_dt_config() function or dt_params[] table, to
allow for the SoC-specific property names, but I doubt that's too hard.
Tegra could be converted then too:-)
> while
> the initial creation of groups and functions has been completely
> rewritten with following assumptions:
> - each group consists of just one pin and does not depend on data
>from device tree,
> - each function is represented by a device tree child node of the
>pin controller, which in turn can contain multiple child nodes
>for pins that need to have different configuration values.
OK, I think that sounds reasonable.
> Device Tree bindings are fully backwards compatible. New functionality
> can be used by defining a new pinctrl group consisting of several child
> nodes, as on following example:
>
> sd4_bus8: sd4-bus-width8 {
> part-1 {
> samsung,pins = "gpk0-3", "gpk0-4",
> "gpk0-5", "gpk0-6";
> samsung,pin-function = <3>;
> samsung,pin-pud = <3>;
> samsung,pin-drv = <3>;
> };
> part-2 {
> samsung,pins = "gpk1-3", "gpk1-4",
> "gpk1-5", "gpk1-6";
> samsung,pin-function = <4>;
> samsung,pin-pud = <4>;
> samsung,pin-drv = <3>;
> };
> };
OK, that all looks great!
> diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
The DT changes fully, and the code a little briefly,
Reviewed-by: Stephen Warren
Just a minor comment below,
> diff --git a/drivers/pinctrl/pinctrl-samsung.c
> b/drivers/pinctrl/pinctrl-samsung.c
> +static int samsung_pinctrl_create_function(struct device *dev,
> + struct samsung_pinctrl_drv_data *drvdata,
> + struct device_node *func_np,
> + struct samsung_pmx_func *func)
...
> + for (i = 0; i < npins; ++i) {
> + const char *gname;
> + char *gname_copy;
> +
> + ret = of_property_read_string_index(func_np, "samsung,pins",
> + i, &gname);
> + if (ret) {
> + dev_err(dev,
> + "failed to read pin name %d from %s node\n",
> + i, func_np->name);
> + return ret;
> }
> +
> + gname_copy = devm_kzalloc(dev, strlen(gname) + 1, GFP_KERNEL);
> + if (!gname_copy)
> + return -ENOMEM;
> + strcpy(gname_copy, gname);
Is the lifetime of the string "returned" by
of_property_read_string_index() really so short that you must copy the
string? I'd be tempted just to store the pointer, although perhaps you
need to get() the node so that's safe.
--
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] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On 11/19/2013 11:59 AM, Doug Anderson wrote: > On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren > wrote: >> On 11/19/2013 10:15 AM, Tomasz Figa wrote: >>> This patch extends the range of settings configurable via pinfunc API >>> to cover pin value as well. This allows configuration of default values >>> of pins. >> >> Shouldn't there be a driver that acquires the GPIO that's output to the >> pin, and configures the output value? IIRC there have been previous >> discussions re: having a list of e.g. initial GPIO output values in DT, >> and that was rejected, and this patch seems to be doing almost the exact >> same thing, just at the pinctrl level rather than GPIO level. >> >> That all said, I admit this could be a useful feature... > > I haven't followed all of the previous discussions, but I know I've > run into scenarios where something like this would be useful. The one > that comes to mind is: > > * We've got GPIOs that default at bootup to a pulled up input since > the default state of the pin should be "high". > > * These pins are really intended to be outputs, like an "enable", > "reset", or "power down" line for a peripheral. The pullup is strong > enough to give us a good default state but we really want outputs. > > * We'd like to provide this GPIO to a peripheral through device tree. > ...and we'd like all the pinmux to be setup automatically so we use > pinctrl-names = "default". > > * If we set the pinmux up as "output" then there's a chance that the > line will glitch at bootup since the pinmux happens (changing the pin > to output) before the driver has a chance to run. I think that last point should be addressed by having a driver that owns the GPIO set it to the desired output level, and the implementation of the SoC's GPIO driver communicate with the pinctrl driver (which might be the same driver; not sure here) so that gpio_direction_output() causes the pinctrl HW to be programmed as output only after the GPIO HW is programmed as output and with the correct output value. In this scenario, the pinctrl default state wouldn't touch the pin's input/output setting; that operation would be deferred until the driver set up the GPIO as an output. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] PM / devfreq: Consider hibernation in pm notifier
Quoting Bartlomiej Zolnierkiewicz (2013-11-19 06:50:05) > Hi, > > Are you planning to add hibernation support to ARM? > > If so then this should be stated somewhere in the patch description. > > OTOH if you are not going to add hibernation support to ARM I see > a little sense in adding hibernation support to ARM-only drivers.. FYI, we at Linaro and a few others have been working on adding hibernation support for ARM. I have not coordinated with Jonghwan however. Apoligies for the earlier toppost. Thanks, Sebastian Capella -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] Exynos 5410 Dual cluster support
Hi, On Thursday 07 of November 2013 12:12:45 Vyacheslav Tyrtov wrote: > The series of patches represent support of Exynos 5410 SoC > > The Exynos 5410 is the first Samsung SoC based on bigLITTLE architecture > Patches allow all 8 CPU cores (4 x A7 and 4 x A15) to run at the same time > > Patches add new platform description, support of clock controller, > dual cluster support and device tree for Exynos 5410 > > Has been build on v3.12. > Has been tested on Exynos 5410 reference board (exynos_defconfig). I've applied the patches on top of today's linux-next and tried to boot my ODROID-XU using exynos5410-smdk5410.dts and exynos_defconfig, but all I can get is an imprecise external abort, when the kernel tries to jump to init. Full boot log below. Any ideas? Best regards, Tomasz 8>< U-Boot 2012.07-g2bcb371 (Nov 19 2013 - 20:17:37) for Exynos5410 CPU: Exynos5410 Rev2.3 [Samsung SOC on SMP Platform Base on ARM CortexA15] APLL = 900MHz, KPLL = 600MHz MPLL = 532MHz, BPLL = 800MHz DRAM: 2 GiB WARNING: Caches not enabled TrustZone Enabled BSP BL1 version: PMIC VER : 0, CHIP REV : 6 VDD MIF : 1.0V VDD ARM : 1.0V VDD INT : 1.0V VDD G3D : 1.0V VDD KFC : 1.0V Checking Boot Mode ... SDMMC MMC: S5P_MSHC2: 0, S5P_MSHC0: 1 MMC Device 0: 14.8 GiB MMC Device 1: [ERROR] response error : 0006 cmd 8 [ERROR] response error : 0006 cmd 55 [ERROR] response error : 0006 cmd 2 In:serial Out: serial Err: serial Net: No ethernet found. Press 'Enter' or 'Space' to stop autoboot: 0 ODROID-XU # ODROID-XU # ODROID-XU # pri baudrate=115200 bootargs=console=ttySAC2,115200n8 earlyprintk ignore_loglevel mem=1G root=/dev/mmcblk0p1 rootwait bootcmd=run netboot bootdelay=1 bootfile=uImage.xu bootscript=source 40008000 copy_uboot_emmc2sd=emmc open 0;movi r z f 0 4000;emmc close 0;movi w f 1 4000;emmc open 0;movi r z b 0 4000;emmc close 0;movi w b 1 4000;emmc open 0;movi r z u 0 4000;emmc close 0;movi w u 1 4000;emmc open 0;movi r z t 0 4000;emmc close 0;movi w t 1 4000;mmc write 1 0x40008000 0x4CF 0x20; copy_uboot_sd2emmc=movi r f 0 4000;emmc open 1;movi w z f 1 4000;emmc close 1;movi r b 0 4000;emmc open 1;movi w z b 1 4000;emmc close 1;movi r u 0 4000;emmc open 1;movi w z u 1 4000;emmc close 1;movi r t 0 4000;emmc open 1;movi w z t 1 4000;emmc close 1;mmc write 1 0x40008000 0x4CF 0x20; default_bootcmd=echo >>> Run Default Bootcmd <<<;movi read kernel 0 40008000;bootz 40008000 ethact=sms0 ipaddr=192.168.1.20 loadbootscript_1=echo >>> Load Boot Script from mmc 0:1 <<<;fatload mmc 0:1 40008000 boot.scr loadbootscript_2=echo >>> Load Boot Script from mmc 0:2 <<<;fatload mmc 0:2 40008000 boot.scr loadbootscript_3=echo >>> Load Boot Script from mmc 1:1 <<<;fatload mmc 1:1 40008000 boot.scr loadbootscript_4=echo >>> Load Boot Script from mmc 1:2 <<<;fatload mmc 1:2 40008000 boot.scr netboot=usb start && tftpboot 40008000 && bootm 40008000 rootfslen=10 serverip=192.168.1.2 stderr=serial stdin=serial stdout=serial usbethaddr=00:11:22:33:44:55 Environment size: 1546/16380 bytes ODROID-XU # run netboot (Re)start USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 3 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found Waiting for Ethernet connection... done. Using sms0 device TFTP from server 192.168.1.2; our IP address is 192.168.1.20 Filename 'uImage.xu'. Load address: 0x40008000 Loading: # # # # done Bytes transferred = 2980232 (2d7988 hex) ## Booting kernel from Legacy Image at 40008000 ... Image Name: Linux-exynos5410-odroidxu Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2980168 Bytes = 2.8 MiB Load Address: 50008000 Entry Point: 50008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [ 0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.12.0-next-20131119-4-g27f3f5f-dirty (tom3q@flatron) (gcc version 4.7.2 (Gentoo 4.7.2-r1 p1.6, pie-0.5.5) ) #11 SMP PREEMPT Wed Nov 20 00:08:02 CET 2013 [0.00] CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] Machine model: H
Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren wrote: > On 11/19/2013 11:59 AM, Doug Anderson wrote: >> On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren >> wrote: >>> On 11/19/2013 10:15 AM, Tomasz Figa wrote: This patch extends the range of settings configurable via pinfunc API to cover pin value as well. This allows configuration of default values of pins. >>> >>> Shouldn't there be a driver that acquires the GPIO that's output to the >>> pin, and configures the output value? IIRC there have been previous >>> discussions re: having a list of e.g. initial GPIO output values in DT, >>> and that was rejected, and this patch seems to be doing almost the exact >>> same thing, just at the pinctrl level rather than GPIO level. >>> >>> That all said, I admit this could be a useful feature... >> >> I haven't followed all of the previous discussions, but I know I've >> run into scenarios where something like this would be useful. The one >> that comes to mind is: >> >> * We've got GPIOs that default at bootup to a pulled up input since >> the default state of the pin should be "high". >> >> * These pins are really intended to be outputs, like an "enable", >> "reset", or "power down" line for a peripheral. The pullup is strong >> enough to give us a good default state but we really want outputs. >> >> * We'd like to provide this GPIO to a peripheral through device tree. >> ...and we'd like all the pinmux to be setup automatically so we use >> pinctrl-names = "default". >> >> * If we set the pinmux up as "output" then there's a chance that the >> line will glitch at bootup since the pinmux happens (changing the pin >> to output) before the driver has a chance to run. > > I think that last point should be addressed by having a driver that owns > the GPIO set it to the desired output level, and the implementation of Some pins are not connected (NC). At that cases, there's no drivers to handle it. To reduce power leakage, it sets proper configuration with values instead of reset values. Thank you, Kyungmin Park > the SoC's GPIO driver communicate with the pinctrl driver (which might > be the same driver; not sure here) so that gpio_direction_output() > causes the pinctrl HW to be programmed as output only after the GPIO HW > is programmed as output and with the correct output value. In this > scenario, the pinctrl default state wouldn't touch the pin's > input/output setting; that operation would be deferred until the driver > set up the GPIO as an output. > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On 11/19/2013 05:02 PM, Kyungmin Park wrote: > On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren wrote: >> On 11/19/2013 11:59 AM, Doug Anderson wrote: >>> On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren >>> wrote: On 11/19/2013 10:15 AM, Tomasz Figa wrote: > This patch extends the range of settings configurable via pinfunc API > to cover pin value as well. This allows configuration of default values > of pins. Shouldn't there be a driver that acquires the GPIO that's output to the pin, and configures the output value? IIRC there have been previous discussions re: having a list of e.g. initial GPIO output values in DT, and that was rejected, and this patch seems to be doing almost the exact same thing, just at the pinctrl level rather than GPIO level. That all said, I admit this could be a useful feature... >>> >>> I haven't followed all of the previous discussions, but I know I've >>> run into scenarios where something like this would be useful. The one >>> that comes to mind is: >>> >>> * We've got GPIOs that default at bootup to a pulled up input since >>> the default state of the pin should be "high". >>> >>> * These pins are really intended to be outputs, like an "enable", >>> "reset", or "power down" line for a peripheral. The pullup is strong >>> enough to give us a good default state but we really want outputs. >>> >>> * We'd like to provide this GPIO to a peripheral through device tree. >>> ...and we'd like all the pinmux to be setup automatically so we use >>> pinctrl-names = "default". >>> >>> * If we set the pinmux up as "output" then there's a chance that the >>> line will glitch at bootup since the pinmux happens (changing the pin >>> to output) before the driver has a chance to run. >> >> I think that last point should be addressed by having a driver that owns >> the GPIO set it to the desired output level, and the implementation of > > Some pins are not connected (NC). At that cases, there's no drivers to > handle it. To reduce power leakage, it sets proper configuration with > values instead of reset values. Hmm. Shouldn't board firmware configure that kind of thing? (Of course, some firmware is starting to use DT to configure itself, so that just shifts the DT discussion, but anyway). -- 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
