This allows us to move the SoCs to probe system timers one SoC
at at time. As arch/arm/mach-omap2/timer.c will be eventually gone,
let's just add omap_init_time_of() to board-generic.c directly.
Cc: Keerthy
Cc: Lokesh Vutla
Cc: Tero Kristo
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2
: Tero Kristo
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/Makefile | 4 +-
arch/arm/mach-omap2/common.h | 7 +
arch/arm/mach-omap2/timer.c | 551 ---
3 files changed, 10 insertions(+), 552 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm
these with assigned-clocks
and assigned-clock-parents as needed.
Cc: devicet...@vger.kernel.org
Cc: Keerthy
Cc: Lokesh Vutla
Cc: Tero Kristo
Signed-off-by: Tony Lindgren
---
arch/arm/boot/dts/am33xx-l4.dtsi | 6 ++---
arch/arm/boot/dts/am33xx.dtsi | 24 +++
arch
: Stephen Boyd
Cc: Tero Kristo
Acked-by: Stephen Boyd
Signed-off-by: Tony Lindgren
---
drivers/clk/ti/clk-816x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/ti/clk-816x.c b/drivers/clk/ti/clk-816x.c
--- a/drivers/clk/ti/clk-816x.c
+++ b/drivers/clk/ti/clk-816x.c
@@ -73,6 +73,7
Signed-off-by: Tony Lindgren
---
arch/arm/boot/dts/dm814x.dtsi | 78 +---
arch/arm/boot/dts/dm816x.dtsi | 82 ++
arch/arm/mach-omap2/board-generic.c| 4 +-
arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 74 ---
4
can optionally configure the timer source clock in using
assigned-clock-parents.
Cc: linux-kernel@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: Daniel Lezcano
Cc: Keerthy
Cc: Lokesh Vutla
Cc: Tero Kristo
Cc: Thomas Gleixner
Signed-off-by: Tony Lindgren
---
drivers/clocksource/Makefile
before registering the
clocksource, now we see it after the clocksource information which is a
bit confusing.
Cc: linux-kernel@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: Daniel Lezcano
Cc: Keerthy
Cc: Lokesh Vutla
Cc: Tero Kristo
Cc: Thomas Gleixner
Signed-off-by: Tony Lindgren
accordingly.
Then for merging when folks are happy with this series, Daniel if you
can please apply the first three patches into an immutable branch it
would be great.
Regards,
Tony
Tony Lindgren (15):
clocksource/drivers/timer-ti-32k: Add support for initializing
directly
dt-bindings: timer
* H. Nikolaus Schaller [200429 21:35]:
> I have reworked the way the spinlocks, setting and resetting
> of the hdq_irqstatus bits are done and now it works right from
> start of boot. Without any timeouts or delays.
>
> I am not exactly sure what went wrong, but it seems as if
> the read is
* Lokesh Vutla [200427 17:29]:
> omap_dm_timer_prepare() is setting up the parent 32KHz clock. This
> prepare() gets called by request_timer in the client's driver. Because of
> this, the timer clock parent that is set with assigned-clock-parent is being
> overwritten. So drop this default
* Tony Lindgren [191022 16:56]:
> * Tero Kristo [191022 16:48]:
> > On 22/10/2019 19:21, Benoit Parrot wrote:
> > > Tony Lindgren wrote on Tue [2019-Oct-22 08:48:16
> > > -0700]:
> > > > * Benoit Parrot [191016 18:47]:
> > > > > --- a/arc
* Stephen Rothwell [191022 20:11]:
> Hi all,
>
> Commit
>
> 40f3ee0ea7f1 ("ARM: OMAP2+: Drop legacy platform data for dra7 rng")
>
> is missing a Signed-off-by from its author and committer.
Oops sorry about that, will fix it.
Regards,
Tony
* H. Nikolaus Schaller [191023 04:42]:
>
> > Am 23.10.2019 um 00:19 schrieb Tony Lindgren :
> >
> > * Adam Ford [191022 19:01]:
> >> On Tue, Oct 22, 2019 at 11:22 AM Tony Lindgren wrote:
> >>>
> >>> Hi,
> >>>
> >
* Adam Ford [191022 19:01]:
> On Tue, Oct 22, 2019 at 11:22 AM Tony Lindgren wrote:
> >
> > Hi,
> >
> > * Adam Ford [191007 15:06]:
> > > The some in the OMAP3 family have a bandgap thermal sensor, but
> > > omap2plus has it disabled.
> > >
* Tero Kristo [191022 16:48]:
> On 22/10/2019 19:21, Benoit Parrot wrote:
> > Tony Lindgren wrote on Tue [2019-Oct-22 08:48:16 -0700]:
> > > * Benoit Parrot [191016 18:47]:
> > > > --- a/arch/arm/boot/dts/am43xx-clocks.dtsi
> > > > +++ b/arch/arm/boo
* Benoit Parrot [191022 16:45]:
> Tony Lindgren wrote on Tue [2019-Oct-22 09:37:54 -0700]:
> > * Benoit Parrot [191022 16:34]:
> > > Tony Lindgren wrote on Tue [2019-Oct-22 09:30:48
> > > -0700]:
> > > > * Benoit Parrot [191022 16:28]:
&g
* Krzysztof Kozlowski [191002 09:45]:
> The device node name should reflect generic class of a device so rename
> the "ocmcram" node to "sram". This will be also in sync with upcoming DT
> schema. No functional change.
Applying this into omap-for-v5.5/dt thanks.
Tony
* Benoit Parrot [191022 16:34]:
> Tony Lindgren wrote on Tue [2019-Oct-22 09:30:48 -0700]:
> > * Benoit Parrot [191022 16:28]:
> > > Tony,
> > >
> > > Ping,
> > >
> > > I already had comments from Rob but i would like your feedbac
* Krzysztof Kozlowski [191021 09:39]:
> The device node name should reflect generic class of a device so rename
> the "ocmcram" node and its children to "sram". This will be also in
> sync with upcoming DT schema. No functional change.
Applying into omap-for-v5.5/dt thanks.
Tony
* Benoit Parrot [191022 16:28]:
> Tony,
>
> Ping,
>
> I already had comments from Rob but i would like your feedback before
> sending a v2.
Looks good to me in general other than what Rob commented
on. Did not spot any node naming issues here :)
Regards,
Tony
* Benoit Parrot [191022 16:17]:
> Tony Lindgren wrote on Tue [2019-Oct-22 08:44:46 -0700]:
> > * Benoit Parrot [191018 15:46]:
> > > Add device nodes for CSI2 camera board OV5640.
> > > Add the CAL port nodes with the necessary linkage to the ov5640 nodes.
> &g
* Benoit Parrot [191022 16:14]:
> Tony Lindgren wrote on Tue [2019-Oct-22 08:40:12 -0700]:
> > Probably the best way would be for tero to collect
> > all the drivers/clk/ti clock data changes and provide
> > an immutable branch with those that I can merge too.
>
> So
Hi,
* Adam Ford [191007 15:06]:
> 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.
Looks like this breaks off mode during idle for omap3, and that's
probably why
* Jonathan Neuschäfer [191002 07:54]:
> Signed-off-by: Jonathan Neuschäfer
> ---
> arch/arm/mach-omap1/ams-delta-fiq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap1/ams-delta-fiq.c
> b/arch/arm/mach-omap1/ams-delta-fiq.c
> index
* Adam Ford [191022 12:13]:
> 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
llow this convention
> > so changes to these boards don't get automatically flagged to
> > route to the omap mailing list. After consulting with Tony
> > Lindgren, he agreed it made sense to add these boards to the
> > list.
> >
> > This patch adds the omap based boa
* Sebastian Reichel [191020 20:34]:
> Hi Tony,
>
> On Tue, Oct 08, 2019 at 07:31:16AM -0700, Tony Lindgren wrote:
> > * Sebastian Reichel [191003 06:42]:
> > > This moves the remaining users of btwilink to the "new" serdev based
> > > hci_ll
* Benoit Parrot [191016 18:47]:
> --- a/arch/arm/boot/dts/am43xx-clocks.dtsi
> +++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
> @@ -704,6 +704,60 @@
> ti,bit-shift = <8>;
> reg = <0x2a48>;
> };
> +
> + clkout1_osc_div_ck: clkout1_osc_div_ck {
> +
* Benoit Parrot [191018 15:46]:
> Add device nodes for CSI2 camera board OV5640.
> Add the CAL port nodes with the necessary linkage to the ov5640 nodes.
>
> Signed-off-by: Benoit Parrot
> ---
> arch/arm/boot/dts/dra72-evm-common.dtsi | 35 +
> 1 file changed, 35
* Benoit Parrot [191018 15:46]:
> Add clkctrl nodes for CAM domain.
You're missing the Linux clk folks and list from Cc, can
you please resend?
I need an ack for the clk-7xx.c changes if I'm to apply
this patch.
Probably the best way would be for tero to collect
all the drivers/clk/ti clock
Also on am335x we need the swsup quirks for musb.
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -1259,6 +1259,8 @@ static const
We need swsup quirks for sidle and mstandby for musb to work
properly.
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
--- a/drivers/bus/ti-sysc.c
+++ b/drivers
* Adam Ford [191016 06:53]:
> 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
>
* H. Nikolaus Schaller [191018 20:28]:
> Since v4.7 the dma initialization requires that there is a
> device tree property for "rx" and "tx" channels which is
> not provided by the pdata-quirks initialization.
>
> By conversion of the mmc3 setup to device tree this will
> finally allows to
* H. Nikolaus Schaller [191021 17:08]:
>
> > Am 21.10.2019 um 16:30 schrieb Tony Lindgren :
> >
> > * H. Nikolaus Schaller [191019 18:43]:
> >> --- a/arch/arm/mach-omap2/Makefile
> >> +++ b/arch/arm/mach-omap2/Makefile
> >> @@ -216,7 +216,6 @@
t; into the format string and drop base_name entirely.
>
> Changes since v1:
> - Use devm_kasprintf instead of manually allocating the target
> buffer.
Acked-by: Tony Lindgren
> ---
> drivers/clk/ti/adpll.c | 11 ++-
> 1 file changed, 2 insertions(+), 9 deletion
* H. Nikolaus Schaller [191019 18:43]:
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -216,7 +216,6 @@ obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
>
> # Platform specific device init code
>
> -omap-hsmmc-$(CONFIG_MMC_OMAP_HS) := hsmmc.o
>
* YueHaibing [191018 12:08]:
> Fix sparse warnings:
>
> arch/arm/mach-omap2/pmic-cpcap.c:29:15: warning: symbol
> 'omap_cpcap_vsel_to_uv' was not declared. Should it be static?
> arch/arm/mach-omap2/pmic-cpcap.c:43:15: warning: symbol
> 'omap_cpcap_uv_to_vsel' was not declared. Should it be
need to also set swsup quirk flag
I probably only tested this earlier with watchdog service running when the
watchdog never gets disabled.
Fixes: 4e23be473e30 ("bus: ti-sysc: Add support for module specific reset
quirks")
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-s
Hi,
Just few comments for future changes that might help below.
* min@mediatek.com [191017 09:42]:
> --- /dev/null
> +++ b/drivers/usb/musb/mediatek.c
> +static int musb_usb_role_sx_set(struct device *dev, enum usb_role role)
> +{
> + struct mtk_glue *glue = dev_get_drvdata(dev);
> +
equential order.
>
> Signed-off-by: Dan Murphy
> CC: Tony Lindgren
> CC: "Benoît Cousson"
>
> k# interactive rebase in progress; onto ae89cc6d4a8c
Maybe check what's up with the line above :)
Othwerwise looks good to me, best to merge this together
with the res
* H. Nikolaus Schaller [191014 09:12]:
>
> > Am 12.10.2019 um 15:09 schrieb H. Nikolaus Schaller :
> >
> > Hi,
> >
> >> Am 05.10.2019 um 18:58 schrieb H. Nikolaus Schaller :
> >
> > I have found the following description, followed all steps, and it works:
> >
> >
* Yi Zheng [191010 06:22]:
> Hi
>
>My patch is canceled. I have tested that simple adjustment, the
> device IRQ masked unexpectedly. It seems that it is more easily to
> occur with that patch.
>
> So, the root cause is not found yet.
OK. Based on your description, it could be a missing
* Adam Ford [191009 19:28]:
> On Wed, Oct 9, 2019 at 12:34 PM Tony Lindgren wrote:
> > From what I recall I tested that DMA on omap3 worked fine with runtime
> > PM for console. Certainly there are issues still remaining though.
> >
> > If you want to disable dma for a
* Alan Stern [191009 18:51]:
> On Wed, 9 Oct 2019, Tony Lindgren wrote:
>
> > With generic wakeirqs we can wake a device, but do not know if the
> > device woke to a wakeirq. Let's add pm_runtime_wakeup_is_wakeirq() so
> > a device can check the wake-up reason.
>
>
function can
then skip some or all of the device wake-up sequence based on
pm_runtime_wakeup_is_wakeirq().
Let's only add RPM_WAKEUP_NONE and RPM_WAKEUP_WAKEIRQ for now, other
events can be added later on if really needed.
Signed-off-by: Tony Lindgren
---
drivers/base/power/wakeirq.c | 14
Hi,
* Yi Zheng [191008 13:06]:
> NOTE: (1) My SoC is a single core ARM chip: TI-AM3352, so the raw
> spin-lock irq_desc->lock will be optimized to
> nothing. handle_level_irq() has no spin-lock protection, right?
Well not always, With CONFIG_SMP we modify only some of
* 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 anyone else had any issues using the CONFIG_SERIAL_8250_DMA on the
> > > OMAP?
> > >
> > > I can use the DMA on the legacy,
* Jeroen Hofstee [191008 17:00]:
> Hi,
>
> On 10/8/19 6:51 PM, Tony Lindgren wrote:
> > * Jeroen Hofstee [191008 16:43]:
> >> Hello Tony,
> >>
> >> On 10/8/19 6:14 PM, Tony Lindgren wrote:
> >>> * Jeroen Hofstee [191008 16:03]:
> >>
* Jeroen Hofstee [191008 16:43]:
> Hello Tony,
>
> On 10/8/19 6:14 PM, Tony Lindgren wrote:
> > * Jeroen Hofstee [191008 16:03]:
> >> Hello Tony,
> >>
> >> On 10/8/19 4:23 PM, Tony Lindgren wrote:
> >>> * Grygorii Strashko [191003 02
* Jeroen Hofstee [191008 16:03]:
> Hello Tony,
>
> On 10/8/19 4:23 PM, Tony Lindgren wrote:
> > * Grygorii Strashko [191003 02:32]:
> >> On 03/10/2019 11:16, Jeroen Hofstee wrote:
> >>> Furthermore 4.19 is fine, so there is no need to include it in stable
>
* Sebastian Reichel [191003 06:42]:
> Hi,
>
> This moves the remaining users of btwilink to the "new" serdev based hci_ll
> driver and drops the btwilink driver afterwards. The patches were only compile
> tested by me, but Enric tested the IGEP platform and Adam will test the
> LogicPD
>
* Grygorii Strashko [191003 02:32]:
> On 03/10/2019 11:16, Jeroen Hofstee wrote:
> > Furthermore 4.19 is fine, so there is no need to include it in stable
> > and have a note to make sure also other patches are required etc.
>
> Hence all above patches went in 5.1 it would be correct to mention
he mux/switch as a whole, so move it there and drop all
> > of the concurrences in child nodes.
> >
> > Fixes: d031773169df ("ARM: dts: Adds device tree file for McGill's
> > IceBoard, based on TI AM3874")
> > Signed-off-by: Andrey Smirnov
> > Cc:
* Tero Kristo [191008 08:01]:
> On 07/10/2019 22:24, H. Nikolaus Schaller wrote:
> > Hi Tero,
> >
> > > Am 07.10.2019 um 21:18 schrieb Tero Kristo :
> > >
> > > On 07/10/2019 18:52, Tony Lindgren wrote:
> > > > Hi,
> > > > * H.
* Emmanuel Vadot [191007 17:30]:
> On Mon, 7 Oct 2019 09:58:59 -0700
> Tony Lindgren wrote:
> > There should be no need to do that for SoC internal devices, the
> > the default status = "okay" should be just fine. Setting the
> > status = "disabled"
* Emmanuel Vadot [191007 16:39]:
> On Mon, 7 Oct 2019 09:16:34 -0700
> Tony Lindgren wrote:
>
> > Hi,
> >
> > * Emmanuel Vadot [191007 08:04]:
> > > Commit 5b63fb90adb95 ("ARM: dts: Fix incomplete dts data for am3 and am4
> > > mmc"
Hi,
* Emmanuel Vadot [191007 08:04]:
> Commit 5b63fb90adb95 ("ARM: dts: Fix incomplete dts data for am3 and am4 mmc")
> fixed the mmc instances on the l3 interconnect but removed the disabled
> status.
> Fix this and let boards properly define it if it have it.
The dts default is "okay", and
* Adam Ford [191004 19:30]:
> On Tue, Jul 23, 2019 at 5:21 PM Tony Lindgren wrote:
> >
> > For many years omap variants have been setting the runtime PM
> > autosuspend delay to -1 to prevent unsafe policy with lossy first
> > character on wake-up. The user must spec
Hi,
* H. Nikolaus Schaller [191005 16:59]:
> Hi all,
> with the arrival of v5.4-rc1 some of Tony's sysc patches have arrived
> upstream, so we do no longer need them here.
>
> Therefore, I have rebased my drivers/staging/pvr driver [1] and fixed some
> more issues:
> * omap4 build only needs to
* Stephen Kitt [190927 15:13]:
> The buffer allocated in ti_adpll_clk_get_name doesn't account for the
> terminating null. This patch adds the extra byte, and switches to
> snprintf to avoid overflowing.
>
> Signed-off-by: Stephen Kitt
> ---
> drivers/clk/ti/adpll.c | 7 ---
> 1 file
* Adam Ford [190911 17:14]:
> 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
* Adam Ford [190911 10:47]:
> 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")
Applying into fixes thanks.
Tony
Oops, thanks for catching it:
Acked-by: Tony Lindgren
pendent config options.
>
> So fix the omap2plus_defconfig to have CONFIG_REMOTEPROC built in.
Acked-by: Tony Lindgren
* H. Nikolaus Schaller [190920 09:12]:
> commit 6953c57ab172 "gpio: of: Handle SPI chipselect legacy bindings"
>
> did introduce logic to centrally handle the legacy spi-cs-high property
> in combination with cs-gpios. This assumes that the polarity
> of the CS has to be inverted if spi-cs-high
* H. Nikolaus Schaller [190920 15:50]:
>
> > Am 20.09.2019 um 17:29 schrieb Andreas Kemnade :
> >
> > On Fri, 20 Sep 2019 16:54:18 +0200
> > "H. Nikolaus Schaller" wrote:
> >
> >>> Am 20.09.2019 um 16:20 schrieb Tony Lindgren :
> >&
king for any error return to catch the -ENOENT case.
Acked-by: Tony Lindgren
* H. Nikolaus Schaller [190920 09:19]:
> > Am 20.09.2019 um 10:55 schrieb Linus Walleij :
> > I suggest to go both way:
> > apply this oneliner and tag for stable so that GTA04 works
> > again.
> >
> > Then for the next kernel think about a possible more abitious
> > whitelist solution and after
* Tero Kristo [190917 07:22]:
> On 24/07/2019 09:47, Tony Lindgren wrote:
> > * Suman Anna [190723 21:02]:
> > > Hi Tony,
> > >
> > > On 7/23/19 6:28 AM, Tony Lindgren wrote:
> > > > The ahclkr clkctrl clock bit 28 only exists for mcasp 1 and 2
* H. Nikolaus Schaller [190911 17:48]:
> CHANGES V3:
> * make omap36xx control the abb-ldo and properly switch mode
> (suggested by Adam Ford )
> * add a note about enabling the turbo-mode OPPs
Looks good to me, when applying, please provide a
minimal immutable branch maybe against v5.3 or
> This patch sets up the OPP50 and OPP100 tables at 300MHz and 600MHz
> for the AM3517 with each having an operating voltage at 1.2V.
Acked-by: Tony Lindgren
gt; 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 LDO
> or mechanism.
Acked-by: Tony Lindgren
> This patch simply adds the am3517 to the compatible table
> similar to a mix of the omap3430 and omap3430 structure.
Acked-by: Tony Lindgren
another field to the SoC description table which
> optionally can specify a list of regulator names.
>
> For omap36xx we define "cpu0-supply" and "vbb-supply".
>
> The default remains "vdd-supply" and "vbb-supply".
Acked-by: Tony Lindgren
the issue.
Fixes: 5d1ebbda0318 ("phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on
Droid 4")
Cc: Marcel Partap
Cc: Merlijn Wajer
Cc: Michael Scott
Cc: NeKit
Cc: Pavel Machek
Cc: Sebastian Reichel
Signed-off-by: Tony Lindgren
---
drivers/phy/motorola/phy-mapphone-mdm6
Hi,
* Stephen Rothwell [190910 14:25]:
> Hi all,
>
> In commit
>
> a932b77b4d19 ("ARM: dts: logicpd-som-lv: Fix i2c2 and i2c3 Pin mux")
>
> Fixes tag
>
> Fixes: 5fe3c0fa0d54 ("ARM: dts: Add pinmuxing for i2c2 and i2c3
>
> has these problem(s):
>
> - Subject has leading but no
* 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 stopped getting RNG data after several rmmod modprobe
cycles, or several hd /dev/random reads. Anybody
Hi,
* H. Nikolaus Schaller [190909 14:57]:
> Another question that came up by private mail from André was if we
> should better disable the turbo OPPs of omap34xx and 36xx by default
> (status = "disabled";) because there are concerns about overheating
> the chips and we have no thermal
Hi,
* Keerthy [190909 01:57]:
> I believe still the previous fix [1] for nfs boot is still not on
> linux-next. Are you planning on more testing or it will be queued as fixes?
I pushed out the pending fixes on Saturday so they should be in
the next version of Linux next.
Regards,
Tony
* Jonathan Cameron [190908 11:16]:
> On Mon, 2 Sep 2019 17:02:45 +0200
> Thierry Reding wrote:
>
> > On Sun, Sep 01, 2019 at 05:58:22PM -0500, David Lechner wrote:
> > > The TI PWMSS driver is a simple bus driver for providing power
> > > power management for the PWM peripherals on TI AM33xx
>
> ti,am3517
> ti,omap3430
> ti,omap3630
>
> in addition to ti,omap3.
>
> We leave ti,omap34xx and ti,omap36xx untouched for compatibility.
Thanks for doing this:
Acked-by: Tony Lindgren
since it is now
> automatically detected.
>
> We also fix a wrong OPP4 voltage for omap3430 which must be
> 0.6V + 54*12.5mV = 1275mV. Otherwise the twl4030 driver will reject
> this OPP.
>
> Signed-off-by: H. Nikolaus Schaller
Acked-by: Tony Lindgren
clarify that the list of boards is incomplete
> * remove some "ti,am33xx", "ti,omap3"
> * add some missing "ti,omap4"
Acked-by: Tony Lindgren
/* legacy */
> > + { .compatible = "ti,omap3430", .data = _soc_data, },
> > + { .compatible = "ti,omap3630", .data = _soc_data, },
>
> Well, I just realized that with the latest DTS changes,
>
> ti,omap34xx and ti,omap36xx are legacy and
> ti,omap3430 and ti,omap3630 are now official.
Heh :) Anyways, with that changed, this looks good to me:
Reviewed-by: Tony Lindgren
dle_nolock() and
clkdm_deny_idle_nolock() have usage count with clkdm->forcewake_count.
Let's drop the unpaired sysc_clkdm_deny_idle() to fix idling of devices.
Fixes: d098913a10f8 ("bus: ti-sysc: Fix clock handling for no-idle quirks")
Cc: Keerthy
Cc: Vignesh Raghavendra
Signed-off-by: Tony Lindgr
* H. Nikolaus Schaller [190906 17:09]:
> for i in 3430 34xx 3630 36xx; do echo $i $(fgrep '"'ti,omap$i'"'
> arch/arm/boot/dts/*.dts* | wc -l); done
>
> 3430 12
> 34xx 28
> 3630 3
> 36xx 23
>
> which would indicate that 34xx and 36xx are more common.
Right, but the xx variants are against the
* Adam Ford [190828 11:34]:
> When the panel-dpi driver was removed, the simple-panels driver
> was never enabled, so anyone who used the panel-dpi driver lost
> video, and those who used it inconjunction with simple-panels
> would have to manually enable CONFIG_DRM_PANEL_SIMPLE.
>
> This patch
* Viresh Kumar [190906 03:05]:
> On 05-09-19, 07:32, Tony Lindgren wrote:
> > Acked-by: Tony Lindgren
>
> Do you want to pick the series instead as this has lots of DT changes
> ?
It unlikely these dts changes will conflict with anything so I
have no problem acking them fo
* H. Nikolaus Schaller [190906 07:53]:
> > Am 05.09.2019 um 16:27 schrieb Tony Lindgren :
> > compatible = "ti,omap3-ldp", "ti,omap3430", "ti,omap34xx", "ti,omap3";
>
> After thinking a little about the whole topic the main rule of this c
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. Since the driver can support
> omap2 and omap4, it seems reasonable to assume the omap3 would
>
or modules with
no clock names specified in device tree we will just ignore the clocks.
Fixes: 2b2f7def058a ("bus: ti-sysc: Add support for missing clockdomain
handling")
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/pdata-quirks.c | 4 ++--
drivers/bus/ti-sysc.c | 5 +
* Viresh Kumar [190905 05:03]:
> Most of the stuff looks fine to me here. I will pick the patches when
> the SoC maintainers provide an Ack.
I noticed few issues with the dts changes but other than that
looks good to me.
Regards,
Tony
7, not
supported by regulator
cpu cpu0: _opp_add: OPP not supported by regulators (55000)
But presumably that can be further patched. So for this
patch:
Acked-by: Tony Lindgren
Hi,
* H. Nikolaus Schaller [190904 08:54]:
> According to omap.txt bindings documentation, matching the ti-cpufreq driver
> needs
> to specify explicitly if a board uses an omap3430 or omap36xx chip.
>
> This needs to add ti,omap3430 to most omap34xx boards and replace ti,omap3630
> by
>
> Signed-off-by: William Breathitt Gray
>
> Jonathan, if you have no objections please pick up this up so that it
> can make it to the 5.4 merge window coming in soon. Alternatively, I can
> merge it into my repository instead and hold it for a while longer
> there, if you prefer that route.
Looks good to me too:
Acked-by: Tony Lindgren
n to allow PM
runtime to idle the module if requested.
Fixes: 1a5cd7c23cc5 ("bus: ti-sysc: Enable all clocks directly during init to
read revision")
Cc: Keerthy
Cc: Vignesh Raghavendra
Reported-by: Keerthy
Reported-by: Grygorii Strashko
Signed-off-
* H. Nikolaus Schaller [190902 10:56]:
> Matching the ti-cpufreq driver needs to specify explicitly if
> a board uses an omap34xx or omap36xx chip.
>
> Signed-off-by: H. Nikolaus Schaller
> ---
> arch/arm/boot/dts/omap3-beagle.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
Cc: Merlijn Wajer
Cc: Michael Scott
Cc: NeKit
Cc: Pavel Machek
Cc: Sebastian Reichel
Fixes: 6d6ce40f63af ("phy: cpcap-usb: Add CPCAP PMIC USB support")
Signed-off-by: Tony Lindgren
---
drivers/phy/motorola/phy-cpcap-usb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
xes: b9762bebc633 ("gpiolib: Pass bitmaps, not integer arrays, to get/set
array")
Cc: Jacopo Mondi
Cc: Janusz Krzysztofik
Cc: Linus Walleij
Cc: Marcel Partap
Cc: Merlijn Wajer
Cc: Michael Scott
Cc: NeKit
Cc: Pavel Machek
Cc: Sebastian Reichel
Signed-off-by: Tony Lindgren
---
drivers
501 - 600 of 8394 matches
Mail list logo
