* Andreas Kemnade [190221 19:40]:
> On Thu, 21 Feb 2019 08:48:03 -0800
> Tony Lindgren wrote:
>
> > * Andreas Kemnade [190221 16:43]:
> > > Hi,
> > >
> > > On Wed, 20 Feb 2019 14:31:32 -0800
> > > Tony Lindgren wrote:
> > >
* Andreas Kemnade [190221 16:43]:
> Hi,
>
> On Wed, 20 Feb 2019 14:31:32 -0800
> Tony Lindgren wrote:
>
> > * Andreas Kemnade [180922 09:48]:
> > > When runtime is not enabled, pm_runtime_get_sync() returns -EACCESS,
> > > the counter will be increme
* David Miller [190221 00:18]:
> From: Tony Lindgren
> Date: Wed, 20 Feb 2019 13:01:27 -0800
>
> > What I can do is set up a separate branch with just this
> > patch on top of the dts changes that the arm-soc guys can
> > then merge towards the end of the merge cycle
* Andreas Kemnade [180922 09:48]:
> When runtime is not enabled, pm_runtime_get_sync() returns -EACCESS,
> the counter will be incremented but the resume callback not called,
> so enumeration and charging will not start properly.
> To avoid that happen, disable irq on suspend and recheck on
* David Miller [190220 20:42]:
> From: Tony Lindgren
> Date: Wed, 20 Feb 2019 12:33:26 -0800
>
> > * David Miller [190220 19:23]:
> >> From: Grygorii Strashko
> >> Date: Wed, 20 Feb 2019 17:25:19 +0200
> >>
> >> > Deprecate cpsw-phy-s
* David Miller [190220 19:23]:
> From: Grygorii Strashko
> Date: Wed, 20 Feb 2019 17:25:19 +0200
>
> > Deprecate cpsw-phy-sel driver as it's been replaced with new
> > TI phy-gmii-sel PHY driver.
> >
> > Signed-off-by: Grygorii Strashko
>
> Acked-by: David S. Miller
Thanks for the ack, but
Hi,
Some more info on chained irq vs mux below that might
help.
* Tony Lindgren [190219 15:36]:
> * Lokesh Vutla [190219 08:51]:
> > With this can you tell me how can we not have a device-tree and still
> > support
> > irq allocation?
>
> Using standard dts re
Hi,
* Grygorii Strashko [190220 15:26]:
> Deprecate cpsw-phy-sel driver as it's been replaced with new
> TI phy-gmii-sel PHY driver.
I'm not going to pick up this one, seems that Dave can merge
this later on? That is unless Dave wants to ack this one.
Regards,
Tony
> Signed-off-by: Grygorii
* Grygorii Strashko [190220 07:26]:
> Hi Tony,
>
> Hence prerequisite patches [1] have been merged already I'm sending final set
> of DT patches to complete conversation of TI CPSW driver to use phy-gmii-sel
> phy driver instead of cpsw-phy-sel.
>
> [1] https://lkml.org/lkml/2018/11/26/154
* Julia Lawall [190219 17:33]:
> On Tue, 19 Feb 2019, Tony Lindgren wrote:
> > In general, if the device tree node is never used afterwards,
> > should this be just:
> >
> > r = of_platform_populate(node, NULL, NULL, >dev);
> >
* Tony Lindgren [190219 17:11]:
> * Lokesh Vutla [190219 16:19]:
> > yes. How different is this from any of the above mentioned drivers using
> > firmware specific ids. Like sci pm domain[1] driver utilizes the same
> > device id for enabling any device in the system. Simil
* Lokesh Vutla [190219 16:19]:
> yes. How different is this from any of the above mentioned drivers using
> firmware specific ids. Like sci pm domain[1] driver utilizes the same
> device id for enabling any device in the system. Similarly clock
> driver[2] uses the same device ids and clock ids
Hi,
Adding devicetree list, Julia, Rob and Tomi to Cc.
* Peng Hao [190212 23:11]:
> of_find_device_by_node() takes a reference to the struct device
> when it finds a match via get_device.When returning error we should
> call put_device.
>
> Signed-off-by: Peng Hao
> ---
>
* Lokesh Vutla [190219 08:51]:
> Hi Tony,
>
> On 18/02/19 8:02 PM, Tony Lindgren wrote:
> > * Lokesh Vutla [190216 03:30]:
> >> On 2/15/2019 9:46 PM, Tony Lindgren wrote:
> >>> The dts node for the interrupt controller should describe a
> >>> prop
* Tony Lindgren [190218 16:20]:
> * Faiz Abbas [190218 13:38]:
> > Hi Tony,
> >
> > On 16/02/19 1:37 AM, Tony Lindgren wrote:
> > > * Faiz Abbas [190215 19:18]:
> > >> From: Chunyan Zhang
> > >>
> > >> sdhci-omap can support b
* Faiz Abbas [190218 13:46]:
> Hi Tony,
>
> On 16/02/19 1:32 AM, Tony Lindgren wrote:
> > * Faiz Abbas [190215 19:17]:
> >> The following add driver patches for porting TI's am335x and am437x
> >> devices to the sdhci-omap driver.
> >>
> >>
* Faiz Abbas [190218 13:38]:
> Hi Tony,
>
> On 16/02/19 1:37 AM, Tony Lindgren wrote:
> > * Faiz Abbas [190215 19:18]:
> >> From: Chunyan Zhang
> >>
> >> sdhci-omap can support both external dma controller via dmaengine
> >> framewor
* Lokesh Vutla [190216 03:30]:
> On 2/12/2019 1:12 PM, Lokesh Vutla wrote:
> > +TISCI Interrupt Router Node:
> > +
> > +- compatible: Must be "ti,sci-intr".
> > +- interrupt-controller:Identifies the node as an interrupt controller
> > +-
* Lokesh Vutla [190216 03:30]:
> On 2/15/2019 9:46 PM, Tony Lindgren wrote:
> > The dts node for the interrupt controller should describe a
> > proper Linux device, that is with reg entries and so on.
>
> You are asking to just keep the compatible property :)
Right
* Faiz Abbas [190215 19:18]:
> From: Chunyan Zhang
>
> sdhci-omap can support both external dma controller via dmaengine
> framework as well as ADMA which standard SD host controller
> provides.
Care to describe here also how to configure things for ADMA and
instead of DMA? Just leave out dmas
* Faiz Abbas [190215 19:17]:
> The following add driver patches for porting TI's am335x and am437x
> devices to the sdhci-omap driver.
>
> This involves adding external DMA support to sdhci (first 3 patches from
> Chunyan) plus some miscellaneous patches to take care of deviations of
> the
Hi,
* Lokesh Vutla [190214 18:03]:
> On 2/14/2019 11:16 PM, Tony Lindgren wrote:
> > But I'd rather have a proper hardware based phandle + index
> > type mapping in the dts if possible though.
>
> The idea about sysfw here is that Linux is not aware of anything about
&g
* Lokesh Vutla [190214 17:32]:
> Hi Tony,
> Please do not snip the on going discussion.
>
> On 2/14/2019 9:11 PM, Tony Lindgren wrote:
> > * Lokesh Vutla [190214 08:39]:
> >> IMHO, device ids are something which can be used in DT. There are many
> >>
failures. Let's also
make sure we warn about possible errors too.
Note that we have twl6040_patch[] reg_sequence with the ACCCTL register
configuration and regcache_sync() will write the new value to ACCCTL.
Cc: Florian Vaussard
Cc: Peter Ujfalusi
Acked-by: Peter Ujfalusi
Signed-off-by: Tony
* Lee Jones [190214 09:21]:
> On Mon, 11 Feb 2019, Tony Lindgren wrote:
> > + ret = regcache_sync(twl6040->regmap);
> > + if (ret) {
> > + dev_err(twl6040->dev, "%s register write failed: %i\n",
> > +
* Roger Quadros [190214 11:09]:
> Suman is mainly concerned about the following changes in v2
> 1) pruss node does not contain reg property representing entire ICSS.
> 2) pruss node does not contain interrupts.
>
> Both of these are required if drivers/uio/uio_pruss.c or in future if
> VFIO is
* Lokesh Vutla [190214 08:40]:
> On 13/02/19 9:02 PM, Tony Lindgren wrote:
> > OK so maybe update the description along those lines saying it's
> > a shared piece of hardware between various independent SoC
> > clusters which may or may not be running Linux.
>
> I
* Lokesh Vutla [190214 08:39]:
> IMHO, device ids are something which can be used in DT. There are many other
> things like the interrupt ranges etc.. which are discoverable from sysfw and
> we
> are implementing it.
We need to describe hardware in the device tree, not firmware.
If you have
* Lokesh Vutla [190212 07:43]:
> With the system coprocessor managing the range allocation of the
> inputs to Interrupt Aggregator, it is difficult to represent
> the device IRQs from DT.
>
> The suggestion is to use MSI in such cases where devices wants
> to allocate and group interrupts
* H. Nikolaus Schaller [190211 18:14]:
>
> > Am 11.02.2019 um 17:20 schrieb Andreas Kemnade :
> >
> > The lcd display of the gta04 has a backlight but the backlight
> > was not referenced in the lcd node, so screen blanking did
> > not turn off the backlight. Fix that.
> >
> > Signed-off-by:
* Lokesh Vutla [190213 04:23]:
> Hi Tony,
>
> On 12/02/19 10:00 PM, Tony Lindgren wrote:
> > Hi,
> >
> > * Lokesh Vutla [190212 07:43]:
> >> +The Interrupt Router (INTR) module provides a mechanism to route M
> >> +interrupt inputs to N interru
* Lokesh Vutla [190213 04:26]:
> Hi Tony,
>
> On 12/02/19 9:52 PM, Tony Lindgren wrote:
> > Hi,
> >
> > * Lokesh Vutla [190212 07:43]:
> >> +Example:
> >> +
> >> +The following example demonstrates both interrupt router node and the
Hi,
* Martyn Welch [190211 04:27]:
> The Bosch Guardian is a TI am335x based device.
>
> It's hardware specifications are as follows:
>
> * 256 MB DDR3 memory
> * 512 MB NAND Flash
> * USB OTG
> * RS232
> * MicroSD external storage
> * LCD Display interface
Thanks applying into
* Christoph Hellwig [190212 07:27]:
> Instead of setting up a kernel pointer to track the current PIO address,
> track the offset in the current page, and do an atomic kmap for the page
> while doing the actual PIO operations.
I'm currently having issues booting my test devices (770 and n8x0)
Hi,
* Lokesh Vutla [190212 07:43]:
> +The Interrupt Router (INTR) module provides a mechanism to route M
> +interrupt inputs to N interrupt outputs, where all M inputs are selectable
> +to be driven per N output. There is one register per output (MUXCNTL_N) that
> +controls the selection.
> +
>
Hi,
* Lokesh Vutla [190212 07:43]:
> +Example:
> +
> +The following example demonstrates both interrupt router node and the
> consumer
> +node(main gpio) on the AM654 SoC:
> +
> +main_intr: interrupt-controller0 {
> + compatible = "ti,sci-intr";
> + interrupt-controller;
> +
Hi,
* Daniel Lezcano [190212 09:08]:
>
> Do you want me to take it through my tree (1 et 3)?
No need to thanks, I already sent a pull request on them
as "[GIT PULL] omap soc regression fixes for v5.0-rc cycle"
with you in Cc.
Regards,
Tony
failures. Let's also
make sure we warn about possible errors too.
Note that we have twl6040_patch[] reg_sequence with the ACCCTL register
configuration and regcache_sync() will write the new value to ACCCTL.
Cc: Florian Vaussard
Cc: Peter Ujfalusi
Signed-off-by: Tony Lindgren
---
drivers/mfd
* Pavel Machek [190207 22:18]:
> Hi!
>
> > > Ok, so I got calls and smses somehow working in kernel ... which
> > > is really all I need.
> >
> > Nice :)
> >
> > I think the SIM card reading and writing should be doable
> > using dlci10 /dev/motmdm10 for AT+CRSM calls..
>
> Might be. Sorry,
* Johan Hovold [190204 08:30]:
> On Fri, Feb 01, 2019 at 08:06:30PM +0100, Andreas Kemnade wrote:
> > On Fri, 1 Feb 2019 11:04:16 +0100
> > Johan Hovold wrote:
> >
> > > On Thu, Jan 31, 2019 at 07:06:40PM +0100, Andreas Kemnade wrote:
> > > > The GTA04 has a w2sg0004 or w2sg0084 gps chip. Not
* Andreas Kemnade [190130 22:24]:
> There is one button and a notifier for incoming phone
> calls/text messages for which we should wakeup from
> suspend.
Applying into omap-for-v5.1/dt thanks.
Tony
* Jonathan Neuschäfer [190129 06:46]:
> There's no need to use an external link when the file is already here.
>
> Signed-off-by: Jonathan Neuschäfer
> ---
>
> Alternatively, I could change the link to https://elixir.bootlin.com
> (the successor of lxr.free-electrons.com), but this solution
* Andreas Kemnade [190206 06:38]:
> But wait... twl4030-power.c is to a big part about switching regulators
> on and off. But how does that connect to hwmods going to ret or off
> mode? That is imho slightly another topic.
The pmic wiring is what must be configured for the regulators
to actually
* Roger Quadros [190205 09:40]:
> On 04/02/19 18:33, Tony Lindgren wrote:
> >
> > shrdram2: memory@1 {
> > device_type = "memory";
> > reg = <0x1 0x3000>;
> > };
>
> Shared RAM is not so straight forw
* Murali Karicheri [190205 16:13]:
> On 02/05/2019 10:41 AM, Roger Quadros wrote:
> > What I'm suggesting here is that kernel remoteproc driver should have
> > nothing to do
> > with the other PRU's data RAM.
> >
> > The application driver if needs both PRUs then it can obviously access both
>
* Lukasz Luba [181113 10:22]:
> Hi Tony,
>
> On 11/8/18 5:59 PM, Tony Lindgren wrote:
> > Hi,
> >
> > * Lukasz Luba [181009 08:36]:
> >> PROVE_LOCKING enables LOCKDEP, which causes big overhead on cache and
> >> bus transactions.
> >>
* Andreas Kemnade [190204 18:33]:
> On Mon, 4 Feb 2019 07:56:04 -0800
> Tony Lindgren wrote:
>
> > * Andreas Kemnade [190202 06:01]:
> > > Enabling off mode was only reachable deeply hidden
> > > in the debugfs. As powersaving is an important feature,
>
* Roger Quadros [190204 14:23]:
> From: "Andrew F. Davis"
>
> The Programmable Real-Time Unit Subsystem (PRUSS) contains an
> interrupt controller (INTC) that can handle various system input
> events and post interrupts back to the device-level initiators.
> The INTC can support upto 64 input
* Roger Quadros [190204 15:54]:
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -167,6 +167,200 @@
> l4_per3: interconnect@4880 {
> };
>
> + pru_icss1: target-module@4b20 {
I suggest you add these into dra7-pruss.dtsi
* Roger Quadros [190204 15:54]:
> +static int sysc_enable_pruss(struct sysc *sysc)
> +{
> + int i;
> + u32 reg;
> + bool ready;
> +
> + /* configure for Smart Idle & Smart Standby */
> + reg = sysc_read(sysc, sysc->offsets[SYSC_SYSCONFIG]);
> + reg &=
ls and host interrupts relies on the mapping configuration
> provided through a firmware resource table for now. This will be
> revisited and enhanced in the future for a better interface. The
> mappings will currently be programmed during the boot/shutdown
> of the PRU.
Acked-by: Tony Lindgren
* Andrew F. Davis [190204 14:52]:
> On 2/4/19 8:22 AM, Roger Quadros wrote:
> > From: Suman Anna
> > +++ b/drivers/soc/ti/Kconfig
> > @@ -73,4 +73,16 @@ config TI_SCI_PM_DOMAINS
> > called ti_sci_pm_domains. Note this is needed early in boot before
> > rootfs may be available.
> >
Hi,
* Roger Quadros [190204 14:23]:
> From: Suman Anna
...
> +Example:
> +
> +1. /* AM33xx PRU-ICSS */
> +
> + pruss: pruss@0 {
> + compatible = "ti,am3356-pruss";
> + reg = <0x0 0x2000>,
> + <0x2000 0x2000>,
> + <0x1
* Andreas Kemnade [190202 06:01]:
> Enabling off mode was only reachable deeply hidden
> in the debugfs. As powersaving is an important feature,
> move the option out of its shady place.
How about let's enable always if we have the twl4030
configured to allow it? You can just check if the dts
* Pavel Machek [190201 20:36]:
> Hi!
>
> Ok, so I got calls and smses somehow working in kernel ... which
> is really all I need.
Nice :)
I think the SIM card reading and writing should be doable
using dlci10 /dev/motmdm10 for AT+CRSM calls..
> I pushed the tree to
* Sebastian Reichel [190129 17:18]:
> Hi,
>
> On Tue, Jan 29, 2019 at 08:48:13AM -0800, Tony Lindgren wrote:
> > Looks like commit 5451781dadf8 ("regulator: core: Only count load for
> > enabled consumers") started showing new warnings with v5.0-rc cycle:
>
* Mark Brown [190129 17:15]:
> On Tue, Jan 29, 2019 at 09:11:51AM -0800, Tony Lindgren wrote:
>
> > OK. Let's see if Sebastian spots where pwm_vibrator_start()
> > and pwm_vibrator_stop() might get called multiple times
> > or something similar.
>
> Given that nobo
* Doug Anderson [190129 17:05]:
> Hi,
>
> On Tue, Jan 29, 2019 at 8:48 AM Tony Lindgren wrote:
> >
> > Hi,
> >
> > Looks like commit 5451781dadf8 ("regulator: core: Only count load for
> > enabled consumers") started showing new warnings with
* Yizhuo [190125 22:32]:
> In function omap4_dsi_mux_pads(), local variable "reg" could
> be uninitialized if function regmap_read() returns -EINVAL.
> However, it will be used directly in the later context, which
> is potentially unsafe.
Thanks applying into omap-for-v5.0/fixes-v2.
Regards,
Hi,
Looks like commit 5451781dadf8 ("regulator: core: Only count load for
enabled consumers") started showing new warnings with v5.0-rc cycle:
regulator-dummy: Underflow of regulator enable count
I'm seeing this at least with my pwm-vibra test case:
# rumble-test
* Keerthy [190129 03:39]:
> On 28/01/19 10:04 PM, Tony Lindgren wrote:
> > Hi,
> >
> > * Randy Dunlap [190126 06:54]:
> >> Hi,
> >>
> >> FYI, I'm seeing this Kconfig warning in 5.0-rc3:
> >
> > Thanks for reporting it.
> >
&
Hi,
* Randy Dunlap [190126 06:54]:
> Hi,
>
> FYI, I'm seeing this Kconfig warning in 5.0-rc3:
Thanks for reporting it.
> WARNING: unmet direct dependencies detected for TI_SOC_THERMAL
> Depends on [n]: THERMAL [=y] && (ARCH_HAS_BANDGAP || COMPILE_TEST [=n]) &&
> HAS_IOMEM [=y]
> Selected
Hi,
* Johan Hovold [190124 16:39]:
> This series adds a new interface (gsm_serdev) but no users, which is not
> something we normally accept. I think you need to post the lot, at least
> as an RFC in order for the full picture to be visible.
Sure I can post them all as RFC series maybe this
* Tero Kristo [190124 19:46]:
> I am not currently publishing -next branch, but I can start tracking one.
Yes please do as the patches should be sitting in
Linux next for at least two weeks before merging.
And there can be often delays of multiple days with
getting patches merged to armsoc next
* Tony Lindgren [190121 17:13]:
> * Felix Brack [190119 17:38]:
> > Hi Tony,
> > On 18.12.18 15:39, Felix Brack wrote:
> > > Remove the unnecessary properties #address-cells and #size-cells
> > > of node pinmux as there are no child-nodes with property reg.
* Heiko Schocher [190121 21:26]:
> Adopt the SPDX license identifier headers to ease license
> compliance management.
Applying into omap-for-v5.1/dt thanks.
Tony
s.
Good to hear this got sorted out, thanks everybody.
Acked-by: Tony Lindgren
* Tony Lindgren [190123 21:57]:
> Hi all,
>
> Commit 412e60373245 ("spi: core: avoid waking pump thread from spi_sync
> instead run teardown delayed") caused a PM regression in Linux next
> where a SPI device (drivers/spi/spi-omap2-mcspi.c) no longer idles
> for
Hi all,
Commit 412e60373245 ("spi: core: avoid waking pump thread from spi_sync
instead run teardown delayed") caused a PM regression in Linux next
where a SPI device (drivers/spi/spi-omap2-mcspi.c) no longer idles
for PM runtime.
Looks like this also breaks suspend as reported at [0].
Regards,
Hi,
* Stephen Rothwell [190123 05:32]:
> Please do not split Fixes tags across more than one line.
OK fine with me.
Regards,
Tony
* Greg Kroah-Hartman [190122 15:23]:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
Acked-by: Tony Lindgren
* Greg Kroah-Hartman [190122 15:23]:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
Acked-by: Tony Lindgren
* Greg Kroah-Hartman [190122 15:23]:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
Acked-by: Tony Lindgren
* Greg Kroah-Hartman [190122 15:22]:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
Acked-by: Tony Lindgren
* Greg Kroah-Hartman [190122 15:28]:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
Acked-by: Tony Lindgren
* Greg Kroah-Hartman [190122 14:41]:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
Acked-by: Tony Lindgren
* Greg Kroah-Hartman [190122 14:41]:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
Acked-by: Tony Lindgren
* Heiko Schocher [190121 21:27]:
> cd pin on mmc1 is GPIO_ACTIVE_LOW not GPIO_ACTIVE_HIGH
Thanks applying into omap-for-v5.0/fixes.
Tony
* Arthur D. [190122 04:59]:
> Signed-off-by: Arthur Demchenkov
Thanks applying into omap-for-v5.0/fixes.
Tony
an Reichel
Cc: Tero Kristo
Cc: Thierry Reding
Cc: Thomas Gleixner
Reported-by: H. Nikolaus Schaller
Signed-off-by: Tony Lindgren
---
arch/arm/boot/dts/omap4-droid4-xt894.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-droid4-xt894.dts
b/arch/arm/b
Cc: Thierry Reding
Cc: Thomas Gleixner
Reported-by: H. Nikolaus Schaller
Signed-off-by: Tony Lindgren
---
drivers/clocksource/timer-ti-dm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/clocksource/timer-ti-dm.c
b/drivers/clocksource/timer-ti-dm.c
--- a/drivers/clocksource
s Gleixner
Reported-by: H. Nikolaus Schaller
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 4 ++--
drivers/clocksource/timer-ti-dm.c | 1 -
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
--- a/drivers/bus/ti-sysc.c
Hi all,
The Pyra handheld PWM LCD regression in v5.0-rc1 reported by Nikolaus
goes back to v4.19 for pwm-omap-dmtimer. Here are patches against v4.19
to fix the issue that also makes pwm-vibra working again for droid 4.
Regards,
Tony
Tony Lindgren (3):
clocksource: timer-ti-dm: Fix pwm
* Fabio Estevam [190121 17:52]:
> On Mon, Jan 21, 2019 at 5:43 AM Arthur Demchenkov wrote:
> >
> > Wrong polarity of card detect GPIO pin leads to the system not
> > booting from external mmc, if the back cover of N900 is closed.
> > When the cover is open the system boots fine.
> >
> > This
WSUP_IDLE))
>
> Changes v3:
> - replace CLK_IS_BASIC
>
> Changes v2:
> - uses spinlocks instead of mutexes
> - invert counter logic
> - check whether clock type is basic
For this series it's best to merge it all via the
clock tree along with the related clock patches:
Acked-by: Tony Lindgren
* Andreas Kemnade [190121 17:54]:
> Hi,
>
> On Mon, 21 Jan 2019 09:07:43 -0800
> Tony Lindgren wrote:
>
> > * Tero Kristo [190121 07:13]:
> > > On 18/01/2019 21:45, Tony Lindgren wrote:
> > > > * Andreas Kemnade [190118 19:39]:
> > > >
* Ulf Hansson [190121 06:41]:
> So, I have put together a debug patch, mostly to verify that things
> seems to be correct in regards to runtime PM. It should produce some
> prints to the log, particular during power on/off of the SDIO card and
> during probe of the wifi driver. Please re-run the
* Felix Brack [190119 17:38]:
> Hi Tony,
> On 18.12.18 15:39, Felix Brack wrote:
> > Remove the unnecessary properties #address-cells and #size-cells
> > of node pinmux as there are no child-nodes with property reg.
> >
> > Signed-off-by: Felix Brack
> > ---
> >
Hi,
* Arthur Demchenkov [190121 03:22]:
> Wrong polarity of card detect GPIO pin leads to the system not
> booting from external mmc, if the back cover of N900 is closed.
> When the cover is open the system boots fine.
>
> This wasn't noticed before, because of a bug, which was fixed
> by
* Tero Kristo [190121 07:13]:
> On 18/01/2019 21:45, Tony Lindgren wrote:
> > * Andreas Kemnade [190118 19:39]:
> > > Hi,
> > >
> > > On Fri, 18 Jan 2019 10:36:30 -0800
> > > Tony Lindgren wrote:
> > >
> > > [...]
> > &
Hi,
* Johan Hovold [190121 10:57]:
> Adding Marcel on CC.
>
> On Fri, Jan 18, 2019 at 12:59:58PM +0100, Greg Kroah-Hartman wrote:
> > On Sun, Jan 13, 2019 at 05:25:25PM -0800, Tony Lindgren wrote:
> > > Hi all,
> > >
> > > Here's a series of patc
* Andreas Kemnade [190118 19:42]:
> On Fri, 18 Jan 2019 20:38:47 +0100
> Andreas Kemnade wrote:
>
> > Hi,
> >
> > On Fri, 18 Jan 2019 10:36:30 -0800
> > Tony Lindgren wrote:
> >
> > [...]
> > > til the next workaround.
> > >
* Andreas Kemnade [190118 19:39]:
> Hi,
>
> On Fri, 18 Jan 2019 10:36:30 -0800
> Tony Lindgren wrote:
>
> [...]
> > til the next workaround.
> >
> > > That flags also causes the iclk being enabled/disabled
> > > manually.
> >
> >
* Andreas Kemnade [190118 17:18]:
> On Fri, 18 Jan 2019 07:48:07 -0800
> Tony Lindgren wrote:
> > * Andreas Kemnade [190116 22:04]:
> > > Deny autoidle for hwmods with the OCPIF_SWSUP_IDLE flag,
> > > that makes hwmods working properly which cannot handle
> >
* Kalle Valo [190118 15:37]:
> Anders Roxell writes:
>
> > On Wed, 16 Jan 2019 at 16:43, Tony Lindgren wrote:
> >>
> >> * Ulf Hansson [190116 11:37]:
> >> > During "wlan-up", we are programming the FW into the WiFi-chip. However,
> >&g
Hi,
* Andreas Kemnade [190116 22:04]:
> Deny autoidle for hwmods with the OCPIF_SWSUP_IDLE flag,
> that makes hwmods working properly which cannot handle
> autoidle properly in lower power states.
Sorry if I'm still missing something :)
But doesn't this now block autoidle for all modules
with
* Ulf Hansson [190118 15:09]:
> On Fri, 18 Jan 2019 at 13:09, Jan Kiszka wrote:
> > Yeah, I'm not claiming at all I know what I'm doing there, just that it
> > happens
> > to work.
>
> I see. Good to know, thanks!
This seems like some separate issue. I wonder if adding
another reset just
* Faiz Abbas [190118 10:54]:
> Tony,
>
> On 16/01/19 9:17 PM, Tony Lindgren wrote:
> > * Thierry Reding [190116 13:28]:
> >> On Tue, Jan 15, 2019 at 05:28:36PM +0100, Thomas Petazzoni wrote:
> >>> The SDHCI core is know properly checking for the state of
Hi,
* min@mediatek.com [190117 07:16]:
> There are some quirk of MediaTek musb controller, such as:
> -W1C interrupt status registers
> -Private data toggle registers
> -No dedicated DMA interrupt line
Can you please separate the musb generic changes listed above
into separate individual
* Pavel Machek [190116 13:48]:
> "quite trivial" does not mix with ofono. I did parts and it is still
> not finished. At the moment, I do not have enough working SIM cards to
> test everything. Feel free to help :-).
I gave it a try but could only see "ofonod[14012]: motmdm init"
on start up.
801 - 900 of 8394 matches
Mail list logo
