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,
aling (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
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
>
asic 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
ctable 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,
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,
>
ome polarity - if
it had none, there'd be no interrupt, right?
> + ti,backup-battery-chargeable;
> + ti,backup-battery-charge-high-current;
> + };
> +
> palmas_pmic {
> compatible = "
gt;
> 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 th
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 suppo
en 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/k
riod 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).
> Sign
_REG_LDO2) {
> + desc->ops = _ops_ldo_1_2;
> + desc->bypass_reg = desc->enable_reg;
> + desc->bypass_mask = TPS65917_LDO_1_2_BYPASS_EN;
> + }
> } else {
>
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
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 unsub
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-controll
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 latenc
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 b
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-CO
ta 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 exp
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.k
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://pasteb
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
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
;> +pinctrl-0 = <_pins_default>;
>>> +
>>> +#interrupt-cells = <2>;
>>> +interrupt-controller;
>>> +
>>> +ti,system-power-controller;
>>
>> Assuming powerhold signal and BOOT0,1 is proper here, else
++ 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:
5";
> + 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
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
)
>
> 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
; .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
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,
Ni
> 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 r
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 L
> 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>
> --
- 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 subt
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 ++---
fined(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
ses 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:
> + status = "okay";
> +};
> +
> +_pinmux {
> + uart2_pins: uart2_pins {
> + pinctrl-single,pins = <
> + 0x150 (PIN_INPUT | MUX_MODE1) /* spi0_sclk.uart2_rxd
> */
> + 0x154 (PIN_OUTPUT | MUX_MODE1
s 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 err
ches 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
65218_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
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
9fa2 ("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-o
..@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
+
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
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/Kc
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
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.
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/
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
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
: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
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
@@
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
;
+ 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
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
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
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
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
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
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
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
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
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
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
-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
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
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
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
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
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
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
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
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
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
, 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
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
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
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
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
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
/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
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
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
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
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
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
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
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
.
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
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
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
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
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
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
: 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
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
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
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
: 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
1 - 100 of 2389 matches
Mail list logo
