On Wed, Oct 9, 2019 at 12:34 PM Tony Lindgren wrote:
>
> * Adam Ford [191009 14:09]:
> > On Wed, Oct 9, 2019 at 8:42 AM Vignesh Raghavendra wrote:
> > >
> > > Hi Adam,
> > >
> > > On 06/10/19 10:34 PM, Adam Ford wrote:
> > > > Has an
On Wed, Oct 9, 2019 at 8:42 AM Vignesh Raghavendra wrote:
>
> Hi Adam,
>
> On 06/10/19 10:34 PM, Adam Ford wrote:
> > Has anyone else had any issues using the CONFIG_SERIAL_8250_DMA on the OMAP?
> >
> > I can use the DMA on the legacy, omap-serial driver, but when I
The some in the OMAP3 family have a bandgap thermal sensor, but
omap2plus has it disabled.
This patch enables the OMAP3_THERMAL by default like the rest of
the OMAP family.
Signed-off-by: Adam Ford
diff --git a/arch/arm/configs/omap2plus_defconfig
b/arch/arm/configs/omap2plus_defconfig
index
>; /* millicelsius */
};
Signed-off-by: Adam Ford
Tested-by: H. Nikolaus Schaller # on GTA04A5 with
dm3730cbp100
diff --git a/arch/arm/boot/dts/omap3-cpu-thermal.dtsi
b/arch/arm/boot/dts/omap3-cpu-thermal.dtsi
index 235ecfd61e2d..dfbd0cb0b00b 100644
--- a/arch/arm/boot/dts/omap3-cpu-thermal.dts
On Mon, Oct 7, 2019 at 10:45 AM H. Nikolaus Schaller wrote:
>
>
> > Am 07.10.2019 um 17:11 schrieb Adam Ford :
> >
> > On Sat, Sep 14, 2019 at 11:12 AM Adam Ford wrote:
> >>
> >> On Sat, Sep 14, 2019 at 9:38 AM H. Nikolaus Schaller
> >> wrote
On Sat, Sep 14, 2019 at 11:12 AM Adam Ford wrote:
>
> On Sat, Sep 14, 2019 at 9:38 AM H. Nikolaus Schaller
> wrote:
> >
> >
> > > Am 14.09.2019 um 15:42 schrieb Adam Ford :
> > >
> > > On Sat, Sep 14, 2019 at 4:20 AM H. Nikolaus Schaller
> &
ftware nodes.
>
> Let's switch this driver over.
>
> Signed-off-by: Dmitry Torokhov
Acked-by: Adam Thomson
> ---
>
> drivers/regulator/da9211-regulator.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/regulato
ing up on my test
board with DA9063. Although very unlikely to occur it does make sense so:
Tested-by: Adam Thomson
>
> ---
>
> Not marking as cc-stable as this was not reproduced and not tested.
> ---
> drivers/rtc/rtc-da9063.c | 3 +++
> 1 file changed, 3 insertions(+)
>
baud, but it
appears to work just fine after some patches I just submitted for
handling RTS/CTS. The legacy omap-serial driver works fine with DMA.
adam
auto RTS/CTS.
Signed-off-by: Adam Ford
---
V2: Made the NULL dererence check from patch 1/2 come before this.
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index c68e2b3a1634..836e736ae188 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty
When using mctrl_gpio_to_gpiod, it dereferences gpios into a single
requested GPIO. This dereferencing can break if gpios is NULL,
so this patch adds a NULL check before dereferencing it. If
gpios is NULL, this function will also return NULL.
Signed-off-by: Adam Ford
---
V2: This patch is new
On Sun, Oct 6, 2019 at 7:34 AM Yegor Yefremov
wrote:
>
> On Sun, Oct 6, 2019 at 1:38 PM Adam Ford wrote:
> >
> > On Sun, Oct 6, 2019 at 6:21 AM Yegor Yefremov
> > wrote:
> > >
> > > Hi Adam,
> > >
> > > On Sun, Oct 6, 2019 at 4:33 AM A
On Sun, Oct 6, 2019 at 6:21 AM Yegor Yefremov
wrote:
>
> Hi Adam,
>
> On Sun, Oct 6, 2019 at 4:33 AM Adam Ford wrote:
> >
> > There are two checks to see if the manual gpio is configured, but
> > these the check is seeing if the structure is NULL instead it
> &
On Sat, Oct 5, 2019 at 8:23 PM Adam Ford wrote:
>
> On Fri, Oct 4, 2019 at 10:45 PM Adam Ford wrote:
> >
> > On Fri, Oct 4, 2019 at 11:51 AM Adam Ford wrote:
> > >
> > > On Fri, Oct 4, 2019 at 9:08 AM Adam Ford wrote:
> > > >
> > > >
-by: Adam Ford
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index c68e2b3a1634..836e736ae188 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -141,7 +141,7 @@ static void omap8250_set_mctrl(struct uart_port
On Fri, Oct 4, 2019 at 10:45 PM Adam Ford wrote:
>
> On Fri, Oct 4, 2019 at 11:51 AM Adam Ford wrote:
> >
> > On Fri, Oct 4, 2019 at 9:08 AM Adam Ford wrote:
> > >
> > > On Fri, Oct 4, 2019 at 7:27 AM Yegor Yefremov
> > > wrote:
> > > >
On Fri, Oct 4, 2019 at 11:51 AM Adam Ford wrote:
>
> On Fri, Oct 4, 2019 at 9:08 AM Adam Ford wrote:
> >
> > On Fri, Oct 4, 2019 at 7:27 AM Yegor Yefremov
> > wrote:
> > >
> > > Hi Adam,
> > >
> > > On Fri, Oct 4, 2019 at 12:39 PM Adam
e comments to the workaround while at it.
This seems to help some of the stability issues I am seeing on the
DM3730 UART2 running Bluetooth at 300 baud.
Does it make sense to backport this to the stable kernels?
adam
>
> Cc: Johan Hovold
> Signed-off-by: Tony Lindgren
> ---
>
On Fri, Oct 4, 2019 at 9:08 AM Adam Ford wrote:
>
> On Fri, Oct 4, 2019 at 7:27 AM Yegor Yefremov
> wrote:
> >
> > Hi Adam,
> >
> > On Fri, Oct 4, 2019 at 12:39 PM Adam Ford wrote:
> > >
> > > On Fri, Oct 4, 2019 at 5:02 AM Adam Ford wrote:
On Fri, Oct 4, 2019 at 7:27 AM Yegor Yefremov
wrote:
>
> Hi Adam,
>
> On Fri, Oct 4, 2019 at 12:39 PM Adam Ford wrote:
> >
> > On Fri, Oct 4, 2019 at 5:02 AM Adam Ford wrote:
> > >
> > > I am running Kernel 5.3.2 trying to troubleshoot some intermit
Linux
> > > admin wrote:
> > > > On Thu, Oct 03, 2019 at 08:34:52AM +0300, Mike Rapoport wrote:
> > > > > (trimmed the CC)
> > > > >
> > > > > On Wed, Oct 02, 2019 at 06:14:11AM -0500, Adam Ford wrote:
> &
On Fri, Oct 4, 2019 at 5:02 AM Adam Ford wrote:
>
> I am running Kernel 5.3.2 trying to troubleshoot some intermittent
> Bluetooth issues, and I think I have narrowed it down to the serial
> driver in use.
I should have also noted that it's using UART2 with CTS and RTS on the
suggestions on how to troubleshoot or what might cause the
difference between the two drivers?
adam
s:6185 acl:0 sco:0 events:581 errors:0
TX bytes:91006 acl:0 sco:0 commands:578 errors:0
>
> This is compile tested only!
>
I am not sure which is more appropriate,
Acked-by: Adam Ford
Tested-by: Adam Ford
> Cc: Adam Ford
> Signed-off-by: Sebastian Reichel
> ---
>
On Thu, Oct 03, 2019 at 10:13:39AM +, David Laight wrote:
> From: Kurt Roeckx
> > Sent: 02 October 2019 17:56
> > As OpenSSL, we want cryptograhic secure random numbers. Before
> > getrandom(), Linux never provided a good API for that, both
> > /dev/random and /dev/urandom have problems. getran
t; > plug headphone, since its cable is used as antenna. For testing there is a
> > > 'radio' utility packages in Debian. When you start the utility you need to
> > > specify a frequency, since initial get_frequency returns an error:
> >
> > What is the
As nice as it would be to update firmware faster, that patch broke
at least two different boards, an OMAP4+WL1285 based Motorola Droid
4, as reported by Sebasian Reichel and the Logic PD i.MX6Q +
WL1837MOD.
This reverts commit a2e02f38eff84f199c8e32359eb213f81f270047.
Signed-off-by: Adam Ford
low to stabilize NVCC_SD1.
Signed-off-by: Adam Ford
diff --git a/arch/arm/boot/dts/imx6-logicpd-som.dtsi
b/arch/arm/boot/dts/imx6-logicpd-som.dtsi
index 547fb141ec0c..233762acbaaf 100644
--- a/arch/arm/boot/dts/imx6-logicpd-som.dtsi
+++ b/arch/arm/boot/dts/imx6-logicpd-som.dtsi
@@ -15,6 +15,18
low to stabilize NVCC_SD1.
Signed-off-by: Adam Ford
diff --git a/arch/arm/boot/dts/imx6-logicpd-som.dtsi
b/arch/arm/boot/dts/imx6-logicpd-som.dtsi
index 547fb141ec0c..233762acbaaf 100644
--- a/arch/arm/boot/dts/imx6-logicpd-som.dtsi
+++ b/arch/arm/boot/dts/imx6-logicpd-som.dtsi
@@ -15,6 +15,18
A previous patch disabled the SNVS power key by default which
breaks the ability for the imx6q-logicpd board to wake from sleep.
This patch re-enables this feature for this board.
Fixes: 770856f0da5d ("ARM: dts: imx6qdl: Enable SNVS power key according to
board design")
Signed-off-by:
A previous patch disabled the SNVS power key by default which
breaks the ability for the imx6q-logicpd board to wake from sleep.
This patch re-enables this feature for this board.
Fixes: 770856f0da5d ("ARM: dts: imx6qdl: Enable SNVS power key according to
board design")
Signed-off-by:
.
Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")
Signed-off-by: Adam Ford
Reviewed-by: Sam Ravnborg
---
V4: No Change
V3: No Change
V2: No Change
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 28fa6ba7b767..8abb31f83ffc 10
On Fri, May 10, 2019 at 10:38 AM Marcel Holtmann wrote:
>
> Hi Adam,
>
> >>>>>>> This moves all remaining users of the legacy TI_ST driver to hcill
> >>>>>>> (patches
> >>>>>>> 1-3). Then patches 4-7 convert w
On 26 September 2019 15:39, Marco Felsch wrote:
> On 19-09-26 14:04, Adam Thomson wrote:
> > On 26 September 2019 12:44, Marco Felsch wrote:
> >
> > > On 19-09-26 10:17, Adam Thomson wrote:
> > > > On 26 September 2019 09:10, Marco Felsch wrote:
> > >
On Fri, Sep 27, 2019 at 1:22 AM Tomi Valkeinen wrote:
>
> On 26/09/2019 17:12, Adam Ford wrote:
>
> >> And what is the hdmi5_configure there? I don't see anything in the
> >> driver that would print hdmi5_configure. And, of course, there's no
> >>
On Thu, Sep 26, 2019 at 1:37 AM Ardelean, Alexandru
wrote:
>
> On Wed, 2019-09-25 at 10:14 -0500, Adam Ford wrote:
> > [External]
> >
> > On Fri, Sep 20, 2019 at 2:06 AM Philipp Puschmann
> > wrote:
> > > Hi Andy,
> > >
> > > Am 2
On 26 September 2019 12:44, Marco Felsch wrote:
> On 19-09-26 10:17, Adam Thomson wrote:
> > On 26 September 2019 09:10, Marco Felsch wrote:
> >
> > > On 19-09-25 16:18, Adam Thomson wrote:
> > > > On 25 September 2019 16:52, Marco Felsch wrote:
> > >
On 26 September 2019 09:10, Marco Felsch wrote:
> On 19-09-25 16:18, Adam Thomson wrote:
> > On 25 September 2019 16:52, Marco Felsch wrote:
> >
> > > Hi Adam,
> > >
> > > On 19-09-24 09:23, Adam Thomson wrote:
> > > > On 17 September 201
On 26 September 2019 06:51, Axel Lin wrote:
> The sleep flag bit decides the mode for BUCK_MODE_MANUAL case, simplify
> the logic as the result is the same.
>
> Signed-off-by: Axel Lin
Reviewed-by: Adam Thomson
> ---
> drivers/regulator/da9063-regulator.c | 9 +++--
&g
62: fix suspend_enable/disable preparation"
However, changes look fine so:
Reviewed-by: Adam Thomson
> ---
> drivers/regulator/da9062-regulator.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/regulator/da9062-regulator.c b/drive
This patch adds documentation of device tree bindings for the WVGA panel
Logic PD Type 28 display.
Signed-off-by: Adam Ford
---
V3: Correct build errors from 'make dt_binding_check'
V2: Use YAML instead of TXT for binding
diff --git
a/Documentation/devicetree/bindings/display/pan
With the removal of the panel-dpi from the omap drivers, the
LCD no longer works. This patch points the device tree to
a newly created panel named "logicpd,type28"
Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")
Signed-off-by: Adam Ford
Acked-by: Sam Ravnborg
-
On 25 September 2019 16:52, Marco Felsch wrote:
> Hi Adam,
>
> On 19-09-24 09:23, Adam Thomson wrote:
> > On 17 September 2019 13:43, Marco Felsch wrote:
> >
> > > Add the documentation which describe the voltage selection gpio support.
> > > This propert
On Fri, Sep 20, 2019 at 2:06 AM Philipp Puschmann
wrote:
>
> Hi Andy,
>
> Am 20.09.19 um 05:42 schrieb Andy Duan:
> > From: Philipp Puschmann Sent: Thursday,
> > September 19, 2019 10:51 PM
> >> Using only 4 DMA periods for UART RX is very few if we have a high
> >> frequency
> >> of small tran
On 17 September 2019 13:43, Marco Felsch wrote:
> The DA9062/1 devices can switch their regulator voltages between
> voltage-A (active) and voltage-B (suspend) settings. Switching the
> voltages can be controlled by ther internal state-machine or by a gpio
> input signal and can be configured for
On 17 September 2019 13:43, Marco Felsch wrote:
> Add the documentation which describe the voltage selection gpio support.
> This property can be applied to each subnode within the 'regulators'
> node so each regulator can be configured differently.
>
> Signed-off-by: Marco Felsch
> ---
> Docum
On 23 September 2019 23:03, Marco Felsch wrote:
> Hi Adam,
>
> On 19-09-23 16:03, Adam Thomson wrote:
> > On 17 September 2019 13:43, Marco Felsch wrote:
> >
> > > Currently the suspend reg_field maps to the pmic voltage selection bits
> > > and is used du
is no need to check
> which regulator setting is active.
>
So I believe you're correct with the above statements. The driver, rather than
enabling/disabling a regulator in system suspend, will instead put the regulator
to a low power state, which is definitely not the desired outcome. Thank
tooth traffic
> consists of many independent small packets, mostly only a few bytes,
> causing high usage of periods.
>
Using the 4.19.y branch, this seems to working just fine for me with an i.MX6Q
with WL1837MOD Bluetooth connected to UART2. I am still seeing some
timeouts with 5.3,
After consulting with Tony
Lindgren, he agreed it made sense to add these boards to the
list.
This patch adds the omap based boards to the omap device tree
maintainer list.
Signed-off-by: Adam Ford
diff --git a/MAINTAINERS b/MAINTAINERS
index a50e97a63bc8..0ee89575699c 100644
--- a/MAINTAINERS
After consulting with Tony
Lindgren, he agreed it made sense to add these boards to the
list.
This patch adds the omap based boards to the omap device tree
maintainer list.
Signed-off-by: Adam Ford
diff --git a/MAINTAINERS b/MAINTAINERS
index a50e97a63bc8..0ee89575699c 100644
--- a/MAINTAINERS
After consulting with Tony
Lindgren, he agreed it made sense to add these boards to the
list.
This patch adds the omap based boards to the omap device tree
maintainer list.
Signed-off-by: Adam Ford
diff --git a/MAINTAINERS b/MAINTAINERS
index a50e97a63bc8..0ee89575699c 100644
--- a/MAINTAINERS
On 17 September 2019 13:43, Marco Felsch wrote:
> Currently the suspend reg_field maps to the pmic voltage selection bits
> and is used during suspend_enabe/disable() and during get_mode(). This
> seems to be wrong for both use cases.
Hi Marco,
I'd be very surprised if what was in place was wron
On Tue, Mar 12, 2019 at 2:01 PM Adam Ford wrote:
>
> This driver supports the ILI2117A touch controller. This is
> different than the ILI210x and it uses different register and
> algorithm so it's a separate driver rather than integrating with
> the other.
>
It
On Sat, Sep 14, 2019 at 9:38 AM H. Nikolaus Schaller wrote:
>
>
> > Am 14.09.2019 um 15:42 schrieb Adam Ford :
> >
> > On Sat, Sep 14, 2019 at 4:20 AM H. Nikolaus Schaller
> > wrote:
> >>
> >>
> >>> Am 13.09.2019 um 17:37 schrieb Adam
On Sat, Sep 14, 2019 at 4:25 AM H. Nikolaus Schaller wrote:
>
>
> > Am 13.09.2019 um 17:37 schrieb Adam Ford :
> >
> > Because the omap34xx, omap36xx and am3517 SoC's have the same
> > thermal junction limits, there is no need to duplicate the entry
> > m
On Sat, Sep 14, 2019 at 4:20 AM H. Nikolaus Schaller wrote:
>
>
> > Am 13.09.2019 um 17:37 schrieb Adam Ford :
> >
> > The OMAP3530, AM3517 and DM3730 all show thresholds of 90C and 105C
> > depending on commercial or industrial temperature ratings. This
> > p
gt;
> /dev/mem opened.
> Memory mapped at address 0xb6fe4000.
> Value at address 0x483072F4 (0xb6fe42f4): 0x3205
> /dev/mem opened.
> Memory mapped at address 0xb6f89000.
> Value at address 0x483072F4 (0xb6f892f4): 0x3201
>
> Note: omap34xx and am3517 have/need no comparable L
On Fri, Sep 13, 2019 at 3:35 PM H. Nikolaus Schaller wrote:
>
> Hi Daniel,
>
> > Am 13.09.2019 um 22:11 schrieb Daniel Lezcano :
> >
> > On 13/09/2019 20:46, Adam Ford wrote:
> >> On Fri, Sep 13, 2019 at 12:18 PM Daniel Lezcano
> >> wrote:
> >
On Fri, Sep 13, 2019 at 1:46 PM Adam Ford wrote:
>
> On Fri, Sep 13, 2019 at 12:18 PM Daniel Lezcano
> wrote:
> >
> > On 13/09/2019 18:51, H. Nikolaus Schaller wrote:
> >
> > [ ... ]
> >
> > >> Good news (I think)
> > >>
> >
0MHz, etc.
If I am interpreting your comment correctly, I should set <&cpu
THERMAL_NO_LIMIT 2> which would allow it to either not cool and run up
to 600MHz and not exceed, is that correct?
>
>
> Does it clarify the DT spec?
>
I think your reply to my inquiry might. If possi
rmal throttling to limit the
operating points of the omap3630 to Only OPP50 and OPP100 if
the thermal sensor reads a value above 90C.
When forcing the high-temperature state, the scaling_max_freq
returns a value that corresponds to OPP100 showing that
OPP130 and OPP1G are not available.
Signed-of
On Fri, Sep 13, 2019 at 11:35 AM Adam Ford wrote:
>
> On Fri, Sep 13, 2019 at 10:09 AM H. Nikolaus Schaller
> wrote:
> >
> >
> > > Am 13.09.2019 um 17:01 schrieb Adam Ford :
> > >
> > > On Fri, Sep 13, 2019 at 9:24 AM H. Nikolaus Schaller
> &
On Fri, Sep 13, 2019 at 10:09 AM H. Nikolaus Schaller
wrote:
>
>
> > Am 13.09.2019 um 17:01 schrieb Adam Ford :
> >
> > On Fri, Sep 13, 2019 at 9:24 AM H. Nikolaus Schaller
> > wrote:
> >>
> >>
> >>> Am 13.09.2019 um 16:05 schri
g the thermal info on the AM3517.
Signed-off-by: Adam Ford
---
V2: Add node name for cpu and add cooling-cells entry
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 4043ecb38016..84704eb3b604 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3
their respective device trees with something like:
&cpu_alert0 {
temperature = <85000>; /* millicelsius */
};
&cpu_crit {
temperature = <9>; /* millicelsius */
};
Signed-off-by: Adam Ford
---
V2: Change the CPU reference to &cpu instead of &cpu0
g the thermal info on the AM3517.
Signed-off-by: Adam Ford
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 4043ecb38016..db9cafddbe69 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -44,6 +
their respective device trees with something like:
&cpu_alert0 {
temperature = <85000>; /* millicelsius */
};
&cpu_crit {
temperature = <9>; /* millicelsius */
};
Signed-off-by: Adam Ford
diff --git a/arch/arm/boot/dts/omap3-cpu-thermal.dtsi
b/arch/ar
On Fri, Sep 13, 2019 at 9:24 AM H. Nikolaus Schaller wrote:
>
>
> > Am 13.09.2019 um 16:05 schrieb Adam Ford :
> >
> > On Fri, Sep 13, 2019 at 8:32 AM H. Nikolaus Schaller
> > wrote:
> >>
> >> Hi Adam,
> >>
> >>> Am 13.09.
On Fri, Sep 13, 2019 at 8:32 AM H. Nikolaus Schaller wrote:
>
> Hi Adam,
>
> > Am 13.09.2019 um 13:07 schrieb Adam Ford :
>
> >>> + cpu_cooling_maps: cooling-maps {
> >>> + map0 {
> >>> + trip = <&cpu
On Fri, Sep 13, 2019 at 6:07 AM Adam Ford wrote:
>
> On Fri, Sep 13, 2019 at 1:56 AM H. Nikolaus Schaller
> wrote:
> >
> > Hi Adam,
> >
> > > Am 12.09.2019 um 20:30 schrieb Adam Ford :
> > >
> > > The thermal sensor in the omap3 family is
On Fri, Sep 13, 2019 at 1:56 AM H. Nikolaus Schaller wrote:
>
> Hi Adam,
>
> > Am 12.09.2019 um 20:30 schrieb Adam Ford :
> >
> > The thermal sensor in the omap3 family isn't accurate, but it's
> > better than nothing. The various OPP's enabled f
On Thu, Sep 12, 2019 at 4:12 PM Daniel Lezcano
wrote:
>
> On 12/09/2019 20:30, Adam Ford wrote:
> > The thermal sensor in the omap3 family isn't accurate, but it's
> > better than nothing. The various OPP's enabled for the omap3630
> > support up to OPP1
On Thu, Sep 12, 2019 at 8:58 AM Adam Ford wrote:
>
> On Wed, Sep 11, 2019 at 12:49 PM Adam Ford wrote:
> >
> > On Wed, Sep 11, 2019 at 12:43 PM H. Nikolaus Schaller
> > wrote:
> > >
> > > Hi Adam,
> > >
> >
rmal throttling to limit the
operating points of the omap3630 to Only OPP50 and OPP100 if
the thermal sensor reads a value above 90C.
Signed-off-by: Adam Ford
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 4bb4f534afe2..58b9d347019f 100644
--- a/ar
On Wed, Sep 11, 2019 at 12:49 PM Adam Ford wrote:
>
> On Wed, Sep 11, 2019 at 12:43 PM H. Nikolaus Schaller
> wrote:
> >
> > Hi Adam,
> >
> > > Am 11.09.2019 um 18:01 schrieb H. Nikolaus Schaller :
> > >
> > >>
> > >> Am
the OPP only for ES1.0 BIT(0) and if the high speed
> eFuse is set BIT(1).
>
> Signed-off-by: H. Nikolaus Schaller
> Reviewed-by: Tony Lindgren
For the entire series, I tested on the Logic PD devices:
DM3730 Torpedo, OMAP3530 SOM-LV, DM3730 SOM-LV and AM3517-EVM
Tested-by: Adam Ford
&
On Wed, Sep 11, 2019 at 12:43 PM H. Nikolaus Schaller
wrote:
>
> Hi Adam,
>
> > Am 11.09.2019 um 18:01 schrieb H. Nikolaus Schaller :
> >
> >>
> >> Am 11.09.2019 um 17:56 schrieb Adam Ford :
> >>
> >>> There are some subtleties for tes
The TFP410 driver was removed but the replacement driver was
never enabled. This patch enableds the DRM_TI_TFP410
Fixes: be3143d8b27f ("drm/omap: Remove TFP410 and DVI connector drivers")
Signed-off-by: Adam Ford
diff --git a/arch/arm/configs/omap2plus_defconfig
b/arch/a
On Wed, Sep 11, 2019 at 11:50 AM Sebastian Reichel wrote:
>
> Hi,
>
> On Wed, Sep 11, 2019 at 09:52:25AM -0500, Adam Ford wrote:
> > The omap panel-dpi driver was removed in
> > Commit 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")
> >
> > The tFP
On Wed, Sep 11, 2019 at 10:46 AM H. Nikolaus Schaller
wrote:
>
> Hi,
>
> > Am 11.09.2019 um 14:43 schrieb Adam Ford :
> >
> >>
> >> I can also see that there are transitions on the voltages (reg.8 is vdd
> >> and reg.3 is abb).
> >
> &g
: Adam Ford
diff --git a/arch/arm/configs/omap2plus_defconfig
b/arch/arm/configs/omap2plus_defconfig
index 166b36be2ca6..a0449d3b48a5 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -128,7 +128,6 @@ CONFIG_PCI_ENDPOINT_CONFIGFS=y
CONFIG_PCI_EPF_TEST
nfig.
Signed-off-by: Adam Ford
diff --git a/arch/arm/configs/omap2plus_defconfig
b/arch/arm/configs/omap2plus_defconfig
index c7bf9c493646..166b36be2ca6 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -349,12 +349,9 @@ CONFIG_OMAP5_DSS_HDMI=y
CO
On Wed, Sep 11, 2019 at 1:50 AM H. Nikolaus Schaller wrote:
>
>
> > Am 11.09.2019 um 08:03 schrieb H. Nikolaus Schaller :
> >
> >
> >> Am 11.09.2019 um 07:13 schrieb H. Nikolaus Schaller :
> >>
> >> Hi Adam,
> >>
> >>> Am
On Tue, Sep 10, 2019 at 7:24 PM Adam Ford wrote:
>
> On Tue, Sep 10, 2019 at 3:06 PM Adam Ford wrote:
> >
> > On Tue, Sep 10, 2019 at 2:55 PM H. Nikolaus Schaller
> > wrote:
> > >
> > > Ok,
> > >
> > > > Am 10.09.2019 um 20:51 sch
On Tue, Sep 10, 2019 at 3:06 PM Adam Ford wrote:
>
> On Tue, Sep 10, 2019 at 2:55 PM H. Nikolaus Schaller
> wrote:
> >
> > Ok,
> >
> > > Am 10.09.2019 um 20:51 schrieb H. Nikolaus Schaller :
> > >
> > >>>> it, but then I got some
vset=0x0
[1.112609] ti_abb 483072f0.regulator-abb-mpu: [1]v=120 ABB=0
ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
[1.112609] ti_abb 483072f0.regulator-abb-mpu: [2]v=1325000 ABB=0
ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
[ 1.112640] ti_abb 483072f0.regulator-abb-mpu: [3]v=1375000 ABB=1
ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
[1.112731] ti_abb 483072f0.regulator-abb-mpu: ti_abb_init_timings:
Clk_rate=1300, sr2_cnt=0x0032
adam
>
> BR,
> Nikolaus
>
gt;
> We also do not need to hold the lock while converting the integer to a string.
>
> Reported-by: Adam Ford
> Signed-off-by: H. Nikolaus Schaller
Tested-by: Adam Ford
> ---
> drivers/regulator/core.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
On Tue, Sep 10, 2019 at 1:51 PM H. Nikolaus Schaller wrote:
>
> Hi,
>
> > Am 10.09.2019 um 20:30 schrieb Adam Ford :
> >
> > On Tue, Sep 10, 2019 at 11:59 AM H. Nikolaus Schaller
> > wrote:
> >>
> >> Hi Adam,
> >>
> >>> Am
On Tue, Sep 10, 2019 at 11:59 AM H. Nikolaus Schaller
wrote:
>
> Hi Adam,
>
> > Am 09.09.2019 um 21:13 schrieb Adam Ford :
> >
> > On Mon, Sep 9, 2019 at 1:11 PM H. Nikolaus Schaller
> > wrote:
> >>
> >> Ok, we have to check if the t
On Tue, Sep 10, 2019 at 10:48 AM Adam Ford wrote:
>
> On Mon, Sep 9, 2019 at 11:35 AM Tony Lindgren wrote:
> >
> > * Pali Rohár [190909 13:41]:
> > > On Monday 09 September 2019 08:37:09 Adam Ford wrote:
> > > > I applied this on 5.3 and it is working. I
On Mon, Sep 9, 2019 at 11:35 AM Tony Lindgren wrote:
>
> * Pali Rohár [190909 13:41]:
> > On Monday 09 September 2019 08:37:09 Adam Ford wrote:
> > > I applied this on 5.3 and it is working. I assume the same is true in
> > > for-next.
>
> Hmm I noticed I st
On Thu, Sep 5, 2019 at 6:04 PM Tony Lindgren wrote:
>
> Hi,
>
> * Adam Ford [190828 15:01]:
> > The datasheet for the AM3517 shows the RNG is connected to L4.
> > It shows the module address for the RNG is 0x480A, and it
> > matches the omap2.dtsi description.
On Mon, Sep 9, 2019 at 11:35 AM Tony Lindgren wrote:
>
> * Pali Rohár [190909 13:41]:
> > On Monday 09 September 2019 08:37:09 Adam Ford wrote:
> > > I applied this on 5.3 and it is working. I assume the same is true in
> > > for-next.
>
> Hmm I noticed I st
the abb_mpu_iva
regulator was even running, but I would get -22 errors when I went to
read the voltage.
# cat
/sys/devices/platform/6800.ocp/483072f0.regulator-abb-mpu/regulator/regulator.5/microvolts
-22
If someone has any suggestions on how to test the abb_mpu_iva driver,
let me know.
>
> Needs a little time to add to a new version of the patch set.
>
> > And make sure that the TJ does not exceed 90°C by reducing the cpufreq
> > through the thermal framework. But: the thermal sensors of the omap3
> > are quite odd (they seem to jump up by 10° after first use).
Can we just do a dummy read to get it out of the way? ;-)
>
> I'll leave this out for the moment for future study.
Works for me, Baby steps.
Thanks for all your work.
adam
>
> BR and thanks,
> Nikolaus
>
On Mon, Sep 9, 2019 at 1:13 PM H. Nikolaus Schaller wrote:
>
> Hi Adam,
>
> > Am 09.09.2019 um 17:45 schrieb Adam Ford :
> >
> > The AM3517 only lists 600MHz @ 1.2V, but the revister values for
>
> a small typo...
>
> s/revister/register/
>
> > 0x
, but even for non-1GHz
versions, having it downclock would be a good thing when running at
extreme temps.
adam
> >
> > But this would mean that every board DTS would have to set it explicitly
> > to "enabled".
>
> Yes I started thinking about that too. I think t
On Mon, Sep 9, 2019 at 11:20 AM Adam Ford wrote:
>
> On Mon, Sep 9, 2019 at 9:57 AM H. Nikolaus Schaller
> wrote:
> >
> > Hi Adam,
> >
> > > Am 09.09.2019 um 16:26 schrieb Adam Ford :
> > >
> > > On Sat, Sep 7, 2019 at 2:38 AM H.
On Mon, Sep 9, 2019 at 9:57 AM H. Nikolaus Schaller wrote:
>
> Hi Adam,
>
> > Am 09.09.2019 um 16:26 schrieb Adam Ford :
> >
> > On Sat, Sep 7, 2019 at 2:38 AM H. Nikolaus Schaller
> > wrote:
> >>
> >> Hi Adam,
> >>
> >>&
structure instead of the 3430.
Signed-off-by: Adam Ford
diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
index f2f58d689320..6b69fb1d6bdf 100644
--- a/drivers/cpufreq/ti-cpufreq.c
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -270,6 +270,7 @@ static int ti_cpufreq_setup_syscon_register
501 - 600 of 1799 matches
Mail list logo
