Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery
On 01/06/2016 02:13 AM, Laxman Dewangan wrote:
>
> On Wednesday 06 January 2016 01:12 PM, H. Nikolaus Schaller wrote:
>> Hi,
>>
>> Am 06.01.2016 um 00:40 schrieb Nishanth Menon <n...@ti.com>:
>>
>>> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
>>>> +rtc {
>>>> +compatible = "ti,palmas-rtc";
>>>> +interrupt-parent = <>;
>>>> +interrupts = <8 IRQ_TYPE_NONE>;
>>> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
>>> it had none, there'd be no interrupt, right?
>> Well, it just translates IRQ_TYPE_NONE through
>>
>> Linux/include/dt-bindings/interrupt-controller/irq.h
>>
>> to
>>
>> interrupts = <8 0>;
>>
>> which is given as an example in
>>
>> Documentation//devicetree/bindings/rtc/rtc-palmas.txt
>>
>> Since I don't know anything about the rtc driver beyond the bindings
>> documentation I assume it is correct...
>> I have added Laxman Dewangan because he introduced this interrupts =
>> <8 0>;
>>
>
> As this is for palmas interrupt controller, it does not use the second
> field for interrupt from RTC.
> So there is no really any polarity. It can be set to 0.
>
> The second argument will be used for GPIOs mainly. However, support need
> to be added on GPIO driver for rising/falling configuration.
Device tree represents the hardware - not to reflect how the driver
works. if the driver is wrong, fix it. the interrupt polarity needs to
be described in DT. based on palmas like designs, you should probably
use IRQ_TYPE_EDGE_FALLING because that is the default signaling inside
the SoC as it reaches Secondary interrupt handlers(SIH) registers.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4430 power management support
On 01/06/2016 08:22 AM, Frank Jenner wrote: > Hello, > > I am working on trying to enable power management features on a > product that was based on the OMAP4430 SoC and the mainline 3.14 > kernel. In particular, I am interested in enabling Smart Reflex/AVS > and frequency scaling (via cpufreq) functionality. AVS class1.5 is supposed to be the official AVS class to be supported on OMAP3630, OMAP4, OMAP5 SoCs. unfortunately, we dont have that supported in upstream yet - let alone with cpufreq. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4430 power management support
On 01/06/2016 09:05 AM, Frank Jenner wrote: > On Wed, Jan 6, 2016 at 9:26 AM, Nishanth Menon <n...@ti.com> wrote: >> On 01/06/2016 08:22 AM, Frank Jenner wrote: >>> Hello, >>> >>> I am working on trying to enable power management features on a >>> product that was based on the OMAP4430 SoC and the mainline 3.14 >>> kernel. In particular, I am interested in enabling Smart Reflex/AVS >>> and frequency scaling (via cpufreq) functionality. >> >> >> AVS class1.5 is supposed to be the official AVS class to be supported on >> OMAP3630, OMAP4, OMAP5 SoCs. unfortunately, we dont have that supported >> in upstream yet - let alone with cpufreq. >> >> -- >> Regards, >> Nishanth Menon > > Sorry my original post might have been TL;DR, but is there a public > fork/branch that does have the support? There should be TI vendor kernels on 3.0 or 3.4 kernel that should have full entitlement of the SoC if you need that.. but I doubt there has been work on OMAP4 on more recent kernels to my knowledge. All work on OMAP4/3 is mostly community driven and in upstream. https://plus.google.com/+NishanthMenon/posts/gvyZQcNieoq kind of gives an overview of where we need to go. all contributions are welcome. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4430 power management support
On 01/06/2016 10:02 AM, Adam Ford wrote: > I dont' know if it helps, but I struggeled with this too. > > With my DM3730 (OMAP 3630), I had to enable Device Drivers->Adaptive > Voltage Scaling Class Support which enables CONFIG_POWER_AVS, a > requirement for POWER_AVS_OMAP. > > Once I did that, I was able to get AVS Class 3 working on my DM3730 > using th3 4.2+ kernel. I haven't tried it with 3.14, but I would Arggh... using AVS class3 with DM3730 will create all kinds of issues later on as the device gets old. Wish we had managed to get AVS 1.5 basic functionality upstream :(. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4430 power management support
On 01/06/2016 01:44 PM, Adam Ford wrote: > Any chance you can define what you mean by 'issues' and 'old'? > AVS class recommendation is AVS Class 1.5 for DM3730. If one does not follow the recommendation, then the result will be that some devices may not function OR fail in some unpredictable manner after a duration of time (aka device gets old). > Logic PD (my daytime employer) uses AVS 3 in their custom Linux > distribution. If that's going to be a problem, I would like to notify > some people there. Logic PD probably should talk with TI on the topic. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery
On 01/06/2016 01:34 PM, Rob Herring wrote:
> On Wed, Jan 6, 2016 at 8:36 AM, Nishanth Menon <n...@ti.com> wrote:
>> On 01/06/2016 02:13 AM, Laxman Dewangan wrote:
>>>
>>> On Wednesday 06 January 2016 01:12 PM, H. Nikolaus Schaller wrote:
>>>> Hi,
>>>>
>>>> Am 06.01.2016 um 00:40 schrieb Nishanth Menon <n...@ti.com>:
>>>>
>>>>> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
>>>>>> +rtc {
>>>>>> +compatible = "ti,palmas-rtc";
>>>>>> +interrupt-parent = <>;
>>>>>> +interrupts = <8 IRQ_TYPE_NONE>;
>>>>> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
>>>>> it had none, there'd be no interrupt, right?
>>>> Well, it just translates IRQ_TYPE_NONE through
>>>>
>>>> Linux/include/dt-bindings/interrupt-controller/irq.h
>>>>
>>>> to
>>>>
>>>> interrupts = <8 0>;
>>>>
>>>> which is given as an example in
>>>>
>>>> Documentation//devicetree/bindings/rtc/rtc-palmas.txt
>>>>
>>>> Since I don't know anything about the rtc driver beyond the bindings
>>>> documentation I assume it is correct...
>>>> I have added Laxman Dewangan because he introduced this interrupts =
>>>> <8 0>;
>>>>
>>>
>>> As this is for palmas interrupt controller, it does not use the second
>>> field for interrupt from RTC.
>>> So there is no really any polarity. It can be set to 0.
>>>
>>> The second argument will be used for GPIOs mainly. However, support need
>>> to be added on GPIO driver for rising/falling configuration.
>>
>>
>> Device tree represents the hardware - not to reflect how the driver
>> works. if the driver is wrong, fix it. the interrupt polarity needs to
>> be described in DT. based on palmas like designs, you should probably
>> use IRQ_TYPE_EDGE_FALLING because that is the default signaling inside
>> the SoC as it reaches Secondary interrupt handlers(SIH) registers.
>
> If the trigger type is not programmable, then not setting the trigger
> type in the DT is fine. Internal connections are often not documented.
>
Weird, that is not what I got feedback when I send
https://patchwork.ozlabs.org/patch/381125/
If this is the new norm, I retract my objection.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery
On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
> tested on OMP5432 EVM
>
> Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com>
> ---
> arch/arm/boot/dts/omap5-board-common.dtsi | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi
> b/arch/arm/boot/dts/omap5-board-common.dtsi
> index 5cf76a1..30c0d3b 100644
> --- a/arch/arm/boot/dts/omap5-board-common.dtsi
> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
> @@ -358,6 +358,14 @@
> #clock-cells = <0>;
> };
>
> + rtc {
> + compatible = "ti,palmas-rtc";
> + interrupt-parent = <>;
> + interrupts = <8 IRQ_TYPE_NONE>;
IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
it had none, there'd be no interrupt, right?
> + ti,backup-battery-chargeable;
> + ti,backup-battery-charge-high-current;
> + };
> +
> palmas_pmic {
> compatible = "ti,palmas-pmic";
> interrupt-parent = <>;
>
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Nokia N900: Adjust MPU OPP values
On 01/02/2016 11:16 AM, Tony Lindgren wrote: > * Pali Rohár <pali.ro...@gmail.com> [160102 06:31]: >> Hello, >> >> MPU OPP table table (omap36xx_vddcore_volt_data) defined in >> opp3xxx_data.c does not match Nokia N900 phone. For a long time we have >> dirty patch in linux-n900 tree for it, see: >> >> https://github.com/pali/linux-n900/commit/4644c5801d7469e2be01d847c61df3d934dadd8c >> >> Now when doing transition to device tree, is there any way how correct >> MPU OOP table for Nokia N900 could be defined in DT file? > > Hmm I'd assume we can just define this in the dts.. Nishanth, got > any comments on this one? > We already have definitions in dtb for omap3 OPPs. I think we should start using device tree as default. the oppxx_data.c is sticking around waiting for legacy boot to go away, then those files should be deleted. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] thermal: Schedule a backup thermal shutdown workqueue after a known period of time to tackle failed poweroff
On 12/31/2015 12:20 PM, Eduardo Valentin wrote:
> On Thu, Dec 31, 2015 at 11:47:57AM -0600, Nishanth Menon wrote:
>> On 12/31/2015 11:29 AM, Eduardo Valentin wrote:
>>> can we have a shorter title?
>>>
>>>
>>> Orderly power off is supposed to take care of this. Looking at the code,
>>> it will force a shutdown in case execution of userland command fails:
>>>
>>> static int __orderly_poweroff(bool force)
>>> {
>>> int ret;
>>>
>>> ret = run_cmd(poweroff_cmd);
>>>
>>> if (ret && force) {
>>> pr_warn("Failed to start orderly shutdown: forcing the
>>> issue\n");
>>>
>>> /*
>>> * I guess this should try to kick off some daemon to sync
>>> and
>>> * poweroff asap. Or not even bother syncing if we're
>>> doing an
>>> * emergency shutdown?
>>> */
>>> emergency_sync();
>>> kernel_power_off();
>>> }
>>
>> Yes, it will *IF* userspace fails. the condition that I had tracked
>> was before identifying the following fix[1] - Example fail is here[2]
>>
>
> OK. But still, why other users of orderly_poweroff do not
> deserve to be fixed, then?
>
I'd agree as well.. I guess the comment from Robin Holt <h...@sgi.com>
anticipated something like this will eventually occur.
"* I guess this should try to kick off some daemon to sync and
* poweroff asap. Or not even bother syncing if we're doing an
* emergency shutdown?
"
Keerthy - would you spin this as a generic fix?
>>
>> I hope this explains the problem.
>>
>> [1]
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=00917b5c55aeb01322d5ab51af8c025b82959224
>> [2] http://pastebin.ubuntu.com/14326688/
>>
>> [3]
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am57xx-beagle-x15.dts#n738
>>
>> --
>> Regards,
>> Nishanth Menon
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] thermal: Schedule a backup thermal shutdown workqueue after a known period of time to tackle failed poweroff
On 12/31/2015 11:29 AM, Eduardo Valentin wrote:
> can we have a shorter title?
>
> On Tue, Dec 29, 2015 at 02:46:49PM +0530, Keerthy wrote:
>> Hi Nishanth,
>>
>
>
>>>
>>> I am not sure if this #ifdeffery is even needed.
>>>
>>>
>>> Eduardo, Rui: If this is not the suggested technique, maybe you guys
>>> could suggest how we could handle a case where userspace might be
>>> hungup due to some reason and a case where a critical temperature
>>> event in the middle of device probe was triggered?
>
> Orderly power off is supposed to take care of this. Looking at the code,
> it will force a shutdown in case execution of userland command fails:
>
> static int __orderly_poweroff(bool force)
> {
> int ret;
>
> ret = run_cmd(poweroff_cmd);
>
> if (ret && force) {
> pr_warn("Failed to start orderly shutdown: forcing the
> issue\n");
>
> /*
> * I guess this should try to kick off some daemon to sync and
> * poweroff asap. Or not even bother syncing if we're doing
> an
> * emergency shutdown?
> */
> emergency_sync();
> kernel_power_off();
> }
Yes, it will *IF* userspace fails. the condition that I had tracked
was before identifying the following fix[1] - Example fail is here[2]
In this case, tmp102 is setup for X15 as [3] - and built as a module.
as the kernel startsup filesystem and starts a modprobe of all modules
via udev rules, the probe of tmp102 detects (falsely) a critical
temperature condition. Shutdown attempt in the middle of driver probe
is always a tricky business.
As we look at the log in [2], Line 472
> thermal thermal_zone3: critical temperature reached(108 C),shutting down
We have userspace trigger for shutdown taking place.
Line 495: INIT: Sending processes the TERM signal
userspace starts shutting down services. (but note that probe for
other devices were either in progress or queued up to complete)..
at line 647 - we are in a weird place -> sysrq shows that system is
idled and userspace is shutdown and system is still active.
In this case, we entered the case thanks to a driver bug, but if this
situation was a real world temperature scenario, then we'd probably in
an overtemp scenario, then device damage could take place OR something
much worse.
The only alternative is to run a parallel thread in case userspace
fails to complete the job in some given period of time - due to what
ever be the condition triggering the problem.
I hope this explains the problem.
[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=00917b5c55aeb01322d5ab51af8c025b82959224
[2] http://pastebin.ubuntu.com/14326688/
[3]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am57xx-beagle-x15.dts#n738
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] thermal: Schedule a backup thermal shutdown workqueue after a known period of time to tackle failed poweroff
On 12/20/2015 11:46 PM, Keerthy wrote:
+linux-pm.
> In few rare conditions like during boot up the orderly_poweroff
> function might not be able to complete fully leaving the device
> running at dangerously high temperatures. Hence adding a backup
> workqueue to act after a known period of time and poweroff the device.
>
> Suggested-by: Nishanth Menon <n...@ti.com>
> Reported-by: Nishanth Menon <n...@ti.com>
The specific case I hit was a critical temperature event as soon as
the hwmon device was probed (the driver tmp102 was a kernel module).
> Signed-off-by: Keerthy <j-keer...@ti.com>
> ---
> drivers/thermal/Kconfig| 9 +
> drivers/thermal/thermal_core.c | 26 ++
> 2 files changed, 35 insertions(+)
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 8cc4ac6..25584ee 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -92,6 +92,15 @@ config THERMAL_DEFAULT_GOV_POWER_ALLOCATOR
>
> endchoice
>
> +config THERMAL_BKUP_SHUTDOWN_DELAY_MS
> +int "Thermal shutdown backup delay in milli-seconds"
> +depends on THERMAL
> +default "5000"
> +---help---
> +The number of milliseconds to delay after orderly_poweroff call.
Probably needs a rephrase.
> +
> +Default: 5000 (5 seconds)
> +
> config THERMAL_GOV_FAIR_SHARE
> bool "Fair-share thermal governor"
> help
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index d9e525c..b793857 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -61,6 +61,12 @@ static DEFINE_MUTEX(thermal_governor_lock);
>
> static struct thermal_governor *def_governor;
>
> +#ifdef CONFIG_THERMAL_BKUP_SHUTDOWN_DELAY_MS
> +#define BKUP_SHUTDOWN_DELAY CONFIG_THERMAL_BKUP_SHUTDOWN_DELAY_MS
> +#else
> +#define BKUP_SHUTDOWN_DELAY 5000
> +#endif
> +
I am not sure if this #ifdeffery is even needed.
Eduardo, Rui: If this is not the suggested technique, maybe you guys
could suggest how we could handle a case where userspace might be
hungup due to some reason and a case where a critical temperature
event in the middle of device probe was triggered?
Obviously, we'd like to take into consideration userspace latencies as
well- but that is very specific to fs being run.. not really a simple
problem, IMHO..
> static struct thermal_governor *__find_governor(const char *name)
> {
> struct thermal_governor *pos;
> @@ -423,6 +429,18 @@ static void handle_non_critical_trips(struct
> thermal_zone_device *tz,
> def_governor->throttle(tz, trip);
> }
>
> +static void bkup_shutdown_func(struct work_struct *unused);
> +static DECLARE_DELAYED_WORK(bkup_shutdown_work, bkup_shutdown_func);
> +
> +static void bkup_shutdown_func(struct work_struct *work)
> +{
> + pr_warn("Orderly_poweroff has failed! Attempting kernel_power_off\n");
> + kernel_power_off();
> +
> + pr_warn("kernel_power_off has failed! Attempting emergency_restart\n");
> + emergency_restart();
I think documentation is necessary that we are hoping for bootloader
to be able to detect and halt as needed -> risk here obviously is an
infinite reboot loop :( .
> +}
> +
> static void handle_critical_trips(struct thermal_zone_device *tz,
> int trip, enum thermal_trip_type trip_type)
> {
> @@ -443,6 +461,14 @@ static void handle_critical_trips(struct
> thermal_zone_device *tz,
> dev_emerg(>device,
> "critical temperature reached(%d C),shutting down\n",
> tz->temperature / 1000);
> + /**
needs to be kernel doc style?
> + * This is a backup option to shutdown the
> + * system in case orderly_poweroff
> + * fails
Maybe adjust to 80char?
> + */
> + schedule_delayed_work(_shutdown_work,
> + msecs_to_jiffies(BKUP_SHUTDOWN_DELAY));
> +
> orderly_poweroff(true);
> }
> }
>
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] regulator: tps65917: Add bypass ops for ldo1 and ldo2 regulators
On 12/11/2015 12:28 AM, Keerthy wrote:
> set/get_bypass ops were missing for ldo1/ldo2 regulators which
> support bypass mode. Adding the bypass ops for ldo1 and ldo2.
> This helps consumers configure ldo1 and ldo2 in bypass mode or
> remove bypass mode if need be.
>
> Signed-off-by: Keerthy <j-keer...@ti.com>
> Reported-by: Kishon Vijay Abraham I <kis...@ti.com>
> ---
> drivers/regulator/palmas-regulator.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/regulator/palmas-regulator.c
> b/drivers/regulator/palmas-regulator.c
> index 8217613..776b59a 100644
> --- a/drivers/regulator/palmas-regulator.c
> +++ b/drivers/regulator/palmas-regulator.c
> @@ -389,6 +389,7 @@ static unsigned int palmas_smps_ramp_delay[4] = {0,
> 1, 5000, 2500};
> #define SMPS10_BOOST_EN (1<<2)
> #define SMPS10_BYPASS_EN (1<<1)
> #define SMPS10_SWITCH_EN (1<<0)
> +#define TPS65917_LDO_1_2_BYPASS_EN BIT(6)
This also applies to TWL6035/37, TPS659038 LDO9 as well.
why not do it for all? considering the bit definition is the same as well?
>
> #define REGULATOR_SLAVE 0
>
> @@ -639,6 +640,19 @@ static struct regulator_ops tps65917_ops_ldo = {
> .set_voltage_time_sel = regulator_set_voltage_time_sel,
> };
>
> +static struct regulator_ops tps65917_ops_ldo_1_2 = {
> + .is_enabled = palmas_is_enabled_ldo,
> + .enable = regulator_enable_regmap,
> + .disable= regulator_disable_regmap,
> + .get_voltage_sel= regulator_get_voltage_sel_regmap,
> + .set_voltage_sel= regulator_set_voltage_sel_regmap,
> + .list_voltage = regulator_list_voltage_linear,
> + .map_voltage= regulator_map_voltage_linear,
> + .set_voltage_time_sel = regulator_set_voltage_time_sel,
> + .set_bypass = regulator_set_bypass_regmap,
> + .get_bypass = regulator_get_bypass_regmap,
> +};
> +
> static int palmas_regulator_config_external(struct palmas *palmas, int id,
> struct palmas_reg_init *reg_init)
> {
> @@ -1019,6 +1033,12 @@ static int tps65917_ldo_registration(struct
> palmas_pmic *pmic,
>* It is of the order of ~60mV/uS.
>*/
> desc->ramp_delay = 2500;
> + if (id == TPS65917_REG_LDO1 ||
> + id == TPS65917_REG_LDO2) {
> + desc->ops = _ops_ldo_1_2;
> + desc->bypass_reg = desc->enable_reg;
> + desc->bypass_mask = TPS65917_LDO_1_2_BYPASS_EN;
> + }
> } else {
> desc->n_voltages = 1;
> if (reg_init && reg_init->roof_floor)
>
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 01/18] ARM: am57xx: cl-som-am57x: dts: add basic module support
On 12/01/2015 10:43 AM, Tony Lindgren wrote: > * Dmitry Lifshitz <lifsh...@compulab.co.il> [151201 08:26]: >> >> It might looks the same set of regulators for multiple boards, >> but it is not. Each board may apply its own regulators usage scheme, and >> this is our case (as compared to am57xx-beagle-x15.dts). >> >> For the best of my knowledge, it used to be in a common *.dtsi file (at >> least in early OMAP5 DT support in TI kernel tree), but then I found that >> PMIC registration had been moved to the boards DT files. > > Have you actually looked at how much of the implementation is same across > the omap5 boards? My guess is that a whole lot is same.. See for example > omap5-board-common.dtsi. Unfortunately with DRA7 / AM57xx: at least 2 different PMICs -> DRA74/DRA72 evms. even across similar PMIC usage, different voltage rail usage accross evms: DRA74evm, x15/GPEVM, AM571x-IDK/AM572x-IDK -> they are not necessarily compatible. Example: some of them have Ganged voltage rail, others dont - few others are mixed. if you are trying to get common regulator usage -> it is kinda pretty hard given the freedom board designers are being given by TI.. OMAP5 was more controlled in terms of what specific configuration the board designers had to follow. that is no longer the case for DRA7/AM57 platforms. just my 2 cents here. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hwmon: (tmp102) Force wait for conversion time for the first valid data
On 12/01/2015 09:09 AM, Guenter Roeck wrote: > On 12/01/2015 06:21 AM, Nishanth Menon wrote: > [ ... ] > >> >> Hint about how the patch will look like: > > Looks ok (and better). Thanks for the feedback. Will post the same. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] reset: Introduce static inline dummy function when CONFIG_RESET_CONTROLLER
When CONFIG_RESET_CONTROLLER is not defined (example COMPILE_TEST),
provide a dummy static inline implementation.
Signed-off-by: Nishanth Menon <n...@ti.com>
---
include/linux/reset-controller.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/reset-controller.h b/include/linux/reset-controller.h
index ce6b962ffed4..4badecb2619e 100644
--- a/include/linux/reset-controller.h
+++ b/include/linux/reset-controller.h
@@ -48,7 +48,16 @@ struct reset_controller_dev {
unsigned int nr_resets;
};
+#if IS_ENABLED(CONFIG_RESET_CONTROLLER)
int reset_controller_register(struct reset_controller_dev *rcdev);
void reset_controller_unregister(struct reset_controller_dev *rcdev);
+#else
+static inline int reset_controller_register(struct reset_controller_dev *r)
+{
+ return -EINVAL;
+}
+static inline void reset_controller_unregister(struct reset_controller_dev *r)
+{
+}
#endif
--
2.6.2.402.g2635c2b
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hwmon: (tmp102) Force wait for conversion time for the first valid data
Hi Guenter,
Thanks for the detailed review..
On 11/30/2015 11:50 PM, Guenter Roeck wrote:
> On 11/30/2015 08:25 PM, Nishanth Menon wrote:
[...]
>>
>> A simpler alternative approach could be to sleep in the probe for the
>> duration required, but that will result in latency that is undesirable
>> that can delay boot sequence un-necessarily.
>>
> A really simpler solution would be to mark when the device is ready
> to be accessed in the probe function, and go to sleep for the remaining
> time
> in the update function if necessary. This would not affect the probe
> function,
> avoid the somewhat awkward -EAGAIN, avoid overloading the value cache,
> and only
> sleep if necessary and as long as needed.
We already have that logic in a different form:
We use last_update to know when to go read the temperature value. Until
the conversion time has elapsed, we keep providing previously cached
value. Trouble is the first time read before conversion time is complete:
On sleep during update:
unfortunately, forcing the delay in update for the first time:
a) Will also cause the latency in the thermal_zone_device_check which
triggers right after tmp102_probe->thermal_zone_of_sensor_register
b) -EAGAIN is used by other hwmon drivers such as
drivers/hwmon/adt7470.c, drivers/hwmon/ltc4245.c, drivers/hwmon/sht15.c,
drivers/hwmon/tc74.c, drivers/hwmon/via-cputemp.c in similar ways when
data cannot be provided back.
Overriding the temp value to indicate first time read:
I can setup a bool in struct tmp102 instead -> but that serves the same
purpose as what we did with override, except increase 1 char footprint -
though I agree, it might be a little more readable.
>
>> [1] http://www.ti.com/lit/ds/symlink/tmp102.pdf
>>
>> Cc: Eduardo Valentin <edubez...@gmail.com>
>> Reported-by: Aparna Balasubramanian <apar...@ti.com>
>> Reported-by: Elvita Lobo <elv...@ti.com>
>> Reported-by: Yan Liu <yan-...@ti.com>
>> Signed-off-by: Nishanth Menon <n...@ti.com>
>> ---
>>
>> Example case (from Beagleboard-x15 using an older kernel revision):
>> http://pastebin.ubuntu.com/13591711/
>> Notice the thermal shutdown trigger:
>> thermal thermal_zone3: critical temperature reached(108
>> C),shutting down
>>
>> drivers/hwmon/tmp102.c | 19 ++-
>> 1 file changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
>> index 65482624ea2c..145f69108f23 100644
>> --- a/drivers/hwmon/tmp102.c
>> +++ b/drivers/hwmon/tmp102.c
>> @@ -50,6 +50,9 @@
>> #defineTMP102_TLOW_REG0x02
>> #defineTMP102_THIGH_REG0x03
>>
>> +/* TMP102 range is -55 to 150C -> we use -128 as a default invalid
>> value */
>> +#define TMP102_NOTREADY-128
>> +
>
> This is a bit misleading, and also not correct, since the temperature is
> stored in
> milli-degrees C, so a value of -128 reflects -0.128 degreees C. While
> that value
> will not be seen in practice, it is still not a good idea to use it for
> this purpose.
>
> Even though the chip temperature range is -55 .. 150 C, that doesn't mean
> it never returns a value outside that range, for example if nothing is
> connected
> to an external sensor or if something is broken.
>
> You should use a value outside the value range, ie outside
> [-128,000 .. 127,999 ] to detect the "not ready" condition.
That is true.. I will just drop this and introduce a bool in tmp102 instead.
>> struct tmp102 {
>> struct i2c_client *client;
>> struct device *hwmon_dev;
>> @@ -102,6 +105,12 @@ static int tmp102_read_temp(void *dev, int *temp)
>> {
>> struct tmp102 *tmp102 = tmp102_update_device(dev);
>>
>> +/* Is it too early even to return a conversion? */
>> +if (tmp102->temp[0] == TMP102_NOTREADY) {
>> +dev_dbg(dev, "%s: Conversion not ready yet..\n", __func__);
>> +return -EAGAIN;
>
> Does this cause a hard loop in the calling code, or will the thermal code
> delay before it reads again ?
>
> If it causes a hard loop, it may be better to go to sleep if needed
> when reading the data, as suggested above.
Thermal framework is capable of handling -EAGAIN without a hard loop
around this (it just seems to reschedule around the polling interval and
comes back to check if data is ready).
If you are ok with the above, then I will send a v2 introducing a bool
to setup a flag for first_time read, but will leave the -EAGAIN alone.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hwmon: (tmp102) Force wait for conversion time for the first valid data
On 07:47-20151201, Nishanth Menon wrote:
> Hi Guenter,
>
> Thanks for the detailed review..
>
> On 11/30/2015 11:50 PM, Guenter Roeck wrote:
> > On 11/30/2015 08:25 PM, Nishanth Menon wrote:
> [...]
>
> >>
> >> A simpler alternative approach could be to sleep in the probe for the
> >> duration required, but that will result in latency that is undesirable
> >> that can delay boot sequence un-necessarily.
> >>
> > A really simpler solution would be to mark when the device is ready
> > to be accessed in the probe function, and go to sleep for the remaining
> > time
> > in the update function if necessary. This would not affect the probe
> > function,
> > avoid the somewhat awkward -EAGAIN, avoid overloading the value cache,
> > and only
> > sleep if necessary and as long as needed.
>
> We already have that logic in a different form:
> We use last_update to know when to go read the temperature value. Until
> the conversion time has elapsed, we keep providing previously cached
> value. Trouble is the first time read before conversion time is complete:
>
> On sleep during update:
> unfortunately, forcing the delay in update for the first time:
> a) Will also cause the latency in the thermal_zone_device_check which
> triggers right after tmp102_probe->thermal_zone_of_sensor_register
> b) -EAGAIN is used by other hwmon drivers such as
> drivers/hwmon/adt7470.c, drivers/hwmon/ltc4245.c, drivers/hwmon/sht15.c,
> drivers/hwmon/tc74.c, drivers/hwmon/via-cputemp.c in similar ways when
> data cannot be provided back.
>
> Overriding the temp value to indicate first time read:
> I can setup a bool in struct tmp102 instead -> but that serves the same
> purpose as what we did with override, except increase 1 char footprint -
> though I agree, it might be a little more readable.
>
> >
> >> [1] http://www.ti.com/lit/ds/symlink/tmp102.pdf
> >>
> >> Cc: Eduardo Valentin <edubez...@gmail.com>
> >> Reported-by: Aparna Balasubramanian <apar...@ti.com>
> >> Reported-by: Elvita Lobo <elv...@ti.com>
> >> Reported-by: Yan Liu <yan-...@ti.com>
> >> Signed-off-by: Nishanth Menon <n...@ti.com>
> >> ---
> >>
> >> Example case (from Beagleboard-x15 using an older kernel revision):
> >> http://pastebin.ubuntu.com/13591711/
> >> Notice the thermal shutdown trigger:
> >> thermal thermal_zone3: critical temperature reached(108
> >> C),shutting down
> >>
> >> drivers/hwmon/tmp102.c | 19 ++-
> >> 1 file changed, 18 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
> >> index 65482624ea2c..145f69108f23 100644
> >> --- a/drivers/hwmon/tmp102.c
> >> +++ b/drivers/hwmon/tmp102.c
> >> @@ -50,6 +50,9 @@
> >> #defineTMP102_TLOW_REG0x02
> >> #defineTMP102_THIGH_REG0x03
> >>
> >> +/* TMP102 range is -55 to 150C -> we use -128 as a default invalid
> >> value */
> >> +#define TMP102_NOTREADY-128
> >> +
> >
> > This is a bit misleading, and also not correct, since the temperature is
> > stored in
> > milli-degrees C, so a value of -128 reflects -0.128 degreees C. While
> > that value
> > will not be seen in practice, it is still not a good idea to use it for
> > this purpose.
> >
> > Even though the chip temperature range is -55 .. 150 C, that doesn't mean
> > it never returns a value outside that range, for example if nothing is
> > connected
> > to an external sensor or if something is broken.
> >
> > You should use a value outside the value range, ie outside
> > [-128,000 .. 127,999 ] to detect the "not ready" condition.
>
>
> That is true.. I will just drop this and introduce a bool in tmp102 instead.
>
> >> struct tmp102 {
> >> struct i2c_client *client;
> >> struct device *hwmon_dev;
> >> @@ -102,6 +105,12 @@ static int tmp102_read_temp(void *dev, int *temp)
> >> {
> >> struct tmp102 *tmp102 = tmp102_update_device(dev);
> >>
> >> +/* Is it too early even to return a conversion? */
> >> +if (tmp102->temp[0] == TMP102_NOTREADY) {
> >> +dev_dbg(dev, "%s: Conversion not ready yet..\n", __func__);
> >> +return -EAGAIN;
> >
> > Does this cause a hard loop in the calling code, or will the thermal code
> > delay before it reads again ?
> >
> >
Re: [PATCH] reset: Introduce static inline dummy function when CONFIG_RESET_CONTROLLER
On 12/01/2015 09:56 AM, kbuild test robot wrote: > Hi Nishanth, > > [auto build test ERROR on v4.4-rc3] > [also build test ERROR on next-20151127] > > url: > https://github.com/0day-ci/linux/commits/Nishanth-Menon/reset-Introduce-static-inline-dummy-function-when-CONFIG_RESET_CONTROLLER/20151201-233708 > config: i386-randconfig-n0-201548 (attached as .config) > reproduce: > # save the attached .config to linux build tree > make ARCH=i386 > > All errors (new ones prefixed by >>): > >In file included from drivers/reset/core.c:18:0: >>> include/linux/reset-controller.h:1:0: error: unterminated #ifndef > #ifndef _LINUX_RESET_CONTROLLER_H_ > ^ Uggh.. thanks kbot... :).. my bad.. last minute whitespace editscan end up deleting #endifs :( While at it, will fix $subject as well. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] hwmon: (tmp102) Force wait for conversion time for the first valid data
TMP102 works based on conversions done periodically. However, as per
the TMP102 data sheet[1] the first conversion is triggered immediately
after we program the configuration register. The temperature data
registers do not reflect proper data until the first conversion is
complete (in our case HZ/4).
The driver currently sets the last_update to be jiffies - HZ, just
after the configuration is complete. When TMP102 driver registers
with the thermal framework, it immediately tries to read the sensor
temperature data. This takes place even before the conversion on the
TMP102 is complete and results in an invalid temperature read.
Depending on the value read, this may cause thermal framework to
assume that a critical temperature event has occurred and attempts to
shutdown the system.
Instead of causing an invalid mid-conversion value to be read
erroneously, we mark the last_update to be in-line with the current
jiffies. This allows the tmp102_update_device function to skip update
until the required conversion time is complete. Further, we ensure to
return -EAGAIN result instead of returning spurious temperature (such
as 0C) values to the caller to prevent any wrong decisions made with
such values. NOTE: this allows the read functions not to be blocking
and allows the callers to make the decision if they would like to
block or try again later. At least the current user(thermal) seems to
handle this by retrying later.
A simpler alternative approach could be to sleep in the probe for the
duration required, but that will result in latency that is undesirable
and delay boot sequence un-necessarily.
[1] http://www.ti.com/lit/ds/symlink/tmp102.pdf
Cc: Eduardo Valentin <edubez...@gmail.com>
Reported-by: Aparna Balasubramanian <apar...@ti.com>
Reported-by: Elvita Lobo <elv...@ti.com>
Reported-by: Yan Liu <yan-...@ti.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
Changes in V2 since V1:
- Dropped out-of-range temperature used as a marker for first time
we are using a bool now
- minor update in comments to explain -EAGAIN return
V1: https://patchwork.kernel.org/patch/7732781/
https://patchwork.kernel.org/patch/7737771/
Example case (from Beagleboard-x15 using an older kernel revision):
http://pastebin.ubuntu.com/13591711/
Notice the thermal shutdown trigger:
thermal thermal_zone3: critical temperature reached(108 C),shutting down
drivers/hwmon/tmp102.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index 65482624ea2c..5289aa0980a8 100644
--- a/drivers/hwmon/tmp102.c
+++ b/drivers/hwmon/tmp102.c
@@ -58,6 +58,7 @@ struct tmp102 {
u16 config_orig;
unsigned long last_update;
int temp[3];
+ bool first_time;
};
/* convert left adjusted 13-bit TMP102 register value to milliCelsius */
@@ -93,6 +94,7 @@ static struct tmp102 *tmp102_update_device(struct device *dev)
tmp102->temp[i] = tmp102_reg_to_mC(status);
}
tmp102->last_update = jiffies;
+ tmp102->first_time = false;
}
mutex_unlock(>lock);
return tmp102;
@@ -102,6 +104,12 @@ static int tmp102_read_temp(void *dev, int *temp)
{
struct tmp102 *tmp102 = tmp102_update_device(dev);
+ /* Is it too early even to return a conversion? */
+ if (tmp102->first_time) {
+ dev_dbg(dev, "%s: Conversion not ready yet..\n", __func__);
+ return -EAGAIN;
+ }
+
*temp = tmp102->temp[0];
return 0;
@@ -114,6 +122,10 @@ static ssize_t tmp102_show_temp(struct device *dev,
struct sensor_device_attribute *sda = to_sensor_dev_attr(attr);
struct tmp102 *tmp102 = tmp102_update_device(dev);
+ /* Is it too early even to return a read? */
+ if (tmp102->first_time)
+ return -EAGAIN;
+
return sprintf(buf, "%d\n", tmp102->temp[sda->index]);
}
@@ -207,7 +219,9 @@ static int tmp102_probe(struct i2c_client *client,
status = -ENODEV;
goto fail_restore_config;
}
- tmp102->last_update = jiffies - HZ;
+ tmp102->last_update = jiffies;
+ /* Mark that we are not ready with data until conversion is complete */
+ tmp102->first_time = true;
mutex_init(>lock);
hwmon_dev = hwmon_device_register_with_groups(dev, client->name,
--
2.6.2.402.g2635c2b
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] reset: Introduce static inline dummy function when CONFIG_RESET_CONTROLLER is not set
When CONFIG_RESET_CONTROLLER is not defined (example COMPILE_TEST),
provide a dummy static inline implementation.
Signed-off-by: Nishanth Menon <n...@ti.com>
---
V2: Thanks to kbot, I realized i messed up the patch -> hopefully, this revision
has better luck.
V1: https://patchwork.kernel.org/patch/7738191/
include/linux/reset-controller.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/linux/reset-controller.h b/include/linux/reset-controller.h
index ce6b962ffed4..e294565540db 100644
--- a/include/linux/reset-controller.h
+++ b/include/linux/reset-controller.h
@@ -48,7 +48,18 @@ struct reset_controller_dev {
unsigned int nr_resets;
};
+#if IS_ENABLED(CONFIG_RESET_CONTROLLER)
int reset_controller_register(struct reset_controller_dev *rcdev);
void reset_controller_unregister(struct reset_controller_dev *rcdev);
+#else
+static inline int reset_controller_register(struct reset_controller_dev *r)
+{
+ return -EINVAL;
+}
+
+static inline void reset_controller_unregister(struct reset_controller_dev *r)
+{
+}
+#endif /* IS_ENABLED(CONFIG_RESET_CONTROLLER) */
#endif
--
2.6.2.402.g2635c2b
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] hwmon: (tmp102) Force wait for conversion time for the first valid data
TMP102 works based on conversions done periodically. However, as per
the TMP102 data sheet[1] the first conversion is triggered immediately
after we program the configuration register. The temperature data
registers do not reflect proper data until the first conversion is
complete (in our case HZ/4).
The driver currently sets the last_update to be jiffies - HZ, just
after the configuration is complete. When tmp102 driver registers
with the thermal framework, it immediately tries to read the sensor
temperature data. This takes place even before the conversion on the
TMP102 is complete and results in an invalid temperature read.
Depending on the value read, this may cause thermal framework to
assume that a critical temperature event has occurred and attempts to
shutdown the system.
Instead of causing an invalid mid-conversion value to be read
erroneously, we mark the last_update to be in-line with the current
jiffies. This allows the tmp102_update_device function to skip update
until the required conversion time is complete. Further, we ensure to
return -EAGAIN result instead of returning spurious temperature (such
as 0C) values to the caller to prevent any wrong decisions made with
such values.
A simpler alternative approach could be to sleep in the probe for the
duration required, but that will result in latency that is undesirable
that can delay boot sequence un-necessarily.
[1] http://www.ti.com/lit/ds/symlink/tmp102.pdf
Cc: Eduardo Valentin <edubez...@gmail.com>
Reported-by: Aparna Balasubramanian <apar...@ti.com>
Reported-by: Elvita Lobo <elv...@ti.com>
Reported-by: Yan Liu <yan-...@ti.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
Example case (from Beagleboard-x15 using an older kernel revision):
http://pastebin.ubuntu.com/13591711/
Notice the thermal shutdown trigger:
thermal thermal_zone3: critical temperature reached(108 C),shutting down
drivers/hwmon/tmp102.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index 65482624ea2c..145f69108f23 100644
--- a/drivers/hwmon/tmp102.c
+++ b/drivers/hwmon/tmp102.c
@@ -50,6 +50,9 @@
#defineTMP102_TLOW_REG 0x02
#defineTMP102_THIGH_REG0x03
+/* TMP102 range is -55 to 150C -> we use -128 as a default invalid value */
+#define TMP102_NOTREADY-128
+
struct tmp102 {
struct i2c_client *client;
struct device *hwmon_dev;
@@ -102,6 +105,12 @@ static int tmp102_read_temp(void *dev, int *temp)
{
struct tmp102 *tmp102 = tmp102_update_device(dev);
+ /* Is it too early even to return a conversion? */
+ if (tmp102->temp[0] == TMP102_NOTREADY) {
+ dev_dbg(dev, "%s: Conversion not ready yet..\n", __func__);
+ return -EAGAIN;
+ }
+
*temp = tmp102->temp[0];
return 0;
@@ -114,6 +123,10 @@ static ssize_t tmp102_show_temp(struct device *dev,
struct sensor_device_attribute *sda = to_sensor_dev_attr(attr);
struct tmp102 *tmp102 = tmp102_update_device(dev);
+ /* Is it too early even to return a read? */
+ if (tmp102->temp[sda->index] == TMP102_NOTREADY)
+ return -EAGAIN;
+
return sprintf(buf, "%d\n", tmp102->temp[sda->index]);
}
@@ -207,7 +220,11 @@ static int tmp102_probe(struct i2c_client *client,
status = -ENODEV;
goto fail_restore_config;
}
- tmp102->last_update = jiffies - HZ;
+ tmp102->last_update = jiffies;
+ /* Mark that we are not ready with data until conversion is complete */
+ tmp102->temp[0] = TMP102_NOTREADY;
+ tmp102->temp[1] = TMP102_NOTREADY;
+ tmp102->temp[2] = TMP102_NOTREADY;
mutex_init(>lock);
hwmon_dev = hwmon_device_register_with_groups(dev, client->name,
--
2.6.2.402.g2635c2b
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/18] ARM: am57xx: cl-som-am57x: dts: add basic module support
On 11/30/2015 07:29 AM, Dmitry Lifshitz wrote: > On 11/29/2015 07:06 PM, Nishanth Menon wrote: >> On 11/29/2015 06:10 AM, Dmitry Lifshitz wrote: [...] >> >> You might want to ask your TI support contact for IODelay >> recommendations. TRM mentions that pinmuxing must be performed under IO >> isolation. There are silicon constraints in DRA7/AM57xx family, which >> were not present previously. >> > > Ok. I understand. This might take time... > Since we'd like to have this in for 4.5, what would you recommend? > Should I drop the muxes from this patch set? All the muxes? > Or should we merge this (as it works correctly) in our tests and check > on this later after investigation with TI? > > Also, in theory, there might be pins shared between two or more > different functionalities and remuxed during runtime. > Can this kind of thing be supported on AM57x? This is why I suggested to talk and confirm with TI support contact on this. I understand the motivation of SoM concept, but this requires some careful designing around. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/18] ARM: am57xx: cl-som-am57x: dts: add basic module support
On 11/30/2015 07:29 AM, Dmitry Lifshitz wrote: > On 11/29/2015 07:06 PM, Nishanth Menon wrote: >> On 11/29/2015 06:10 AM, Dmitry Lifshitz wrote: [...] >> >> You might want to ask your TI support contact for IODelay >> recommendations. TRM mentions that pinmuxing must be performed under IO >> isolation. There are silicon constraints in DRA7/AM57xx family, which >> were not present previously. >> > > Ok. I understand. This might take time... > Since we'd like to have this in for 4.5, what would you recommend? > Should I drop the muxes from this patch set? All the muxes? > Or should we merge this (as it works correctly) in our tests and check > on this later after investigation with TI? > > Also, in theory, there might be pins shared between two or more > different functionalities and remuxed during runtime. > Can this kind of thing be supported on AM57x? This is why I suggested to talk and confirm with TI support contact on this. I understand the motivation of SoM concept, but this requires some careful designing around. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/18] ARM: am57xx: cl-som-am57x: dts: add basic module support
On 11/29/2015 06:10 AM, Dmitry Lifshitz wrote:
[...]
>>> +};
>>> +
>>> +leds {
>>> +compatible = "gpio-leds";
>>> +pinctrl-names = "default";
>>> +pinctrl-0 = <_pins_default>;
>>> +
>>> +led@0 {
>>> +label = "cl-som-am57x:green";
>>> +gpios = < 5 GPIO_ACTIVE_HIGH>;
>>> +linux,default-trigger = "heartbeat";
>>> +default-state = "off";
>>> +};
>>> +};
>>> +};
>>> +
>>> +_pmx_core {
>>> +leds_pins_default: leds_pins_default {
>>> +pinctrl-single,pins = <
>>> +DRA7XX_CORE_IOPAD(0x347c, PIN_OUTPUT | MUX_MODE14)/*
>>> gpmc_a15.gpio2_5 */
>>> +>;
>>> +};
>>> +
>>> +i2c1_pins_default: i2c1_pins_default {
>>> +pinctrl-single,pins = <
>>> +DRA7XX_CORE_IOPAD(0x3800, PIN_INPUT_PULLUP |
>>> MUX_MODE0)/* i2c1_sda.sda */
>>> +DRA7XX_CORE_IOPAD(0x3804, PIN_INPUT_PULLUP |
>>> MUX_MODE0)/* i2c1_scl.scl */
>>> +>;
>>> +};
>>> +
>>> +tps659038_pins_default: tps659038_pins_default {
>>> +pinctrl-single,pins = <
>>> +DRA7XX_CORE_IOPAD(0x3818, PIN_INPUT_PULLUP | MUX_MODE14)
>>> /* wakeup0.gpio1_0 */
>>> +>;
>>> +};
>>
>> Generic comment: As per requirements of the SoC -> all pinctrl must be
>> done in bootloader. this was a recommendation that came in too late
>> for TI platforms that got introduced in upstream, but that cleanup
>> should eventually take place as well.
>>
>
> Please, could you provide a reference to those recommendations.
> Do you mean pinctrl for PMIC pins only?
You might want to ask your TI support contact for IODelay
recommendations. TRM mentions that pinmuxing must be performed under IO
isolation. There are silicon constraints in DRA7/AM57xx family, which
were not present previously.
>>> +tps659038: tps659038@58 {
>>> +compatible = "ti,tps659038";
>>> +reg = <0x58>;
>>> +interrupt-parent = <>;
>>> +interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>>
>> Also See: https://patchwork.kernel.org/patch/7596541/ ->
>> Documentation/devicetree/bindings/i2c/i2c.txt -> since you seem to
>> have a PMIC with power button, you might be able to get wakeup source
>> also there.
>>
>
> Do you mean just adding "wakeup-source" property?
>
> According to Documentation/devicetree/bindings/i2c/i2c.txt the primary
> interrupt will be used as wakeup interrupt.
I think you might have to describe a "wakeup" interrupt -> which will be
similar in description to the one you used to describe uart wakeup
capability.
[..]
>>> +pinctrl-names = "default";
>>> +pinctrl-0 = <_pins_default>;
>>> +
>>> +#interrupt-cells = <2>;
>>> +interrupt-controller;
>>> +
>>> +ti,system-power-controller;
>>
>> Assuming powerhold signal and BOOT0,1 is proper here, else poweroff
>> will never work.
>>
>
> Please, could you provide more details regarding this issue.
well, if poweroff command does not completely power off your board, you
may want to investigate further. overall, the better circuit
configuration is the X15 configuration:
https://github.com/beagleboard/beagleboard-x15/blob/master/BeagleBoard-X15_RevA2.pdf
Pay close attention to the PMIC GPIO_&/POWERHOLD signal. Also notice the
extra reset circuit involved.
Again, a topic that you should probably discuss with your TI support
contact person.
[...]
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: dra72-evm: Mark uart1 rxd as wakeup capable
On 11/26/2015 02:31 AM, Vignesh R wrote:
> Uart1 rxd is wakeup capable on DRA72 EVM. Hence, mark rxd line as
> wakeup capable. This is similar to commit 66b0436977e2c ("ARM: dts:
> dra7-evm: Mark uart1 rxd as wakeup capable") for DRA74 EVM.
>
> Signed-off-by: Vignesh R <vigne...@ti.com>
> ---
> arch/arm/boot/dts/dra72-evm.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
> index d6104d5f0c01..8bf36b0b3c33 100644
> --- a/arch/arm/boot/dts/dra72-evm.dts
> +++ b/arch/arm/boot/dts/dra72-evm.dts
> @@ -478,6 +478,8 @@
>
> {
> status = "okay";
> + interrupts-extended = <_mpu GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
> + <_pmx_core 0x3e0>;
> };
>
> {
>
Acked-by: Nishanth Menon <n...@ti.com>
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/18] ARM: am57xx: sbc-am57x: dts: add GPIO extender support
On 11/25/2015 12:39 AM, Dmitry Lifshitz wrote:
> Add PCA9555 GPIO extender support (over I2C5 bus).
I think you meant to say "GPIO expander" in commit message and
$subject perhaps?
>
> Signed-off-by: Dmitry Lifshitz <lifsh...@compulab.co.il>
> Acked-by: Igor Grinberg <grinb...@compulab.co.il>
> ---
> arch/arm/boot/dts/am57xx-sbc-am57x.dts | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> index 7b65efb..8b7c0b5 100644
> --- a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> +++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> @@ -90,4 +90,11 @@
> reg = <0x50>;
> pagesize = <16>;
> };
> +
> + pca9555: pca9555@20 {
> + compatible = "nxp,pca9555";
> + reg = <0x20>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> };
>
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/18] ARM: am57xx: cl-som-am57x: dts: add basic module support
s to figure that out..
> +
> + ldo9_reg: ldo9 {
> + /* VDD_RTC */
> + regulator-name = "ldo9";
> + regulator-min-microvolt = <105>;
> + regulator-max-microvolt = <105>;
> + regulator-always-on;
> + regulator-boot-on;
as per data sheet:
"VD_RTC can optionally be tied to VD_CORE and operate at the VD_CORE
AVS voltages."
I assume that is not the case here.
> + };
> +
> + ldoln_reg: ldoln {
> + /* VDDA_1V8_PLL */
> + regulator-name = "ldoln";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + ldousb_reg: ldousb {
> + /* VDDA_3V_USB: VDDA_USBHS33 */
> + regulator-name = "ldousb";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-boot-on;
All SoC VDDAs must be always-on.
[...]
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rtc: ds1307: Fix alarm programming for mcp794xx
On 10/23/2015 01:29 AM, Tero Kristo wrote:
> mcp794xx alarm registers must be written in BCD format. However, the
> alarm programming logic neglected this by adding one to the value
> after bin2bcd conversion has been already done, writing bad values
> to month register in case the alarm being set is in October. In this
> case, the alarm month value becomes 0x0a instead of the expected 0x10.
>
> Fix by moving the +1 addition within the bin2bcd call also.
>
> Fixes: 1d1945d261a2 ("drivers/rtc/rtc-ds1307.c: add alarm support for
> mcp7941x chips")
>
> Signed-off-by: Tero Kristo <t-kri...@ti.com>
Nice catch.
Acked-by: Nishanth Menon <n...@ti.com>
> ---
> drivers/rtc/rtc-ds1307.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
> index a705e64..188006c 100644
> --- a/drivers/rtc/rtc-ds1307.c
> +++ b/drivers/rtc/rtc-ds1307.c
> @@ -718,9 +718,9 @@ static int mcp794xx_set_alarm(struct device *dev, struct
> rtc_wkalrm *t)
> regs[3] = bin2bcd(t->time.tm_sec);
> regs[4] = bin2bcd(t->time.tm_min);
> regs[5] = bin2bcd(t->time.tm_hour);
> - regs[6] = bin2bcd(t->time.tm_wday) + 1;
> + regs[6] = bin2bcd(t->time.tm_wday + 1);
> regs[7] = bin2bcd(t->time.tm_mday);
> - regs[8] = bin2bcd(t->time.tm_mon) + 1;
> + regs[8] = bin2bcd(t->time.tm_mon + 1);
>
> /* Clear the alarm 0 interrupt flag. */
> regs[6] &= ~MCP794XX_BIT_ALMX_IF;
>
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: DRA7: hwmod: Enable DEBUG_LL for UART4
On 10/22/2015 04:01 PM, Praneeth Bajjuri wrote:
> UART4 low level debug support. This helps in debugging with UART4
> serial console output on DRA7 based platforms.
>
> Extending the following fix for UART4.
> commit 1c7e36bfc3e2 ("ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL enabled
> on UART3")
>
> For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART4 in menuconfig.
> On DRA7, UART4 hwmod doesn't have this flag enabled,
> failure observed when UART4 is used for low level debugging.
>
> Hence, Enable DEBUG_OMAP4UART4_FLAGS for UART4 hwmod.
>
> Signed-off-by: J.D. Schroeder <jay.schroe...@garmin.com>
> Signed-off-by: Praneeth Bajjuri <prane...@ti.com>
> ---
> arch/arm/mach-omap2/omap_hwmod_7xx_data.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index 562247b..a242572 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -2065,7 +2065,7 @@ static struct omap_hwmod dra7xx_uart4_hwmod = {
> .class = _uart_hwmod_class,
> .clkdm_name = "l4per_clkdm",
> .main_clk = "uart4_gfclk_mux",
> - .flags = HWMOD_SWSUP_SIDLE_ACT,
> + .flags = HWMOD_SWSUP_SIDLE_ACT | DEBUG_OMAP4UART4_FLAGS,
> .prcm = {
> .omap4 = {
> .clkctrl_offs = DRA7XX_CM_L4PER_UART4_CLKCTRL_OFFSET,
>
are there other uarts that may need this to be done?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] ARM: DRA7: hwmod: Enable DEBUG_LL for UART4
On 10/22/2015 08:01 PM, Praneeth wrote:
> Hi Nishanth,
>
> On 10/22/2015 07:24 PM, Praneeth Bajjuri wrote:
>> From: "J.D. Schroeder" <jay.schroe...@garmin.com>
>>
>> UART4 low level debug support. This helps in debugging with UART4
>> serial console output on DRA7 based platforms.
>>
>> Extending the following fix for UART4.
>> commit 1c7e36bfc3e2 ("ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL
>> enabled on UART3")
>>
>> For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART4 in menuconfig.
>> On DRA7, UART4 hwmod doesn't have this flag enabled,
>> failure observed when UART4 is used for low level debugging.
>>
>> Hence, Enable DEBUG_OMAP4UART4_FLAGS for UART4 hwmod.
> Replying to your question from V1
>
> we have DRA7 based platforms with UART1/UART3/UART4 for serial console.
>
> 1,3 seems to be already fixed in mainline. Hence sending fix only for 4
Tony or others can comment. IMHO, 1c7e36bfc3e2 is an excellent example.
it considered just UART3 as the missing thing. UART1 was already done.
now, we have UART4, tomorrow, some other board will have UART2, how many
patch on top of patch do we want to do for the same problem?
Phytech
http://phytec.com/site/assets/files/2109/phytec_am57x-som_pb_release.pdf
is a SOM module (page 2 - UART5,3 go to expansion connector).
And then you have
http://www.compulab.co.il/products/computer-on-modules/cl-som-am57x-ti-am5728-am5718-system-on-module/#diagram
When we see issues like these that are probably symptoms, we might as
well try and do as wide a solution as necessary.
if we stick with the rule that we will only enable DEBUG_LL only for
those boards that are actually in upstream, then obviously, this patch
should be dropped.
I do think, personally, that by introducing changes such as enabling
DEBUG_LL for all ports, we are making the "evil vendor tree" less
different from upstream and hence reduce cost of upstreaming - hopefully
this might help motivate various product folks to actually provide
upstream support for their products (N900 is still my favourite phone
which actually works in upstream kernel- thanks to a lot of passionate
community folks) - we really want to see more of those actual products
function and be maintained with upstream kernel.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap_hsmmc: fix initialization order of mmc block devices
On Tue, Oct 13, 2015 at 3:03 AM, Lokesh Vutla <a0131...@ti.com> wrote:
>
>
> On Tuesday 13 October 2015 01:14 PM, Heiko Schocher wrote:
>> Hello Lokesh,
>>
>> Am 13.10.2015 um 08:46 schrieb Lokesh Vutla:
>>> +Nishanth,
>>>
>>> On Tuesday 13 October 2015 10:59 AM, Heiko Schocher wrote:
>>>> On embedded devices, often there is a combination of
>>>> removable mmc devices (e.g. MMC/SD cards) and hard
>>>> wired ones (e.g. eMMC). Depending on the hardware
>>>> configuration, the 'mmcblkN' node might change if
>>>> the removable device is available or not at boot time.
>>>>
>>>> E.g. if the removable device is attached at boot time,
>>>> it might become mmxblk0. And the hard wired one mmcblk1.
>>>> But if the removable device isn't there at boot time,
>>>> the hard wired one will become mmcblk0. This makes it
>>>> somehow difficult to hard code the root device to the
>>>> non-removable device and boot fast.
>>>
>>> Why not use "root=PARTUUID=${uuid}" option instead of relying on
>>> mmcblk no?
>>> U-Boot can easily detect your partuuid. Refer to [1] on how TI platforms
>>> does this in u-boot.
>>
>> Good tip ... I do not know, if it is possible to update U-Boot
>> on this boards...
>>
>> Current U-Boot says:
>> U-Boot 2013.01.01_heads/master-gc7900a0 (2015-05-06 - 20:37:15)
>>
>> I2C: ready
>> DRAM: 512 MiB
>> [...]
>> U-Boot# mmc rescan
>> U-Boot# mmc part
>>
>> Partition Map for MMC device 0 -- Partition Type: DOS
>>
>> PartStart SectorNum Sectors UUIDType
>> 1 63 144522 000ce343-01 0e Boot
>> 2 144585 659861 000ce343-02 83
>> U-Boot# part uuid mmc 0:2 uuid
>> Unknown command 'part' - try 'help'
>> U-Boot#
>>
>> So, if this patch has no chance for mainline, please let me
>> know it, thanks!
>>
>
> IIRC, Nishanth had posted a patch something similar but got rejected for
> some reason. Probably Nishanth can comment more here.
>
overall the feedback I received was for block devices, there is
already an unique method(PARTUUID/uuid) of referencing required device
and mmcxblky aliasing was not really needed - hence dropped my patch
and switched over to partuuid.
CC Tom and u-boot list as well.
for reference the current thread: http://marc.info/?t=14447142172=1=2
--
---
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] ARM: multi_v7_defconfig: Enable more OMAP family platforms
On 10/12/2015 03:04 PM, Tony Lindgren wrote: > * Nishanth Menon <n...@ti.com> [150813 08:12]: >> On Tue, Aug 11, 2015 at 5:37 AM, Tony Lindgren <t...@atomide.com> wrote: >>> >>> * Kevin Hilman <khil...@kernel.org> [150807 16:10]: >>>> Tony Lindgren <t...@atomide.com> writes: >>>> >>>>> Ping, looks like these are still pending. Probably should be >>>>> applied directly by the arm-soc maintainers. >>>> >>>> If these should go through arm-soc, please resend to:a...@kernel.org so >>>> they make it into our queue of stuff to be reviewed/applied. >>> >>> OK thanks, up to Nihshant to resend. >>> >> >> Sorry about the slow response - i will have to do this at a later >> point(probably based off 4.3-rc1). tied up with a few other internal >> stuff atm :( > > Ping, can you please resend a...@kernel.org? Would be good to have these > working for v4.4. > > Anyways, untagging this old thread so don't expect more pings from > me on this. > Will do. Sorry about the delay - we had to bring down our board farm(where the boards were hosted) for a few days due to some internal relocation. will get around to this asap. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4] arm: omap2: timer: always define omap4_local_timer_init
On 09/29/2015 11:15 AM, Felipe Balbi wrote:
> omap4_local_timer_init() can be used by other
> platforms as is. At least AM437x wants to use
> it. Instead of making omap4-only and providing
> a stub for builds without OMAP4, we can just
> make sure that function is always available
> for all SoCs that need it.
Sounds right now. $subject needs fixing. if Tony is ok picking and
fixing it up himself...
Reviewed-by: Nishanth Menon <n...@ti.com>
>
> Reported-by: Nishanth Menon <n...@ti.com>
> Signed-off-by: Felipe Balbi <ba...@ti.com>
> ---
>
> changes since v3:
> - modify commit log slightly
>
> changes since v2:
> - move ifdefs around
>
> changes since v1:
> - make sure result builds on AM43xx-only builds
>
> arch/arm/mach-omap2/timer.c | 16 +++-
> 1 file changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index e4d8701f99f9..3ebe16cd645e 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -634,32 +634,22 @@ OMAP_SYS_32K_TIMER_INIT(3_secure, 12, "secure_32k_fck",
> "ti,timer-secure",
> 2, "timer_sys_ck", NULL);
> #endif /* CONFIG_ARCH_OMAP3 */
>
> -#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) || \
> - defined(CONFIG_SOC_AM43XX)
> +#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
> OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL,
> 1, "timer_sys_ck", "ti,timer-alwon");
> #endif
>
> #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
> - defined(CONFIG_SOC_DRA7XX)
> + defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
> static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon",
> 2, "sys_clkin_ck", NULL);
> -#endif
>
> -#ifdef CONFIG_ARCH_OMAP4
> -#ifdef CONFIG_HAVE_ARM_TWD
> void __init omap4_local_timer_init(void)
> {
> omap4_sync32k_timer_init();
> clocksource_of_init();
> }
> -#else
> -void __init omap4_local_timer_init(void)
> -{
> - omap4_sync32k_timer_init();
> -}
> -#endif /* CONFIG_HAVE_ARM_TWD */
> -#endif /* CONFIG_ARCH_OMAP4 */
> +#endif
>
> #if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
> void __init omap5_realtime_timer_init(void)
>
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3] arm: omap2: timer: always define omap4_local_timer_init
On 09/29/2015 10:53 AM, Felipe Balbi wrote:
> omap4_local_timer_init() can be used by other
> platforms as is. At least AM437x wants to use
> it. Instead of making omap4-only and providing
> a stub for builds without OMAP4, we can just
> always define that function.
>
> Reported-by: Nishanth Menon <n...@ti.com>
> Signed-off-by: Felipe Balbi <ba...@ti.com>
> ---
>
> changes since v2:
> - move ifdefs around
>
> changes since v1:
> - make sure result builds on AM43xx-only builds
>
>
> arch/arm/mach-omap2/timer.c | 16 +++-
> 1 file changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index e4d8701f99f9..3ebe16cd645e 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -634,32 +634,22 @@ OMAP_SYS_32K_TIMER_INIT(3_secure, 12, "secure_32k_fck",
> "ti,timer-secure",
> 2, "timer_sys_ck", NULL);
> #endif /* CONFIG_ARCH_OMAP3 */
>
> -#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) || \
> - defined(CONFIG_SOC_AM43XX)
> +#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
> OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL,
> 1, "timer_sys_ck", "ti,timer-alwon");
> #endif
>
> #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
> - defined(CONFIG_SOC_DRA7XX)
> + defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
> static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon",
> 2, "sys_clkin_ck", NULL);
> -#endif
>
> -#ifdef CONFIG_ARCH_OMAP4
> -#ifdef CONFIG_HAVE_ARM_TWD
> void __init omap4_local_timer_init(void)
> {
> omap4_sync32k_timer_init();
> clocksource_of_init();
> }
> -#else
> -void __init omap4_local_timer_init(void)
> -{
> - omap4_sync32k_timer_init();
> -}
> -#endif /* CONFIG_HAVE_ARM_TWD */
> -#endif /* CONFIG_ARCH_OMAP4 */
> +#endif
>
> #if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
> void __init omap5_realtime_timer_init(void)
>
OK -> the change was subtle for v3 -> you now have the entire
omap4_local_timer_init under the same #ifdef as for the rest.
but then, you are wrong on $subject and commit message since you are no
longer always enabling the local_timer_init.
otherwise the change itself looks ok to me.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] arm: omap2: timer: always define omap4_local_timer_init
bit of nitpick on capitalization of $subject.. aside..
On 09/28/2015 04:23 PM, Felipe Balbi wrote:
> omap4_local_timer_init() can be used by other
> platforms as is. At least AM437x wants to use
> it. Instead of making omap4-only and providing
> a stub for builds without OMAP4, we can just
> always define that function.
>
> Reported-by: Nishanth Menon <n...@ti.com>
> Signed-off-by: Felipe Balbi <ba...@ti.com>
> ---
>
> changes since v1:
> - make sure result builds on AM43xx-only builds
>
> arch/arm/mach-omap2/timer.c | 14 ++
> 1 file changed, 2 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index e4d8701f99f9..3cdd22251a0d 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -634,32 +634,22 @@ OMAP_SYS_32K_TIMER_INIT(3_secure, 12, "secure_32k_fck",
> "ti,timer-secure",
> 2, "timer_sys_ck", NULL);
> #endif /* CONFIG_ARCH_OMAP3 */
>
> -#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) || \
> - defined(CONFIG_SOC_AM43XX)
> +#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
> OMAP_SYS_GP_TIMER_INIT(3, 2, "timer_sys_ck", NULL,
> 1, "timer_sys_ck", "ti,timer-alwon");
> #endif
>
> #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
> - defined(CONFIG_SOC_DRA7XX)
> + defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
> static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon",
> 2, "sys_clkin_ck", NULL);
> #endif
>
> -#ifdef CONFIG_ARCH_OMAP4
> -#ifdef CONFIG_HAVE_ARM_TWD
OK -> so we removed both of these..
> void __init omap4_local_timer_init(void)
> {
> omap4_sync32k_timer_init();
but this only gets defined *if*
> #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
> - defined(CONFIG_SOC_DRA7XX)
> + defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
we should fail build on omap3 only, correct??
or am i missing something else?
> clocksource_of_init();
> }
> -#else
> -void __init omap4_local_timer_init(void)
> -{
> - omap4_sync32k_timer_init();
> -}
> -#endif /* CONFIG_HAVE_ARM_TWD */
> -#endif /* CONFIG_ARCH_OMAP4 */
>
> #if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
> void __init omap5_realtime_timer_init(void)
>
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: omap2: timer: always define omap4_local_timer_init
On 09/28/2015 01:25 PM, Felipe Balbi wrote:
> omap4_local_timer_init() can be used by other
> platforms as is. At least AM437x wants to use
> it. Instead of making omap4-only and providing
> a stub for builds without OMAP4, we can just
> always define that function.
>
> Reported-by: Nishanth Menon <n...@ti.com>
> Signed-off-by: Felipe Balbi <ba...@ti.com>
> ---
> arch/arm/mach-omap2/timer.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index a55655127ef2..f9028582e962 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -642,20 +642,11 @@ static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck",
> "ti,timer-alwon",
> 2, "sys_clkin_ck", NULL);
> #endif
>
> -#ifdef CONFIG_ARCH_OMAP4
> -#ifdef CONFIG_HAVE_ARM_TWD
> void __init omap4_local_timer_init(void)
> {
> omap4_sync32k_timer_init();
> clocksource_of_init();
> }
> -#else
> -void __init omap4_local_timer_init(void)
> -{
> - omap4_sync32k_timer_init();
> -}
> -#endif /* CONFIG_HAVE_ARM_TWD */
> -#endif /* CONFIG_ARCH_OMAP4 */
>
> #if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
> void __init omap5_realtime_timer_init(void)
>
I am a little confused if this will build in a am437xx only build.
#define OMAP_SYS_32K_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop, \
clksrc_nr, clksrc_src, clksrc_prop) \
void __init omap##name##_sync32k_timer_init(void) \
Would you like to consider this for OMAP4 only build as well?
#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
defined(CONFIG_SOC_DRA7XX)
static OMAP_SYS_32K_TIMER_INIT(4, 1, "timer_32k_ck", "ti,timer-alwon",
2, "sys_clkin_ck", NULL);
#endif
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: am57xx-beagle-x15: set VDD_SD to always-on
On 09/25/2015 08:02 AM, Tomi Valkeinen wrote:
> LDO1 regulator (VDD_SD) is connected to SoC's vddshv8. vddshv8 needs to
> be kept always powered (see commit 5a0f93c6576a ("ARM: dts: Add
> am57xx-beagle-x15"), but at the moment VDD_SD is enabled/disabled
> depending on whether an SD card is inserted or not.
>
> This patch sets LDO1 regulator to always-on.
>
> This patch has a side effect of fixing another issue, HDMI DDC not
> working when SD card is not inserted:
>
> Why this happens is that the tpd12s015 (HDMI level shifter/ESD
> protection chip) has LS_OE GPIO input, which needs to be enabled for the
> HDMI DDC to work. LS_OE comes from gpio6_28. The pin that provides
> gpio6_28 is powered by vddshv8, and vddshv8 comes from VDD_SD.
>
> So when SD card is not inserted, VDD_SD is disabled, and LS_OE stays
> off.
>
> The proper fix for the HDMI DDC issue would be to maybe have the pinctrl
> framework manage the pin specific power.
>
> Apparently this fixes also a third issue (copy paste from Kishon's
> patch):
>
> ldo1_reg in addition to being connected to the io lines is also
> connected to the card detect line. On card removal, omap_hsmmc
> driver does a regulator_disable causing card detect line to be
> pulled down. This raises a card insertion interrupt and once the
> MMC core detects there is no card inserted, it does a
> regulator disable which again raises a card insertion interrupt.
> This happens in a loop causing infinite MMC interrupts.
>
> Fixes: 5a0f93c6576a ("ARM: dts: Add am57xx-beagle-x15")
> Cc: Kishon Vijay Abraham I <kis...@ti.com>
> Signed-off-by: Tomi Valkeinen <tomi.valkei...@ti.com>
> Reported-by: Louis McCarthy <compeo...@gmail.com>
Acked-by: Nishanth Menon <n...@ti.com>
> ---
> arch/arm/boot/dts/am57xx-beagle-x15.dts | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> index 3a05b94f59ed..ba8ef66a16e0 100644
> --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> @@ -415,11 +415,12 @@
> /* SMPS9 unused */
>
> ldo1_reg: ldo1 {
> - /* VDD_SD */
> + /* VDD_SD / VDDSHV8 */
> regulator-name = "ldo1";
> regulator-min-microvolt = <180>;
> regulator-max-microvolt = <330>;
> regulator-boot-on;
> + regulator-always-on;
> };
>
> ldo2_reg: ldo2 {
>
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Add am335x-bonegreen
On 09/25/2015 10:10 AM, Robert Nelson wrote:
> SeeedStudio BeagleBone Green (BBG) is clone of the BeagleBone Black (BBB)
> minus
> the HDMI port and addition of two Grove connectors (i2c2 and usart2).
>
> This board can be identified by the 1A value after A335BNLT (BBB) in the at24
> eeprom:
> 1A: [aa 55 33 ee 41 33 33 35 42 4e 4c 54 1a 00 00 00 |.U3.A335BNLT|]
>
> http://beagleboard.org/green
> http://www.seeedstudio.com/wiki/Beaglebone_green
>
> Signed-off-by: Robert Nelson <robertcnel...@gmail.com>
> CC: Tony Lindgren <t...@atomide.com>
> CC: Jason Kridner <jkrid...@gmail.com>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/am335x-bonegreen.dts | 53
> ++
> 2 files changed, 54 insertions(+)
> create mode 100644 arch/arm/boot/dts/am335x-bonegreen.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 233159d..e45d771 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -446,6 +446,7 @@ dtb-$(CONFIG_SOC_AM33XX) += \
> am335x-base0033.dtb \
> am335x-bone.dtb \
> am335x-boneblack.dtb \
> + am335x-bonegreen.dtb \
> am335x-sl50.dtb \
> am335x-evm.dtb \
> am335x-evmsk.dtb \
> diff --git a/arch/arm/boot/dts/am335x-bonegreen.dts
> b/arch/arm/boot/dts/am335x-bonegreen.dts
> new file mode 100644
> index 000..0f65bda
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-bonegreen.dts
> @@ -0,0 +1,53 @@
> +/*
> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +/dts-v1/;
> +
> +#include "am33xx.dtsi"
> +#include "am335x-bone-common.dtsi"
> +
> +/ {
> + model = "TI AM335x BeagleBone Green";
> + compatible = "ti,am335x-bone-green", "ti,am335x-bone-black",
> "ti,am335x-bone", "ti,am33xx";
> +};
> +
> +_reg {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-always-on;
> +};
> +
> + {
> + vmmc-supply = <_fixed>;
> +};
> +
> + {
> + vmmc-supply = <_fixed>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + bus-width = <8>;
> + status = "okay";
> +};
> +
> +_pinmux {
> + uart2_pins: uart2_pins {
> + pinctrl-single,pins = <
> + 0x150 (PIN_INPUT | MUX_MODE1) /* spi0_sclk.uart2_rxd
> */
> + 0x154 (PIN_OUTPUT | MUX_MODE1) /* spi0_d0.uart2_txd */
> + >;
> + };
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + status = "okay";
> +};
> +
> + {
> + system-power-controller;
> +};
>
Would still work when https://patchwork.kernel.org/patch/6394821/ gets in?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: OMAP2: erratum I688 handling disabled for AM335x
On 09/25/2015 09:35 AM, Tony Lindgren wrote: > * Bastian Stender <b...@pengutronix.de> [150925 05:40]: >> Hi, >> >> On 09/25/2015 02:08 PM, Russell King - ARM Linux wrote: >>> On Fri, Sep 25, 2015 at 12:01:13PM +0200, Bastian Stender wrote: >>>> Signed-off-by: Bastian Stender <b...@pengutronix.de> >>>> --- >>>> arch/arm/mach-omap2/omap4-common.c | 6 ++ >>>> 1 file changed, 6 insertions(+) >>>> >>>> diff --git a/arch/arm/mach-omap2/omap4-common.c >>>> b/arch/arm/mach-omap2/omap4-common.c >>>> index 949696b..a3a0cd1 100644 >>>> --- a/arch/arm/mach-omap2/omap4-common.c >>>> +++ b/arch/arm/mach-omap2/omap4-common.c >>>> @@ -131,6 +131,12 @@ static int __init omap4_sram_init(void) >>>>struct device_node *np; >>>>struct gen_pool *sram_pool; >>>> >>>> + /* AM335x is OMAP2+, so no erratum I688 handling needed >>>> + * (see CONFIG_OMAP4_ERRATA_I688) needed >>> >>> This makes no sense. OMAP4 is OMAP2+ as well, but it needs the erratum. >>> In fact, all code in mach-omap2 is "OMAP2+". >>> >>> So, AM335x being "OMAP2+" is no reason at all why I688 should be disabled. >> >> So, the Device Tree for AM335x does need a compatible = "ti,omap4-mpu" node >> + sram property for I688 handling? > > If the errata is interconnect related and applies for omap4+, then > the interconnects are the same also on dm81xx and am335x AFAIK. > > If I688 is not needed on am335x, then it seems there are still some > mysteries remaining with this erratum to unravel. Something like > difference in the L3 implementation. Maybe somebody from TI > can investigate which SoCs this is really needed on? > > Regards, > > Tony > + Richard who probably has the oldest history on the topic. I suspect strongly that the erratum was discovered during A9 OMAP4 days, but never percolated to older SoC erratum documentation. The need of barrier logic was clarified with SoC folks to confirm the behavior though. Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: All OMAP platforms: MMC is broken
On 09/24/2015 08:13 PM, Tony Lindgren wrote:
> * Tony Lindgren <t...@atomide.com> [150924 16:42]:
>> * Russell King - ARM Linux <li...@arm.linux.org.uk> [150924 02:04]:
>>> Nightly testing has revealed that both the OMAP3430 LDP and the OMAP4430
>>> SDP fail to boot due to lack of working MMC. Both platforms fail to
>>> find their rootfs, which is on a SD card.
>>>
>>> The breakage occurred somewhere between trees of September 9th (commit
>>> 4e4adb2f4628) and September 12th (commit b0a1ea51bda4), so during the
>>> merge window.
>>
>> Yes sorry things got messed up in multiple ways :( I've summarized
>> the mess here earlier:
>>
>> http://article.gmane.org/gmane.linux.kernel.mmc/33911
>>
>> And today commit b9c93646fd5c ("regulator: pbias: program pbias register
>> offset in pbias driver") hit mainline so I'll send a pull request for
>> the related dts change.
>
> Kishon, while testing I noticed there are still at least two
> issues remaining that seem to need fixing in the MMC driver:
>
> 1. The legacy booting without device tree does not probe MMC at
>all on omap3
>
> 2. I'm getting the regulator warning on omap4 duovero
>
> Anyways, I'm sending a pull request for the fixes so far as that
> gets MMC working again for most platforms.
>
> Regards,
>
With 0925, i think the patches got merged. here is my testing status on
the boards I have access to:
https://github.com/nmenon/kernel-test-logs/tree/next-20150925
Looks like with omap2plus_defconfig, at least
https://github.com/nmenon/kernel-test-logs/blob/next-20150925/omap2plus_defconfig/am335x-evm.txt
somethign is broken there - dunno what yet.
There are a few more farm related failures in various locations, but not
too interesting.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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] regulator: tps65218: Fix missing zero typo
On 09/15/2015 03:34 PM, Andrew F. Davis wrote:
> Add missing zero to value. This will be needed when range checking
> is implemented.
>
> Signed-off-by: Andrew F. Davis <a...@ti.com>
Care about Fixes tag?
> ---
> drivers/regulator/tps65218-regulator.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/regulator/tps65218-regulator.c
> b/drivers/regulator/tps65218-regulator.c
> index 7f97223..a02c1b9 100644
> --- a/drivers/regulator/tps65218-regulator.c
> +++ b/drivers/regulator/tps65218-regulator.c
> @@ -73,7 +73,7 @@ static const struct regulator_linear_range dcdc4_ranges[] =
> {
> };
>
> static struct tps_info tps65218_pmic_regs[] = {
> - TPS65218_INFO(DCDC1, "DCDC1", 85, 167500),
> + TPS65218_INFO(DCDC1, "DCDC1", 85, 1675000),
> TPS65218_INFO(DCDC2, "DCDC2", 85, 1675000),
> TPS65218_INFO(DCDC3, "DCDC3", 90, 340),
> TPS65218_INFO(DCDC4, "DCDC4", 1175000, 340),
>
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: am57xx-beagle-x15: Update Phy supplies
Hi Tony,
On 09/03/2015 02:23 PM, Nishanth Menon wrote:
> Originally, all the SoC PHY rails were supplied by LDO3. However, as a
> result of characterization, it was determined that this posed a risk in
> extreme load conditions. Hence the PHY rails are split between two
> different LDOs. Update the related node as a result
>
> LDO3/VDDA_1V8_PHYA supplies vdda_usb1, vdda_usb2, vdda_sata, vdda_usb3
> LDO4/VDDA_1V8_PHYB supplies vdda_pcie1, vdda_pcie0, vdda_hdmi, vdda_pcie
>
> NOTE: We break compatibility with pre-production boards with this change
> since, the PMIC LDO4 is disabled at OTP level.
>
> The new configuration is the plan of record and all pre-production
> boards are supposed to be replaced with the latest boards matching the
> mentioned configuration.
>
> Signed-off-by: Nishanth Menon <n...@ti.com>
> ---
Gentle ping. Some very few 10 something boards have been created and
stopped production till the latest modifications were done (PMIC USB
interrupt, LDO4 etc) - and all of those boards are now getting
scrapped.. If there are any (as per tracking information, there should
not be any), TI should be contacted to have them replaced.
Is it possible for us to consider this patch in 4.3 cycle - given that
we are this close, might have been great to see 4.3 vanilla function on
the production platform.
> arch/arm/boot/dts/am57xx-beagle-x15.dts | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> index 3a05b94f59ed..ede7fb73c717 100644
> --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> @@ -432,7 +432,7 @@
> };
>
> ldo3_reg: ldo3 {
> - /* VDDA_1V8_PHY */
> + /* VDDA_1V8_PHYA */
> regulator-name = "ldo3";
> regulator-min-microvolt = <180>;
> regulator-max-microvolt = <180>;
> @@ -440,6 +440,15 @@
> regulator-boot-on;
> };
>
> + ldo4_reg: ldo4 {
> + /* VDDA_1V8_PHYB */
> + regulator-name = "ldo4";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> ldo9_reg: ldo9 {
> /* VDD_RTC */
> regulator-name = "ldo9";
> @@ -681,7 +690,7 @@
>
> {
> status = "ok";
> - vdda-supply = <_reg>;
> + vdda-supply = <_reg>;
>
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
>
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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] ARM: omap2+: board-generic: Remove stale of_irq macros
When commit c4082d499fa2 ("ARM: omap2+: board-generic: clean up the
irq data from board file") cleaned up the direct usage of gic_of_init
and omap_intc_of_init, it failed to clean up the macros properly.
Since these macros are no longer used, lets just remove them.
Fixes: c4082d499fa2 ("ARM: omap2+: board-generic: clean up the irq data from
board file")
Reported-by: Carlos Hernandez <c...@ti.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
arch/arm/mach-omap2/board-generic.c |7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 24c9afc9e8a7..6133eaac685d 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -20,13 +20,6 @@
#include "common.h"
-#if !(defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3))
-#define intc_of_init NULL
-#endif
-#ifndef CONFIG_ARCH_OMAP4
-#define gic_of_initNULL
-#endif
-
static const struct of_device_id omap_dt_match_table[] __initconst = {
{ .compatible = "simple-bus", },
{ .compatible = "ti,omap-infra", },
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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] ARM: OMAP5: Cleanup options for SoC only build
OMAP5 SoC has Cortex-A15 which does not use TWD timer. It uses ARCH_TIMER instead, clean up unwanted configuration and enable OMAP_INTERCONNECT and OPP which is necessary for expected functionality on the SoC. Reported-by: Carlos Hernandez <c...@ti.com> Reported-by: Felipe Balbi <ba...@ti.com> Signed-off-by: Nishanth Menon <n...@ti.com> --- arch/arm/mach-omap2/Kconfig |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 403022a38607..b3a0dff67e3f 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -44,10 +44,11 @@ config SOC_OMAP5 select ARM_CPU_SUSPEND if PM select ARM_GIC select HAVE_ARM_SCU if SMP - select HAVE_ARM_TWD if SMP select HAVE_ARM_ARCH_TIMER select ARM_ERRATA_798181 if SMP + select OMAP_INTERCONNECT select OMAP_INTERCONNECT_BARRIER + select PM_OPP if PM config SOC_AM33XX bool "TI AM33XX" -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] ARM: OMAP5/DRA7: minor fixes
Hi, While doing a SoC only build for DRA7, a few bugs did pop up. The following series provides necessary fixups for the same. Nishanth Menon (4): ARM: OMAP4+: PM: erratum is used by OMAP5 and DRA7 as well ARM: omap2+: board-generic: Remove stale of_irq macros ARM: DRA7: Select missing options for SoC only build ARM: OMAP5: Cleanup options for SoC only build arch/arm/mach-omap2/Kconfig |6 +- arch/arm/mach-omap2/board-generic.c |7 --- arch/arm/mach-omap2/pm.h|3 ++- 3 files changed, 7 insertions(+), 9 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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] ARM: DRA7: Select missing options for SoC only build
DRA7 does use OPP, uses OMAP interconnect and also does require SCU. These are missing in the SoC only build of DRA7 breaking various PM features in DRA7 only build. Reported-by: Carlos Hernandez <c...@ti.com> Signed-off-by: Nishanth Menon <n...@ti.com> --- arch/arm/mach-omap2/Kconfig |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 07d2e100caab..403022a38607 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -70,10 +70,13 @@ config SOC_DRA7XX select ARCH_OMAP2PLUS select ARM_CPU_SUSPEND if PM select ARM_GIC + select HAVE_ARM_SCU if SMP select HAVE_ARM_ARCH_TIMER select IRQ_CROSSBAR select ARM_ERRATA_798181 if SMP + select OMAP_INTERCONNECT select OMAP_INTERCONNECT_BARRIER + select PM_OPP if PM config ARCH_OMAP2PLUS bool -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" 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] ARM: OMAP4+: PM: erratum is used by OMAP5 and DRA7 as well
OMAP5 and DRA7 reuse the same pm44xx_erratum variable so, enable the
same, else PM features such as Suspend to ram is broken in a SoC only
build configuration.
Reported-by: Carlos Hernandez <c...@ti.com>
Signed-off-by: Nishanth Menon <n...@ti.com>
---
arch/arm/mach-omap2/pm.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 425bfcd67db6..f5bae699baac 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -103,7 +103,8 @@ static inline void
enable_omap3630_toggle_l2_on_restore(void) { }
#define PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD (1 << 0)
#define PM_OMAP4_CPU_OSWR_DISABLE (1 << 1)
-#if defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_PM) && (defined(CONFIG_ARCH_OMAP4) ||\
+ defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX))
extern u16 pm44xx_errata;
#define IS_PM44XX_ERRATUM(id) (pm44xx_errata & (id))
#else
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: am57xx-beagle-x15: Add wakeup irq for mcp79410
With the support in the generic PM framework for wakeirq and capability
added to the rtc-ds1307 driver to support this, we can now define the
optional wakeup irq to allow the RTC to wakeup the system from low power
modes as part of suspend.
Signed-off-by: Nishanth Menon <n...@ti.com>
---
This patch depends on upcoming merge for RTC
https://git.kernel.org/cgit/linux/kernel/git/abelloni/linux.git/log/?h=rtc-next=50
merge to master of:
9901c41bd019 rtc: ds1307: Support optional wakeup interrupt source
496a7ede6cac rtc: ds1307: Sort the headers
e28475b15b65 rtc: ds1307: Switch to managed irq allocation
27a1dce6528a rtc: ds1307: Convert to threaded IRQ
Tested with the above commits from linux-next:
http://pastebin.ubuntu.com/12265857/
Could probably go in round 2 of merges for 4.3?
arch/arm/boot/dts/am57xx-beagle-x15.dts |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index ede7fb73c717..8464f3cea280 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -526,7 +526,8 @@
mcp_rtc: rtc@6f {
compatible = "microchip,mcp7941x";
reg = <0x6f>;
- interrupts = ; /* IRQ_SYS_1N */
+ interrupts-extended = <_mpu GIC_SPI 2
IRQ_TYPE_EDGE_RISING>,
+ <_pmx_core 0x424>;
pinctrl-names = "default";
pinctrl-0 = <_pins_default>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: am57xx-beagle-x15: Update Phy supplies
Originally, all the SoC PHY rails were supplied by LDO3. However, as a
result of characterization, it was determined that this posed a risk in
extreme load conditions. Hence the PHY rails are split between two
different LDOs. Update the related node as a result
LDO3/VDDA_1V8_PHYA supplies vdda_usb1, vdda_usb2, vdda_sata, vdda_usb3
LDO4/VDDA_1V8_PHYB supplies vdda_pcie1, vdda_pcie0, vdda_hdmi, vdda_pcie
NOTE: We break compatibility with pre-production boards with this change
since, the PMIC LDO4 is disabled at OTP level.
The new configuration is the plan of record and all pre-production
boards are supposed to be replaced with the latest boards matching the
mentioned configuration.
Signed-off-by: Nishanth Menon <n...@ti.com>
---
arch/arm/boot/dts/am57xx-beagle-x15.dts | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 3a05b94f59ed..ede7fb73c717 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -432,7 +432,7 @@
};
ldo3_reg: ldo3 {
- /* VDDA_1V8_PHY */
+ /* VDDA_1V8_PHYA */
regulator-name = "ldo3";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
@@ -440,6 +440,15 @@
regulator-boot-on;
};
+ ldo4_reg: ldo4 {
+ /* VDDA_1V8_PHYB */
+ regulator-name = "ldo4";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
ldo9_reg: ldo9 {
/* VDD_RTC */
regulator-name = "ldo9";
@@ -681,7 +690,7 @@
{
status = "ok";
- vdda-supply = <_reg>;
+ vdda-supply = <_reg>;
pinctrl-names = "default";
pinctrl-0 = <_pins>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: DRA752: Add ID detect for ES2.0
From: Vishal Mahaveer vish...@ti.com ES2.0 is a minor variant of ES1.1. ES2.0 is an incremental revision with various fixes including the following: - reset logic fixes - few assymetric aging logic fixes - MMC clock rate fixes - Ethernet speed fixes - edma fixes for mcasp NOTE: even though we use a compatible of dra742 and dra752, the usage in the Linux kernel is more or less interchangable - we use dra752 more often in the linux kernel compared to dra742 and 4.2-rc6 Signed-off-by: Vishal Mahaveer vish...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- based on linux-next next-20150812, applies to v4.2-rc6 as well. Definetly not a 4.2 material, for 4.3, this probably missed the first merge window for 4.3, will be great if it could be considered for the second merge window. arch/arm/mach-omap2/id.c | 8 ++-- arch/arm/mach-omap2/soc.h | 2 ++ 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index e3f713ffb06b..54a5ba54d2ff 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -653,8 +653,12 @@ void __init dra7xxx_check_revision(void) omap_revision = DRA752_REV_ES1_0; break; case 1: - default: omap_revision = DRA752_REV_ES1_1; + break; + case 2: + default: + omap_revision = DRA752_REV_ES2_0; + break; } break; @@ -674,7 +678,7 @@ void __init dra7xxx_check_revision(void) /* Unknown default to latest silicon rev as default*/ pr_warn(%s: unknown idcode=0x%08x (hawkeye=0x%08x,rev=0x%x)\n, __func__, idcode, hawkeye, rev); - omap_revision = DRA752_REV_ES1_1; + omap_revision = DRA752_REV_ES2_0; } sprintf(soc_name, DRA%03x, omap_rev() 16); diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h index f97654d11ea5..2d1d3845253c 100644 --- a/arch/arm/mach-omap2/soc.h +++ b/arch/arm/mach-omap2/soc.h @@ -469,6 +469,8 @@ IS_OMAP_TYPE(3430, 0x3430) #define DRA7XX_CLASS 0x0700 #define DRA752_REV_ES1_0 (DRA7XX_CLASS | (0x52 16) | (0x10 8)) #define DRA752_REV_ES1_1 (DRA7XX_CLASS | (0x52 16) | (0x11 8)) +#define DRA752_REV_ES2_0 (DRA7XX_CLASS | (0x52 16) | (0x20 8)) +#define DRA722_REV_ES1_0 (DRA7XX_CLASS | (0x22 16) | (0x10 8)) #define DRA722_REV_ES1_0 (DRA7XX_CLASS | (0x22 16) | (0x10 8)) void omap2xxx_check_revision(void); -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] ARM: multi_v7_defconfig: Enable more OMAP family platforms
On Tue, Aug 11, 2015 at 5:37 AM, Tony Lindgren t...@atomide.com wrote: * Kevin Hilman khil...@kernel.org [150807 16:10]: Tony Lindgren t...@atomide.com writes: Ping, looks like these are still pending. Probably should be applied directly by the arm-soc maintainers. If these should go through arm-soc, please resend to:a...@kernel.org so they make it into our queue of stuff to be reviewed/applied. OK thanks, up to Nihshant to resend. Sorry about the slow response - i will have to do this at a later point(probably based off 4.3-rc1). tied up with a few other internal stuff atm :( -- --- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cmm files for omap4460
On 08/06/2015 11:38 PM, Ryan wrote: Hi, I am using a 4460 Based custom board i want to debug linux using Trace32. Could anyone share the cmm files required for debugging omap4460. I also request you to share any related documentation for debugging omap using trace32. You need to talk to lauterbach support. I have kind of always used the following and it seems to work.. ;t32id=C:\t32 t32id=/opt/t32 kdir=~/Src/opensource/linux print Connecting to OMAP 4460... SYStem.RESet system.mode down system.cpu omap4460 sys.jc RTCK system.mode attach core.select 1 system.MEMACCESS.DAP core.select 0 system.MEMACCESS.DAP TASK.RESet sYmbol.RESet sYmbol.AutoLoad.RESet ; reset autoloader list TRONCHIP.s undef ON TrOnchip.Set DABORT OFF TrOnchip.Set PABORT OFF TrOnchip.Set UNDEF OFF SYStem.Option DACR ON ; give Debugger global write permissions SETUP.IMASKASM OFF ; lock interrupts while single stepping SYSTEM.MEMACCESS DAP ; enable DAP access ;setup missing trace funnel and TPIU disable d.s eapb:0xd4164fb0 %l 0xc5acce55 d.s eapb:0xd4164000 %l 0x0301 ; ds.l 0x54160020 %1 1 print Connecting to OMAP 4460 Completed Successfully ;Resetting watchdog ;d.s e:0x4A314048 %l 0x ;wait 10.ms ;d.s e:0x4A314048 %l 0x system.option pwrdwn on setup.urate 3.s system.polling slow per.reprogram t32id\peromap4460app.per menu.reprogram t32id\menomap4460app.men data.load.elf kdir/vmlinux /nocode /gnu enddo -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP5 / DRA7: Introduce workaround for 801819
Add workaround for Cortex-A15 ARM erratum 801819 which says in summary
that A livelock can occur in the L2 cache arbitration that might
prevent a snoop from completing. Under certain conditions this can
cause the system to deadlock.
Recommended workaround is as follows:
Do both of the following:
1) Do not use the write-back no-allocate memory type.
2) Do not issue write-back cacheable stores at any time when the cache
is disabled (SCTLR.C=0) and the MMU is enabled (SCTLR.M=1). Because it
is implementation defined whether cacheable stores update the cache when
the cache is disabled it is not expected that any portable code will
execute cacheable stores when the cache is disabled.
For implementations of Cortex-A15 configured without the “L2 arbitration
register slice” option (typically one or two core systems), you must
also do the following:
3) Disable write-streaming in each CPU by setting ACTLR[28:25] = 0b
So, we provide an option to disable write streaming on OMAP5 and DRA7.
It is a rare condition to occur and may be enabled selectively based
on platform acceptance of risk.
Applies to: A15 revisions r2p0, r2p1, r2p2, r2p3 or r2p4 and REVIDR[3]
is set to 0.
Based on ARM errata Document revision 18.0 (22 Nov 2013)
Note: the configuration for the workaround needs to be done with
each CPU bringup, since CPU0 bringup is done by bootloader, it is
recommended to have the workaround in the bootloader, kernel also does
ensure that CPU0 has the workaround and makes the workaround active
when CPU1 gets active.
With CONFIG_SMP disabled, it is expected to be done by the bootloader.
This does show significant degradation in synthetic tests such as
mbw (https://packages.qa.debian.org/m/mbw.html)
mbw -n 100 100|grep AVG (on a test platform)
Without enabling the erratum:
AVG Method: MEMCPY Elapsed: 0.13406 MiB: 100.0 Copy: 745.913 MiB/s
AVG Method: DUMBElapsed: 0.06746 MiB: 100.0 Copy: 1482.357 MiB/s
AVG Method: MCBLOCK Elapsed: 0.03058 MiB: 100.0 Copy: 3270.569 MiB/s
After enabling the erratum:
AVG Method: MEMCPY Elapsed: 0.13757 MiB: 100.0 Copy: 726.913 MiB/s
AVG Method: DUMBElapsed: 0.12024 MiB: 100.0 Copy: 831.668 MiB/s
AVG Method: MCBLOCK Elapsed: 0.09243 MiB: 100.0 Copy: 1081.942 MiB/s
Most benchmarks are designed for specific performance analysis, so
overall usecase must be considered before making a decision to
enable/disable the erratum workaround.
Pending internal investigation, the erratum is kept disabled by default.
Cc: Russell King rmk+ker...@arm.linux.org.uk
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Tony Lindgren t...@atomide.com
Suggested-by: Richard Woodruff r-woodru...@ti.com
Suggested-by: Brad Griffis bgrif...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Since this is a generic ARM erratum with potentially other SoCs
benefitting from a workaround.. the only problem with a generic
workaround, as far as I can see if the SoC specific smc based acr
modification. It will be great to get some direction in this front.
Also note:
We did notice that this erratum was discussed earlier [1] however,
with internal evaluation, it was summarized that this does impact our
SoCs.
[1] https://lists.linaro.org/pipermail/linaro-kernel/2013-June/004687.html
arch/arm/mach-omap2/Kconfig | 8 +++
arch/arm/mach-omap2/omap-secure.h | 1 +
arch/arm/mach-omap2/omap-smp.c| 48 +++
3 files changed, 52 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 4a023e8d1bdb..b62835562ff0 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -245,4 +245,12 @@ endmenu
endif
+config OMAP5_ERRATA_801819
+ bool Errata 801819: An eviction from L1 data cache might stall
indefinitely
+ depends on SOC_OMAP5 || SOC_DRA7XX
+ help
+ A livelock can occur in the L2 cache arbitration that might prevent
+ a snoop from completing. Under certain conditions this can cause the
+ system to deadlock.
+
endmenu
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index af2851fbcdf0..bae263fba640 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -46,6 +46,7 @@
#define OMAP5_DRA7_MON_SET_CNTFRQ_INDEX0x109
#define OMAP5_MON_AMBA_IF_INDEX0x108
+#define OMAP5_DRA7_MON_SET_ACR_INDEX 0x107
/* Secure PPA(Primary Protected Application) APIs */
#define OMAP4_PPA_L2_POR_INDEX 0x23
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 5305ec7341ec..faaf366c220e 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -50,6 +50,39 @@ void __iomem *omap4_get_scu_base(void)
return scu_base;
}
+#ifdef CONFIG_OMAP5_ERRATA_801819
+void omap5_erratum_workaround_801819(void)
+{
+ u32 acr, revidr;
+ u32 acr_mask;
+
+ /* REVIDR[3
Re: [PATCH 12/17] ARM: dts: am57xx-beagle-x15: Fix regulator populated in MMC1 dt node
On 07/29/2015 06:09 AM, Kishon Vijay Abraham I wrote: For beagle x15, both the vdd and io lines are connected to the same regulator (ldo1_reg). However vmmc_aux is populated to vdd_3v3. Remove it. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- arch/arm/boot/dts/am57xx-beagle-x15.dts |1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts b/arch/arm/boot/dts/am57xx-beagle-x15.dts index a63bf78..d0db5c5 100644 --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts @@ -579,7 +579,6 @@ pinctrl-0 = mmc1_pins_default; vmmc-supply = ldo1_reg; - vmmc_aux-supply = vdd_3v3; pbias-supply = pbias_mmc_reg; bus-width = 4; cd-gpios = gpio6 27 0; /* gpio 219 */ Acked-by: Nishanth Menon n...@ti.com -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap5-uevm: Add Palmas power button support
On 07/20/2015 04:07 PM, Aparna Balasubramanian wrote:
Palmas on OMAP5uevm has support for power button, so enable it.
Signed-off-by: Aparna Balasubramanian apar...@ti.com
---
Based on kernel tag 4.2.0-rc1 and test result log is at
http://pastebin.ubuntu.com/11910178/
arch/arm/boot/dts/omap5-uevm.dts |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 275618f..3cc8f35 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -510,6 +510,13 @@
};
};
};
+
+ palmas_power_button: palmas_power_button {
+ compatible = ti,palmas-pwrbutton;
+ interrupt-parent = palmas;
+ interrupts = 1 IRQ_TYPE_EDGE_FALLING;
+ wakeup-source;
+ };
};
twl6040: twl@4b {
Tested (with evtest) and verified on v4.2-rc3
Acked-by: Nishanth Menon n...@ti.com
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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: DRA7: Provide proper IO map table
On 07/15/2015 01:26 AM, Tony Lindgren wrote: * Nishanth Menon n...@ti.com [150622 08:14]: DRA7 uses OMAP5 IO table at the moment. This is purely spurious since the OMAP5 and DRA7 register maps are different in many aspects. AM57xx/DRA7 TRM Reference: http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf NOTE: Most of the drivers are already doing ioremap, so, there should'nt be any functional improvement involved here, other than making the initial iotable more accurate. Fixes: a3a9384a1157 (ARM: DRA7: Reuse io tables and add a new .init_early) Signed-off-by: Nishanth Menon n...@ti.com Is this needed for v4.2-rc or can this wait for v4.3 merge window? It can wait till 4.3 for sure. there is no known functional issue traced to this. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: dts: dra7: arch timer sits in always-on power domain
On Mon, Jul 13, 2015 at 3:41 PM, Felipe Balbi ba...@ti.com wrote:
According to DRA7x TRM section 4.3.5 Realtime Counter (Master Counter),
the realtime counter sits in the Wakeup Always-On Power domain.
Furthermore, the counter will automatically switch the 32K clock source
when MPU goes into standby and automatically switch back to SYS_CLK or
ABE_LP when MPU goes out of standby.
Signed-off-by: Felipe Balbi ba...@ti.com
Acked-by: NIshanth Menon n...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 8f1e25bcecbd..c1e6fd82485f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -50,6 +50,7 @@
GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) |
IRQ_TYPE_LEVEL_LOW),
GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) |
IRQ_TYPE_LEVEL_LOW);
interrupt-parent = gic;
+ always-on;
};
gic: interrupt-controller@48211000 {
--
2.4.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
---
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] thermal: Switch mode to enabled once the cooling device is bound
On 06/25/2015 07:50 AM, Keerthy wrote: Currently mode is still disabled even after the cooling device is bound to the appropriate device. Hence changing the mode to enabled as soon as the cooling device is registered successfully. Signed-off-by: Keerthy j-keer...@ti.com --- drivers/thermal/of-thermal.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c index 04b1be7..bc84485 100644 --- a/drivers/thermal/of-thermal.c +++ b/drivers/thermal/of-thermal.c @@ -163,6 +163,9 @@ static int of_thermal_bind(struct thermal_zone_device *thermal, } } + /* Now that cooling device is bound enable the thermal device*/ + data-mode = THERMAL_DEVICE_ENABLED; + return 0; } This makes sense to me rather than waiting for userspace to enable the zone -(by which time we might have hit catastrophic thermal events which may have been prevented if we had the zones enabled and cooling devices functional. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap 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/5] drivers/rtc/rtc-ds1307.c: Support optional wakeup interrupt source
On 06/24/2015 10:36 AM, Grygorii Strashko wrote:
On 06/23/2015 07:15 PM, Nishanth Menon wrote:
[...]
+ds1307-wakeirq = of_irq_get(node, 1);
+if (ds1307-wakeirq = 0) {
+if (ds1307-wakeirq == -EPROBE_DEFER) {
+err = ds1307-wakeirq;
+goto exit;
+}
+ds1307-wakeirq = 0;
+goto no_irq;
+}
Might be above code could be done a little bit simpler?
err = of_irq_get(node, 1);
if (err = 0) {
if (err == -EPROBE_DEFER)
goto exit;
goto no_irq;
I had considered it, but problem with this approach is that is err
does not get reset back to 0 and probe will fail as it flows through
the rest of the code.. which is not our intent.
}
ds1307-wakeirq = err;
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/5] drivers/rtc/rtc-ds1307.c: Support optional wakeup interrupt source
On 11:07-20150624, Nishanth Menon wrote:
On 06/24/2015 10:36 AM, Grygorii Strashko wrote:
On 06/23/2015 07:15 PM, Nishanth Menon wrote:
[...]
+ ds1307-wakeirq = of_irq_get(node, 1);
+ if (ds1307-wakeirq = 0) {
+ if (ds1307-wakeirq == -EPROBE_DEFER) {
+ err = ds1307-wakeirq;
+ goto exit;
+ }
+ ds1307-wakeirq = 0;
+ goto no_irq;
+ }
Might be above code could be done a little bit simpler?
err = of_irq_get(node, 1);
if (err = 0) {
if (err == -EPROBE_DEFER)
goto exit;
goto no_irq;
I had considered it, but problem with this approach is that is err
does not get reset back to 0 and probe will fail as it flows through
the rest of the code.. which is not our intent.
I am wrong here - code just returns 0 and ignores err. So, how about
the following patch instead: (Alexandre, please do let me know if the
entire series needs to be reposted):
- improvement as suggested
- Picked up previous acks
- cleanup in probe does not need dev_pm_clear_wake_irq.
--8---
From 12367f8edffc25613f6f920d9bd7b69dfed57ce1 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Mon, 22 Jun 2015 14:13:19 -0500
Subject: [PATCH V3] drivers/rtc/rtc-ds1307.c: Support optional wakeup interrupt
source
With the recent pinctrl-single changes, SoCs such as Texas
Instrument's OMAP processors can treat wake-up events from deeper idle
states as interrupts.
Let's add support for the optional second interrupt for wake-up using
the generic wakeirq support added in commit 4990d4fe327b (PM /
Wakeirq: Add automated device wake IRQ handling)
Finally, to pass the wake-up interrupt in the dts file,
interrupts-extended property needs to be passed.
This is similar in approach to commit 2a0b965cfb6e (serial: omap: Add
support for optional wake-up) + ee83bd3b6483 (serial: omap: Switch
wake-up interrupt to generic wakeirq)
Acked-by: Tony Lindgren t...@atomide.com
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/rtc/rtc-ds1307.c | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index b03880fc32b5..e16989c48a90 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -15,6 +15,9 @@
#include linux/i2c.h
#include linux/init.h
#include linux/module.h
+#include linux/of_device.h
+#include linux/of_irq.h
+#include linux/pm_wakeirq.h
#include linux/rtc/ds1307.h
#include linux/rtc.h
#include linux/slab.h
@@ -114,6 +117,7 @@ struct ds1307 {
#define HAS_ALARM 1 /* bit 1 == irq claimed */
struct i2c_client *client;
struct rtc_device *rtc;
+ int wakeirq;
s32 (*read_block_data)(const struct i2c_client *client, u8 command,
u8 length, u8 *values);
s32 (*write_block_data)(const struct i2c_client *client, u8 command,
@@ -1156,6 +1160,8 @@ read_rtc:
}
if (want_irq) {
+ struct device_node *node = client-dev.of_node;
+
err = devm_request_threaded_irq(client-dev,
client-irq, NULL, irq_handler,
IRQF_SHARED | IRQF_ONESHOT,
@@ -1163,13 +1169,34 @@ read_rtc:
if (err) {
client-irq = 0;
dev_err(client-dev, unable to request IRQ!\n);
- } else {
+ goto no_irq;
+ }
- set_bit(HAS_ALARM, ds1307-flags);
- dev_dbg(client-dev, got IRQ %d\n, client-irq);
+ set_bit(HAS_ALARM, ds1307-flags);
+ dev_dbg(client-dev, got IRQ %d\n, client-irq);
+
+ /* Currently supported by OF code only! */
+ if (!node)
+ goto no_irq;
+
+ err = of_irq_get(node, 1);
+ if (err = 0) {
+ if (err == -EPROBE_DEFER)
+ goto exit;
+ goto no_irq;
+ }
+ ds1307-wakeirq = err;
+
+ err = dev_pm_set_dedicated_wake_irq(client-dev,
+ ds1307-wakeirq);
+ if (err) {
+ dev_err(client-dev, unable to setup wakeIRQ %d!\n,
+ err);
+ goto exit;
}
}
+no_irq:
if (chip-nvram_size) {
ds1307-nvram = devm_kzalloc(client-dev,
@@ -1213,6 +1240,9 @@ static int ds1307_remove(struct i2c_client *client)
{
struct ds1307 *ds1307 = i2c_get_clientdata(client
[PATCH V2 0/5] drivers/rtc/rtc-ds1307.c: Basic cleanups and support for wakeupirq
Hi, Here is the revamp of the patch posted eariler to support wakeupirq. This series does a few cleanups as well prior to introducing the generic apis required to support the wakeirq mechanism used on certain TI SoCs. Cleanups done here are just minimal set of the cleanups we discussed in [2]. Series is based on next-20150623 Test log: http://pastebin.ubuntu.com/11763002/ NOTE1: I have only tested in mcp79410 device, and not on other ds1307-rtc driver compatbile devices as I dont have any other. additional testing might be nice to have. NOTE2: there are additional fixes that linux-next seems to need but those are in omap-rtc, cpufreq etc, but those are not related by the ds-1307. V1: https://patchwork.kernel.org/patch/4759171/ NOTE: Patch 5/5 of the series is meant to indicate the usage, and will be reposted along with other wakeup sources to be enabled once the driver changes are accepted. Felipe Balbi (1): drivers/rtc/rtc-ds1307.c: Convert to threaded IRQ Nishanth Menon (4): drivers/rtc/rtc-ds1307.c: Switch to managed irq allocation drivers/rtc/rtc-ds1307.c: Sort the headers drivers/rtc/rtc-ds1307.c: Support optional wakeup interrupt source (TMP) ARM: dts: am57xx-beagle-x15: Add wakeup irq for mcp79410 arch/arm/boot/dts/am57xx-beagle-x15.dts |3 +- drivers/rtc/rtc-ds1307.c| 110 +-- 2 files changed, 63 insertions(+), 50 deletions(-) -- 1.7.9.5 [2] https://patchwork.kernel.org/patch/6245101/ -- To unsubscribe from this list: send the line unsubscribe linux-omap 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/5] drivers/rtc/rtc-ds1307.c: Sort the headers
It is always a good practice to keep the #includes sorted Signed-off-by: Nishanth Menon n...@ti.com --- drivers/rtc/rtc-ds1307.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c index 0a98d8a52791..b03880fc32b5 100644 --- a/drivers/rtc/rtc-ds1307.c +++ b/drivers/rtc/rtc-ds1307.c @@ -11,14 +11,14 @@ * published by the Free Software Foundation. */ -#include linux/module.h +#include linux/bcd.h +#include linux/i2c.h #include linux/init.h +#include linux/module.h +#include linux/rtc/ds1307.h +#include linux/rtc.h #include linux/slab.h -#include linux/i2c.h #include linux/string.h -#include linux/rtc.h -#include linux/bcd.h -#include linux/rtc/ds1307.h /* * We can't determine type by probing, but if we expect pre-Linux code -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap 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/5] drivers/rtc/rtc-ds1307.c: Switch to managed irq allocation
Since we are not doing anything fancy in remove function that requires
us to sequence IRQ free operation, we might as well switch over to devm_
equivalent of managed IRQ allocation and remove the explicit free_irq
since it'd be done automatically at remove.
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/rtc/rtc-ds1307.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index 8ea496e54a2e..0a98d8a52791 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -1156,9 +1156,10 @@ read_rtc:
}
if (want_irq) {
- err = request_threaded_irq(client-irq, NULL, irq_handler,
- IRQF_SHARED | IRQF_ONESHOT,
- ds1307-rtc-name, client);
+ err = devm_request_threaded_irq(client-dev,
+ client-irq, NULL, irq_handler,
+ IRQF_SHARED | IRQF_ONESHOT,
+ ds1307-rtc-name, client);
if (err) {
client-irq = 0;
dev_err(client-dev, unable to request IRQ!\n);
@@ -1212,9 +1213,6 @@ static int ds1307_remove(struct i2c_client *client)
{
struct ds1307 *ds1307 = i2c_get_clientdata(client);
- if (test_and_clear_bit(HAS_ALARM, ds1307-flags))
- free_irq(client-irq, client);
-
if (test_and_clear_bit(HAS_NVRAM, ds1307-flags))
sysfs_remove_bin_file(client-dev.kobj, ds1307-nvram);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[TMP PATCH V2 5/5] ARM: dts: am57xx-beagle-x15: Add wakeup irq for mcp79410
With the support in the generic PM framework for wakeirq and capability
added to the rtc-ds1307 driver to support this, we can now define the
optional wakeup irq to allow the RTC to wakeup the system from low power
modes as part of suspend.
Signed-off-by: Nishanth Menon n...@ti.com
---
Please do not merge this patch - since this needs to come via linux-omap
tree and also needs to be done with a few other changes on other peripherals.
This is meant for illustration only.
arch/arm/boot/dts/am57xx-beagle-x15.dts |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index a42cc377a862..5c9ce2df260a 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -517,7 +517,8 @@
mcp_rtc: rtc@6f {
compatible = microchip,mcp7941x;
reg = 0x6f;
- interrupts = GIC_SPI 2 IRQ_TYPE_EDGE_RISING; /* IRQ_SYS_1N */
+ interrupts-extended = crossbar_mpu GIC_SPI 2
IRQ_TYPE_EDGE_RISING,
+ dra7_pmx_core 0x424;
pinctrl-names = default;
pinctrl-0 = mcp79410_pins_default;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 4/5] drivers/rtc/rtc-ds1307.c: Support optional wakeup interrupt source
With the recent pinctrl-single changes, SoCs such as Texas
Instrument's OMAP processors can treat wake-up events from deeper idle
states as interrupts.
Let's add support for the optional second interrupt for wake-up using
the generic wakeirq support added in commit 4990d4fe327b (PM /
Wakeirq: Add automated device wake IRQ handling)
Finally, to pass the wake-up interrupt in the dts file,
interrupts-extended property needs to be passed.
This is similar in approach to commit 2a0b965cfb6e (serial: omap: Add
support for optional wake-up) + ee83bd3b6483 (serial: omap: Switch
wake-up interrupt to generic wakeirq)
Signed-off-by: Nishanth Menon n...@ti.com
---
Changes since V1:
- dropped the need for specific suspend-resume handlers generic api
has adequate hooks for those
- little more code flow cleanups.
V1: https://patchwork.kernel.org/patch/4759171/
drivers/rtc/rtc-ds1307.c | 41 ++---
1 file changed, 38 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index b03880fc32b5..b00d97dbf955 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -15,6 +15,9 @@
#include linux/i2c.h
#include linux/init.h
#include linux/module.h
+#include linux/of_device.h
+#include linux/of_irq.h
+#include linux/pm_wakeirq.h
#include linux/rtc/ds1307.h
#include linux/rtc.h
#include linux/slab.h
@@ -114,6 +117,7 @@ struct ds1307 {
#define HAS_ALARM 1 /* bit 1 == irq claimed */
struct i2c_client *client;
struct rtc_device *rtc;
+ int wakeirq;
s32 (*read_block_data)(const struct i2c_client *client, u8 command,
u8 length, u8 *values);
s32 (*write_block_data)(const struct i2c_client *client, u8 command,
@@ -1156,6 +1160,8 @@ read_rtc:
}
if (want_irq) {
+ struct device_node *node = client-dev.of_node;
+
err = devm_request_threaded_irq(client-dev,
client-irq, NULL, irq_handler,
IRQF_SHARED | IRQF_ONESHOT,
@@ -1163,13 +1169,36 @@ read_rtc:
if (err) {
client-irq = 0;
dev_err(client-dev, unable to request IRQ!\n);
- } else {
+ goto no_irq;
+ }
+
+ set_bit(HAS_ALARM, ds1307-flags);
+ dev_dbg(client-dev, got IRQ %d\n, client-irq);
- set_bit(HAS_ALARM, ds1307-flags);
- dev_dbg(client-dev, got IRQ %d\n, client-irq);
+ /* Currently supported by OF code only! */
+ if (!node)
+ goto no_irq;
+
+ ds1307-wakeirq = of_irq_get(node, 1);
+ if (ds1307-wakeirq = 0) {
+ if (ds1307-wakeirq == -EPROBE_DEFER) {
+ err = ds1307-wakeirq;
+ goto exit;
+ }
+ ds1307-wakeirq = 0;
+ goto no_irq;
+ }
+
+ err = dev_pm_set_dedicated_wake_irq(client-dev,
+ ds1307-wakeirq);
+ if (err) {
+ dev_err(client-dev, unable to setup wakeIRQ %d\n,
+ err);
+ goto exit;
}
}
+no_irq:
if (chip-nvram_size) {
ds1307-nvram = devm_kzalloc(client-dev,
@@ -1206,6 +1235,9 @@ read_rtc:
return 0;
exit:
+ if (ds1307-wakeirq)
+ dev_pm_clear_wake_irq(client-dev);
+
return err;
}
@@ -1213,6 +1245,9 @@ static int ds1307_remove(struct i2c_client *client)
{
struct ds1307 *ds1307 = i2c_get_clientdata(client);
+ if (ds1307-wakeirq)
+ dev_pm_clear_wake_irq(client-dev);
+
if (test_and_clear_bit(HAS_NVRAM, ds1307-flags))
sysfs_remove_bin_file(client-dev.kobj, ds1307-nvram);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/5] drivers/rtc/rtc-ds1307.c: Convert to threaded IRQ
From: Felipe Balbi ba...@ti.com
The driver currently emulates the concept of threaded IRQ using a
workqueue, which it really does not need to. Instead, switch over to
threaded_irq handlers which is meant precisely for the same purpose.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/rtc/rtc-ds1307.c | 59 +++---
1 file changed, 19 insertions(+), 40 deletions(-)
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index 6e76de1856fc..8ea496e54a2e 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -114,7 +114,6 @@ struct ds1307 {
#define HAS_ALARM 1 /* bit 1 == irq claimed */
struct i2c_client *client;
struct rtc_device *rtc;
- struct work_struct work;
s32 (*read_block_data)(const struct i2c_client *client, u8 command,
u8 length, u8 *values);
s32 (*write_block_data)(const struct i2c_client *client, u8 command,
@@ -311,27 +310,17 @@ static s32 ds1307_native_smbus_read_block_data(const
struct i2c_client *client,
/*--*/
/*
- * The IRQ logic includes a real handler running in IRQ context just
- * long enough to schedule this workqueue entry. We need a task context
- * to talk to the RTC, since I2C I/O calls require that; and disable the
- * IRQ until we clear its status on the chip, so that this handler can
- * work with any type of triggering (not just falling edge).
- *
* The ds1337 and ds1339 both have two alarms, but we only use the first
* one (with a seconds field). For ds1337 we expect nINTA is our alarm
* signal; ds1339 chips have only one alarm signal.
*/
-static void ds1307_work(struct work_struct *work)
+static irqreturn_t ds1307_irq(int irq, void *dev_id)
{
- struct ds1307 *ds1307;
- struct i2c_client *client;
- struct mutex*lock;
+ struct i2c_client *client = dev_id;
+ struct ds1307 *ds1307 = i2c_get_clientdata(client);
+ struct mutex*lock = ds1307-rtc-ops_lock;
int stat, control;
- ds1307 = container_of(work, struct ds1307, work);
- client = ds1307-client;
- lock = ds1307-rtc-ops_lock;
-
mutex_lock(lock);
stat = i2c_smbus_read_byte_data(client, DS1337_REG_STATUS);
if (stat 0)
@@ -352,18 +341,8 @@ static void ds1307_work(struct work_struct *work)
}
out:
- if (test_bit(HAS_ALARM, ds1307-flags))
- enable_irq(client-irq);
mutex_unlock(lock);
-}
-
-static irqreturn_t ds1307_irq(int irq, void *dev_id)
-{
- struct i2c_client *client = dev_id;
- struct ds1307 *ds1307 = i2c_get_clientdata(client);
- disable_irq_nosync(irq);
- schedule_work(ds1307-work);
return IRQ_HANDLED;
}
@@ -634,13 +613,14 @@ static const struct rtc_class_ops ds13xx_rtc_ops = {
MCP794XX_BIT_ALMX_C1 | \
MCP794XX_BIT_ALMX_C2)
-static void mcp794xx_work(struct work_struct *work)
+static irqreturn_t mcp794xx_irq(int irq, void *dev_id)
{
- struct ds1307 *ds1307 = container_of(work, struct ds1307, work);
- struct i2c_client *client = ds1307-client;
+ struct i2c_client *client = dev_id;
+ struct ds1307 *ds1307 = i2c_get_clientdata(client);
+ struct mutex*lock = ds1307-rtc-ops_lock;
int reg, ret;
- mutex_lock(ds1307-rtc-ops_lock);
+ mutex_lock(lock);
/* Check and clear alarm 0 interrupt flag. */
reg = i2c_smbus_read_byte_data(client, MCP794XX_REG_ALARM0_CTRL);
@@ -665,9 +645,9 @@ static void mcp794xx_work(struct work_struct *work)
rtc_update_irq(ds1307-rtc, 1, RTC_AF | RTC_IRQF);
out:
- if (test_bit(HAS_ALARM, ds1307-flags))
- enable_irq(client-irq);
- mutex_unlock(ds1307-rtc-ops_lock);
+ mutex_unlock(lock);
+
+ return IRQ_HANDLED;
}
static int mcp794xx_read_alarm(struct device *dev, struct rtc_wkalrm *t)
@@ -896,6 +876,8 @@ static int ds1307_probe(struct i2c_client *client,
boolwant_irq = false;
unsigned char *buf;
struct ds1307_platform_data *pdata = dev_get_platdata(client-dev);
+ irq_handler_t irq_handler = ds1307_irq;
+
static const intbbsqi_bitpos[] = {
[ds_1337] = 0,
[ds_1339] = DS1339_BIT_BBSQI,
@@ -962,8 +944,6 @@ static int ds1307_probe(struct i2c_client *client,
* running on Vbackup (BBSQI/BBSQW)
*/
if (ds1307-client-irq 0 chip-alarm) {
- INIT_WORK(ds1307-work, ds1307_work);
-
ds1307-regs[0] |= DS1337_BIT_INTCN
[PATCH] pinctrl: dra: dt-bindings: Add virtual mode configuration option
In addition to the regular mux configuration such as mux mode 1, 2 etc, certain pins of DRA7 require to have virtual mode also programmed. This allows for predefined delay characteristics to be used by the SoC to meet timing characterstics needed for the interface. Provide easy to use macro to do the same. It is important to note that the official TI guidelines recommend to do as minimal pin reconfiguration beyond the bootloader given the design of the hardware involved which can result in substantial glitches which may impair functionality of certain peripherals. Signed-off-by: Nishanth Menon n...@ti.com --- Baseline: v4.1 include/dt-bindings/pinctrl/dra.h | 20 1 file changed, 20 insertions(+) diff --git a/include/dt-bindings/pinctrl/dra.h b/include/dt-bindings/pinctrl/dra.h index 7448edff4723..4379e29f0460 100644 --- a/include/dt-bindings/pinctrl/dra.h +++ b/include/dt-bindings/pinctrl/dra.h @@ -30,6 +30,26 @@ #define MUX_MODE14 0xe #define MUX_MODE15 0xf +/* Certain pins need virtual mode, but note: they may glitch */ +#define MUX_VIRTUAL_MODE0 (MODE_SELECT | (0x0 4)) +#define MUX_VIRTUAL_MODE1 (MODE_SELECT | (0x1 4)) +#define MUX_VIRTUAL_MODE2 (MODE_SELECT | (0x2 4)) +#define MUX_VIRTUAL_MODE3 (MODE_SELECT | (0x3 4)) +#define MUX_VIRTUAL_MODE4 (MODE_SELECT | (0x4 4)) +#define MUX_VIRTUAL_MODE5 (MODE_SELECT | (0x5 4)) +#define MUX_VIRTUAL_MODE6 (MODE_SELECT | (0x6 4)) +#define MUX_VIRTUAL_MODE7 (MODE_SELECT | (0x7 4)) +#define MUX_VIRTUAL_MODE8 (MODE_SELECT | (0x8 4)) +#define MUX_VIRTUAL_MODE9 (MODE_SELECT | (0x9 4)) +#define MUX_VIRTUAL_MODE10 (MODE_SELECT | (0xa 4)) +#define MUX_VIRTUAL_MODE11 (MODE_SELECT | (0xb 4)) +#define MUX_VIRTUAL_MODE12 (MODE_SELECT | (0xc 4)) +#define MUX_VIRTUAL_MODE13 (MODE_SELECT | (0xd 4)) +#define MUX_VIRTUAL_MODE14 (MODE_SELECT | (0xe 4)) +#define MUX_VIRTUAL_MODE15 (MODE_SELECT | (0xf 4)) + +#define MODE_SELECT(1 8) + #define PULL_ENA (0 16) #define PULL_DIS (1 16) #define PULL_UP(1 17) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in
[PATCH] ARM: DRA7: Provide proper IO map table
DRA7 uses OMAP5 IO table at the moment. This is purely spurious since
the OMAP5 and DRA7 register maps are different in many aspects.
AM57xx/DRA7 TRM Reference: http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf
NOTE: Most of the drivers are already doing ioremap, so, there should'nt
be any functional improvement involved here, other than making the
initial iotable more accurate.
Fixes: a3a9384a1157 (ARM: DRA7: Reuse io tables and add a new .init_early)
Signed-off-by: Nishanth Menon n...@ti.com
---
NOTE: there are a few 80c checkpatch warnings in this patch, which i decided
to ignore since it helps readability of the macros and overall code formatting
already used in the header.
Baseline: v4.1
Test (boot):
AM57xx-BeagleBoard-X15: http://pastebin.ubuntu.com/11757238/
DRA72x Evm: http://pastebin.ubuntu.com/11757252/
DRA74x Evm: http://pastebin.ubuntu.com/11757259/
arch/arm/mach-omap2/board-generic.c |4 +--
arch/arm/mach-omap2/common.h|1 +
arch/arm/mach-omap2/io.c| 58 ++--
arch/arm/mach-omap2/iomap.h | 63 +++
arch/arm/mach-omap2/omap54xx.h |8 +
5 files changed, 130 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 34ff14b7beab..b4fbe50672a3 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -297,7 +297,7 @@ static const char *const dra74x_boards_compat[] __initconst
= {
DT_MACHINE_START(DRA74X_DT, Generic DRA74X (Flattened Device Tree))
.reserve= omap_reserve,
.smp= smp_ops(omap4_smp_ops),
- .map_io = omap5_map_io,
+ .map_io = dra7xx_map_io,
.init_early = dra7xx_init_early,
.init_late = dra7xx_init_late,
.init_irq = omap_gic_of_init,
@@ -316,7 +316,7 @@ static const char *const dra72x_boards_compat[] __initconst
= {
DT_MACHINE_START(DRA72X_DT, Generic DRA72X (Flattened Device Tree))
.reserve= omap_reserve,
- .map_io = omap5_map_io,
+ .map_io = dra7xx_map_io,
.init_early = dra7xx_init_early,
.init_late = dra7xx_init_late,
.init_irq = omap_gic_of_init,
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index cf3cf22ecd42..749d50bb4ca5 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -198,6 +198,7 @@ void __init omap3_map_io(void);
void __init am33xx_map_io(void);
void __init omap4_map_io(void);
void __init omap5_map_io(void);
+void __init dra7xx_map_io(void);
void __init ti81xx_map_io(void);
/**
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 820dde8b5b04..c10fb291b99f 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -236,7 +236,7 @@ static struct map_desc omap44xx_io_desc[] __initdata = {
};
#endif
-#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
+#ifdef CONFIG_SOC_OMAP5
static struct map_desc omap54xx_io_desc[] __initdata = {
{
.virtual= L3_54XX_VIRT,
@@ -265,6 +265,53 @@ static struct map_desc omap54xx_io_desc[] __initdata = {
};
#endif
+#ifdef CONFIG_SOC_DRA7XX
+static struct map_desc dra7xx_io_desc[] __initdata = {
+ {
+ .virtual= L4_CFG_MPU_DRA7XX_VIRT,
+ .pfn= __phys_to_pfn(L4_CFG_MPU_DRA7XX_PHYS),
+ .length = L4_CFG_MPU_DRA7XX_SIZE,
+ .type = MT_DEVICE,
+ },
+ {
+ .virtual= L3_MAIN_SN_DRA7XX_VIRT,
+ .pfn= __phys_to_pfn(L3_MAIN_SN_DRA7XX_PHYS),
+ .length = L3_MAIN_SN_DRA7XX_SIZE,
+ .type = MT_DEVICE,
+ },
+ {
+ .virtual= L4_PER1_DRA7XX_VIRT,
+ .pfn= __phys_to_pfn(L4_PER1_DRA7XX_PHYS),
+ .length = L4_PER1_DRA7XX_SIZE,
+ .type = MT_DEVICE,
+ },
+ {
+ .virtual= L4_PER2_DRA7XX_VIRT,
+ .pfn= __phys_to_pfn(L4_PER2_DRA7XX_PHYS),
+ .length = L4_PER2_DRA7XX_SIZE,
+ .type = MT_DEVICE,
+ },
+ {
+ .virtual= L4_PER3_DRA7XX_VIRT,
+ .pfn= __phys_to_pfn(L4_PER3_DRA7XX_PHYS),
+ .length = L4_PER3_DRA7XX_SIZE,
+ .type = MT_DEVICE,
+ },
+ {
+ .virtual= L4_CFG_DRA7XX_VIRT,
+ .pfn= __phys_to_pfn(L4_CFG_DRA7XX_PHYS),
+ .length = L4_CFG_DRA7XX_SIZE,
+ .type = MT_DEVICE,
+ },
+ {
+ .virtual= L4_WKUP_DRA7XX_VIRT,
+ .pfn= __phys_to_pfn
Re: drivers/rtc/rtc-ds1307.c: Support optional wakeup interrupt source
Hi Alexandre, On 05/28/2015 08:06 AM, Alexandre Belloni wrote: Do you mind rebasing that one so I can apply it? Thanks for responding. I see Tony has done a changes in [1] - So, I will respin my series and repost. [1] http://marc.info/?l=linux-omapm=143156023023154w=2 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tty: serial: omap: use mctrl_gpio helpers
On 05/22/2015 07:16 AM, yegorsli...@googlemail.com wrote: From: Yegor Yefremov yegorsli...@googlemail.com This patch permits to use GPIOs to control the CTS/RTS/DTR/DSR/DCD/RI signals. Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com --- .../devicetree/bindings/serial/omap_serial.txt |9 + drivers/tty/serial/Kconfig |1 + drivers/tty/serial/omap-serial.c | 168 +++- 3 files changed, 171 insertions(+), 7 deletions(-) Would we rather move introducing new features to 8250_omap.c rather than doing that to omap-serial and keep feature creeping it such that we wont ever be able to switch to 8250_omap ? -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 00/27] ARM: OMAP2+: clock code migration to drivers/clk/ti
On 05/21/2015 01:38 AM, Tero Kristo wrote: On 05/21/2015 01:40 AM, Paul Walmsley wrote: On Tue, 19 May 2015, Tero Kristo wrote: Any news on this? As noted previously, I am not able to reproduce the issue you are seeing currently, can you give DEBUG_LL a shot? Yeah I just bisected it, it was caused by this: commit cc4a5fe972ad7834e8662b49b3a5fdb597e9e15e Author: Felipe Balbi ba...@ti.com Date: Fri Jan 30 11:18:56 2015 -0600 arm: config: omap2plus_defconfig: switch over to LZMA compression LZMA compression makes about 33% smaller zImage with just a slight extra decompression time. Before this patch, zImage built with o2+_dc is 4.5MiB and after it's about 3.3MiB. Suggested-by: David Cohen david.a.co...@linux.intel.com Signed-off-by: Felipe Balbi ba...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com and the timeouts on the testbed being set to fail if a kernel takes longer than five seconds to start. Seems that the part about a slight extra decompression time probably only applies to relatively recent chips. - Paul Oh, so this explains why I was thinking it took very long time to boot the recent kernels also. The boot lag is clearly noticeable without any measurement. I wonder if we should probably revert this patch. we already have issues with zImage size bloating up and running headlong into dtb - esp on platforms like N900. Felipe spend quiet some time getting things into a manageable size here - loosing 33% sounds like bad idea to me :( -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap 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] omap: i2c: Add calls for pinctrl state select
On 04/28/2015 06:05 AM, Pascal Huerst wrote: [...] On 23.04.2015 02:32, Nishanth Menon wrote: [...] Would you think adding relevant documentation in Documentation/devicetree/bindings/i2c/i2c-omap.txt might be good as well? I mean, folks should know looking at dt documentation that this bus driver does indeed support this option.. I'm not sure about that. Actually this is all handled by the pinctrl subsystem, so I would guess that documentation belongs there, since in: Documentation/devicetree/bindings/i2c/i2c-at91.txt Documentation/devicetree/bindings/i2c/i2c-nomadik.txt is no documentation about that as well. But there is documentation in: Documentation/pinctrl.txt right? Otherwise, I would say we should add documentation for all devices, so it is consistent. that is probably good since drivers may or maynot support the sleep configuration. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap 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] omap: i2c: Add calls for pinctrl state select
On 04/28/2015 06:05 AM, Pascal Huerst wrote: [...] On 23.04.2015 02:32, Nishanth Menon wrote: [...] Would you think adding relevant documentation in Documentation/devicetree/bindings/i2c/i2c-omap.txt might be good as well? I mean, folks should know looking at dt documentation that this bus driver does indeed support this option.. I'm not sure about that. Actually this is all handled by the pinctrl subsystem, so I would guess that documentation belongs there, since in: Documentation/devicetree/bindings/i2c/i2c-at91.txt Documentation/devicetree/bindings/i2c/i2c-nomadik.txt is no documentation about that as well. But there is documentation in: Documentation/pinctrl.txt right? Otherwise, I would say we should add documentation for all devices, so it is consistent. that is probably good since drivers may or maynot support support the sleep configuration. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] bus: omap_l3_noc: add missed callbacks for suspend-to-disk
On Mon, Apr 27, 2015 at 1:24 PM, grygorii.stras...@linaro.org wrote:
From: Grygorii Strashko grygorii.stras...@linaro.org
Add missed callbacks needed for proper supporting of suspend-to-disk
by using recently introduced macro SET_NOIRQ_SYSTEM_SLEEP_PM_OPS.
Cc: Tony Lindgren t...@atomide.com
Cc: Nishanth Menon n...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Santosh Shilimkar ssant...@kernel.org
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
---
drivers/bus/omap_l3_noc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 11f7982..6ae3884 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -300,7 +300,7 @@ static int omap_l3_probe(struct platform_device *pdev)
return ret;
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
/**
* l3_resume_noirq() - resume function for l3_noc
@@ -346,7 +346,7 @@ static int l3_resume_noirq(struct device *dev)
}
static const struct dev_pm_ops l3_dev_pm_ops = {
- .resume_noirq = l3_resume_noirq,
+ SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(NULL, l3_resume_noirq)
};
#define L3_DEV_PM_OPS (l3_dev_pm_ops)
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-pm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Acked-by: Nishanth Menon n...@ti.com
--
---
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bus: omap_l3_noc: Fix master id address decoding for OMAP5
On 04/24/2015 12:54 PM, Suman Anna wrote: The L3 Error handling on OMAP5 for the most part is very similar to that of OMAP4, and had leveraged common data structures and register layout definitions so far. Upon closer inspection, there are a few minor differences causing an incorrect decoding and reporting of the master NIU upon an error: 1. The L3_TARG_STDERRLOG_MSTADDR.STDERRLOG_MSTADDR occupies 11 bits on OMAP5 as against 8 bits on OMAP4, with the master NIU connID encoded in the 6 MSBs of the STDERRLOG_MSTADDR field. 2. The CLK3 FlagMux component has 1 input source on OMAP4 and 3 input sources on OMAP5. The common DEBUGSS source is at a different input on each SoC. Fix the above issues by using a OMAP5-specific compatible property and using SoC-specific data where there are differences. Cc: Nishanth Menon n...@ti.com Signed-off-by: Suman Anna s-a...@ti.com --- Some validation traces by adding couple of traces and intentionally creating L3 errors from DSP IPU by accessing invalid Timers Before Patch: OMAP4 [Correct] IPU accessing Timer4 [ 46.548095] flagmux = 1, err_reg = 0x8000 err_src = 0xf [ 46.553344] mstaddr = 0x44 mask = 0xfc masterid = 0x11 [ 46.553955] [ cut here ] [ 46.563171] WARNING: CPU: 0 PID: 4 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 46.564941] 4400.ocp:L3 Custom Error: MASTER DucatiM3 TARGET L4PER3 (Idle): Data Access in User mode during Functional access DSP accessing Timer5: [ 114.018524] flagmux = 0, err_reg = 0x4 err_src = 0x2 [ 114.023498] mstaddr = 0x20 mask = 0xfc masterid = 0x8 [ 114.028564] [ cut here ] [ 114.033233] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 114.042572] 4400.ocp:L3 Custom Error: MASTER DSP TARGET ABE (Idle): Data Access in Supervisor mode during Functional access OMAP5 [Incorrect] IPU accessing Timer4: [ 29.579306] flagmux = 1, err_reg = 0x8000 err_src = 0xf [ 29.584550] mstaddr = 0x220 mask = 0xfc masterid = 0x8 [ 29.589705] [ cut here ] [ 29.594345] WARNING: CPU: 0 PID: 61 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 29.603774] 4400.ocp:L3 Custom Error: MASTER DSP TARGET L4PER3 (Idle): Data Access in User mode during Functional access DSP accessing Timer5: [ 21.347105] flagmux = 0, err_reg = 0x4 err_src = 0x2 [ 21.352091] mstaddr = 0x100 mask = 0xfc masterid = 0x0 [ 21.357250] [ cut here ] [ 21.361896] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 21.371242] 4400.ocp:L3 Custom Error: MASTER MPU TARGET ABE (Idle): Data Access in Supervisor mode during Functional access After Patch: OMAP4 same as above OMAP5 [Corrected] IPU accessing Timer4 [ 67.896693] flagmux = 1, err_reg = 0x8000 err_src = 0xf [ 67.901940] mstaddr = 0x220 mask = 0x7e0 masterid = 0x11 [ 67.907275] [ cut here ] [ 67.911924] WARNING: CPU: 0 PID: 61 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 67.921357] 4400.ocp:L3 Custom Error: MASTER DucatiM3 TARGET L4PER3 (Idle): Data Access in User mode during Functional access DSP accessing Timer5 [ 24.452565] flagmux = 0, err_reg = 0x4 err_src = 0x2 [ 24.457552] mstaddr = 0x100 mask = 0x7e0 masterid = 0x8 [ 24.462798] [ cut here ] [ 24.467449] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 24.476795] 4400.ocp:L3 Custom Error: MASTER DSP TARGET ABE (Idle): Data Access in Supervisor mode during Functional access .../devicetree/bindings/arm/omap/l3-noc.txt| 1 + arch/arm/boot/dts/omap5.dtsi | 2 +- drivers/bus/omap_l3_noc.c | 5 ++- drivers/bus/omap_l3_noc.h | 52 -- 4 files changed, 44 insertions(+), 16 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt index 974624ea68f6..161448da959d 100644 --- a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt +++ b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt @@ -6,6 +6,7 @@ provided by Arteris. Required properties: - compatible : Should be ti,omap3-l3-smx for OMAP3 family Should be ti,omap4-l3-noc for OMAP4 family + Should be ti,omap5-l3-noc for OMAP5 family Should be ti,dra7-l3-noc for DRA7 family Should be ti,am4372-l3-noc for AM43 family - reg: Contains L3 register address range for each noc domain. diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index efe5f737f39b..7d24ae0306b5 100644 --- a/arch/arm/boot/dts
Re: Enabling IPU on OMAP44xx
On 04/24/2015 11:21 AM, Jack Mitchell wrote: I've been fighting for a week with trying to get the IPU booted over remoteproc on an OMAP4470. I feel like I've got most of the way there we do not have support for OMAP4470 on git.kernel.org. If you are interested in TI vendor kernel support, please use e2e.ti.com. ... -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bus: omap_l3_noc: Fix master id address decoding for OMAP5
On Fri, Apr 24, 2015 at 2:10 PM, Suman Anna s-a...@ti.com wrote:
On 04/24/2015 01:33 PM, Nishanth Menon wrote:
On 04/24/2015 12:54 PM, Suman Anna wrote:
...
-static struct l3_target_data omap_l3_target_data_clk3[] = {
-{0x0100, EMUSS,},
-{0x0300, DEBUG SOURCE,},
-{0x0, HOST CLK3,},
^^ this was HOST CLK3
..
+/* OMAP5 data */
+static struct l3_target_data omap5_l3_target_data_clk3[] = {
+{0x0100, L3INSTR,},
+{0x0300, DEBUGSS,},
+{0x0,HOSTCLK3,},
HOST CLK
Why? I followed the convention used for the other two HOST CLKs for the
so asked, if it should be HOSTspaceCLK3
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bus: omap_l3_noc: Fix master id address decoding for OMAP5
On 04/24/2015 02:54 PM, Suman Anna wrote:
On 04/24/2015 02:38 PM, Nishanth Menon wrote:
On Fri, Apr 24, 2015 at 2:10 PM, Suman Anna s-a...@ti.com wrote:
On 04/24/2015 01:33 PM, Nishanth Menon wrote:
On 04/24/2015 12:54 PM, Suman Anna wrote:
...
-static struct l3_target_data omap_l3_target_data_clk3[] = {
-{0x0100, EMUSS,},
-{0x0300, DEBUG SOURCE,},
-{0x0, HOST CLK3,},
^^ this was HOST CLK3
..
+/* OMAP5 data */
+static struct l3_target_data omap5_l3_target_data_clk3[] = {
+{0x0100, L3INSTR,},
+{0x0300, DEBUGSS,},
+{0x0,HOSTCLK3,},
HOST CLK
Why? I followed the convention used for the other two HOST CLKs for the
so asked, if it should be HOSTspaceCLK3
Aah ok, you missed the trailing number before. In anycase, this was
Sorry about that..
intentional to match HOSTCLK1 and HOSTCLK2 on OMAP4/5. Overall, the
names are somewhat non-standard, some use underscores and some others
strip out the underscore and do not use any spaces in between either.
HOST CLK3 would be the only one to use a space for OMAP4, so I got rid
of it, so hope that's ok with you.
would have been nice to cover that in commit message. no biggie for me.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
On 04/23/2015 05:17 AM, grygorii.stras...@linaro.org wrote: On 04/23/2015 03:00 AM, Nishanth Menon wrote: On 04/22/2015 08:26 AM, grygorii.stras...@linaro.org wrote: Hi, On 04/21/2015 03:51 AM, Nishanth Menon wrote: Alarm interrupt enable register is at offset 0x7, while the time registers for the alarm follow that. When we program Alarm interrupt enable prior to programming the time, it is possible that previous time value could be close or match at the time of alarm enable resulting in interrupt trigger which is unexpected (and does not match the time we expect it to trigger). To prevent this scenario from occuring, program the ALM0_EN bit only after the alarm time is appropriately programmed. Ofcourse, I2C programming is non-atomic, so there are loopholes where the interrupt wont trigger if the time requested is in the past at the time of programming the ALM0_EN bit. However, we will not have unexpected interrupts while the time is programmed after the interrupt are enabled. I think it will be nice if you will mention that you going to follow vendor recommendations - AN1491 Configuring the MCP794XX RTCC Family http://ww1.microchip.com/downloads/en/AppNotes/01491A.pdf ;) Also, it is recommended that the alarm registers be loaded before the alarm is enabled. Hmm... i did not know that existed, thanks for digging it up.. that teaches me to look for docs before putting a scope/LA on the board (not that I regret doing that)... That said, reading the app note, I kind of realized: a) that playing with ST bit for programming time is not done, but then, that implies that oscillator will have to be restarted (upto a few seconds for certain crystals).. but that said, it does not seem mandatory or seem to (yet seen) functional issues... b) We dont have flexibility yet to describe if we do indeed have a backup battery or not - VBATEN should be set only if we have a backup battery on the platform :( - on some it might even be optional thanks to certain compliance requirements of shipping boards internationally and general unlike of lithium ion in cargo hold.. c) we dont have capability to control the alarm polarity in the driver which, by the way, we probably should also control OUT polarity (when ALARM is not asserted).. d) we dont have support for external 32k oscillator(X1 only) instead of assuming we always have a 32k crystal(X1 and X2)... Ugghhh... more cleaning up to do for the future.. that said, the sequence it does recommend (in page 4): The following steps show how the Alarm 0 is config- ured. Alarm 1 can be configured in the same manner. 1.Write 0x23 to the Alarm0 Seconds register [0x0A]. 2.Write 0x47 to the Alarm0 Minutes register [0x0B]. 3.Write 0x71 to the Alarm0 Hours register [0x0C] – 11 hours in 12-hour format. 4.Write 0x72 to the Alarm0 Day register [0x0D] – Tuesday + Alarm Polarity Low + Match on all. The Alarm0 Interrupt Flag is also cleared. 5.Write 0x14 to the Alarm0 Date register [0x0E]. 6.Write 0x08 to the Alarm0 Month register [0x0F]. With all the Alarm0 registers set we can now activate the Alarm0 on the Control register. 7.Write 0x10 to the Control register [0x07] – Alarm0 enabled no CLKOUT, Alarm1 disabled before this patch we do ( http://pastebin.ubuntu.com/10863880/) CONTROL r[7] = 0x90 (OUT=1, ALM0EN=1) OSCTRIM r[8] = 0x00 EEUNLOCK r[9] = 0x00 ALM0SEC r[A] = 0x01 ALM0MIN r[B] = 0x45 ALM0HOUR r[C] = 0x23 ALM0WKDAY r[D] = 0x75 -ALMOIF is cleared ALM0DATE r[E] = 0x09 ALM0MTH r[F] = 0x04 RSRVED r[10] = 0x01 with this patch, we do: burst( CONTROL r[7] = 0x80 (OUT=1) OSCTRIM r[8] = 0x00 EEUNLOCK r[9] = 0x00 ALM0SEC r[A] = 0x01 ALM0MIN r[B] = 0x45 ALM0HOUR r[C] = 0x23 ALM0WKDAY r[D] = 0x75 -ALMOIF is cleared ALM0DATE r[E] = 0x09 ALM0MTH r[F] = 0x04 RSRVED r[10] = 0x01 ) CONTROL r[7] = 0x90 (OUT=1, ALM0EN=1) Which is slightly unoptimal way of what the app note recommends. - as I mentioned earlier in this thread, I will try and do optimizations in a later patch. Given that Andrew had picked up this patch, I dont see a reason to respin this yet. but will include the app note for future patches - thanks for pointing it out to me. ^^ Up to you. Np, Always yours! Considering the narrow focus of the current patch (which does fix an issue that it attempts to), can I get an Ack? -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap 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] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
On 04/22/2015 06:30 AM, Alexandre Belloni wrote: Apologies on a tardy response, got dragged into another issue and got cooped up in lab whole day. On 21/04/2015 at 20:59:15 -0500, Nishanth Menon wrote : Why is that so? when set alarm is requested for time X, you want interrupt at time X, not an interrupt for previous configured RTC alarm time! You expect at least an interrupt. And you will get an interrupt if the event occurs before the i2c burst starts. Once the i2cburst does start, you are committing to the new time. You mean that even if ALM0EN is set after ALM0IF was set to 1, it will trigger the interrupt? I had a look at the MFP output block diagram would let me think that this is the case. I was thinking otherwise before. If that is so, then indeed, your patch is OK. At least based on my testing it seems to be the case, and as you can see in the block diagram, the ALM0EN mux comes after ALM0IF.. agreed that I am not sure the mux to have some internal buffers/latches etc.. dont have access to rtl to make more comments. My concern was about the time between ds1307-write_block_data() and i2c_smbus_write_byte_data() which actually calls cond_sched(). I fully agree that your patch doesn't change the behaviour for the other cases you presented and further clean up is to be done in a separate set of patches. Can I take this as an Acked-by? -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap 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] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
On 04/22/2015 08:26 AM, grygorii.stras...@linaro.org wrote: Hi, On 04/21/2015 03:51 AM, Nishanth Menon wrote: Alarm interrupt enable register is at offset 0x7, while the time registers for the alarm follow that. When we program Alarm interrupt enable prior to programming the time, it is possible that previous time value could be close or match at the time of alarm enable resulting in interrupt trigger which is unexpected (and does not match the time we expect it to trigger). To prevent this scenario from occuring, program the ALM0_EN bit only after the alarm time is appropriately programmed. Ofcourse, I2C programming is non-atomic, so there are loopholes where the interrupt wont trigger if the time requested is in the past at the time of programming the ALM0_EN bit. However, we will not have unexpected interrupts while the time is programmed after the interrupt are enabled. I think it will be nice if you will mention that you going to follow vendor recommendations - AN1491 Configuring the MCP794XX RTCC Family http://ww1.microchip.com/downloads/en/AppNotes/01491A.pdf ;) Also, it is recommended that the alarm registers be loaded before the alarm is enabled. Hmm... i did not know that existed, thanks for digging it up.. that teaches me to look for docs before putting a scope/LA on the board (not that I regret doing that)... That said, reading the app note, I kind of realized: a) that playing with ST bit for programming time is not done, but then, that implies that oscillator will have to be restarted (upto a few seconds for certain crystals).. but that said, it does not seem mandatory or seem to (yet seen) functional issues... b) We dont have flexibility yet to describe if we do indeed have a backup battery or not - VBATEN should be set only if we have a backup battery on the platform :( - on some it might even be optional thanks to certain compliance requirements of shipping boards internationally and general unlike of lithium ion in cargo hold.. c) we dont have capability to control the alarm polarity in the driver which, by the way, we probably should also control OUT polarity (when ALARM is not asserted).. d) we dont have support for external 32k oscillator(X1 only) instead of assuming we always have a 32k crystal(X1 and X2)... Ugghhh... more cleaning up to do for the future.. that said, the sequence it does recommend (in page 4): The following steps show how the Alarm 0 is config- ured. Alarm 1 can be configured in the same manner. 1.Write 0x23 to the Alarm0 Seconds register [0x0A]. 2.Write 0x47 to the Alarm0 Minutes register [0x0B]. 3.Write 0x71 to the Alarm0 Hours register [0x0C] – 11 hours in 12-hour format. 4.Write 0x72 to the Alarm0 Day register [0x0D] – Tuesday + Alarm Polarity Low + Match on all. The Alarm0 Interrupt Flag is also cleared. 5.Write 0x14 to the Alarm0 Date register [0x0E]. 6.Write 0x08 to the Alarm0 Month register [0x0F]. With all the Alarm0 registers set we can now activate the Alarm0 on the Control register. 7.Write 0x10 to the Control register [0x07] – Alarm0 enabled no CLKOUT, Alarm1 disabled before this patch we do ( http://pastebin.ubuntu.com/10863880/) CONTROL r[7] = 0x90 (OUT=1, ALM0EN=1) OSCTRIM r[8] = 0x00 EEUNLOCK r[9] = 0x00 ALM0SEC r[A] = 0x01 ALM0MIN r[B] = 0x45 ALM0HOUR r[C] = 0x23 ALM0WKDAY r[D] = 0x75 -ALMOIF is cleared ALM0DATE r[E] = 0x09 ALM0MTH r[F] = 0x04 RSRVED r[10] = 0x01 with this patch, we do: burst( CONTROL r[7] = 0x80 (OUT=1) OSCTRIM r[8] = 0x00 EEUNLOCK r[9] = 0x00 ALM0SEC r[A] = 0x01 ALM0MIN r[B] = 0x45 ALM0HOUR r[C] = 0x23 ALM0WKDAY r[D] = 0x75 -ALMOIF is cleared ALM0DATE r[E] = 0x09 ALM0MTH r[F] = 0x04 RSRVED r[10] = 0x01 ) CONTROL r[7] = 0x90 (OUT=1, ALM0EN=1) Which is slightly unoptimal way of what the app note recommends. - as I mentioned earlier in this thread, I will try and do optimizations in a later patch. Given that Andrew had picked up this patch, I dont see a reason to respin this yet.. but will include the app note for future patches - thanks for pointing it out to me. Signed-off-by: Nishanth Menon n...@ti.com --- Changes in v2: - minor typo fix in comments - merged up code that I missed committing in V1: https://patchwork.kernel.org/patch/6245041/ drivers/rtc/rtc-ds1307.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c index 4ffabb322a9a..3cd4783375a5 100644 --- a/drivers/rtc/rtc-ds1307.c +++ b/drivers/rtc/rtc-ds1307.c @@ -742,17 +742,17 @@ static int mcp794xx_set_alarm(struct device *dev, struct rtc_wkalrm *t) regs[6] = ~MCP794XX_BIT_ALMX_IF; /* Set alarm match: second, minute, hour, day, date, month. */ regs[6] |= MCP794XX_MSK_ALMX_MATCH; - -if (t-enabled
Re: [PATCH v2] omap: i2c: Add calls for pinctrl state select
few nitpicks: i2c: omap: in $subject instead of omap: i2c: I usually would do: git log --no-merges --oneline drivers/i2c/busses/i2c-omap.c and look for common usage. On 04/22/2015 04:07 AM, pascal.hue...@gmail.com wrote: From: Pascal Huerst pascal.hue...@gmail.com This adds calls to pinctrl subsystem in order to switch pin states on suspend/resume if you provide a sleep state in DT. Signed-off-by: Pascal Huerst pascal.hue...@gmail.com --- drivers/i2c/busses/i2c-omap.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 0e89419..8261941 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -38,6 +38,7 @@ #include linux/slab.h #include linux/i2c-omap.h #include linux/pm_runtime.h +#include linux/pinctrl/consumer.h /* I2C controller revisions */ #define OMAP_I2C_OMAP1_REV_2 0x20 @@ -1423,6 +1424,8 @@ static int omap_i2c_runtime_suspend(struct device *dev) omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG); } + pinctrl_pm_select_sleep_state(dev); + return 0; } @@ -1431,6 +1434,8 @@ static int omap_i2c_runtime_resume(struct device *dev) struct platform_device *pdev = to_platform_device(dev); struct omap_i2c_dev *_dev = platform_get_drvdata(pdev); + pinctrl_pm_select_default_state(dev); + if (!_dev-regs) return 0; -- 2.1.0 Build tested with omap2plus_defconfig on linus master (27cf3a16b253) and next-20150422 While I do understand that the sleep state and default states are optional - might be nice to state it in commit message (as a result of which we dont do error checks). Would you think adding relevant documentation in Documentation/devicetree/bindings/i2c/i2c-omap.txt might be good as well? I mean, folks should know looking at dt documentation that this bus driver does indeed support this option.. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: OMAP2+: Fix omap3 off idle power consumption creeping up
On 14:47-20150421, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [150421 09:24]:
If we use a combination of VMODE and I2C4 for retention modes,
eventually the off idle power consumption will creep up by about
23mW, even during off mode with I2C4 always staying enabled.
Looks like the only way to fix the extra power consumption is to
disable I2C4 usage by setting SEL_VMODE for both off idle and
retention idle. Let's also update the comments accordingly.
Thanks Nishanth for pointing me to the related SmartReflex I2C4
erratum. No need to disable I2C4 with the SREN workaround :)
Better patch below, presumably this only affects omap3?
SREN applies to both OMAP3 and 4 - so, the patch looks right.
Regards,
Tony
8 --
From: Tony Lindgren t...@atomide.com
Date: Tue, 21 Apr 2015 14:31:23 -0700
Subject: [PATCH] ARM: OMAP2+: Fix omap3 off idle power consumption creeping up
If we use a combination of VMODE and I2C4 for retention modes,
eventually the off idle power consumption will creep up by about
23mW, even during off mode with I2C4 always staying enabled.
Turns out this is because of erratum 2.11 Extra Power Consumed
I suggest using the unique ID
i531 - that remains constant across SoCs.
When Repeated Start Operation Mode Is Enabled on I2C Interface
Dedicated for Smart Reflex (I2C4) as pointed out by Nishanth
Menon n...@ti.com.
Let's fix the issue by adding i2c_cfg_clear_mask for the bits
to clear when initializing the I2C4 adapter so we can clear
SREN bit that drives the I2C4 lines low otherwise when there
is no traffic.
Fixes: 3b8c4ebb7630 (ARM: OMAP3: Fix idle mode signaling for
sys_clkreq and sys_off_mode)
Cc: Kevin Hilman khil...@kernel.org
Cc: Nishanth Menon n...@ti.com
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/prm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/prm-regbits-34xx.h
@@ -112,6 +112,7 @@
#define OMAP3430_VC_CMD_ONLP_SHIFT 16
#define OMAP3430_VC_CMD_RET_SHIFT8
#define OMAP3430_VC_CMD_OFF_SHIFT0
+#define OMAP3430_SREN_MASK (1 4)
#define OMAP3430_HSEN_MASK (1 3)
#define OMAP3430_MCODE_MASK (0x7 0)
#define OMAP3430_VALID_MASK (1 24)
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -316,7 +316,8 @@ static void __init omap3_vc_init_pmic_signaling(struct
voltagedomain *voltdm)
* idle. And we can also scale voltages to zero for off-idle.
* Note that no actual voltage scaling during off-idle will
* happen unless the board specific twl4030 PMIC scripts are
- * loaded.
+ * loaded. See also omap_vc_i2c_init for comments regarding
+ * erratum 2.11.
^^ here as well. 2.11 on 3630 is 2.3 on OMAP3430 etc..
*/
val = voltdm-read(OMAP3_PRM_VOLTCTRL_OFFSET);
if (!(val OMAP3430_PRM_VOLTCTRL_SEL_OFF)) {
@@ -704,9 +705,16 @@ static void __init omap_vc_i2c_init(struct voltagedomain
*voltdm)
return;
}
+ /*
+ * Note that for omap3 OMAP3430_SREN_MASK clears SREN to work around
+ * erratum 2.11 Extra Power Consumed When Repeated Start Operation
+ * Mode Is Enabled on I2C Interface Dedicated for Smart Reflex (I2C4).
+ * Otherwise I2C4 eventually leads into about 23mW extran power being
+ * consumed even during off idle using VMODE.
+ */
i2c_high_speed = voltdm-pmic-i2c_high_speed;
if (i2c_high_speed)
- voltdm-rmw(vc-common-i2c_cfg_hsen_mask,
+ voltdm-rmw(vc-common-i2c_cfg_clear_mask,
vc-common-i2c_cfg_hsen_mask,
vc-common-i2c_cfg_reg);
--- a/arch/arm/mach-omap2/vc.h
+++ b/arch/arm/mach-omap2/vc.h
@@ -34,6 +34,7 @@ struct voltagedomain;
* @cmd_ret_shift: RET field shift in PRM_VC_CMD_VAL_* register
* @cmd_off_shift: OFF field shift in PRM_VC_CMD_VAL_* register
* @i2c_cfg_reg: I2C configuration register offset
+ * @i2c_cfg_clear_mask: high-speed mode bit clear mask in I2C config register
* @i2c_cfg_hsen_mask: high-speed mode bit field mask in I2C config register
* @i2c_mcode_mask: MCODE field mask for I2C config register
*
@@ -52,6 +53,7 @@ struct omap_vc_common {
u8 cmd_ret_shift;
u8 cmd_off_shift;
u8 i2c_cfg_reg;
+ u8 i2c_cfg_clear_mask;
u8 i2c_cfg_hsen_mask;
u8 i2c_mcode_mask;
};
--- a/arch/arm/mach-omap2/vc3xxx_data.c
+++ b/arch/arm/mach-omap2/vc3xxx_data.c
@@ -28,6 +28,7 @@
/*
* VC data common to 34xx/36xx chips
* XXX This stuff presumably belongs in the vc3xxx.c or vc.c file.
+ * Note that we must clear SREN to work around erratum 2.11.
*/
static struct omap_vc_common omap3_vc_common = {
.bypass_val_reg = OMAP3_PRM_VC_BYPASS_VAL_OFFSET,
@@ -40,6 +41,7
Re: [PATCH 1/1] ARM: OMAP2+: Fix omap3 off idle power consumption creeping up
On 04/21/2015 08:00 PM, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [150421 15:13]:
On 14:47-20150421, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [150421 09:24]:
If we use a combination of VMODE and I2C4 for retention modes,
eventually the off idle power consumption will creep up by about
23mW, even during off mode with I2C4 always staying enabled.
Looks like the only way to fix the extra power consumption is to
disable I2C4 usage by setting SEL_VMODE for both off idle and
retention idle. Let's also update the comments accordingly.
Thanks Nishanth for pointing me to the related SmartReflex I2C4
erratum. No need to disable I2C4 with the SREN workaround :)
Better patch below, presumably this only affects omap3?
SREN applies to both OMAP3 and 4 - so, the patch looks right.
Oh OK, I was missing setting the clear bit for omap4. I've added
it now.
If we use a combination of VMODE and I2C4 for retention modes,
eventually the off idle power consumption will creep up by about
23mW, even during off mode with I2C4 always staying enabled.
Turns out this is because of erratum 2.11 Extra Power Consumed
I suggest using the unique ID
i531 - that remains constant across SoCs.
OK thanks, updated patch below.
Regards,
Tony
8 --
From: Tony Lindgren t...@atomide.com
Date: Tue, 21 Apr 2015 14:31:23 -0700
Subject: [PATCH] ARM: OMAP2+: Fix omap off idle power consumption creeping up
If we use a combination of VMODE and I2C4 for retention modes,
eventually the off idle power consumption will creep up by about
23mW, even during off mode with I2C4 always staying enabled.
Turns out this is because of erratum i531 Extra Power Consumed
When Repeated Start Operation Mode Is Enabled on I2C Interface
Dedicated for Smart Reflex (I2C4) as pointed out by Nishanth
Menon n...@ti.com.
Let's fix the issue by adding i2c_cfg_clear_mask for the bits
to clear when initializing the I2C4 adapter so we can clear
SREN bit that drives the I2C4 lines low otherwise when there
is no traffic.
Fixes: 3b8c4ebb7630 (ARM: OMAP3: Fix idle mode signaling for
sys_clkreq and sys_off_mode)
Cc: Kevin Hilman khil...@kernel.org
Cc: Nishanth Menon n...@ti.com
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/prm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/prm-regbits-34xx.h
@@ -112,6 +112,7 @@
#define OMAP3430_VC_CMD_ONLP_SHIFT 16
#define OMAP3430_VC_CMD_RET_SHIFT8
#define OMAP3430_VC_CMD_OFF_SHIFT0
+#define OMAP3430_SREN_MASK (1 4)
#define OMAP3430_HSEN_MASK (1 3)
#define OMAP3430_MCODE_MASK (0x7 0)
#define OMAP3430_VALID_MASK (1 24)
--- a/arch/arm/mach-omap2/prm-regbits-44xx.h
+++ b/arch/arm/mach-omap2/prm-regbits-44xx.h
@@ -35,6 +35,7 @@
#define OMAP4430_GLOBAL_WARM_SW_RST_SHIFT1
#define OMAP4430_GLOBAL_WUEN_MASK(1
16)
#define OMAP4430_HSMCODE_MASK
(0x7 0)
+#define OMAP4430_SRMODEEN_MASK
(1 4)
#define OMAP4430_HSMODEEN_MASK
(1 3)
#define OMAP4430_HSSCLL_SHIFT
24
#define OMAP4430_ICEPICK_RST_SHIFT 9
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -316,7 +316,8 @@ static void __init omap3_vc_init_pmic_signaling(struct
voltagedomain *voltdm)
* idle. And we can also scale voltages to zero for off-idle.
* Note that no actual voltage scaling during off-idle will
* happen unless the board specific twl4030 PMIC scripts are
- * loaded.
+ * loaded. See also omap_vc_i2c_init for comments regarding
+ * erratum i531.
*/
val = voltdm-read(OMAP3_PRM_VOLTCTRL_OFFSET);
if (!(val OMAP3430_PRM_VOLTCTRL_SEL_OFF)) {
@@ -704,9 +705,16 @@ static void __init omap_vc_i2c_init(struct voltagedomain
*voltdm)
return;
}
+ /*
+ * Note that for omap3 OMAP3430_SREN_MASK clears SREN to work around
+ * erratum i531 Extra Power Consumed When Repeated Start Operation
+ * Mode Is Enabled on I2C Interface Dedicated for Smart Reflex (I2C4).
+ * Otherwise I2C4 eventually leads into about 23mW extran power being
nitpick: extran ;)
+ * consumed even during off idle using VMODE.
+ */
i2c_high_speed = voltdm-pmic-i2c_high_speed;
if (i2c_high_speed)
- voltdm-rmw(vc-common-i2c_cfg_hsen_mask,
+ voltdm-rmw(vc-common-i2c_cfg_clear_mask,
vc-common-i2c_cfg_hsen_mask,
vc-common-i2c_cfg_reg);
--- a/arch/arm/mach-omap2/vc.h
+++ b
Re: [PATCH V2] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
On 04/21/2015 08:09 PM, Alexandre Belloni wrote: On 21/04/2015 at 18:58:43 -0500, Nishanth Menon wrote : Consider the following use case: a platform is setting the RTC alarm before going to suspend to ram. Before your patch, it may be woken up ^^ precisely what I am trying to solve. quite quickly, before expected. After your patch, it may never wake at all. Why is that so? when set alarm is requested for time X, you want interrupt at time X, not an interrupt for previous configured RTC alarm time! You expect at least an interrupt. And you will get an interrupt if the event occurs before the i2c burst starts. Once the i2cburst does start, you are committing to the new time. If the time X is the point when ALM0 is programmed, then you will get an interrupt. You are eluding my point. What happens if the alarm expires before ALM0 is programmed? Your system is probably dead because it will never wake up. if the previous alarm does expire before the new alarm is programmed (before the burst is started), you will get an event - why does this patch change this? the case you are concerned seem to be the case where the time you program is in the past at the point when alarm interrupt is enabled. Lets see the current behavior(before this patch): time currently requested is in the past, you are dead anyways. this can happen since the decision of programming the time is done in userspace(example with rtcwake) and there are latencies as part of suspend path (file sync) that can cause the possible cases - consider rtcwake -s 1 - and for the moment, lets assume that rtc event is the only wakeup event possible for the system (to address your point). a) If the rtcwake progams time before initiating suspend state and prior to suspend_no_irq is hit event triggers, irq is handled by rtc driver, and we proceed on to suspend state - but no further irqs can be expected dead state b) predicted time occurs before suspend_no_irq level is reached, but before the system actually enters suspend - event occurs with irq disabled and depending on smartness of platform code, it can detect that the wakeup event occurred prior to attempting suspend (hence dead state) c) If rtcwake's set_alarm invocation is slowed due to filesystem or other load activities, the time requested to wakeup is already in the past, you are in deadstate as the wakeup event has already occurred prior to entering suspend path. Note: even with android alarm driver(at least the last time i looked at it a few years ago), this situation is probably escaping (a), but (b) and (c) is still real and has to be properly anticipated. My patch does nothing different to this behavior - only point changed is *if the previous event does not take place prior to new request being initiated, then we have to assume that the new time is what we wanted wakeup event for*. That I strongly believe is necessary. Point being - using a time for wake attempted to be predicted ahead of time of suspend path is a a bunch of empirical data analysis - you can have a dead system today and this code does not change that behavior - I doubt you can ever get a clean fix without a constant latency. If you get an interrupt (like my screenshot shows) because the new value has not yet been programmed (just because we enabled interrupt before programming time), it is unexpected event and wrong! Another scenario: Take the following time points A B C D we program at time (A), an interrupt for time (C). but at time B, we intiate a new time request for time (D). if we happen to send the first ALM0EN at time C (before programming D), you will generate an interrupt, but before the irq handler can handle (since we are doing burst i2c), we program D which clears the irq status (as can be seen in waveform). This does not make sense for a predictable behavior! Yeah, it will wakeup quickly, but when we go and read irqstatus (ALM0IF), it will be 0 and nothing will get reported to rtc subsystem. So: a) we woke up at a time not requested - this is wrong b) our irq handler has nothing to handle! - this is wrong as well. in short, the behavior you are asking for is quiet the wrong behavior! I agree that an unexpected event is wrong but it is still better than a dead system. I'm not asking to keep the current behaviour. I'm just wanting to try to not introduce another race condition. What about setting ALM0MTH to 0x1F before reading the control registers? Ummm why is that any different? In effect, you are just disabling the compare logic inside the RTC differently and that said, I am not entirely sure if I want to test the MCP794xx RTL designer's logic with invalid dates being programmed for month/date etc.. ;) You could also read only the first 3 registers as all the others are overwritten. And finally, you only need to write 9 bytes instead of 10 True - had noticed that as well. have'nt had time to optimize the path yet. (register 0x10 is reserved
Re: [PATCH V2] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
On 04/21/2015 06:41 PM, Alexandre Belloni wrote: Hi, On 20/04/2015 at 19:51:34 -0500, Nishanth Menon wrote : Alarm interrupt enable register is at offset 0x7, while the time registers for the alarm follow that. When we program Alarm interrupt enable prior to programming the time, it is possible that previous time value could be close or match at the time of alarm enable resulting in interrupt trigger which is unexpected (and does not match the time we expect it to trigger). To prevent this scenario from occuring, program the ALM0_EN bit only after the alarm time is appropriately programmed. Ofcourse, I2C programming is non-atomic, so there are loopholes where the interrupt wont trigger if the time requested is in the past at the time of programming the ALM0_EN bit. However, we will not have unexpected interrupts while the time is programmed after the interrupt are enabled. Do you have more details about the issue you are trying to solve? Testcase: rtctest /dev/rtc0 waveform capture: http://goo.gl/S8Z54x Corresponding decode: http://pastebin.ubuntu.com/10863880/ Consider the following use case: a platform is setting the RTC alarm before going to suspend to ram. Before your patch, it may be woken up ^^ precisely what I am trying to solve. quite quickly, before expected. After your patch, it may never wake at all. Why is that so? when set alarm is requested for time X, you want interrupt at time X, not an interrupt for previous configured RTC alarm time! If the time X is the point when ALM0 is programmed, then you will get an interrupt. If you get an interrupt (like my screenshot shows) because the new value has not yet been programmed (just because we enabled interrupt before programming time), it is unexpected event and wrong! Another scenario: Take the following time points A B C D we program at time (A), an interrupt for time (C). but at time B, we intiate a new time request for time (D). if we happen to send the first ALM0EN at time C (before programming D), you will generate an interrupt, but before the irq handler can handle (since we are doing burst i2c), we program D which clears the irq status (as can be seen in waveform). This does not make sense for a predictable behavior! Yeah, it will wakeup quickly, but when we go and read irqstatus (ALM0IF), it will be 0 and nothing will get reported to rtc subsystem. So: a) we woke up at a time not requested - this is wrong b) our irq handler has nothing to handle! - this is wrong as well. in short, the behavior you are asking for is quiet the wrong behavior! Signed-off-by: Nishanth Menon n...@ti.com --- Changes in v2: - minor typo fix in comments - merged up code that I missed committing in V1: https://patchwork.kernel.org/patch/6245041/ drivers/rtc/rtc-ds1307.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c index 4ffabb322a9a..3cd4783375a5 100644 --- a/drivers/rtc/rtc-ds1307.c +++ b/drivers/rtc/rtc-ds1307.c @@ -742,17 +742,17 @@ static int mcp794xx_set_alarm(struct device *dev, struct rtc_wkalrm *t) regs[6] = ~MCP794XX_BIT_ALMX_IF; /* Set alarm match: second, minute, hour, day, date, month. */ regs[6] |= MCP794XX_MSK_ALMX_MATCH; - -if (t-enabled) -regs[0] |= MCP794XX_BIT_ALM0_EN; -else -regs[0] = ~MCP794XX_BIT_ALM0_EN; +/* Disable interrupt. We will not enable until completely programmed */ +regs[0] = ~MCP794XX_BIT_ALM0_EN; ret = ds1307-write_block_data(client, MCP794XX_REG_CONTROL, 10, regs); if (ret 0) return ret; -return 0; +if (!t-enabled) +return 0; +regs[0] |= MCP794XX_BIT_ALM0_EN; +return i2c_smbus_write_byte_data(client, MCP794XX_REG_CONTROL, regs[0]); } static int mcp794xx_alarm_irq_enable(struct device *dev, unsigned int enabled) -- 1.7.9.5 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
Alarm interrupt enable register is at offset 0x7, while the time registers for the alarm follow that. When we program Alarm interrupt enable prior to programming the time, it is possible that previous time value could be close or match at the time of alarm enable resulting in interrupt trigger which is unexpected (and does not match the time we expect it to trigger). To prevent this scenario from occuring, program the ALM0_EN bit only after the alarm time is appropriately programmed. Ofcourse, I2C programming is non-atomic, so there are loopholes where the interrupt wont trigger if the time requested is in the past at the time of programming the ALM0_EN bit. However, we will not have unexpected interrupts while the time is programmed after the interrupt are enabled. Signed-off-by: Nishanth Menon n...@ti.com --- Changes in v2: - minor typo fix in comments - merged up code that I missed committing in V1: https://patchwork.kernel.org/patch/6245041/ drivers/rtc/rtc-ds1307.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c index 4ffabb322a9a..3cd4783375a5 100644 --- a/drivers/rtc/rtc-ds1307.c +++ b/drivers/rtc/rtc-ds1307.c @@ -742,17 +742,17 @@ static int mcp794xx_set_alarm(struct device *dev, struct rtc_wkalrm *t) regs[6] = ~MCP794XX_BIT_ALMX_IF; /* Set alarm match: second, minute, hour, day, date, month. */ regs[6] |= MCP794XX_MSK_ALMX_MATCH; - - if (t-enabled) - regs[0] |= MCP794XX_BIT_ALM0_EN; - else - regs[0] = ~MCP794XX_BIT_ALM0_EN; + /* Disable interrupt. We will not enable until completely programmed */ + regs[0] = ~MCP794XX_BIT_ALM0_EN; ret = ds1307-write_block_data(client, MCP794XX_REG_CONTROL, 10, regs); if (ret 0) return ret; - return 0; + if (!t-enabled) + return 0; + regs[0] |= MCP794XX_BIT_ALM0_EN; + return i2c_smbus_write_byte_data(client, MCP794XX_REG_CONTROL, regs[0]); } static int mcp794xx_alarm_irq_enable(struct device *dev, unsigned int enabled) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
On 04/20/2015 06:55 PM, Nishanth Menon wrote: Alarm interrupt enable register is at offset 0x7, while the time registers for the alarm follow that. When we program Alarm interrupt enable prior to programming the time, it is possible that previous time value could be close or match at the time of alarm enable resulting in interrupt trigger which is unexpected (and does not match the time we expect it to trigger). To prevent this scenario from occurring, program the ALM0_EN bit only after the alarm time is appropriately programmed. Of course, I2C programming is non-atomic, so there are loopholes where the interrupt wont trigger if the time requested is in the past at the time of programming the ALM0_EN bit. However, we will not have unexpected interrupts while the time is programmed after the interrupt are enabled. Signed-off-by: Nishanth Menon n...@ti.com --- drivers/rtc/rtc-ds1307.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c index 4ffabb322a9a..59f9ecf323d5 100644 --- a/drivers/rtc/rtc-ds1307.c +++ b/drivers/rtc/rtc-ds1307.c @@ -742,17 +742,17 @@ static int mcp794xx_set_alarm(struct device *dev, struct rtc_wkalrm *t) regs[6] = ~MCP794XX_BIT_ALMX_IF; /* Set alarm match: second, minute, hour, day, date, month. */ regs[6] |= MCP794XX_MSK_ALMX_MATCH; - - if (t-enabled) - regs[0] |= MCP794XX_BIT_ALM0_EN; - else - regs[0] = ~MCP794XX_BIT_ALM0_EN; + /* Disable interrupt. We will not enable until completely programed */ ^^ typo here. s/programed/programmed + regs[0] = ~MCP794XX_BIT_ALM0_EN; ret = ds1307-write_block_data(client, MCP794XX_REG_CONTROL, 10, regs); if (ret 0) return ret; - return 0; + if (!t-enabled) + return 0; + regs[0] |= MCP7941X_BIT_ALM0_EN; ^^ messed up git commit --amend :( + return i2c_smbus_write_byte_data(client, MCP794XX_REG_CONTROL, regs[0]); } static int mcp794xx_alarm_irq_enable(struct device *dev, unsigned int enabled) will repost a rev2 - apologies on the noise. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drivers/rtc/rtc-ds1307.c: Enable the mcp794xx alarm after programming time
Alarm interrupt enable register is at offset 0x7, while the time registers for the alarm follow that. When we program Alarm interrupt enable prior to programming the time, it is possible that previous time value could be close or match at the time of alarm enable resulting in interrupt trigger which is unexpected (and does not match the time we expect it to trigger). To prevent this scenario from occurring, program the ALM0_EN bit only after the alarm time is appropriately programmed. Of course, I2C programming is non-atomic, so there are loopholes where the interrupt wont trigger if the time requested is in the past at the time of programming the ALM0_EN bit. However, we will not have unexpected interrupts while the time is programmed after the interrupt are enabled. Signed-off-by: Nishanth Menon n...@ti.com --- drivers/rtc/rtc-ds1307.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c index 4ffabb322a9a..59f9ecf323d5 100644 --- a/drivers/rtc/rtc-ds1307.c +++ b/drivers/rtc/rtc-ds1307.c @@ -742,17 +742,17 @@ static int mcp794xx_set_alarm(struct device *dev, struct rtc_wkalrm *t) regs[6] = ~MCP794XX_BIT_ALMX_IF; /* Set alarm match: second, minute, hour, day, date, month. */ regs[6] |= MCP794XX_MSK_ALMX_MATCH; - - if (t-enabled) - regs[0] |= MCP794XX_BIT_ALM0_EN; - else - regs[0] = ~MCP794XX_BIT_ALM0_EN; + /* Disable interrupt. We will not enable until completely programed */ + regs[0] = ~MCP794XX_BIT_ALM0_EN; ret = ds1307-write_block_data(client, MCP794XX_REG_CONTROL, 10, regs); if (ret 0) return ret; - return 0; + if (!t-enabled) + return 0; + regs[0] |= MCP7941X_BIT_ALM0_EN; + return i2c_smbus_write_byte_data(client, MCP794XX_REG_CONTROL, regs[0]); } static int mcp794xx_alarm_irq_enable(struct device *dev, unsigned int enabled) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: dra7: Fix efuse register size for ABB
Fix a typo in DRA7 dtsi where 12 bytes are needed for register description of ABB efuse registers, however only 8 bytes are provided to map. For some weird reason, this does not generate abort at offset 0x8, probably due to default maps already provided in io.c for the bus register ranges. Reported-by: Matt Gessner matt.gess...@windriver.com Reported-by: Suman Anna s-a...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/boot/dts/dra7.dtsi |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index 5332b57b4950..92b8bb873f43 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -911,7 +911,7 @@ ti,clock-cycles = 16; reg = 0x4ae07ddc 0x4, 0x4ae07de0 0x4, - 0x4ae06014 0x4, 0x4a003b20 0x8, + 0x4ae06014 0x4, 0x4a003b20 0xc, 0x4ae0c158 0x4; reg-names = setup-address, control-address, int-address, efuse-address, @@ -944,7 +944,7 @@ ti,clock-cycles = 16; reg = 0x4ae07e34 0x4, 0x4ae07e24 0x4, - 0x4ae06010 0x4, 0x4a0025cc 0x8, + 0x4ae06010 0x4, 0x4a0025cc 0xc, 0x4a002470 0x4; reg-names = setup-address, control-address, int-address, efuse-address, @@ -977,7 +977,7 @@ ti,clock-cycles = 16; reg = 0x4ae07e30 0x4, 0x4ae07e20 0x4, - 0x4ae06010 0x4, 0x4a0025e0 0x8, + 0x4ae06010 0x4, 0x4a0025e0 0xc, 0x4a00246c 0x4; reg-names = setup-address, control-address, int-address, efuse-address, @@ -1010,7 +1010,7 @@ ti,clock-cycles = 16; reg = 0x4ae07de4 0x4, 0x4ae07de8 0x4, - 0x4ae06010 0x4, 0x4a003b08 0x8, + 0x4ae06010 0x4, 0x4a003b08 0xc, 0x4ae0c154 0x4; reg-names = setup-address, control-address, int-address, efuse-address, -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bus: omap_l3_noc: Fix offset for DRA7 CLK1_HOST_CLK1_2 instance
From: Illia Smyrnov illia.smyr...@globallogic.com
The base address for DRA7 CLK1_HOST_CLK1_2 host instance is
0x4480, so correct offset is 0x80. DRA7 TRM rev X(fewb 2015)
has updates for this information.
With wrong offset these errors are not correctly cleared by the L3
IRQ handler and cause an continuous interrupt scenario and system lockup.
Signed-off-by: Illia Smyrnov illia.smyr...@globallogic.com
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/bus/omap_l3_noc.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bus/omap_l3_noc.h b/drivers/bus/omap_l3_noc.h
index 95254585db86..a314d800f394 100644
--- a/drivers/bus/omap_l3_noc.h
+++ b/drivers/bus/omap_l3_noc.h
@@ -274,7 +274,7 @@ static struct l3_flagmux_data dra_l3_flagmux_clk1 = {
static struct l3_target_data dra_l3_target_data_clk2[] = {
{0x0, HOST CLK1,},
- {0x0, HOST CLK2,},
+ {0x80, HOST CLK2,},
{0xdead, L3_TARGET_NOT_SUPPORTED,},
{0x3400, SHA2_2,},
{0x0900, BB2D,},
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration
On 04/14/2015 08:29 PM, Lennart Sorensen wrote: On Tue, Mar 17, 2015 at 06:41:51PM -0700, Tony Lindgren wrote: Yeah agreed. I suggest discussing the binding and the generic parsing code for it first :) It seems with the generic binding the actual driver should be just the hardware specific code hopefully. Did this thread go anywhere in the last month? I am certainly looking forward to seeing what the resolution is to this, given for our use the boot loader setup is not appealing at all. I am yet to post a new revision to this series - few other stuff got in the way. IODelay driver in no way removes the constraint that the SoC architecture has - most of the pins still need to be muxed in bootloader - we cannot escape that. The reasoning for doing the mux in bootloader is independent of the need for iodelay. Reasoning for mux in bootloader is because the mux and pull fields are glitchy - much more than previous generations of TI SoCs and significantly long enough to cause issues depending on the pins being muxed. Reasoning for iodelay is different - it is a hardware block meant to control the timing of signals in a particular signal path to ensure that specification compliance is met. Lets try not to mix the two. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration
On 04/15/2015 01:44 PM, Lennart Sorensen wrote: On Wed, Apr 15, 2015 at 11:51:32AM -0500, Nishanth Menon wrote: I am yet to post a new revision to this series - few other stuff got in the way. IODelay driver in no way removes the constraint that the SoC architecture has - most of the pins still need to be muxed in bootloader - we cannot escape that. The reasoning for doing the mux in bootloader is independent of the need for iodelay. Reasoning for mux in bootloader is because the mux and pull fields are glitchy - much more than previous generations of TI SoCs and significantly long enough to cause issues depending on the pins being muxed. Well if we know glitching is NOT an issue on our boards, then we don't have to do anything in the boot loader other than the basic setup for the serial console and emmc and SD, which has always been necesary. I consider moving the mux setup to the bootloader a terrible design and won't go along with it. We make sure all external devices have reset lines being held while the pinmux is being setup, so glitching is a non issue. I cannot discuss customer boards on this list - the right forum for TI support is e2e.ti.com or in cases where FAE (Field Applications Engineer) is involved, via appropriate support path. Now, that said, even with personal opinions in place, I have to stick with what the SoC constraints on hand and suggested architecture we have discussed to ensure safe platform operation at least for the platforms we are contributing to. again... muxing in the bootloader IS NOT what this patch is about. If we can stick to the topic in discussion, it is probably more effective. Any improvement suggestions to the code is more than appreciated. Reasoning for iodelay is different - it is a hardware block meant to control the timing of signals in a particular signal path to ensure that specification compliance is met. Lets try not to mix the two. Well I was told by multiple people from TI that the reason for moving the pinmux setup to the bootloader was because of the iodelay issue, so you will have to get the message made clear within TI then. I have passed on this message. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ARM: omap2plus_defconfig: Switch over to using 8250 driver
On 04/10/2015 02:40 PM, Peter Hurley wrote: [ +Sebastian, +Tony ] On 04/10/2015 02:18 PM, Nishanth Menon wrote: 8250 driver should be relatively feature complete. It can co-exist with omap-serial driver Not really; if the omap_8250 is selected then it is probed first and will be the only driver claiming omap UART ports. omap-serial would just be dead-weight. true.. my bad.. , so just enable 8250 OMAP layer driver and route all ttyOx references to ttySx through the standard 8250 driver to ensure no breakage of userspace occurs. Not quite; the only automatic handling is for console only, not for userspace. Expect lots of userspace breakage. Yep - overall, looking through individual logs, in my testing, it seems to work at least for console for all platforms - even though the filesystems are mostly going bonkers - older fs did not have the udev redirection to take care of this - mostly to do with the getty hooked on to static consoles. There are infact two issues: a) bootloader change for cmdline - O2 to S2 - in many cases we are lesser inclined to change the bootloader, hence the fixup configuration b) fs changes - these are sometimes more realistic to do, but is a clear breakage risk. Overall, keeping two equally functional drivers in the system sounds a bunch of maintenance burden for all of us and not to mention confusion for the future. Btw, I am not exactly proposing this for 4.1 kernel.. instead, we should probably discuss how to best introduce this in and throw out the older omap_serial driver - just reuse 8250 and co-exist with the rest of the good world folks ;).. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ARM: omap2plus_defconfig: Switch over to using 8250 driver
On 04/11/2015 02:40 PM, Peter Hurley wrote: On 04/11/2015 02:27 PM, Nishanth Menon wrote: On 04/10/2015 02:40 PM, Peter Hurley wrote: [ +Sebastian, +Tony ] On 04/10/2015 02:18 PM, Nishanth Menon wrote: 8250 driver should be relatively feature complete. It can co-exist with omap-serial driver Not really; if the omap_8250 is selected then it is probed first and will be the only driver claiming omap UART ports. omap-serial would just be dead-weight. true.. my bad.. , so just enable 8250 OMAP layer driver and route all ttyOx references to ttySx through the standard 8250 driver to ensure no breakage of userspace occurs. Not quite; the only automatic handling is for console only, not for userspace. Expect lots of userspace breakage. Yep - overall, looking through individual logs, in my testing, it seems to work at least for console for all platforms - even though the filesystems are mostly going bonkers - older fs did not have the udev redirection to take care of this - mostly to do with the getty hooked on to static consoles. There are infact two issues: a) bootloader change for cmdline - O2 to S2 - in many cases we are lesser inclined to change the bootloader, hence the fixup configuration Just an FYI - support for handling of _any_ console command line string by _any_ driver was accepted for 4.01; the console can declare a match() function which will be called at registration time for every console command line, and can opt to perform console setup using any criteria. This provides a migration path for _any_ driver (and also allow any earlycon-to-console handoff for non-8250 drivers by using a defined match() function to match the appropriate earlycon= command line; the particulars are in the univ8250_console_match() kernel-doc header in -next). OK. b) fs changes - these are sometimes more realistic to do, but is a clear breakage risk. Overall, keeping two equally functional drivers in the system sounds a bunch of maintenance burden for all of us and not to mention confusion for the future. I think for the moment we should just freeze omap-serial and let most of userspace catch up first; a lot of the official and unofficial vender support is still stuck in 3.14. By the time, 3.19+ is de rigueur we'll hopefully have figured out the ttyS sharing and how to migrate without breaking userspace. How about the folks stuck on older distros like Maemo N900? -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] ARM: multi_v7_defconfig: Enable more OMAP family platforms
Hi, As of next-20150409 tag, the following platforms (I have access to) report failures for AM437x-sk and legacy beaglebone (white). omap2plus_defconfig boots up fine on these platforms. So, the basic minimum stuff I could pickup to fix up beaglebone-white and am437x-sk. This series is still missing the magic sauce for LDP - will try to track that down later as well. This series is based on next-20150409 multi_v7_defconfig (as on next-20150409) 1: am335x-evm: BOOT: PASS: am335x-evm.txt 2: am335x-sk: BOOT: PASS: am335x-sk.txt 3: am3517-evm: BOOT: PASS: am3517-evm.txt 4: am37x-evm: BOOT: PASS: am37x-evm.txt 5: am437x-sk: BOOT: FAIL: am437x-sk.txt 6:am43xx-epos: BOOT: PASS: am43xx-epos.txt 7: am43xx-gpevm: BOOT: PASS: am43xx-gpevm.txt 8: BeagleBoard-XM: BOOT: PASS: beagleboard.txt 9:beagleboard-vanilla: BOOT: PASS: beagleboard-vanilla.txt 10: beaglebone-black: BOOT: PASS: beaglebone-black.txt 11: beaglebone: BOOT: FAIL: beaglebone.txt 12: craneboard: BOOT: PASS: craneboard.txt 13: dra72x-evm: BOOT: PASS: dra72x-evm.txt 14: dra7xx-evm: BOOT: PASS: dra7xx-evm.txt 15: OMAP3430-Labrador(LDP): BOOT: FAIL: ldp.txt 16: n900: BOOT: PASS: n900.txt 17: omap5-evm: BOOT: PASS: omap5-evm.txt 18: pandaboard-es: BOOT: PASS: pandaboard-es.txt 19: pandaboard-vanilla: BOOT: PASS: pandaboard-vanilla.txt 20:sdp3430: BOOT: PASS: sdp3430.txt 21:sdp4430: BOOT: PASS: sdp4430.txt After this series: 1: am335x-evm: BOOT: PASS: am335x-evm.txt 2: am3517-evm: BOOT: PASS: am3517-evm.txt 3: am37x-evm: BOOT: PASS: am37x-evm.txt 4: am437x-sk: BOOT: PASS: am437x-sk.txt 5:am43xx-epos: BOOT: PASS: am43xx-epos.txt 6: am43xx-gpevm: BOOT: PASS: am43xx-gpevm.txt 7: BeagleBoard-XM: BOOT: PASS: beagleboard.txt 8:beagleboard-vanilla: BOOT: PASS: beagleboard-vanilla.txt 9: beaglebone-black: BOOT: PASS: beaglebone-black.txt 10: beaglebone: BOOT: PASS: beaglebone.txt 11: craneboard: BOOT: PASS: craneboard.txt 12: dra72x-evm: BOOT: PASS: dra72x-evm.txt 13: dra7xx-evm: BOOT: PASS: dra7xx-evm.txt 14: OMAP3430-Labrador(LDP): BOOT: FAIL: ldp.txt 15: n900: BOOT: PASS: n900.txt 16: omap5-evm: BOOT: PASS: omap5-evm.txt 17: pandaboard-es: BOOT: PASS: pandaboard-es.txt 18: pandaboard-vanilla: BOOT: PASS: pandaboard-vanilla.txt 19:sdp3430: BOOT: PASS: sdp3430.txt 20:sdp4430: BOOT: PASS: sdp4430.txt TOTAL = 20 boards, Booted Boards = 19, No Boot boards = 1 Nishanth Menon (3): ARM: multi_v7_defconfig: Enable beaglebone PMIC TPS65217 ARM: multi_v7_defconfig: Enable AM437x PMIC TPS65218 ARM: multi_v7_defconfig: Enable generic SoC internal OMAP regulators arch/arm/configs/multi_v7_defconfig |6 ++ 1 file changed, 6 insertions(+) Regards, Nishanth Menon -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: multi_v7_defconfig: Enable generic SoC internal OMAP regulators
ABB and PBIAS are internal LDO control regulators that are needed for maintaining proper functionality of OMAP architecture SoCs. Enable the same. Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/configs/multi_v7_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index f48dfa7787dc..b86ff6e957a0 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -363,8 +363,10 @@ CONFIG_REGULATOR_MAX8907=y CONFIG_REGULATOR_MAX8973=y CONFIG_REGULATOR_MAX77686=y CONFIG_REGULATOR_PALMAS=y +CONFIG_REGULATOR_PBIAS=y CONFIG_REGULATOR_S2MPS11=y CONFIG_REGULATOR_S5M8767=y +CONFIG_REGULATOR_TI_ABB=y CONFIG_REGULATOR_TPS51632=y CONFIG_REGULATOR_TPS62360=y CONFIG_REGULATOR_TPS65090=y -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: multi_v7_defconfig: Enable AM437x PMIC TPS65218
Enable PMIC for AM437x platforms such as AM437x-sk similar to commit a186cf10da84 (ARM: omap2plus_defconfig: enable TPS65218 configs). This allows multi_v7_defconfig to boot up on AM437x-sk platform. Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/configs/multi_v7_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 11c64858c623..f48dfa7787dc 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -347,6 +347,7 @@ CONFIG_MFD_STMPE=y CONFIG_MFD_PALMAS=y CONFIG_MFD_TPS65090=y CONFIG_MFD_TPS65217=y +CONFIG_MFD_TPS65218=y CONFIG_MFD_TPS6586X=y CONFIG_MFD_TPS65910=y CONFIG_REGULATOR_AB8500=y @@ -368,6 +369,7 @@ CONFIG_REGULATOR_TPS51632=y CONFIG_REGULATOR_TPS62360=y CONFIG_REGULATOR_TPS65090=y CONFIG_REGULATOR_TPS65217=y +CONFIG_REGULATOR_TPS65218=y CONFIG_REGULATOR_TPS6586X=y CONFIG_REGULATOR_TPS65910=y CONFIG_REGULATOR_TWL4030=y -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: multi_v7_defconfig: Enable beaglebone PMIC TPS65217
Enable PMIC for beaglebone similar to commit 7a5c6065669c (ARM: OMAP2+: omap2plus_defconfig: Add tps65217 support) - this allows multi_v7_defconfig to boot up on older beaglebone platforms. Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/configs/multi_v7_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 48dfe885fbb7..11c64858c623 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -346,6 +346,7 @@ CONFIG_MFD_SEC_CORE=y CONFIG_MFD_STMPE=y CONFIG_MFD_PALMAS=y CONFIG_MFD_TPS65090=y +CONFIG_MFD_TPS65217=y CONFIG_MFD_TPS6586X=y CONFIG_MFD_TPS65910=y CONFIG_REGULATOR_AB8500=y @@ -366,6 +367,7 @@ CONFIG_REGULATOR_S5M8767=y CONFIG_REGULATOR_TPS51632=y CONFIG_REGULATOR_TPS62360=y CONFIG_REGULATOR_TPS65090=y +CONFIG_REGULATOR_TPS65217=y CONFIG_REGULATOR_TPS6586X=y CONFIG_REGULATOR_TPS65910=y CONFIG_REGULATOR_TWL4030=y -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: dts: am57xx-beagle-x15: Fix IRQ type for mcp7941x
From: Grygorii Strashko grygorii.stras...@linaro.org
The interrupt polarity provided in devicetree is used to configure
the interrupt controller(ARM GIC), however, it seems that we have an
inverter at the GIC boundary inside AM57xx which inverts the signal
input from sys_irq external interrupt source.
Further, as per GIC distributor TRM,
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438d/BGBHIACJ.html#BABJFCFB
ARM GIC distributor does not support IRQ trigger type
IRQ_TYPE_LEVEL_LOW, and only rising or level high signals.
However, for some reason, the current configuration(which gets ignored
by GIC driver) functions on some platforms, however, on few platforms
results in infinite interrupts hogging the system down.
Switch over to rising edge for GIC configuration which is also aligned
with trigger point from the RTC chip and the internal inversion.
Fixes: 5a0f93c6576a (ARM: dts: Add am57xx-beagle-x15)
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/am57xx-beagle-x15.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index fe141c47d647..57279e3b439b 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -455,7 +455,7 @@
mcp_rtc: rtc@6f {
compatible = microchip,mcp7941x;
reg = 0x6f;
- interrupts = GIC_SPI 2 IRQ_TYPE_LEVEL_LOW; /* IRQ_SYS_1N */
+ interrupts = GIC_SPI 2 IRQ_TYPE_EDGE_RISING; /* IRQ_SYS_1N */
pinctrl-names = default;
pinctrl-0 = mcp79410_pins_default;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
