Re: [PATCH 14/22] ARM: omap1: use pci_ioremap_io() for omap_cf
* Aaro Koskinen [190828 18:23]: > On Wed, Aug 28, 2019 at 03:02:36PM +0200, Arnd Bergmann wrote: > > I assume you checked that the uart output wasn't already broken > > by one of the earlier patches, right? > > Correct, it's only with the mapping change patch it hangs. > > > Also, looking at arch/arm/mach-omap1/include/mach/uncompress.h > > it seems that SX1 normally uses UART3, not UART1. > > Is that different in qemu? > > In QEMU all uarts can be used, trying with UART3 as early console > hangs as well. (It prints Uncompressing... done. but I guess that's > done with the physical address.) Hmm maybe we now need to get rid of the machine based detection code for DEBUGLL like we did for mach-omap2. Just get rid of arch_decomp_setup() in mach-omap1 uncompress.h file and make sure the assembly code only relies on the the Kconfig options only. That needs to be done at least for device tree based support since we use a generic machine ID. But maybe with multiarch support we need to rely on generic uncompress.h and assembly. Regards, Tony
Re: [PATCH] ARM: OMAP2+: Delete an unnecessary kfree() call in omap_hsmmc_pdata_init()
* Ladislav Michl [190827 18:15]: > On Mon, Aug 26, 2019 at 09:20:50AM -0700, Tony Lindgren wrote: > > * Markus Elfring [190826 06:31]: > > > From: Markus Elfring > > > Date: Mon, 26 Aug 2019 15:05:31 +0200 > > > > > > A null pointer would be passed to a call of the function "kfree" directly > > > after a call of the function "kzalloc" failed at one place. > > > Remove this superfluous function call. > > > > > > This issue was detected by using the Coccinelle software. > > > > Applying into omap-for-v5.4/soc thanks. > > Is it really wise touching almost dead code? Last user is pandora board, so > +Cc: Nikolaus Schaller Yeah would be good to finally get rid of that old code. Anyways, I'll keep the $subject patch to cut down on coccinelle produced issue. Regards, Tony
[PATCH] leds: lm3532: Avoid potentially unpaired regulator calls
We may currently get unpaired regulator calls when configuring the LED
brightness via sysfs in case of regulator calls producing errors. Let's
fix this by maintaining local state for enabled.
Signed-off-by: Tony Lindgren
---
drivers/leds/leds-lm3532.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/leds/leds-lm3532.c b/drivers/leds/leds-lm3532.c
--- a/drivers/leds/leds-lm3532.c
+++ b/drivers/leds/leds-lm3532.c
@@ -127,6 +127,7 @@ struct lm3532_als_data {
* @num_leds - Number of LED strings are supported in this array
* @full_scale_current - The full-scale current setting for the current sink.
* @led_strings - The LED strings supported in this array
+ * @enabled - Enabled status
* @label - LED label
*/
struct lm3532_led {
@@ -138,6 +139,7 @@ struct lm3532_led {
int ctrl_brt_pointer;
int num_leds;
int full_scale_current;
+ int enabled:1;
u32 led_strings[LM3532_MAX_CONTROL_BANKS];
char label[LED_MAX_NAME_SIZE];
};
@@ -292,11 +294,15 @@ static int lm3532_get_ramp_index(int ramp_time)
ramp_time);
}
+/* Caller must take care of locking */
static int lm3532_led_enable(struct lm3532_led *led_data)
{
int ctrl_en_val = BIT(led_data->control_bank);
int ret;
+ if (led_data->enabled)
+ return 0;
+
ret = regmap_update_bits(led_data->priv->regmap, LM3532_REG_ENABLE,
ctrl_en_val, ctrl_en_val);
if (ret) {
@@ -304,14 +310,24 @@ static int lm3532_led_enable(struct lm3532_led *led_data)
return ret;
}
- return regulator_enable(led_data->priv->regulator);
+ ret = regulator_enable(led_data->priv->regulator);
+ if (ret < 0)
+ return ret;
+
+ led_data->enabled = 1;
+
+ return 0;
}
+/* Caller must take care of locking */
static int lm3532_led_disable(struct lm3532_led *led_data)
{
int ctrl_en_val = BIT(led_data->control_bank);
int ret;
+ if (!led_data->enabled)
+ return 0;
+
ret = regmap_update_bits(led_data->priv->regmap, LM3532_REG_ENABLE,
ctrl_en_val, 0);
if (ret) {
@@ -319,7 +335,13 @@ static int lm3532_led_disable(struct lm3532_led *led_data)
return ret;
}
- return regulator_disable(led_data->priv->regulator);
+ ret = regulator_disable(led_data->priv->regulator);
+ if (ret < 0)
+ return ret;
+
+ led_data->enabled = 0;
+
+ return 0;
}
static int lm3532_brightness_set(struct led_classdev *led_cdev,
--
2.23.0
Re: [PATCH v3 1/5] leds: lm3532: Fix brightness control for i2c mode
* Dan Murphy [190827 16:20]:
> Tony
>
> On 8/27/19 11:04 AM, Tony Lindgren wrote:
> > * Dan Murphy [190827 13:02]:
> > > Hello
> > >
> > > On 8/27/19 7:44 AM, Dan Murphy wrote:
> > > > Tony
> > > >
> > > > On 8/27/19 7:18 AM, Pavel Machek wrote:
> > > > > On Mon 2019-08-26 15:44:37, Tony Lindgren wrote:
> > > > > > * Pavel Machek [190826 22:14]:
> > > > > > > On Mon 2019-08-26 14:58:22, Tony Lindgren wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > * Dan Murphy [190820 19:53]:
> > > > > > > > > Fix the brightness control for I2C mode. Instead of
> > > > > > > > > changing the full scale current register update the ALS target
> > > > > > > > > register for the appropriate banks.
> > > > > > > > >
> > > > > > > > > In addition clean up some code errors and random misspellings
> > > > > > > > > found
> > > > > > > > > during coding.
> > > > > > > > >
> > > > > > > > > Tested on Droid4 as well as LM3532 EVM connected to
> > > > > > > > > a BeagleBoneBlack
> > > > > > > > >
> > > > > > > > > Fixes: e37a7f8d77e1 ("leds: lm3532: Introduce the
> > > > > > > > > lm3532 LED driver")
> > > > > > > > > Reported-by: Pavel Machek
> > > > > > > > > Signed-off-by: Dan Murphy
> > > > > > > > > ---
> > > > > > > > >
> > > > > > > > > v3 - Removed register define updates -
> > > > > > > > > https://lore.kernel.org/patchwork/patch/1114542/
> > > > > > > > Looks like starting with this patch in Linux next the LCD on
> > > > > > > > droid4
> > > > > > > > is so dim it's unreadable even with brightness set to 255.
> > > > > > > > Setting
> > > > > > > > brightness to 0 does blank it completely though.
> > > > > > > >
> > > > > > > > Did something maybe break with the various patch revisions or
> > > > > > > > are
> > > > > > > > we now missing some dts patch?
> > > > > > > Maybe missing dts patch. We should provide maximum current the
> > > > > > > LED can
> > > > > > > handle...
> > > > > > Or i2c control is somehow broken and only als control now works?
> > > > With only setting CONFIG_LEDS_LM3532=m to the next branch I get full
> > > > brightness with 255.
> > > >
> > > > I also see half brightness at 128 with the ramp down working.
> > > >
> > > > I am not able to reproduce this issue on my device.
> > > >
> > > Just to make sure my data was right I did a clean rebuild on commit
> > > 1dbb9fb4082ce2a2f1cf9596881ddece062d15d0
> > >
> > > from the led-next branch.
> > >
> > > Just adding the above config flag. I still cannot reproduce the issue
> > >
> > > See attached pic
> > OK thanks for checking. Probably you can reproduce the issue if you
> > reset things to commit c4b8354e5341 ("leds: lm3532: Fix brightness
> > control for i2c mode"). There might now be something uninitialized
> > with that commit depending on the hardware state on boot if you
> > care to check that. Or maybe there's some interaction with other
> > patches not yet at commit c4b8354e5341 level.
>
> Ok the fix for that issue is in this patch
>
> leds: lm3532: Fixes for the driver for stability
>
> The fix for setting the brightness control register during the init forced
> the ALS mode to
>
> be enabled. The Fixes for driver stability patch then set the led->mode to
> the correct register setting.
OK yeah so that part starts to make sense now. I wonder if the reason
for my issues was caused by change in sysfs brightness level values
and I ended up chasing an already fixed issue. I think I was using
value of 30 recently, which is now very dim :)
> > I confirmed again that things fail at commit c4b8354e5341. But
> > now testing with the same Linux next as yesterday things works again.
> > Not sure what's going on as failures with Linux next yestreday
> > made me start narrowing down what commit causes the issues.
> >
> > Anyways, playing with loading and unloading the leds-lm3532.ko I
> > noticed we can also have unpaired regulator calls when using sysfs
> > brightness that the below patch attempts to fix. Not sure how I got
> > to the point of regulator warnings, but I was trying to enable
> > the brightness via sysfs. Maybe I had other patches too when
> > I got the regulator warnings.. But please check if the below
> > patch makes sense.
>
> Makes sense did you want me to push a patch?
No need to, I can send out a proper patch later today after typing up
the patch description if no other comments.
Regards,
Tony
Re: [PATCH v3 1/5] leds: lm3532: Fix brightness control for i2c mode
* Dan Murphy [190827 13:02]:
> Hello
>
> On 8/27/19 7:44 AM, Dan Murphy wrote:
> > Tony
> >
> > On 8/27/19 7:18 AM, Pavel Machek wrote:
> > > On Mon 2019-08-26 15:44:37, Tony Lindgren wrote:
> > > > * Pavel Machek [190826 22:14]:
> > > > > On Mon 2019-08-26 14:58:22, Tony Lindgren wrote:
> > > > > > Hi,
> > > > > >
> > > > > > * Dan Murphy [190820 19:53]:
> > > > > > > Fix the brightness control for I2C mode. Instead of
> > > > > > > changing the full scale current register update the ALS target
> > > > > > > register for the appropriate banks.
> > > > > > >
> > > > > > > In addition clean up some code errors and random misspellings
> > > > > > > found
> > > > > > > during coding.
> > > > > > >
> > > > > > > Tested on Droid4 as well as LM3532 EVM connected to
> > > > > > > a BeagleBoneBlack
> > > > > > >
> > > > > > > Fixes: e37a7f8d77e1 ("leds: lm3532: Introduce the
> > > > > > > lm3532 LED driver")
> > > > > > > Reported-by: Pavel Machek
> > > > > > > Signed-off-by: Dan Murphy
> > > > > > > ---
> > > > > > >
> > > > > > > v3 - Removed register define updates -
> > > > > > > https://lore.kernel.org/patchwork/patch/1114542/
> > > > > > Looks like starting with this patch in Linux next the LCD on droid4
> > > > > > is so dim it's unreadable even with brightness set to 255. Setting
> > > > > > brightness to 0 does blank it completely though.
> > > > > >
> > > > > > Did something maybe break with the various patch revisions or are
> > > > > > we now missing some dts patch?
> > > > > Maybe missing dts patch. We should provide maximum current the LED can
> > > > > handle...
> > > > Or i2c control is somehow broken and only als control now works?
> >
> > With only setting CONFIG_LEDS_LM3532=m to the next branch I get full
> > brightness with 255.
> >
> > I also see half brightness at 128 with the ramp down working.
> >
> > I am not able to reproduce this issue on my device.
> >
> Just to make sure my data was right I did a clean rebuild on commit
> 1dbb9fb4082ce2a2f1cf9596881ddece062d15d0
>
> from the led-next branch.
>
> Just adding the above config flag. I still cannot reproduce the issue
>
> See attached pic
OK thanks for checking. Probably you can reproduce the issue if you
reset things to commit c4b8354e5341 ("leds: lm3532: Fix brightness
control for i2c mode"). There might now be something uninitialized
with that commit depending on the hardware state on boot if you
care to check that. Or maybe there's some interaction with other
patches not yet at commit c4b8354e5341 level.
I confirmed again that things fail at commit c4b8354e5341. But
now testing with the same Linux next as yesterday things works again.
Not sure what's going on as failures with Linux next yestreday
made me start narrowing down what commit causes the issues.
Anyways, playing with loading and unloading the leds-lm3532.ko I
noticed we can also have unpaired regulator calls when using sysfs
brightness that the below patch attempts to fix. Not sure how I got
to the point of regulator warnings, but I was trying to enable
the brightness via sysfs. Maybe I had other patches too when
I got the regulator warnings.. But please check if the below
patch makes sense.
Regards,
Tony
8< ---
diff --git a/drivers/leds/leds-lm3532.c b/drivers/leds/leds-lm3532.c
--- a/drivers/leds/leds-lm3532.c
+++ b/drivers/leds/leds-lm3532.c
@@ -127,6 +127,7 @@ struct lm3532_als_data {
* @num_leds - Number of LED strings are supported in this array
* @full_scale_current - The full-scale current setting for the current sink.
* @led_strings - The LED strings supported in this array
+ * @enabled - Enabled status
* @label - LED label
*/
struct lm3532_led {
@@ -138,6 +139,7 @@ struct lm3532_led {
int ctrl_brt_pointer;
int num_leds;
int full_scale_current;
+ int enabled:1;
u32 led_strings[LM3532_MAX_CONTROL_BANKS];
char label[LED_MAX_NAME_SIZE];
};
@@ -292,11 +294,15 @@ static int lm3532_get_ramp_index(int ramp_time)
ramp_time);
}
+/* Caller must take care of locking */
static int lm3532_led_enable(struct lm3532_led *led_data)
{
int ctrl_en_val = BIT(led_data-
Re: [PATCH v3 1/5] leds: lm3532: Fix brightness control for i2c mode
* Pavel Machek [190826 22:14]:
> On Mon 2019-08-26 14:58:22, Tony Lindgren wrote:
> > Hi,
> >
> > * Dan Murphy [190820 19:53]:
> > > Fix the brightness control for I2C mode. Instead of
> > > changing the full scale current register update the ALS target
> > > register for the appropriate banks.
> > >
> > > In addition clean up some code errors and random misspellings found
> > > during coding.
> > >
> > > Tested on Droid4 as well as LM3532 EVM connected to a BeagleBoneBlack
> > >
> > > Fixes: e37a7f8d77e1 ("leds: lm3532: Introduce the lm3532 LED driver")
> > > Reported-by: Pavel Machek
> > > Signed-off-by: Dan Murphy
> > > ---
> > >
> > > v3 - Removed register define updates -
> > > https://lore.kernel.org/patchwork/patch/1114542/
> >
> > Looks like starting with this patch in Linux next the LCD on droid4
> > is so dim it's unreadable even with brightness set to 255. Setting
> > brightness to 0 does blank it completely though.
> >
> > Did something maybe break with the various patch revisions or are
> > we now missing some dts patch?
>
> Maybe missing dts patch. We should provide maximum current the LED can
> handle...
Or i2c control is somehow broken and only als control now works?
Regards,
Tony
Re: [PATCH v3 1/5] leds: lm3532: Fix brightness control for i2c mode
Hi,
* Dan Murphy [190820 19:53]:
> Fix the brightness control for I2C mode. Instead of
> changing the full scale current register update the ALS target
> register for the appropriate banks.
>
> In addition clean up some code errors and random misspellings found
> during coding.
>
> Tested on Droid4 as well as LM3532 EVM connected to a BeagleBoneBlack
>
> Fixes: e37a7f8d77e1 ("leds: lm3532: Introduce the lm3532 LED driver")
> Reported-by: Pavel Machek
> Signed-off-by: Dan Murphy
> ---
>
> v3 - Removed register define updates -
> https://lore.kernel.org/patchwork/patch/1114542/
Looks like starting with this patch in Linux next the LCD on droid4
is so dim it's unreadable even with brightness set to 255. Setting
brightness to 0 does blank it completely though.
Did something maybe break with the various patch revisions or are
we now missing some dts patch?
Regards,
Tony
Re: [PATCH] ARM: OMAP2+: Delete an unnecessary kfree() call in omap_hsmmc_pdata_init()
* Markus Elfring [190826 06:31]: > From: Markus Elfring > Date: Mon, 26 Aug 2019 15:05:31 +0200 > > A null pointer would be passed to a call of the function "kfree" directly > after a call of the function "kzalloc" failed at one place. > Remove this superfluous function call. > > This issue was detected by using the Coccinelle software. Applying into omap-for-v5.4/soc thanks. Tony
Re: [PATCH] ARM: omap2: move platform-specific asm-offset.h to arch/arm/mach-omap2
* Masahiro Yamada [190822 19:59]: > is only generated and included by > arch/arm/mach-omap2/, so it does not need to reside in the globally > visible include/generated/. > > I renamed it to arch/arm/mach-omap2/pm-asm-offsets.h since the prefix > 'ti-' is just redundant in mach-omap2/. > > My main motivation of this change is to avoid the race condition for > the parallel build (-j) when CONFIG_IKHEADERS is enabled. > > When it is enabled, all the headers under include/ are archived into > kernel/kheaders_data.tar.xz and exposed in the sysfs. > > In the parallel build, we have no idea in which order files are built. > > - If ti-pm-asm-offsets.h is built before kheaders_data.tar.xz, >the header will be included in the archive. Probably nobody will >use it, but it is harmless except that it will increase the archive >size needlessly. > > - If kheaders_data.tar.xz is built before ti-pm-asm-offsets.h, >the header will not be included in the archive. However, in the next >build, the archive will be re-generated to include the newly-found >ti-pm-asm-offsets.h. This is not nice from the build system point >of view. > > - If ti-pm-asm-offsets.h and kheaders_data.tar.xz are built at the >same time, the corrupted header might be included in the archive, >which does not look nice either. > > This commit fixes the race. > > Signed-off-by: Masahiro Yamada > Tested-by: Keerthy Applying into omap-for-v5.4/soc thanks. The commit is on top of v5.3-rc1 so it can be merged into other branches if needed after it's been sitting in Linux next for few days with no issues. Regards, Tony
Re: [PATCH v4] bus: ti-sysc: Change return types of functions
* Roger Quadros [190815 13:03]: > On 15/08/2019 08:46, Nishka Dasgupta wrote: > > Change return type of functions sysc_check_one_child() and > > sysc_check_children() from int to void as neither ever returns an error. > > Modify call sites of both functions accordingly. > > > > Signed-off-by: Nishka Dasgupta > > Acked-by: Roger Quadros Applying into omap-for-v5.4/ti-sysc thanks. Tony
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
* Adam Ford [190819 19:26]: > On Sat, Aug 17, 2019 at 2:03 AM Tony Lindgren wrote: > > > > * Adam Ford [190816 23:02]: > > > On Wed, Aug 14, 2019 at 8:16 AM Tony Lindgren wrote: > > > > Well I just posted some sgx interconnect target module patches. We might > > > > still have them in v5.4 assuming people manage to review and test them. > > > > > > Nikolaus, > > > > > > I tested Tony's change and I can confirm that I can read the value > > > when enabled. Should I apply his patches to your branch before I > > > test, or is it go too to go as-is? I've got an AM3517, OMAP35 and a > > > DM3730. I am not sure if the AM3517 is even on the radar, but it has > > > an sgx530 as well. > > > > My estimate is am3517 is wired the same way as omap34xx with a 60% > > chance, then 30% chance it's wired the same way as omap36xx, and then > > 10% chance for similar wiring to am335x.. So hopefully that leaves 0% > > chance for yet something different for it's wiring :) > > Based on [1], I went under the assumption it was wired like the > omap34xx. I applied your omap34 patches to the am3517.dtsi, and I was > able to get the same response as I did for the omap3530. Do you want > me to post the patches to the mailing list, or do you want to do it? OK great, yeah please post patches :) Thanks, TOny
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
* Adam Ford [190816 23:02]: > On Wed, Aug 14, 2019 at 8:16 AM Tony Lindgren wrote: > > Well I just posted some sgx interconnect target module patches. We might > > still have them in v5.4 assuming people manage to review and test them. > > Nikolaus, > > I tested Tony's change and I can confirm that I can read the value > when enabled. Should I apply his patches to your branch before I > test, or is it go too to go as-is? I've got an AM3517, OMAP35 and a > DM3730. I am not sure if the AM3517 is even on the radar, but it has > an sgx530 as well. My estimate is am3517 is wired the same way as omap34xx with a 60% chance, then 30% chance it's wired the same way as omap36xx, and then 10% chance for similar wiring to am335x.. So hopefully that leaves 0% chance for yet something different for it's wiring :) If you have a chance please give it a try. Also check the TRM for the sgx sysconfig register bits to see which of the above matches, and if 3517 has a related rstctrl register like am335x has. Regards, Tony
Re: [PATCH 14/22] ARM: omap1: use pci_ioremap_io() for omap_cf
* Arnd Bergmann [190814 10:37]: > On Wed, Aug 14, 2019 at 9:49 AM Tony Lindgren wrote: > > * Arnd Bergmann [190813 19:34]: > > > On Tue, Aug 13, 2019 at 8:12 PM Aaro Koskinen > > > wrote: > > > diff --git a/arch/arm/mach-omap1/hardware.h > > > b/arch/arm/mach-omap1/hardware.h > > > index 232b8deef907..9fc76a3c9e57 100644 > > > --- a/arch/arm/mach-omap1/hardware.h > > > +++ b/arch/arm/mach-omap1/hardware.h > > > @@ -61,7 +61,7 @@ static inline u32 omap_cs3_phys(void) > > > > > > #endif /* ifndef __ASSEMBLER__ */ > > > > > > -#define OMAP1_IO_OFFSET0x0100 /* Virtual IO > > > = 0xfefb */ > > > +#define OMAP1_IO_OFFSET0x00fb /* Virtual IO > > > = 0xff00 */ > > > #define OMAP1_IO_ADDRESS(pa) IOMEM((pa) - OMAP1_IO_OFFSET) > > > > > > #include "serial.h" > > > > Oh OK yeah sounds like that's the issue. > > > > > There may be additional locations that hardcode the virtual address. > > > > Those should be in mach-omap1/io.c, and I recall innovator had some > > hardcoded fpga address that should also be checked. > > I see four boards with hardcoded I/O addresses, but they are all below > the PCI I/O virtual address range, and are not affected by that change. > > For the innovator FPGA access, this was ok, it uses the correct address > in the OMAP1_IO_OFFSET range. OK thanks for checking. I tried to apply your virtual address patch to test boot it, but could not get it to apply. What tree is it against? Regards, Tony
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
* H. Nikolaus Schaller [190814 10:34]: > > > Am 14.08.2019 um 11:47 schrieb Tony Lindgren : > > > > * H. Nikolaus Schaller [190814 08:57]: > >> I also have pushed good news to > >> > >>https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr > >> > >> Thanks to the help from the Pyra community, I was able to get a (binary) > >> reference > >> implementation using DRM that works on Pyra/OMAP5. At least the gles1test1. > >> > >> With that reference setup I was able to fix my Makefiles for the > >> staging/pvr implementation. > >> > >> I have tested that it works with v4.19.66 and v5.3-rc4 (LPAE build of the > >> LetuxOS kernel tree) > >> on the Pyra. > >> > >> In which areas does this tree go beyond the TI SDK/IMG DDK 1.14? > >> > >> * includes internal API fixes for kernels up to v5.3 > >> * lives in drivers/staging/pvr/1.14.3699939 - so that we can ask for > >> inclusion in linux-next > >> * has Kconfig and Makefiles for in-kernel configuration (no separate build > >> system) > >> * builds separate kernel modules for omap3430, omap3630, am335x, omap4, > >> omap5, dra7 etc. > >> pvrsrvkm > >> e.g. pvrsrvkm_omap_omap5_sgx544_116 > >> * the correct kernel module is automatically probed by matching > >> .compatible in device tree > >> so that the code is multi-platform friendly > >> * includes SoC integration for OMAP3/4/5 and has some preliminary bindings > >> documentation > >> * code base should also support JZ4780/CI20 and some Intel Atom processors > >> (CedarView, Poulsbo) > >> * has got a ToDo to describe what should be done during staging phase > >> > >> > >> https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/latest-pvr/drivers/staging/pvr/TODO > >> > >> My plans for the next steps are: > >> > >> * do more testing (e.g. X11, kmscube) > >> * check if and/or how it can run on am335x (BeagleBone) or OMAP3 (e.g. > >> GTA04, OpenPandora) > >> * try a JZ480/CI20 build (unfortuantely I have no HDMI there with mainline > >> kernels and I am > >> missing the user-space libraries for MIPS). > > > > That sounds good to me, just one comment. Before getting these into > > staging, I'd like to have omap variants use proper interconnect > > target module in devicetree like we already have in omap4.dtsi > > as target-module@5600. This should simplify things further > > as the module child device driver(s) can just enable things with > > runtime PM and we can leave out all the legacy hwmod platform data > > that sounds like you're still carrying. > > Yes, there is still a lot of SoC-glue included: > > > https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/commits/letux/omap-pvr-soc-glue > > It would indeed be a good move to simplify and reduce the glue code > and make it more maintainable / stable / identical on different platforms. OK yeah all that should just disappear :) > > I have patches here to add similar interconnect target modules for > > at least omap34xx, omap36xx, omap5, and am335x that I'll try to post > > later on today to play with. For am335x, things still depend on the > > recentely posted prm rstctrl patches. I'm not sure if I already > > did a dts patch for dra7 yet, need to check. > > I assume it is not yet in linux-next... So something for v5.5 or later. Well I just posted some sgx interconnect target module patches. We might still have them in v5.4 assuming people manage to review and test them. Regards, Tony
Re: Lay common foundation to make PVR/SGX work without hacks on OMAP34xx, OMAP36xx, AM335x and potentially OMAP4, OMAP5
* H. Nikolaus Schaller [190814 08:57]: > I also have pushed good news to > > https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux-pvr > > Thanks to the help from the Pyra community, I was able to get a (binary) > reference > implementation using DRM that works on Pyra/OMAP5. At least the gles1test1. > > With that reference setup I was able to fix my Makefiles for the staging/pvr > implementation. > > I have tested that it works with v4.19.66 and v5.3-rc4 (LPAE build of the > LetuxOS kernel tree) > on the Pyra. > > In which areas does this tree go beyond the TI SDK/IMG DDK 1.14? > > * includes internal API fixes for kernels up to v5.3 > * lives in drivers/staging/pvr/1.14.3699939 - so that we can ask for > inclusion in linux-next > * has Kconfig and Makefiles for in-kernel configuration (no separate build > system) > * builds separate kernel modules for omap3430, omap3630, am335x, omap4, > omap5, dra7 etc. > pvrsrvkm > e.g. pvrsrvkm_omap_omap5_sgx544_116 > * the correct kernel module is automatically probed by matching .compatible > in device tree > so that the code is multi-platform friendly > * includes SoC integration for OMAP3/4/5 and has some preliminary bindings > documentation > * code base should also support JZ4780/CI20 and some Intel Atom processors > (CedarView, Poulsbo) > * has got a ToDo to describe what should be done during staging phase > > > https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/blob/letux/latest-pvr/drivers/staging/pvr/TODO > > My plans for the next steps are: > > * do more testing (e.g. X11, kmscube) > * check if and/or how it can run on am335x (BeagleBone) or OMAP3 (e.g. GTA04, > OpenPandora) > * try a JZ480/CI20 build (unfortuantely I have no HDMI there with mainline > kernels and I am > missing the user-space libraries for MIPS). That sounds good to me, just one comment. Before getting these into staging, I'd like to have omap variants use proper interconnect target module in devicetree like we already have in omap4.dtsi as target-module@5600. This should simplify things further as the module child device driver(s) can just enable things with runtime PM and we can leave out all the legacy hwmod platform data that sounds like you're still carrying. I have patches here to add similar interconnect target modules for at least omap34xx, omap36xx, omap5, and am335x that I'll try to post later on today to play with. For am335x, things still depend on the recentely posted prm rstctrl patches. I'm not sure if I already did a dts patch for dra7 yet, need to check. Regards, Tony
Re: "PM / wakeup: Show wakeup sources stats in sysfs" causes boot warnings
* Stephen Boyd [691231 23:00]: > I also notice that device_set_wakeup_capable() has a check to see if the > device is registered yet and it skips creating sysfs entries for the > device if it isn't created in sysfs yet. Why? Just so it can be called > before the device is created? I guess the same logic is handled by > dpm_sysfs_add() if the device is registered after calling > device_set_wakeup_*(). Hmm just guessing.. It's maybe because drivers can enable and disable the wakeup capability at any point for example like driver/net drivers do based on WOL etc? > There's two approaches I see: > > 1) Do a similar check for device_set_wakeup_enable() and skip > adding the wakeup class until dpm_sysfs_add(). > > 2) Find each case where this happens and only call wakeup APIs > on the device after the device is added. > > I guess it's better to let devices have wakeup modified on them before > they're registered with the device core? I think we should at least initially handle case #1 above as multiple places otherwise seem to break. Then maybe we could add a warning to help fix all the #2 cases if needed? Regards, Tony
Re: [PATCH 14/22] ARM: omap1: use pci_ioremap_io() for omap_cf
* Arnd Bergmann [190813 19:34]: > On Tue, Aug 13, 2019 at 8:12 PM Aaro Koskinen wrote: > > On Tue, Aug 13, 2019 at 01:02:16PM +0200, Arnd Bergmann wrote: > > > On Tue, Aug 13, 2019 at 12:36 PM Tony Lindgren wrote: > > > > > - I force CONFIG_PCI to be enabled here in order to keep the > > > asm/io.h logic unchanged. If PCI support in itself is an issue, > > > then turning on CONFIG_PCI without the rest of this patch > > > should also break. > > > > The board dies early, probably in pci_reserve_io(): > > > > Starting kernel ... > > > > [0.00] Booting Linux on physical CPU 0x0 > > [0.00] Linux version 5.3.0-rc4-osk-los_80efa+-00028-g09f6f22a63e9 > > (aaro@amd-fx-6350) (gcc version 8.3.0 (GCC)) #1 Tue Aug 13 20:50:11 EEST > > 2019 > > [0.00] CPU: ARM926EJ-S [41069263] revision 3 (ARMv5TEJ), cr=0005317f > > [0.00] CPU: VIVT data cache, VIVT instruction cache > > [0.00] Machine: TI-OSK > > [0.00] Ignoring tag cmdline (using the default kernel command line) > > [0.00] printk: bootconsole [earlycon0] enabled > > [0.00] Memory policy: Data cache writeback > > [0.00] Internal error: Oops - undefined instruction: 0 [#1] ARM > > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted > > 5.3.0-rc4-osk-los_80efa+-00028-g09f6f22a63e9 #1 > > [0.00] Hardware name: TI-OSK > > [0.00] PC is at vm_area_add_early+0x1c/0x74 > > That sounds like an address conflict in the virtual addres space. > > In multiplatform kernels, PCI I/O space is hardwired to addresses > 0xfee0-0xfeff, > which happened to be available on all the other machines that needed it so > far. > > OMAP1_IO_VIRT is 0xfefb-0xfefe, which clearly overlaps with the end of > the PCI I/O area. > > We only really need 4KB of I/O space rather than the full 2MB, but it > would also be > good not to make this too machine specific. > > Could we change OMAP1_IO_OFFSET to stay out of that area? Something like > > diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug > index 97c114c1ef80..3b66d203dc98 100644 > --- a/arch/arm/Kconfig.debug > +++ b/arch/arm/Kconfig.debug > @@ -1794,9 +1794,9 @@ config DEBUG_UART_VIRT > default 0xfef0 if ARCH_IXP4XX && !CPU_BIG_ENDIAN > default 0xfef3 if ARCH_IXP4XX && CPU_BIG_ENDIAN > default 0xfef36000 if DEBUG_HIGHBANK_UART > - default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 > - default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 > - default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 > + default 0xff00 if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 > + default 0xff000800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 > + default 0xff009800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 > default 0xff003000 if DEBUG_U300_UART > default 0xffd01000 if DEBUG_HIP01_UART > default DEBUG_UART_PHYS if !MMU > diff --git a/arch/arm/mach-omap1/hardware.h b/arch/arm/mach-omap1/hardware.h > index 232b8deef907..9fc76a3c9e57 100644 > --- a/arch/arm/mach-omap1/hardware.h > +++ b/arch/arm/mach-omap1/hardware.h > @@ -61,7 +61,7 @@ static inline u32 omap_cs3_phys(void) > > #endif /* ifndef __ASSEMBLER__ */ > > -#define OMAP1_IO_OFFSET0x0100 /* Virtual IO > = 0xfefb */ > +#define OMAP1_IO_OFFSET0x00fb /* Virtual IO > = 0xff00 */ > #define OMAP1_IO_ADDRESS(pa) IOMEM((pa) - OMAP1_IO_OFFSET) > > #include "serial.h" Oh OK yeah sounds like that's the issue. > There may be additional locations that hardcode the virtual address. Those should be in mach-omap1/io.c, and I recall innovator had some hardcoded fpga address that should also be checked. Regards, Tony
Re: Regression in Linux next with show wakeup sources stats in sysfs
* Stephen Boyd [190814 07:09]:
> Quoting Tony Lindgren (2019-08-13 23:38:03)
> > Hi all,
> >
> > Looks like commit 986845e747af ("PM / wakeup: Show wakeup sources stats
> > in sysfs") has caused a regression in Linux next where I can now get
> > some errors like this during the boot:
> >
> > kobject_add_internal failed for wakeup10 (error: -2 parent: usb)
> >
> > Any ideas why this might be happening? Maybe some deferred probe
> > related issue?
> >
>
> Yeah! Take a look at this thread[1] and please test out patches I'm
> throwing out there like a total cowboy(d).
>
> [1] https://lkml.kernel.org/r/1565731976.8572.16.ca...@lca.pw
Oh OK thanks, looks like I'm a bit behind then. My test case turned
out to be caused by device_init_wakeup() called before device_add() for
power_supply in case that helps. In that case create_dir() will fail
for kobject_add_internal(). Doing something like below fixes the
issue, but seems like we probably have other similar issues as well.
Adding Sebastian to Cc in case this might be a real problem despite
the other issues.
Regards,
Tony
8< ---
diff --git a/drivers/power/supply/power_supply_core.c
b/drivers/power/supply/power_supply_core.c
--- a/drivers/power/supply/power_supply_core.c
+++ b/drivers/power/supply/power_supply_core.c
@@ -1051,14 +1051,14 @@ __power_supply_register(struct device *parent,
}
spin_lock_init(&psy->changed_lock);
- rc = device_init_wakeup(dev, ws);
- if (rc)
- goto wakeup_init_failed;
-
rc = device_add(dev);
if (rc)
goto device_add_failed;
+ rc = device_init_wakeup(dev, ws);
+ if (rc)
+ goto wakeup_init_failed;
+
rc = psy_register_thermal(psy);
if (rc)
goto register_thermal_failed;
@@ -1100,9 +1100,9 @@ __power_supply_register(struct device *parent,
register_cooler_failed:
psy_unregister_thermal(psy);
register_thermal_failed:
+wakeup_init_failed:
device_del(dev);
device_add_failed:
-wakeup_init_failed:
check_supplies_failed:
dev_set_name_failed:
put_device(dev);
Regression in Linux next with show wakeup sources stats in sysfs
Hi all,
Looks like commit 986845e747af ("PM / wakeup: Show wakeup sources stats
in sysfs") has caused a regression in Linux next where I can now get
some errors like this during the boot:
kobject_add_internal failed for wakeup10 (error: -2 parent: usb)
Any ideas why this might be happening? Maybe some deferred probe
related issue?
Regards,
Tony
Re: [PATCH -next] soc: ti: pm33xx: Make two symbols static
* Yue Haibing [190413 07:13]: > From: YueHaibing > > Fix sparse warnings: > > drivers/soc/ti/pm33xx.c:144:27: warning: symbol 'rtc_wake_src' was not > declared. Should it be static? > drivers/soc/ti/pm33xx.c:160:5: warning: symbol 'am33xx_rtc_only_idle' was not > declared. Should it be static? Applying into fixes thanks. Tony
Re: [PATCH] soc: ti: pm33xx: Fix static checker warnings
* Keerthy [190626 00:50]: > The patch fixes a bunch of static checker warnings. Sorry I just noticed that this one is still pending, applying into fixes. Tony
Re: [PATCH] ARM: OMAP: dma: Mark expected switch fall-throughs
* Kees Cook [190729 16:35]:
> On Sun, Jul 28, 2019 at 06:22:40PM -0500, Gustavo A. R. Silva wrote:
> > Mark switch cases where we are expecting to fall through.
> >
> > This patch fixes the following warnings:
> >
> > arch/arm/plat-omap/dma.c: In function 'omap_set_dma_src_burst_mode':
> > arch/arm/plat-omap/dma.c:384:6: warning: this statement may fall through
> > [-Wimplicit-fallthrough=]
> >if (dma_omap2plus()) {
> > ^
> > arch/arm/plat-omap/dma.c:393:2: note: here
> > case OMAP_DMA_DATA_BURST_16:
> > ^~~~
> > arch/arm/plat-omap/dma.c:394:6: warning: this statement may fall through
> > [-Wimplicit-fallthrough=]
> >if (dma_omap2plus()) {
> > ^
> > arch/arm/plat-omap/dma.c:402:2: note: here
> > default:
> > ^~~
> > arch/arm/plat-omap/dma.c: In function 'omap_set_dma_dest_burst_mode':
> > arch/arm/plat-omap/dma.c:473:6: warning: this statement may fall through
> > [-Wimplicit-fallthrough=]
> >if (dma_omap2plus()) {
> > ^
> > arch/arm/plat-omap/dma.c:481:2: note: here
> > default:
> > ^~~
> >
> > Notice that, in this particular case, the code comment is
> > modified in accordance with what GCC is expecting to find.
> >
> > Reported-by: Stephen Rothwell
> > Signed-off-by: Gustavo A. R. Silva
>
> Reviewed-by: Kees Cook
Applying into fixes thanks.
Tony
Re: [PATCH v2] ARM: dts: am335x-boneblue: Use of am335x-osd335x-common.dtsi
* David Lechner [190807 13:10]: > This makes use of the am335x-osd335x-common.dtsi file that contains the > common device tree components for Octavo Systems AM335x System-in- > Package that is used on the BeagleBone Blue. > > This has two minor side-effects: > 1. pinmux_i2c0_pins is renamed to pinmux-i2c0-pins > 2. the 1000MHz cpufreq operating point is enabled Applying into omap-for-v5.4/dt thanks. Tony
Re: [PATCH 1/2] DTS: ARM: gta04: define chosen/stdout-path
* H. Nikolaus Schaller [190708 14:46]: > This allows to remove the console= entry in the kernel command line. Applying this patch into omap-for-v5.4/dt thanks. Tony
Re: [PATCH v3 2/2] bus: ti-sysc: sysc_check_children(): Change return type to void
* Roger Quadros [190813 11:14]: > > On 13/08/2019 10:55, Nishka Dasgupta wrote: > > Change return type of function sysc_check_children() from int to void as > > it always returns 0. Remove its return statement as well. > > At call site, remove the variable that was used to store the return > > value, as well as the check on the return value. > > > > You don't need to describe each and everything as it is obvious > from code. How about? > "Change return type of sysc_check_children() to "void" > as it never returns error" > > Should both patches can be squashed into one patch? Sure why not, makes it easier to follow :) Regards, Tony
Re: [PATCH -next] bus: ti-sysc: remove set but not used variable 'quirks'
* YueHaibing [190627 21:17]:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/bus/ti-sysc.c: In function sysc_reset:
> drivers/bus/ti-sysc.c:1452:50: warning: variable quirks set but not used
> [-Wunused-but-set-variable]
>
> It is never used since commit e0db94fe87da ("bus: ti-sysc: Make
> OCP reset work for sysstatus and sysconfig reset bits")
Applying into omap-for-v5.4/ti-sysc thanks.
Tony
Re: [PATCH 0/3] bus: ti-sysc: fixes for reset handling
* Tero Kristo [190807 05:47]: > Hi, > > Here are a few patches to fix reset handling for ti-sysc bus driver. > Without these, the iommu won't be working properly at least. Applying these into omap-for-v5.4/ti-sysc since the prm rstctrl driver is not yet merged and these should not be needed as fixes at this point. Regards, Tony
Re: [PATCH 2/8] ARM: OMAP2+: Remove unconfigured midlemode for am3 lcdc
* Jyri Sarha [190813 11:05]:
> On 23/07/2019 22:03, Suman Anna wrote:
> > + Jyri
> >
> > On 7/23/19 6:28 AM, Tony Lindgren wrote:
> >> We currently get a warning for lcdc because of a difference
> >> with dts provided configuration compared to the legacy platform
> >> data. This is because lcdc has SYSC_HAS_MIDLEMODE configured in
> >> the platform data without configuring the modes.
> >
> > Hi Tony,
> > While I understand that you are trying to match the DT data with the
> > existing legacy data, do you know if there was a reason why this was
> > omitted in the first place? Should we be really adding the MSTANDBY_
> > flags and fix up the DTS node accordingly? I tried looking through the
> > git log, and the initial commit itself didn't add the MSTANDBY_ flags
> > but used the SYSC_HAS_MIDLEMODE.
> >
> > Jyri,
> > Do you know the history?
> >
>
> Sorry. This all has happened before my time. This is all new to me.
Oh OK. Well if possible, could you please check if the following patch
behaves with v5.2 for you for LCDC? I only have rack access to a
beaglebone with hdmi right now.
TRM "Table 13-34. SYSCONFIG Register Field Descriptions" lists both
standbymode and idlemode that should be just the sidle and midle
registers where midle is currently unconfigured.
Regards,
Tony
8< -
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -255,8 +255,9 @@ static struct omap_hwmod am33xx_gpio0_hwmod = {
static struct omap_hwmod_class_sysconfig lcdc_sysc = {
.rev_offs = 0x0,
.sysc_offs = 0x54,
- .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_flags = SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE,
+ .idlemodes = SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART,
.sysc_fields= &omap_hwmod_sysc_type2,
};
Re: [PATCH 5/5] bus: ti-sysc: Simplify cleanup upon failures in sysc_probe()
* Suman Anna [190627 15:24]: > On 6/27/19 7:11 AM, Tony Lindgren wrote: > > Hi, > > > > * Suman Anna [190625 23:33]: > >> The clocks are not yet parsed and prepared until after a successful > >> sysc_get_clocks(), so there is no need to unprepare the clocks upon > >> any failure of any of the prior functions in sysc_probe(). The current > >> code path would have been a no-op because of the clock validity checks > >> within sysc_unprepare(), but let's just simplify the cleanup path by > >> returning the error directly. > >> > >> While at this, also fix the cleanup path for a sysc_init_resets() > >> failure which is executed after the clocks are prepared. > > > > Sounds like this should get queued separately as a fix for v5.3-rc > > cycle, probably got broken with the recent ti-sysc init order changes. > > Yeah, this patch does not depend on the previous 4 patches, so can be > picked up independently for v5.3-rc as well. OK applying the $subject patch into fixes, and the rest into omap-for-v5.4/ti-sysc. Regards, Tony
Re: [PATCH 2/8] ARM: OMAP2+: Remove unconfigured midlemode for am3 lcdc
* Suman Anna [190724 18:29]: > On 7/24/19 1:31 AM, Tony Lindgren wrote: > > OK thanks for testing. Let's drop this for now, sounds like there is > > some midlemode configuration happening even with no flags set. > > You were dropping the ti,sysc-midle property in patch 8, is that still > ok without this patch? Yeah let's wait on that one too until we hear back from Jyri. Regards, Tony
Re: [PATCH 14/22] ARM: omap1: use pci_ioremap_io() for omap_cf
Hi, * Arnd Bergmann [190808 21:34]: > The ISA I/O space handling in omap_cf is incompatible with > PCI drivers in a multiplatform kernel, and requires a custom > mach/io.h. > > Change the driver to use pci_ioremap_io() like PCI drivers do, > so the generic ioport access can work across platforms. > > To actually use that code, we have to select CONFIG_PCI > here. > > Signed-off-by: Arnd Bergmann Looks like this series boots for me on 5912osk up to this patch, but this patch breaks booting somehow. Any ideas for fixes? Regards, Tony > --- > arch/arm/Kconfig | 2 +- > arch/arm/mach-omap1/include/mach/io.h | 45 --- > drivers/pcmcia/omap_cf.c | 9 ++ > 3 files changed, 4 insertions(+), 52 deletions(-) > delete mode 100644 arch/arm/mach-omap1/include/mach/io.h > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index b7162ac8d756..8263fe7a5e64 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -496,13 +496,13 @@ config ARCH_OMAP1 > select ARCH_OMAP > select CLKDEV_LOOKUP > select CLKSRC_MMIO > + select FORCE_PCI if PCCARD > select GENERIC_CLOCKEVENTS > select GENERIC_IRQ_CHIP > select GENERIC_IRQ_MULTI_HANDLER > select GPIOLIB > select HAVE_IDE > select IRQ_DOMAIN > - select NEED_MACH_IO_H if PCCARD > select NEED_MACH_MEMORY_H > select SPARSE_IRQ > help > diff --git a/arch/arm/mach-omap1/include/mach/io.h > b/arch/arm/mach-omap1/include/mach/io.h > deleted file mode 100644 > index ce4f8005b26f.. > --- a/arch/arm/mach-omap1/include/mach/io.h > +++ /dev/null > @@ -1,45 +0,0 @@ > -/* > - * arch/arm/mach-omap1/include/mach/io.h > - * > - * IO definitions for TI OMAP processors and boards > - * > - * Copied from arch/arm/mach-sa1100/include/mach/io.h > - * Copyright (C) 1997-1999 Russell King > - * > - * This program is free software; you can redistribute it and/or modify it > - * under the terms of the GNU General Public License as published by the > - * Free Software Foundation; either version 2 of the License, or (at your > - * option) any later version. > - * > - * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED > - * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF > - * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN > - * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, > - * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT > - * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF > - * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON > - * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT > - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF > - * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > - * > - * You should have received a copy of the GNU General Public License along > - * with this program; if not, write to the Free Software Foundation, Inc., > - * 675 Mass Ave, Cambridge, MA 02139, USA. > - * > - * Modifications: > - * 06-12-1997 RMK Created. > - * 07-04-1999 RMK Major cleanup > - */ > - > -#ifndef __ASM_ARM_ARCH_IO_H > -#define __ASM_ARM_ARCH_IO_H > - > -#define IO_SPACE_LIMIT 0x > - > -/* > - * We don't actually have real ISA nor PCI buses, but there is so many > - * drivers out there that might just work if we fake them... > - */ > -#define __io(a) __typesafe_io(a) > - > -#endif > diff --git a/drivers/pcmcia/omap_cf.c b/drivers/pcmcia/omap_cf.c > index 98df6473034d..9f8ad82f5fce 100644 > --- a/drivers/pcmcia/omap_cf.c > +++ b/drivers/pcmcia/omap_cf.c > @@ -235,9 +235,9 @@ static int __init omap_cf_probe(struct platform_device > *pdev) > cf->phys_cf = res->start; > > /* pcmcia layer only remaps "real" memory */ > - cf->socket.io_offset = (unsigned long) > - ioremap(cf->phys_cf + SZ_4K, SZ_2K); > - if (!cf->socket.io_offset) > + cf->socket.io_offset = 0x1; > + status = pci_ioremap_io(cf->socket.io_offset, cf->phys_cf + SZ_4K); > + if (status) > goto fail1; > > if (!request_mem_region(cf->phys_cf, SZ_8K, driver_name)) > @@ -281,8 +281,6 @@ static int __init omap_cf_probe(struct platform_device > *pdev) > fail2: > release_mem_region(cf->phys_cf, SZ_8K); > fail1: > - if (cf->socket.io_offset) > - iounmap((void __iomem *) cf->socket.io_offset); > free_irq(irq, cf); > fail0: > kfree(cf); > @@ -296,7 +294,6 @@ static int __exit omap_cf_remove(struct platform_device > *pdev) > cf->active = 0; > pcmcia_unregister_socket(&cf->socket); > del_timer_sync(&cf->timer); > - iounmap((void __iomem *) cf->socket.io_offset); > release_mem_region(cf->phys_cf, SZ_8K); > free_irq(cf->irq, cf); > kfree(cf); > -- > 2.20.0 >
Re: [PATCH for v5.3] ARM: OMAP1: ams-delta-fiq: Fix missing irq_ack
* Janusz Krzysztofik [190811 01:48]:
> Non-serio path of Amstrad Delta FIQ deferred handler depended on
> irq_ack() method provided by OMAP GPIO driver. That method has been
> removed by commit 693de831c6e5 ("gpio: omap: remove irq_ack method").
> Remove useless code from the deferred handler and reimplement the
> missing operation inside the base FIQ handler.
>
> Should another dependency - irq_unmask() - be ever removed from the OMAP
> GPIO driver, WARN once if missing.
Thanks applying into fixes.
Tony
Re: [alsa-devel] Regression in next with codec unload and snd_soc_component_get/put
* Takashi Iwai [190809 08:24]:
> On Fri, 09 Aug 2019 09:46:43 +0200,
> Tony Lindgren wrote:
> >
> > * Takashi Iwai [190809 07:25]:
> > > On Fri, 09 Aug 2019 09:00:03 +0200,
> > > Tony Lindgren wrote:
> > > >
> > > > Hi,
> > > >
> > > > Looks like commit 4a81e8f30d0b ("ASoC: soc-component: add
> > > > snd_soc_component_get/put()") causes a regression where trying
> > > > to rmmod a codec driver fails with module is in use error after
> > > > rmmod of snd-soc-audio-graph-card for example.
> > > >
> > > > Any ideas what goes wrong there?
> > >
> > > There is an obvious typo: soc_cleanup_component() should call
> > > snd_soc_component_module_put_when_remove() instead of *_close().
> >
> > Making that change locally seems to fix it thanks.
>
> ... and it was already fixed in the later commit 0e36f36b04e7
> "ASoC: soc-core: fix module_put() warning in soc_cleanup_component".
Mark, looks like this commit is still not in Linux next, forgot
to push out something?
Regards,
Tony
Re: [PATCH] ARM: dts: dra74x: Fix iodelay configuration for mmc3
* Faiz Abbas [190807 03:53]: > According to the latest am572x[1] and dra74x[2] data manuals, mmc3 > default, hs, sdr12 and sdr25 modes use iodelay values given in > MMC3_MANUAL1. Set the MODE_SELECT bit for these so that manual mode is > selected and correct iodelay values can be configured. Thanks applying into fixes. Tony
Re: [PATCH 1/1] ARM: dts: am335x: Fix UARTs length
Hi, * Emmanuel Vadot [190724 05:24]: > As seen on the AM335x TRM all the UARTs controller only are 0x1000 in size. > Fix this in the DTS. Thanks applying into fixes. FYI, the module size is usually (but not always) 0x1000 with additional 0x1000 for the interconnect related registers. Regards, Tony
Re: [PATCH] ARM: dts: am335x-wega.dtsi: fix wrong card detect pin level
* Andreas Klinger [190709 11:32]:
> mmc cards on mmc1 are not detected because of wrong card detect (cd) level.
>
> Change cd from GPIO_ACTIVE_HIGH to GPIO_ACTIVE_LOW.
>
> This is necessary because of commit e63201f19438 ("mmc: omap_hsmmc:
> Delete platform data GPIO CD and WP")
>
> Signed-off-by: Andreas Klinger
> ---
> arch/arm/boot/dts/am335x-wega.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/am335x-wega.dtsi
> b/arch/arm/boot/dts/am335x-wega.dtsi
> index b7d28a20341f..84581fed3d06 100644
> --- a/arch/arm/boot/dts/am335x-wega.dtsi
> +++ b/arch/arm/boot/dts/am335x-wega.dtsi
> @@ -157,7 +157,7 @@
> bus-width = <4>;
> pinctrl-names = "default";
> pinctrl-0 = <&mmc1_pins>;
> - cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
> + cd-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
> status = "okay";
> };
>
Looks like this already got fixed with an earlier commit 8a0098c05a27
("ARM: dts: am335x phytec boards: Fix cd-gpios active level").
Regards,
Tony
Re: [PATCH] bus: ti-sysc: Remove if-block in sysc_check_children()
* Roger Quadros [190813 06:26]: > None of those functions return anything. > Maybe you can fix sysc_check_one_child() to return void? > I think you can retain your patch but get rid of error variable. Makes sense to me. Regards, Tony
Re: [alsa-devel] Regression in next with codec unload and snd_soc_component_get/put
* Takashi Iwai [190809 07:25]:
> On Fri, 09 Aug 2019 09:00:03 +0200,
> Tony Lindgren wrote:
> >
> > Hi,
> >
> > Looks like commit 4a81e8f30d0b ("ASoC: soc-component: add
> > snd_soc_component_get/put()") causes a regression where trying
> > to rmmod a codec driver fails with module is in use error after
> > rmmod of snd-soc-audio-graph-card for example.
> >
> > Any ideas what goes wrong there?
>
> There is an obvious typo: soc_cleanup_component() should call
> snd_soc_component_module_put_when_remove() instead of *_close().
Making that change locally seems to fix it thanks.
> And the module_get_upon_open boolean switch is a bit hard to
> understand. Maybe using enum would be simpler there.
>
> > BTW, looks like the lore.kernel.org link in that commit also is
> > unreachable?
>
> It's because alsa-devel ML isn't tracked on lore.kernel.org,
> unfortunately.
>
> Jaroslav, I asked this already. Shall we ask lore to track alsa-devel
> ML?
> https://korg.wiki.kernel.org/userdoc/lore
Regards,
Tony
Regression in next with codec unload and snd_soc_component_get/put
Hi,
Looks like commit 4a81e8f30d0b ("ASoC: soc-component: add
snd_soc_component_get/put()") causes a regression where trying
to rmmod a codec driver fails with module is in use error after
rmmod of snd-soc-audio-graph-card for example.
Any ideas what goes wrong there?
BTW, looks like the lore.kernel.org link in that commit also is
unreachable?
Regards,
Tony
Re: [PATCH] kernfs: fix memleak in kernel_ops_readdir()
Hi,
* Tejun Heo [691231 23:00]:
> From: Andrea Arcangeli
>
> If getdents64 is killed or hits on segfault, it'll leave cgroups
> directories in sysfs pinned leaking memory because the kernfs node
> won't be freed on rmdir and the parent neither.
Somehow this causes a regression in Linux next for me where I'm seeing
lots of sysfs entries now missing under /sys/bus/platform/devices.
For example, I now only see one .serial entry show up in sysfs.
Things work again if I revert commit cc798c83898e ("kernfs: fix memleak
inkernel_ops_readdir()"). Any ideas why that would be?
Below is a diff -u of ls /sys/bus/platform/devices for reference
showing the missing entries with cc798c83898e.
Regards,
Tony
8< ---
--- works
+++ fails
@@ -1,227 +1,44 @@
-2c00.ethernet
4010.interconnect
-4010.interconnect:segment@0
-40122000.mcbsp
-4012208c.target-module
-4012408c.target-module
4012608c.target-module
-40128000.target-module
-4012c000.target-module
-4012e000.target-module
-4013.target-module
-4013.wdt
-40132000.target-module
40138000.target-module
-40138000.timer
-4013a000.target-module
-4013a000.timer
-4013c000.target-module
-4013c000.timer
4013e000.target-module
-4013e000.timer
-401f1000.target-module
-40304000.ocmcram
-4400.ocp
-4800.interconnect
-4800.interconnect:segment@0
-4800.interconnect:segment@20
-4802.serial
-48020050.target-module
-48032000.target-module
-48032000.timer
-48034000.target-module
-48034000.timer
-48036000.target-module
48036000.timer
-4803e000.target-module
-4803e000.timer
48055000.gpio
-48055000.target-module
-48057000.gpio
-48057000.target-module
-48059000.gpio
48059000.target-module
-4805b000.gpio
-4805b000.target-module
-4805d000.gpio
4805d000.target-module
-4806.i2c
-4806.target-module
-4806a000.serial
-4806a050.target-module
-4806c000.serial
-4806c050.target-module
4806e000.serial
4806e050.target-module
-4807.i2c
4807.i2c:twl@48:gpadc
-4807.i2c:twl@48:pwm
-4807.i2c:twl@48:pwmled
-4807.i2c:twl@48:regulator-v1v8
-4807.i2c:twl@48:regulator-v2v1
4807.i2c:twl@48:regulator-vana
-4807.i2c:twl@48:regulator-vaux1
-4807.i2c:twl@48:regulator-vaux2
-4807.i2c:twl@48:regulator-vaux3
4807.i2c:twl@48:regulator-vcxio
-4807.i2c:twl@48:regulator-vdac
-4807.i2c:twl@48:regulator-vmmc
-4807.i2c:twl@48:regulator-vpp
-4807.i2c:twl@48:regulator-vusb
-4807.i2c:twl@48:regulator-vusim
-4807.i2c:twl@48:rtc
4807.i2c:twl@48:usb-comparator
-4807.target-module
-48072000.i2c
-48072000.target-module
-48076000.target-module
-48078000.target-module
-48086000.target-module
48086000.timer
-48088000.target-module
-48088000.timer
-4809608c.target-module
-48098000.spi
-48098000.target-module
-4809a000.spi
4809a000.target-module
-4809c000.mmc
4809c000.target-module
-480a5000.des
-480ad000.target-module
-480b2000.1w
-480b2000.target-module
-480b4000.target-module
480b8000.spi
-480b8000.target-module
-480ba000.spi
-480ba000.target-module
-480d1000.target-module
480d5000.mmc
-480d5000.target-module
-48240600.local-timer
48242000.l2-cache-controller
-4835.i2c
-4835.target-module
-4a00.interconnect
-4a00.interconnect:segment@0
-4a00.interconnect:segment@10
-4a00.interconnect:segment@18
-4a00.interconnect:segment@20
-4a00.interconnect:segment@28
4a00.interconnect:segment@30
4a00.interconnect:segment@8
-4a002000.scm
-4a002000.scm_conf
-4a002000.target-module
-4a002260.bandgap
-4a002300.control-phy
-4a00233c.control-phy
-4a004000.cm1
-4a004000.target-module
-4a004300.mpuss_cm
-4a004400.tesla_cm
-4a004500.abe_cm
-4a008000.cm2
-4a008000.target-module
-4a008600.l4_ao_cm
-4a008700.l3_1_cm
-4a008800.l3_2_cm
-4a008900.ducati_cm
-4a008a00.l3_dma_cm
4a008b00.l3_emif_cm
4a008c00.d2d_cm
-4a008d00.l4_cfg_cm
4a008e00.l3_instr_cm
-4a008f00.ivahd_cm
-4a009000.iss_cm
-4a009100.l3_dss_cm
-4a009200.l3_gfx_cm
-4a009300.l3_init_cm
-4a009400.l4_per_cm
-4a056000.dma-controller
4a056000.target-module
-4a058000.hsi
-4a058000.target-module
4a062000.target-module
-4a062000.usbhstll
-4a064000.target-module
4a064000.usbhshost
4a064800.ohci
-4a064c00.ehci
-4a066000.mmu
-4a0ab000.usb_otg_hs
4a0ab400.target-module
-4a0ad000.ocp2scp
-4a0ad000.target-module
4a0ad080.usb2phy
-4a0d9000.smartreflex
-4a0d9038.target-module
4a0db000.smartreflex
-4a0db038.target-module
-4a0dd000.smartreflex
-4a0dd038.target-module
-4a0f4000.mailbox
-4a0f4000.target-module
-4a0f6000.spinlock
-4a0f6000.target-module
4a10.target-module
4a100040.pinmux
-4a1005a0.omap4_padconf_global
-4a100600.pbias_regulator
-4a10a000.target-module
-4a30.interconnect
-4a30.interconnect:segment@0
-4a30.interconnect:segment@1
4a30.interconnect:segment@2
-4a306000.prm
-4a306000.target-module
-4a307bd0.regulator-abb-mpu
4a30a000.scrm
-4a30a000.target-module
-4a30c000.target-module
4a30c000.target-module:scm@c000
-4a31.gpio
-4a31.tar
Re: [PATCH 5/8] ARM: dts: Drop bogus ahclkr clocks for dra7 mcasp 3 to 8
* 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 on dra7.
> > Otherwise we get the following warning on beagle-x15:
...
> > @@ -2962,9 +2958,8 @@
> > ;
> > /* Domains (P, C): l4per_pwrdm, l4per2_clkdm */
> > clocks = <&l4per2_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL 0>,
> > -<&l4per2_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL
> > 24>,
> > -<&l4per2_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL
> > 28>;
> > - clock-names = "fck", "ahclkx", "ahclkr";
> > +<&l4per2_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL
> > 24>;
> > + clock-names = "fck", "ahclkx";
>
> The equivalent change to MCASP8 is missing.
Thanks for spotting it, probably should be set up the same way as
MCASP4 too looking at the TRM.
Tero, care to check the dra7 mcasp clocks we have defined?
$ grep MCASP drivers/clk/ti/clk-7xx.c
{ DRA7_IPU_MCASP1_CLKCTRL, dra7_mcasp1_bit_data, CLKF_SW_SUP,
"ipu-clkctrl::22" },
{ DRA7_L4PER2_MCASP2_CLKCTRL, dra7_mcasp2_bit_data, CLKF_SW_SUP,
"l4per2-clkctrl:0154:22" },
{ DRA7_L4PER2_MCASP3_CLKCTRL, dra7_mcasp3_bit_data, CLKF_SW_SUP,
"l4per2-clkctrl:015c:22" },
{ DRA7_L4PER2_MCASP5_CLKCTRL, dra7_mcasp5_bit_data, CLKF_SW_SUP,
"l4per2-clkctrl:016c:22" },
{ DRA7_L4PER2_MCASP8_CLKCTRL, dra7_mcasp8_bit_data, CLKF_SW_SUP,
"l4per2-clkctrl:0184:24" },
{ DRA7_L4PER2_MCASP4_CLKCTRL, dra7_mcasp4_bit_data, CLKF_SW_SUP,
"l4per2-clkctrl:018c:22" },
{ DRA7_L4PER2_MCASP6_CLKCTRL, dra7_mcasp6_bit_data, CLKF_SW_SUP,
"l4per2-clkctrl:01f8:22" },
{ DRA7_L4PER2_MCASP7_CLKCTRL, dra7_mcasp7_bit_data, CLKF_SW_SUP,
"l4per2-clkctrl:01fc:22" },
Is bit 24 above correct for MCASP8 or should it too be 22 like
adjacent MCASP4 in the TRM?
Regards,
Tony
Re: [PATCH 2/8] ARM: OMAP2+: Remove unconfigured midlemode for am3 lcdc
* Keerthy [190724 05:50]:
>
> On 24/07/19 12:33 AM, Suman Anna wrote:
> > + Jyri
> >
> > On 7/23/19 6:28 AM, Tony Lindgren wrote:
> > > We currently get a warning for lcdc because of a difference
> > > with dts provided configuration compared to the legacy platform
> > > data. This is because lcdc has SYSC_HAS_MIDLEMODE configured in
> > > the platform data without configuring the modes.
> >
> > Hi Tony,
> > While I understand that you are trying to match the DT data with the
> > existing legacy data, do you know if there was a reason why this was
> > omitted in the first place? Should we be really adding the MSTANDBY_
> > flags and fix up the DTS node accordingly? I tried looking through the
> > git log, and the initial commit itself didn't add the MSTANDBY_ flags
> > but used the SYSC_HAS_MIDLEMODE.
Yes the goal is to get rid of all errors and warnings in dmesg output
so we can spot the real issues.
> > Jyri,
> > Do you know the history?
>
> Tony/Suman,
>
> This patch breaks DS0 on am3.
OK thanks for testing. Let's drop this for now, sounds like there is
some midlemode configuration happening even with no flags set.
Probably the right fix is to configure the usable midlemodes instead
both for platform data and dts data and then drop the platform data.
Regards,
Tony
> > > Let's fix the warning by removing SYSC_HAS_MIDLEMODE. Note that
> > > the am335x TRM lists SYSC_HAS_MIDLEMODE, but it is unused.
> >
> >
> >
> > >
> > > Signed-off-by: Tony Lindgren
> > > ---
> > > arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> > > b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> > > --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> > > +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> > > @@ -231,7 +231,7 @@ static struct omap_hwmod am33xx_control_hwmod = {
> > > static struct omap_hwmod_class_sysconfig lcdc_sysc = {
> > > .rev_offs = 0x0,
> > > .sysc_offs = 0x54,
> > > - .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
> > > + .sysc_flags = SYSC_HAS_SIDLEMODE,
> > > .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> > > .sysc_fields= &omap_hwmod_sysc_type2,
> > > };
> > >
> >
Re: [PATCH 3/4] ARM: dts: am33xx: Add nodes for eQEP
* David Lechner [190723 14:46]:
> On 7/23/19 3:42 AM, Tony Lindgren wrote:
> > * David Lechner [190722 15:46]:
> > > This adds new nodes for the Texas Instruments Enhanced Quadrature
> > > Encoder Pulse (eQEP) module in the PWM subsystem on AM33XX.
> > >
> > > Signed-off-by: David Lechner
> > > ---
> > > arch/arm/boot/dts/am33xx-l4.dtsi | 27 +++
> > > 1 file changed, 27 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/am33xx-l4.dtsi
> > > b/arch/arm/boot/dts/am33xx-l4.dtsi
> > > index 3b1fb2ba4dff..7fdc2f61c553 100644
> > > --- a/arch/arm/boot/dts/am33xx-l4.dtsi
> > > +++ b/arch/arm/boot/dts/am33xx-l4.dtsi
> > > @@ -1908,6 +1908,15 @@
> > > status = "disabled";
> > > };
> > > + eqep0: eqep@180 {
> > > + compatible = "ti,am3352-eqep";
> > > + reg = <0x180 0x80>;
> > > + clocks = <&l4ls_gclk>;
> > > + clock-names = "fck";
> > > + interrupts = <79>;
> > > + status = "disabled";
> > > + };
> > > +
> >
> > You probably no longer need to map any clocks here as this> is now a child
> > of the interconnect target module managed
> > by ti-sysc driver. I have not checked but probably l4ls_gclk
> > is same as clocks = <&l4ls_clkctrl AM3_L4LS_EPWMSS0_CLKCTRL 0>
> > already managed by ti-sysc. If so, then just using runtime PM
> > calls in any of the child device drivers will keep it enabled.
> >
> > If l4ls_gclk is a separate functional clock, then it still
> > needs to be managed by the child device driver directly.
>
> The clock is included so that we can get the clock rate for
> the timing aspects of the eQEP, not for power management.
>
> I chose to use the "fck" name to be consistent with the
> sibling EHRPWM and ECAP nodes that already have the same
> bindings for the same clock.
OK makes sense to me thanks.
Tony
[PATCH] serial: 8250_omap: Fix idling for unloaded serdev drivers
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 specifically enable the timeout for UARTs if desired. We must not enable the workaround for serdev devices though. It leads into UARTs not idling if no serdev devices are loaded and there is no sysfs entry to configure the UART in that case. And this means that my PM may not work unless the serdev modules are loaded. We can detect a serdev device being configured based on a dts child node, and we can simply skip the workround in that case. And the serdev driver can idle the port during runtime when suitable if an out-of-band wake-up GPIO line exists for example. Let's also add some comments to the workaround while at it. Cc: Johan Hovold Signed-off-by: Tony Lindgren --- drivers/tty/serial/8250/8250_omap.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c --- a/drivers/tty/serial/8250/8250_omap.c +++ b/drivers/tty/serial/8250/8250_omap.c @@ -1234,7 +1234,16 @@ static int omap8250_probe(struct platform_device *pdev) device_init_wakeup(&pdev->dev, true); pm_runtime_use_autosuspend(&pdev->dev); - pm_runtime_set_autosuspend_delay(&pdev->dev, -1); + + /* +* Disable runtime PM until autosuspend delay unless specifically +* enabled by the user via sysfs. This is the historic way to +* prevent an unsafe default policy with lossy characters on wake-up. +* For serdev devices this is not needed, the policy can be managed by +* the serdev driver. +*/ + if (!of_get_available_child_count(pdev->dev.of_node)) + pm_runtime_set_autosuspend_delay(&pdev->dev, -1); pm_runtime_irq_safe(&pdev->dev); pm_runtime_enable(&pdev->dev); -- 2.21.0
[PATCH 8/8] ARM: dts: Fix lcdc sysc flags for am3
The LCDC controller on am335x has a sysconfig register without a SOFTRESET bit. Let's configure that by setting ti,sysc-mask = <0> as otherwise we get the following warning: ti-sysc 4830e000.target-module: idlemodes 0087 != 0007 And the legacy platform data has LCDC midle unconfigured so let's remove that property. Signed-off-by: Tony Lindgren --- arch/arm/boot/dts/am33xx-l4.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/am33xx-l4.dtsi b/arch/arm/boot/dts/am33xx-l4.dtsi --- a/arch/arm/boot/dts/am33xx-l4.dtsi +++ b/arch/arm/boot/dts/am33xx-l4.dtsi @@ -2038,7 +2038,7 @@ reg = <0xe000 0x4>, <0xe054 0x4>; reg-names = "rev", "sysc"; - ti,sysc-midle ; + ti,sysc-mask = <0>; ti,sysc-sidle = , , ; -- 2.21.0
[PATCH 7/8] ARM: dts: Fix incorrect dcan register mapping for am3, am4 and dra7
We are currently using a wrong register for dcan revision. Although
this is currently only used for detecting the dcan module, let's
fix it to avoid confusion.
Signed-off-by: Tony Lindgren
---
arch/arm/boot/dts/am33xx-l4.dtsi | 4
arch/arm/boot/dts/am437x-l4.dtsi | 4
arch/arm/boot/dts/dra7-l4.dtsi | 4 ++--
drivers/bus/ti-sysc.c| 3 ++-
4 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx-l4.dtsi b/arch/arm/boot/dts/am33xx-l4.dtsi
--- a/arch/arm/boot/dts/am33xx-l4.dtsi
+++ b/arch/arm/boot/dts/am33xx-l4.dtsi
@@ -1758,6 +1758,8 @@
target-module@cc000 { /* 0x481cc000, ap 60
46.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
+ reg = <0xcc020 0x4>;
+ reg-names = "rev";
ti,hwmods = "d_can0";
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_D_CAN0_CLKCTRL 0>,
@@ -1780,6 +1782,8 @@
target-module@d { /* 0x481d, ap 62
42.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
+ reg = <0xd0020 0x4>;
+ reg-names = "rev";
ti,hwmods = "d_can1";
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM3_L4LS_D_CAN1_CLKCTRL 0>,
diff --git a/arch/arm/boot/dts/am437x-l4.dtsi b/arch/arm/boot/dts/am437x-l4.dtsi
--- a/arch/arm/boot/dts/am437x-l4.dtsi
+++ b/arch/arm/boot/dts/am437x-l4.dtsi
@@ -1574,6 +1574,8 @@
target-module@cc000 { /* 0x481cc000, ap 50
46.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
+ reg = <0xcc020 0x4>;
+ reg-names = "rev";
ti,hwmods = "d_can0";
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM4_L4LS_D_CAN0_CLKCTRL 0>;
@@ -1593,6 +1595,8 @@
target-module@d { /* 0x481d, ap 52
3a.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
+ reg = <0xd0020 0x4>;
+ reg-names = "rev";
ti,hwmods = "d_can1";
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <&l4ls_clkctrl AM4_L4LS_D_CAN1_CLKCTRL 0>;
diff --git a/arch/arm/boot/dts/dra7-l4.dtsi b/arch/arm/boot/dts/dra7-l4.dtsi
--- a/arch/arm/boot/dts/dra7-l4.dtsi
+++ b/arch/arm/boot/dts/dra7-l4.dtsi
@@ -3020,7 +3020,7 @@
target-module@8 { /* 0x4848, ap 31
16.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
- reg = <0x8 0x4>;
+ reg = <0x80020 0x4>;
reg-names = "rev";
clocks = <&l4per2_clkctrl DRA7_L4PER2_DCAN2_CLKCTRL 0>;
clock-names = "fck";
@@ -4572,7 +4572,7 @@
target-module@c000 {/* 0x4ae3c000, ap 30
04.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
- reg = <0xc000 0x4>;
+ reg = <0xc020 0x4>;
reg-names = "rev";
clocks = <&wkupaon_clkctrl DRA7_WKUPAON_DCAN1_CLKCTRL
0>;
clock-names = "fck";
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
@@ -1267,7 +1267,8 @@ static const struct sysc_revision_quirk
sysc_revision_quirks[] = {
SYSC_QUIRK("control", 0, 0, 0x10, -1, 0x4900, 0x, 0),
SYSC_QUIRK("cpgmac", 0, 0x1200, 0x1208, 0x1204, 0x4edb1902,
0x00f0, 0),
- SYSC_QUIRK("dcan", 0, 0, -1, -1, 0x, 0x, 0),
+ SYSC_QUIRK("dcan", 0, 0x20, -1, -1, 0xa3170504, 0x, 0),
+ SYSC_QUIRK("dcan", 0, 0x20, -1, -1, 0x4edb1902, 0x, 0),
SYSC_QUIRK("dmic", 0, 0, 0x10, -1, 0x5001, 0x, 0),
SYSC_QUIRK("dwc3", 0, 0, 0x10, -1, 0x500a0200, 0x, 0),
SYSC_QUIRK("epwmss", 0, 0, 0x4, -1, 0x4741, 0x, 0),
--
2.21.0
[PATCH 6/8] ARM: dts: Fix flags for gpio7
The ti,no-idle-on-init and ti,no-reset-on-init flags need to be at
the interconnect target module level for the modules that have it
defined. Otherwise we get the following warnings:
dts flag should be at module level for ti,no-idle-on-init
dts flag should be at module level for ti,no-reset-on-init
Signed-off-by: Tony Lindgren
---
arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 2 +-
arch/arm/boot/dts/dra7-evm.dts | 2 +-
arch/arm/boot/dts/dra7-l4.dtsi | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
--- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
@@ -379,7 +379,7 @@
};
};
-&gpio7 {
+&gpio7_target {
ti,no-reset-on-init;
ti,no-idle-on-init;
};
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -498,7 +498,7 @@
phy-supply = <&ldousb_reg>;
};
-&gpio7 {
+&gpio7_target {
ti,no-reset-on-init;
ti,no-idle-on-init;
};
diff --git a/arch/arm/boot/dts/dra7-l4.dtsi b/arch/arm/boot/dts/dra7-l4.dtsi
--- a/arch/arm/boot/dts/dra7-l4.dtsi
+++ b/arch/arm/boot/dts/dra7-l4.dtsi
@@ -1261,7 +1261,7 @@
};
};
- target-module@51000 { /* 0x48051000, ap 45
2e.0 */
+ gpio7_target: target-module@51000 { /* 0x48051000,
ap 45 2e.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
ti,hwmods = "gpio7";
reg = <0x51000 0x4>,
--
2.21.0
[PATCH 0/8] ti-sysc related warning fixes for v5.3-rc cycle
Hi all, I noticed that with recent ti-sysc driver changes some new warnings have crept in. Mostly they are caused by having different configuration in the dts compared to the legacy platform data. Let's fix these first before we continue dropping the legacy platform data. I also noticed we need two fixes for the ti-sysc driver while looking at the warnings. Regards, Tony Tony Lindgren (8): ARM: OMAP2+: Fix missing SYSC_HAS_RESET_STATUS for dra7 epwmss ARM: OMAP2+: Remove unconfigured midlemode for am3 lcdc bus: ti-sysc: Fix handling of forced idle bus: ti-sysc: Fix using configured sysc mask value ARM: dts: Drop bogus ahclkr clocks for dra7 mcasp 3 to 8 ARM: dts: Fix flags for gpio7 ARM: dts: Fix incorrect dcan register mapping for am3, am4 and dra7 ARM: dts: Fix lcdc sysc flags for am3 arch/arm/boot/dts/am33xx-l4.dtsi | 6 +++- arch/arm/boot/dts/am437x-l4.dtsi | 4 +++ .../boot/dts/am57xx-beagle-x15-common.dtsi| 2 +- arch/arm/boot/dts/dra7-evm.dts| 2 +- arch/arm/boot/dts/dra7-l4.dtsi| 31 --- arch/arm/mach-omap2/omap_hwmod_33xx_data.c| 2 +- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 3 +- drivers/bus/ti-sysc.c | 10 +++--- 8 files changed, 31 insertions(+), 29 deletions(-) -- 2.21.0
[PATCH 1/8] ARM: OMAP2+: Fix missing SYSC_HAS_RESET_STATUS for dra7 epwmss
TRM says PWMSS_SYSCONFIG bit for SOFTRESET changes to zero when
reset is completed. Let's configure it as otherwise we get warnings
on boot when we check the data against dts provided data. Eventually
the legacy platform data will be just dropped, but let's fix the
warning first.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -379,7 +379,8 @@ static struct omap_hwmod dra7xx_dcan2_hwmod = {
static struct omap_hwmod_class_sysconfig dra7xx_epwmss_sysc = {
.rev_offs = 0x0,
.sysc_offs = 0x4,
- .sysc_flags = SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET,
+ .sysc_flags = SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_RESET_STATUS,
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= &omap_hwmod_sysc_type2,
};
--
2.21.0
[PATCH 2/8] ARM: OMAP2+: Remove unconfigured midlemode for am3 lcdc
We currently get a warning for lcdc because of a difference
with dts provided configuration compared to the legacy platform
data. This is because lcdc has SYSC_HAS_MIDLEMODE configured in
the platform data without configuring the modes.
Let's fix the warning by removing SYSC_HAS_MIDLEMODE. Note that
the am335x TRM lists SYSC_HAS_MIDLEMODE, but it is unused.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -231,7 +231,7 @@ static struct omap_hwmod am33xx_control_hwmod = {
static struct omap_hwmod_class_sysconfig lcdc_sysc = {
.rev_offs = 0x0,
.sysc_offs = 0x54,
- .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
+ .sysc_flags = SYSC_HAS_SIDLEMODE,
.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= &omap_hwmod_sysc_type2,
};
--
2.21.0
[PATCH 4/8] bus: ti-sysc: Fix using configured sysc mask value
We have cases where there are no softreset bits like with am335x lcdc. In that case ti,sysc-mask = <0> needs to be handled properly. Signed-off-by: Tony Lindgren --- drivers/bus/ti-sysc.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) 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 @@ -1692,10 +1692,7 @@ static int sysc_init_sysc_mask(struct sysc *ddata) if (error) return 0; - if (val) - ddata->cfg.sysc_val = val & ddata->cap->sysc_mask; - else - ddata->cfg.sysc_val = ddata->cap->sysc_mask; + ddata->cfg.sysc_val = val & ddata->cap->sysc_mask; return 0; } -- 2.21.0
[PATCH 5/8] ARM: dts: Drop bogus ahclkr clocks for dra7 mcasp 3 to 8
The ahclkr clkctrl clock bit 28 only exists for mcasp 1 and 2 on dra7.
Otherwise we get the following warning on beagle-x15:
ti-sysc 48468000.target-module: could not add child clock ahclkr: -19
Fixes: 5241ccbf2819 ("ARM: dts: Add missing ranges for dra7 mcasp l3 ports")
Signed-off-by: Tony Lindgren
---
arch/arm/boot/dts/dra7-l4.dtsi | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-l4.dtsi b/arch/arm/boot/dts/dra7-l4.dtsi
--- a/arch/arm/boot/dts/dra7-l4.dtsi
+++ b/arch/arm/boot/dts/dra7-l4.dtsi
@@ -2818,9 +2818,8 @@
;
/* Domains (P, C): l4per_pwrdm, l4per2_clkdm */
clocks = <&l4per2_clkctrl DRA7_L4PER2_MCASP3_CLKCTRL 0>,
-<&l4per2_clkctrl DRA7_L4PER2_MCASP3_CLKCTRL
24>,
-<&l4per2_clkctrl DRA7_L4PER2_MCASP3_CLKCTRL
28>;
- clock-names = "fck", "ahclkx", "ahclkr";
+<&l4per2_clkctrl DRA7_L4PER2_MCASP3_CLKCTRL
24>;
+ clock-names = "fck", "ahclkx";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x68000 0x2000>,
@@ -2854,9 +2853,8 @@
;
/* Domains (P, C): l4per_pwrdm, l4per2_clkdm */
clocks = <&l4per2_clkctrl DRA7_L4PER2_MCASP4_CLKCTRL 0>,
-<&l4per2_clkctrl DRA7_L4PER2_MCASP4_CLKCTRL
24>,
-<&l4per2_clkctrl DRA7_L4PER2_MCASP4_CLKCTRL
28>;
- clock-names = "fck", "ahclkx", "ahclkr";
+<&l4per2_clkctrl DRA7_L4PER2_MCASP4_CLKCTRL
24>;
+ clock-names = "fck", "ahclkx";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x6c000 0x2000>,
@@ -2890,9 +2888,8 @@
;
/* Domains (P, C): l4per_pwrdm, l4per2_clkdm */
clocks = <&l4per2_clkctrl DRA7_L4PER2_MCASP5_CLKCTRL 0>,
-<&l4per2_clkctrl DRA7_L4PER2_MCASP5_CLKCTRL
24>,
-<&l4per2_clkctrl DRA7_L4PER2_MCASP5_CLKCTRL
28>;
- clock-names = "fck", "ahclkx", "ahclkr";
+<&l4per2_clkctrl DRA7_L4PER2_MCASP5_CLKCTRL
24>;
+ clock-names = "fck", "ahclkx";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x7 0x2000>,
@@ -2926,9 +2923,8 @@
;
/* Domains (P, C): l4per_pwrdm, l4per2_clkdm */
clocks = <&l4per2_clkctrl DRA7_L4PER2_MCASP6_CLKCTRL 0>,
-<&l4per2_clkctrl DRA7_L4PER2_MCASP6_CLKCTRL
24>,
-<&l4per2_clkctrl DRA7_L4PER2_MCASP6_CLKCTRL
28>;
- clock-names = "fck", "ahclkx", "ahclkr";
+<&l4per2_clkctrl DRA7_L4PER2_MCASP6_CLKCTRL
24>;
+ clock-names = "fck", "ahclkx";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x74000 0x2000>,
@@ -2962,9 +2958,8 @@
;
/* Domains (P, C): l4per_pwrdm, l4per2_clkdm */
clocks = <&l4per2_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL 0>,
-<&l4per2_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL
24>,
-<&l4per2_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL
28>;
- clock-names = "fck", "ahclkx", "ahclkr";
+<&l4per2_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL
24>;
+ clock-names = "fck", "ahclkx";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x78000 0x2000>,
--
2.21.0
[PATCH 3/8] bus: ti-sysc: Fix handling of forced idle
For some devices we can get the following warning on boot:
ti-sysc 48485200.target-module: sysc_disable_module: invalid midlemode
Fix this by treating SYSC_IDLE_FORCE like we do for the other bits
for idlemodes mask.
Fixes: d59b60564cbf ("bus: ti-sysc: Add generic enable/disable functions")
Cc: Roger Quadros
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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
@@ -949,7 +949,7 @@ static int sysc_best_idle_mode(u32 idlemodes, u32
*best_mode)
*best_mode = SYSC_IDLE_SMART_WKUP;
else if (idlemodes & BIT(SYSC_IDLE_SMART))
*best_mode = SYSC_IDLE_SMART;
- else if (idlemodes & SYSC_IDLE_FORCE)
+ else if (idlemodes & BIT(SYSC_IDLE_FORCE))
*best_mode = SYSC_IDLE_FORCE;
else
return -EINVAL;
--
2.21.0
Re: [PATCH 3/4] ARM: dts: am33xx: Add nodes for eQEP
* David Lechner [190722 15:46]:
> This adds new nodes for the Texas Instruments Enhanced Quadrature
> Encoder Pulse (eQEP) module in the PWM subsystem on AM33XX.
>
> Signed-off-by: David Lechner
> ---
> arch/arm/boot/dts/am33xx-l4.dtsi | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am33xx-l4.dtsi
> b/arch/arm/boot/dts/am33xx-l4.dtsi
> index 3b1fb2ba4dff..7fdc2f61c553 100644
> --- a/arch/arm/boot/dts/am33xx-l4.dtsi
> +++ b/arch/arm/boot/dts/am33xx-l4.dtsi
> @@ -1908,6 +1908,15 @@
> status = "disabled";
> };
>
> + eqep0: eqep@180 {
> + compatible = "ti,am3352-eqep";
> + reg = <0x180 0x80>;
> + clocks = <&l4ls_gclk>;
> + clock-names = "fck";
> + interrupts = <79>;
> + status = "disabled";
> + };
> +
You probably no longer need to map any clocks here as this
is now a child of the interconnect target module managed
by ti-sysc driver. I have not checked but probably l4ls_gclk
is same as clocks = <&l4ls_clkctrl AM3_L4LS_EPWMSS0_CLKCTRL 0>
already managed by ti-sysc. If so, then just using runtime PM
calls in any of the child device drivers will keep it enabled.
If l4ls_gclk is a separate functional clock, then it still
needs to be managed by the child device driver directly.
Regards,
Tony
Re: nl80211 wlcore regression in next
* Johannes Berg [190723 05:08]: > Hi, > > > Looks like this one crept back as the fix is missing from v5.3-rc1. > > > > Forgot to include in the pull request? > > More like forgot to send the pull request, my bad. I eventually realized > a couple of days ago and it'll be coming upstream soon. Sorry about > that. OK thanks, Tony
Re: nl80211 wlcore regression in next
Hi,
* Johannes Berg [190625 08:03]:
> On Tue, 2019-06-25 at 01:00 -0700, Tony Lindgren wrote:
> > Hi,
> >
> > * Johannes Berg [190625 07:47]:
> > > On Tue, 2019-06-25 at 00:38 -0700, Tony Lindgren wrote:
> > > > Hi,
> > > >
> > > > Looks like at least drivers/net/wireless/ti wlcore driver has stopped
> > > > working in Linux next with commit 901bb9891855 ("nl80211: require and
> > > > validate vendor command policy"). Reverting the commit above makes it
> > > > work again.
> > > >
> > > > It fails with the warning below, any ideas what goes wrong?
> > >
> > > Oops. For some reason, I neglected to check the vendor command usage
> > > beyond hwsim.
> > >
> > > The patch below should work?
> >
> > Yeah thanks that fixes the issue for me:
> >
> > Tested-by: Tony Lindgren
>
> Thanks, I'll drop that into my tree and hopefully will remember to send
> it on soon.
Looks like this one crept back as the fix is missing from v5.3-rc1.
Forgot to include in the pull request?
Regards,
Tony
Re: [PATCH 5/5] bus: ti-sysc: Simplify cleanup upon failures in sysc_probe()
Hi, * Suman Anna [190625 23:33]: > The clocks are not yet parsed and prepared until after a successful > sysc_get_clocks(), so there is no need to unprepare the clocks upon > any failure of any of the prior functions in sysc_probe(). The current > code path would have been a no-op because of the clock validity checks > within sysc_unprepare(), but let's just simplify the cleanup path by > returning the error directly. > > While at this, also fix the cleanup path for a sysc_init_resets() > failure which is executed after the clocks are prepared. Sounds like this should get queued separately as a fix for v5.3-rc cycle, probably got broken with the recent ti-sysc init order changes. Regards, Tony
Re: [PATCH] ARM: dts: am57xx: Disable voltage switching for SD card
* Faiz Abbas [190619 03:25]:
> If UHS speed modes are enabled, a compatible SD card switches down to
> 1.8V during enumeration. If after this a software reboot/crash takes
> place and on-chip ROM tries to enumerate the SD card, the difference in
> IO voltages (host @ 3.3V and card @ 1.8V) may end up damaging the card.
>
> The fix for this is to have support for power cycling the card in
> hardware (with a PORz/soft-reset line causing a power cycle of the
> card). Because the beaglebone X15 (rev A,B and C), am57xx-idks and
> am57xx-evms don't have this capability, disable voltage switching for
> these boards.
>
> The major effect of this is that the maximum supported speed
> mode is now high speed(50 MHz) down from SDR104(200 MHz).
>
> commit 88a748419b84 ("ARM: dts: am57xx-idk: Remove support for voltage
> switching for SD card") did this only for idk boards. Do it for all
> affected boards.
Thanks applying into fixes.
Regards,
Tony
Re: nl80211 wlcore regression in next
Hi,
* Johannes Berg [190625 07:47]:
> On Tue, 2019-06-25 at 00:38 -0700, Tony Lindgren wrote:
> > Hi,
> >
> > Looks like at least drivers/net/wireless/ti wlcore driver has stopped
> > working in Linux next with commit 901bb9891855 ("nl80211: require and
> > validate vendor command policy"). Reverting the commit above makes it
> > work again.
> >
> > It fails with the warning below, any ideas what goes wrong?
>
> Oops. For some reason, I neglected to check the vendor command usage
> beyond hwsim.
>
> The patch below should work?
Yeah thanks that fixes the issue for me:
Tested-by: Tony Lindgren
nl80211 wlcore regression in next
Hi,
Looks like at least drivers/net/wireless/ti wlcore driver has stopped
working in Linux next with commit 901bb9891855 ("nl80211: require and
validate vendor command policy"). Reverting the commit above makes it
work again.
It fails with the warning below, any ideas what goes wrong?
Regards,
Tony
8<
WARNING: CPU: 0 PID: 21 at net/wireless/core.c:868 wiphy_register+0x85c/0xbd4
[cfg80211]
...
[] (wiphy_register [cfg80211]) from []
(ieee80211_register_hw+0x4e4/0xcd8 [mac80211])
[] (ieee80211_register_hw [mac80211]) from []
(wlcore_nvs_cb+0x758/0xabc [wlcore])
[] (wlcore_nvs_cb [wlcore]) from []
(request_firmware_work_func+0x50/0x8c)
[] (request_firmware_work_func) from []
(process_one_work+0x20c/0x504)
...
Re: [PATCH-next 00/20] gpio: gpio-omap: set of fixes and big clean-up
Hi, * Grygorii Strashko [190610 10:11]: > Hi Linus, Russell, Tony, All, > > This series contains set of patches from Russell King which were circulated > internally for quite some time already and I fill it's reasonable to move > future discussion upstream (and also avoid rebasing). > Fisrt two patches are fixes and the rest are big, great clean up > from Russell King. > > Personally, I like this clean up and refactoring very much and don't want > it to be lost. Adding Aaro to Cc too hopefully for more testing. Yes this is very nice and behaves for my idle test cases. I've also boot tested omap1 osk and it still works just fine for NFSroot. FYI, after this series, the only issue I'm aware of still remaining is the lost edge wake-up interrupts for L4 PER idle that I posted a WIP fix as "[PATCH] gpio: gpio-omap: Fix lost edge wake-up interrupts". But that one still needs a bit more work and is a separate fix from this series. So for this whole series, please feel free to add: Tested-by: Tony Lindgren > Code can be found at: > g...@git.ti.com:~gragst/ti-linux-kernel/gragsts-ti-linux-kernel.git > branch: > lkml-next-gpio-clean-up > > Russell King (20): > gpio: gpio-omap: ensure irq is enabled before wakeup > gpio: gpio-omap: fix lack of irqstatus_raw0 for OMAP4 > gpio: gpio-omap: remove remainder of list management > gpio: gpio-omap: clean up edge interrupt handling > gpio: gpio-omap: remove irq_ack method > gpio: gpio-omap: move omap_gpio_request() and omap_gpio_free() > gpio: gpio-omap: simplify omap_gpio_get_direction() > gpio: gpio-omap: simplify get() method > gpio: gpio-omap: simplify get_multiple() > gpio: gpio-omap: simplify set_multiple() > gpio: gpio-omap: simplify bank->level_mask > gpio: gpio-omap: simplify read-modify-write > gpio: gpio-omap: simplify omap_toggle_gpio_edge_triggering() > gpio: gpio-omap: simplify omap_set_gpio_irqenable() > gpio: gpio-omap: remove dataout variation in context handling > gpio: gpio-omap: clean up omap_gpio_restore_context() > gpio: gpio-omap: constify register tables > gpio: gpio-omap: clean up wakeup handling > gpio: gpio-omap: irq_startup() must not return error codes > gpio: gpio-omap: clean up register access in omap2_set_gpio_debounce() > > drivers/gpio/gpio-omap.c| 497 > include/linux/platform_data/gpio-omap.h | 2 +- > 2 files changed, 161 insertions(+), 338 deletions(-) > > -- > 2.17.1 >
Re: [PATCH] soc: ti: pm33xx: Add a print while entering RTC only mode with DDR in self-refresh
* Tony Lindgren [190429 18:43]: > * santosh.shilim...@oracle.com [190429 18:40]: > > On 4/28/19 9:44 PM, Keerthy wrote: > > > Currently there is no way to distinguish if the SoC entered DS0 > > > mode or the RTC only mode. Hence add a print before entering > > > the RTC only mode. > > > > > > Signed-off-by: Keerthy > > > --- > > Acked-by: Santosh Shilimkar > > > > Tony, Am assuming you will queue this up ? > > OK yeah I'll queue it. Just found this still sitting in my inbox, applying into omap-for-v5.3/soc. Sorry for the delay. Regards, Tony
Re: [PATCH -next] ARM: OMAP2+: Make some variables static
Hi, * Yue Haibing [190413 07:18]: > From: YueHaibing > > Fix sparse warnings: > > arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c:532:25: warning: > symbol 'am33xx_gpio_hwmod_class' was not declared. Should it be static? > arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c:542:19: warning: > symbol 'am33xx_gpio1_hwmod' was not declared. Should it be static? > arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c:562:19: warning: > symbol 'am33xx_gpio2_hwmod' was not declared. Should it be static? > arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c:582:19: warning: > symbol 'am33xx_gpio3_hwmod' was not declared. Should it be static? I just noticed this is still pending, sorry for the delay. Applying into omap-for-v5.3/soc. Regards, Tony
[PATCH] bus: ti-sysc: Add support for module specific reset quirks
Some older interconnect target modules need module internal clock
toggling quirks to reset properly. We've been doing this in the
platform code earlier, but need to be able to it directly in the
ti-sysc driver when we no longer rely on on the platform code.
Let's add reset handling for 1-wire, i2c and watchdog. Later on
we can add more modules like msdi and dss as they get tested.
For dra7 pcie, we should be able to just use the rstctrl reset
driver when available.
Signed-off-by: Tony Lindgren
---
This is based on the following series I posted earlier:
[PATCHv2 00/13] ti-sysc driver changes to drop custom hwmods property
---
drivers/bus/ti-sysc.c | 129 +-
include/linux/platform_data/ti-sysc.h | 3 +
2 files changed, 127 insertions(+), 5 deletions(-)
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
@@ -71,6 +71,9 @@ static const char * const clock_names[SYSC_MAX_CLOCKS] = {
* @name: name if available
* @revision: interconnect target module revision
* @needs_resume: runtime resume needed on resume from suspend
+ * @clk_enable_quirk: module specific clock enable quirk
+ * @clk_disable_quirk: module specific clock disable quirk
+ * @reset_done_quirk: module specific reset done quirk
*/
struct sysc {
struct device *dev;
@@ -94,6 +97,9 @@ struct sysc {
unsigned int child_needs_resume:1;
unsigned int disable_on_idle:1;
struct delayed_work idle_work;
+ void (*clk_enable_quirk)(struct sysc *sysc);
+ void (*clk_disable_quirk)(struct sysc *sysc);
+ void (*reset_done_quirk)(struct sysc *sysc);
};
static void sysc_parse_dts_quirks(struct sysc *ddata, struct device_node *np,
@@ -760,8 +766,11 @@ static int sysc_ioremap(struct sysc *ddata)
ddata->offsets[SYSC_SYSCONFIG],
ddata->offsets[SYSC_SYSSTATUS]);
+ if (size < SZ_1K)
+ size = SZ_1K;
+
if ((size + sizeof(u32)) > ddata->module_size)
- return -EINVAL;
+ size = ddata->module_size;
}
ddata->module_va = devm_ioremap(ddata->dev,
@@ -1234,6 +1243,22 @@ static const struct sysc_revision_quirk
sysc_revision_quirks[] = {
SYSC_QUIRK_EXT_OPT_CLOCK | SYSC_QUIRK_NO_RESET_ON_INIT |
SYSC_QUIRK_SWSUP_SIDLE),
+ /* Quirks that need to be set based on detected module */
+ SYSC_QUIRK("hdq1w", 0, 0, 0x14, 0x18, 0x0006, 0x,
+ SYSC_MODULE_QUIRK_HDQ1W),
+ SYSC_QUIRK("hdq1w", 0, 0, 0x14, 0x18, 0x000a, 0x,
+ SYSC_MODULE_QUIRK_HDQ1W),
+ SYSC_QUIRK("i2c", 0, 0, 0x20, 0x10, 0x0036, 0x00ff,
+ SYSC_MODULE_QUIRK_I2C),
+ SYSC_QUIRK("i2c", 0, 0, 0x20, 0x10, 0x003c, 0x00ff,
+ SYSC_MODULE_QUIRK_I2C),
+ SYSC_QUIRK("i2c", 0, 0, 0x20, 0x10, 0x0040, 0x00ff,
+ SYSC_MODULE_QUIRK_I2C),
+ SYSC_QUIRK("i2c", 0, 0, 0x10, 0x90, 0x504a, 0xf0f0,
+ SYSC_MODULE_QUIRK_I2C),
+ SYSC_QUIRK("wdt", 0, 0, 0x10, 0x14, 0x502a0500, 0xf0f0,
+ SYSC_MODULE_QUIRK_WDT),
+
#ifdef DEBUG
SYSC_QUIRK("adc", 0, 0, 0x10, -1, 0x4731, 0x, 0),
SYSC_QUIRK("atl", 0, 0, -1, -1, 0x0a070100, 0x, 0),
@@ -1247,11 +1272,8 @@ static const struct sysc_revision_quirk
sysc_revision_quirks[] = {
SYSC_QUIRK("dwc3", 0, 0, 0x10, -1, 0x500a0200, 0x, 0),
SYSC_QUIRK("epwmss", 0, 0, 0x4, -1, 0x4741, 0x, 0),
SYSC_QUIRK("gpu", 0, 0x1fc00, 0x1fc10, -1, 0, 0, 0),
- SYSC_QUIRK("hdq1w", 0, 0, 0x14, 0x18, 0x0006, 0x, 0),
- SYSC_QUIRK("hdq1w", 0, 0, 0x14, 0x18, 0x000a, 0x, 0),
SYSC_QUIRK("hsi", 0, 0, 0x10, 0x14, 0x50043101, 0x, 0),
SYSC_QUIRK("iss", 0, 0, 0x10, -1, 0x4101, 0x, 0),
- SYSC_QUIRK("i2c", 0, 0, 0x10, 0x90, 0x504a, 0xf0f0, 0),
SYSC_QUIRK("lcdc", 0, 0, 0x54, -1, 0x4f201000, 0x, 0),
SYSC_QUIRK("mcasp", 0, 0, 0x4, -1, 0x44306302, 0x, 0),
SYSC_QUIRK("mcasp", 0, 0, 0x4, -1, 0x44307b02, 0x, 0),
@@ -1287,7 +1309,6 @@ static const struct sysc_revision_quirk
sysc_revision_quirks[] = {
SYSC_QUIRK("usb_host_hs", 0, 0, 0x10, -1, 0x50700101, 0x, 0),
SYSC_QUIRK("usb_otg_hs", 0, 0x400, 0x404, 0x408, 0x0050,
0x, 0),
- SYSC_QUIRK("wdt", 0, 0, 0x10, 0x14, 0x502a0500, 0xf0f0, 0),
SYSC_QUIRK("vfpe", 0, 0, 0x104, -1,
Re: [PATCH] wlcore/wl18xx: Add invert-irq OF property for physically inverted IRQ
Hi,
* Kalle Valo [190610 07:01]:
> Eugeniu Rosca writes:
>
> > The wl1837mod datasheet [1] says about the WL_IRQ pin:
> >
> > ---8<---
> > SDIO available, interrupt out. Active high. [..]
> > Set to rising edge (active high) on powerup.
> > ---8<---
> >
> > That's the reason of seeing the interrupt configured as:
> > - IRQ_TYPE_EDGE_RISING on HiKey 960/970
> > - IRQ_TYPE_LEVEL_HIGH on a number of i.MX6 platforms
> >
> > We assert that all those platforms have the WL_IRQ pin connected
> > to the SoC _directly_ (confirmed on HiKey 970 [2]).
> >
> > That's not the case for R-Car Kingfisher extension target, which carries
> > a WL1837MODGIMOCT IC. There is an SN74LV1T04DBVR inverter present
> > between the WLAN_IRQ pin of the WL18* chip and the SoC, effectively
> > reversing the requirement quoted from [1]. IOW, in Kingfisher DTS
> > configuration we would need to use IRQ_TYPE_EDGE_FALLING or
> > IRQ_TYPE_LEVEL_LOW.
> >
> > Unfortunately, v4.2-rc1 commit bd763482c82ea2 ("wl18xx: wlan_irq:
> > support platform dependent interrupt types") made a special case out
> > of these interrupt types. After this commit, it is impossible to provide
> > an IRQ configuration via DTS which would describe an inverter present
> > between the WL18* chip and the SoC, generating the need for workarounds
> > like [3].
> >
> > Create a boolean OF property, called "invert-irq" to specify that
> > the WLAN_IRQ pin of WL18* is connected to the SoC via an inverter.
> >
> > This solution has been successfully tested on R-Car H3ULCB-KF-M06 using
> > the DTS configuration [4] combined with the "invert-irq" property.
> >
> > [1] http://www.ti.com/lit/ds/symlink/wl1837mod.pdf
> > [2]
> > https://www.96boards.org/documentation/consumer/hikey/hikey970/hardware-docs/
> > [3]
> > https://github.com/CogentEmbedded/meta-rcar/blob/289fbd4f8354/meta-rcar-gen3-adas/recipes-kernel/linux/linux-renesas/0024-wl18xx-do-not-invert-IRQ-on-WL-side.patch
> > [4] https://patchwork.kernel.org/patch/10895879/
> > ("arm64: dts: ulcb-kf: Add support for TI WL1837")
> >
> > Signed-off-by: Eugeniu Rosca
>
> Tony&Eyal, do you agree with this?
Yeah if there's some hardware between the WLAN device and the SoC
inverting the interrupt, I don't think we have clear a way to deal
with it short of setting up a separate irqchip that does the
translation.
But in some cases we also do not want to invert the interrupt, so
I think this property should take IRQ_TYPE_EDGE_RISING and
IRQ_TYPE_EDGE_RISING values to override the setting for
the WLAN end of the hardware?
Let's wait a bit longer for comments from Eyal too.
Regards,
Tony
Re: [PATCH] arm: dts: dra72x: Disable usb4_tm target module
* Keerthy [190603 23:13]: > usb4_tm is unsed on dra72 and accessing the module > with ti,sysc is causing a boot crash hence disable its target > module. Thanks for testing and fixing this, applying into fixes. Tony
Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support
* Tomi Valkeinen [190529 07:06]: > On 28/05/2019 13:18, Tony Lindgren wrote: > > > > My board is x15 rev A3, attached to AM5 EVM. I've also attached my kernel > > > config. > > > > Strange that this is not affecting other x15? I think timer12 would > > be blocked on HS devices though? > > Seems that the kernel config affects. omap2plus_defconfig boots ok. OK, this line in your oops: Unable to handle kernel paging request at virtual address 5a5a5a5a Probably means we hit some slab poison with DEBUG_SLAB set. Looks like your config boots fine with DEBUG_SLAB disabled for me. As this only happens for timer12, I wonder if we're again hitting some uncompress issue with corrupted dtb. Changing u-boot ftdaddr higher up might possibly make it go away. Or else there's a bug elsewhere :) Regards, Tony
Re: [PATCH 01/12] bus: ti-sysc: Support 16-bit writes too
* David Laight [190528 11:06]:
> From: Tony Lindgren
> > Sent: 27 May 2019 13:14
> > We need to also support 16-bit writes for i2c in addition to the reads
> > when we start configuring the sysconfig register for reset and idle modes.
> >
> > Signed-off-by: Tony Lindgren
> > ---
> > drivers/bus/ti-sysc.c | 7 +++
> > 1 file changed, 7 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
> > @@ -100,6 +100,13 @@ static void sysc_parse_dts_quirks(struct sysc *ddata,
> > struct device_node *np,
> >
> > static void sysc_write(struct sysc *ddata, int offset, u32 value)
> > {
> > + if (ddata->cfg.quirks & SYSC_QUIRK_16BIT) {
> > + writew_relaxed(value & 0x, ddata->module_va + offset);
> > + writew_relaxed(value >> 16, ddata->module_va + offset + 4);
>
> Should that be + 2 ???
Well the stride for I2C revision registers is 4. But while checking
that again, I noticed that the other registers do not have HI and LO
registers and should just use a single 16-bit read and write. So far
it's harmless, but should be fixed.
Updated patch below.
Regards,
Tony
8<
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren
Date: Mon, 27 May 2019 04:51:53 -0700
Subject: [PATCH] bus: ti-sysc: Support 16-bit writes too
We need to also support 16-bit writes for i2c in addition to the reads
when we start configuring the sysconfig register for reset and idle modes.
Note that only i2c revision register has LO and HI registers, so let's
add a check also for 16-bit register read. This change is currently cosmetic
and does not affect anything until we enable the module specific quirk
handling for i2c reset and enable later on.
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
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
@@ -100,6 +100,20 @@ static void sysc_parse_dts_quirks(struct sysc *ddata,
struct device_node *np,
static void sysc_write(struct sysc *ddata, int offset, u32 value)
{
+ if (ddata->cfg.quirks & SYSC_QUIRK_16BIT) {
+ writew_relaxed(value & 0x, ddata->module_va + offset);
+
+ /* Only i2c revision has LO and HI register with stride of 4 */
+ if (ddata->offsets[SYSC_REVISION] >= 0 &&
+ offset == ddata->offsets[SYSC_REVISION]) {
+ u16 hi = value >> 16;
+
+ writew_relaxed(hi, ddata->module_va + offset + 4);
+ }
+
+ return;
+ }
+
writel_relaxed(value, ddata->module_va + offset);
}
@@ -109,7 +123,14 @@ static u32 sysc_read(struct sysc *ddata, int offset)
u32 val;
val = readw_relaxed(ddata->module_va + offset);
- val |= (readw_relaxed(ddata->module_va + offset + 4) << 16);
+
+ /* Only i2c revision has LO and HI register with stride of 4 */
+ if (ddata->offsets[SYSC_REVISION] >= 0 &&
+ offset == ddata->offsets[SYSC_REVISION]) {
+ u16 tmp = readw_relaxed(ddata->module_va + offset + 4);
+
+ val |= tmp << 16;
+ }
return val;
}
--
2.21.0
[PATCH 07/13] bus: ti-sysc: Handle swsup idle mode quirks
Some modules have idlemodes wired, but not completely functional. We have
quirks for SWSUP_SIDLE and SWSUP_SIDLE_ACT to manage interconnect target
modules without hardware support, but we've been only using them so far
in legacy mode. Let's add support for SWSUP quirks in non-legacy mode too.
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
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
@@ -872,10 +872,15 @@ static int sysc_enable_module(struct device *dev)
if (!idlemodes || regbits->sidle_shift < 0)
goto set_midle;
- best_mode = fls(ddata->cfg.sidlemodes) - 1;
- if (best_mode > SYSC_IDLE_MASK) {
- dev_err(dev, "%s: invalid sidlemode\n", __func__);
- return -EINVAL;
+ if (ddata->cfg.quirks & (SYSC_QUIRK_SWSUP_SIDLE |
+SYSC_QUIRK_SWSUP_SIDLE_ACT)) {
+ best_mode = SYSC_IDLE_NO;
+ } else {
+ best_mode = fls(ddata->cfg.sidlemodes) - 1;
+ if (best_mode > SYSC_IDLE_MASK) {
+ dev_err(dev, "%s: invalid sidlemode\n", __func__);
+ return -EINVAL;
+ }
}
reg &= ~(SYSC_IDLE_MASK << regbits->sidle_shift);
@@ -959,10 +964,14 @@ static int sysc_disable_module(struct device *dev)
if (!idlemodes || regbits->sidle_shift < 0)
return 0;
- ret = sysc_best_idle_mode(idlemodes, &best_mode);
- if (ret) {
- dev_err(dev, "%s: invalid sidlemode\n", __func__);
- return ret;
+ if (ddata->cfg.quirks & SYSC_QUIRK_SWSUP_SIDLE) {
+ best_mode = SYSC_IDLE_FORCE;
+ } else {
+ ret = sysc_best_idle_mode(idlemodes, &best_mode);
+ if (ret) {
+ dev_err(dev, "%s: invalid sidlemode\n", __func__);
+ return ret;
+ }
}
reg &= ~(SYSC_IDLE_MASK << regbits->sidle_shift);
--
2.21.0
[PATCH 01/13] bus: ti-sysc: Add support for missing clockdomain handling
We need to let ti-sysc driver manage clockdomain autoidle for the
duration of of reset, enable and idle. And we need to do it before we
enable the clock and after we disable it. Currently we are still
relying on platform callbacks indirectly managing clockdomain autoidle.
But I noticed that for device tree only probed drivers it now happens
only after we enabling the clocks and before we disable the clocks,
while it should be the other way around. So far I have not noticed
any issues with this though.
Let's add new ti_sysc_clkdm_deny_idle() and ti_sysc_clkdm_allow_idle()
functions for ti-sysc driver to use to manage clockdomains directly via
platform data callbacks. Note that we can implement the clockdomain
functions in pdata-quirks.c as for probing devices without "ti,hwmods"
custom property we don't need to use the other platform data callbacks.
Let's do this in one patch as there's is still an unlikely chance we
may need to apply this as a fix for v5.2 for dropping legacy platform
data for some devices. We also do have the option of adding back the
platform data if needed in case of trouble.
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/omap_hwmod.c | 39 +---
arch/arm/mach-omap2/pdata-quirks.c| 60
drivers/bus/ti-sysc.c | 127 --
include/linux/platform_data/ti-sysc.h | 8 ++
4 files changed, 174 insertions(+), 60 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3445,6 +3445,7 @@ static int omap_hwmod_check_module(struct device *dev,
* @dev: struct device
* @oh: module
* @sysc_fields: sysc register bits
+ * @clockdomain: clockdomain
* @rev_offs: revision register offset
* @sysc_offs: sysconfig register offset
* @syss_offs: sysstatus register offset
@@ -3456,6 +3457,7 @@ static int omap_hwmod_check_module(struct device *dev,
static int omap_hwmod_allocate_module(struct device *dev, struct omap_hwmod
*oh,
const struct ti_sysc_module_data *data,
struct sysc_regbits *sysc_fields,
+ struct clockdomain *clkdm,
s32 rev_offs, s32 sysc_offs,
s32 syss_offs, u32 sysc_flags,
u32 idlemodes)
@@ -3463,8 +3465,6 @@ static int omap_hwmod_allocate_module(struct device *dev,
struct omap_hwmod *oh,
struct omap_hwmod_class_sysconfig *sysc;
struct omap_hwmod_class *class = NULL;
struct omap_hwmod_ocp_if *oi = NULL;
- struct clockdomain *clkdm = NULL;
- struct clk *clk = NULL;
void __iomem *regs = NULL;
unsigned long flags;
@@ -3511,36 +3511,6 @@ static int omap_hwmod_allocate_module(struct device
*dev, struct omap_hwmod *oh,
oi->user = OCP_USER_MPU | OCP_USER_SDMA;
}
- if (!oh->_clk) {
- struct clk_hw_omap *hwclk;
-
- clk = of_clk_get_by_name(dev->of_node, "fck");
- if (!IS_ERR(clk))
- clk_prepare(clk);
- else
- clk = NULL;
-
- /*
-* Populate clockdomain based on dts clock. It is needed for
-* clkdm_deny_idle() and clkdm_allow_idle() until we have have
-* interconnect driver and reset driver capable of blocking
-* clockdomain idle during reset, enable and idle.
-*/
- if (clk) {
- hwclk = to_clk_hw_omap(__clk_get_hw(clk));
- if (hwclk && hwclk->clkdm_name)
- clkdm = clkdm_lookup(hwclk->clkdm_name);
- }
-
- /*
-* Note that we assume interconnect driver manages the clocks
-* and do not need to populate oh->_clk for dynamically
-* allocated modules.
-*/
- clk_unprepare(clk);
- clk_put(clk);
- }
-
spin_lock_irqsave(&oh->_lock, flags);
if (regs)
oh->_mpu_rt_va = regs;
@@ -3626,7 +3596,7 @@ int omap_hwmod_init_module(struct device *dev,
u32 sysc_flags, idlemodes;
int error;
- if (!dev || !data)
+ if (!dev || !data || !data->name || !cookie)
return -EINVAL;
oh = _lookup(data->name);
@@ -3697,7 +3667,8 @@ int omap_hwmod_init_module(struct device *dev,
return error;
return omap_hwmod_allocate_module(dev, oh, data, sysc_fields,
- rev_offs, sysc_offs, syss_offs,
+ cookie->clkdm, rev_offs,
+
[PATCH 10/13] bus: ti-sysc: Do rstctrl reset handling in two phases
We need to deassert rstctrl resets before enabling clocks to avoid clock
"failed to enable" errors. For asserting rstctrl reset, the clocks need
to be enabled.
As the reset controller status is not available for arrays, let's use
devm_reset_control_get_optional() so we can get the status after reset.
Note that depends on a proper PRM rstctrl driver, so far I've only
tested this with earlier reset-simple patches.
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
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
@@ -483,7 +483,7 @@ static void sysc_clkdm_allow_idle(struct sysc *ddata)
static int sysc_init_resets(struct sysc *ddata)
{
ddata->rsts =
- devm_reset_control_array_get_optional_exclusive(ddata->dev);
+ devm_reset_control_get_optional(ddata->dev, "rstctrl");
if (IS_ERR(ddata->rsts))
return PTR_ERR(ddata->rsts);
@@ -1407,7 +1407,7 @@ static int sysc_legacy_init(struct sysc *ddata)
*/
static int sysc_rstctrl_reset_deassert(struct sysc *ddata, bool reset)
{
- int error;
+ int error, val;
if (!ddata->rsts)
return 0;
@@ -1418,7 +1418,14 @@ static int sysc_rstctrl_reset_deassert(struct sysc
*ddata, bool reset)
return error;
}
- return reset_control_deassert(ddata->rsts);
+ error = reset_control_deassert(ddata->rsts);
+ if (error == -EEXIST)
+ return 0;
+
+ error = readx_poll_timeout(reset_control_status, ddata->rsts, val,
+ val == 0, 100, MAX_MODULE_SOFTRESET_WAIT);
+
+ return error;
}
/*
@@ -1476,12 +1483,8 @@ static int sysc_init_module(struct sysc *ddata)
{
int error = 0;
bool manage_clocks = true;
- bool reset = true;
- if (ddata->cfg.quirks & SYSC_QUIRK_NO_RESET_ON_INIT)
- reset = false;
-
- error = sysc_rstctrl_reset_deassert(ddata, reset);
+ error = sysc_rstctrl_reset_deassert(ddata, false);
if (error)
return error;
@@ -1505,6 +1508,12 @@ static int sysc_init_module(struct sysc *ddata)
goto err_opt_clocks;
}
+ if (!(ddata->cfg.quirks & SYSC_QUIRK_NO_RESET_ON_INIT)) {
+ error = sysc_rstctrl_reset_deassert(ddata, true);
+ if (error)
+ goto err_main_clocks;
+ }
+
ddata->revision = sysc_read_revision(ddata);
sysc_init_revision_quirks(ddata);
--
2.21.0
[PATCH 05/13] bus: ti-sysc: Enable interconnect target module autoidle bit on enable
For interconnect target modules with autoidle bit wired, we need to manage
it for enable and disable.
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
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
@@ -879,7 +879,7 @@ static int sysc_enable_module(struct device *dev)
/* Set MIDLE mode */
idlemodes = ddata->cfg.midlemodes;
if (!idlemodes || regbits->midle_shift < 0)
- return 0;
+ goto set_autoidle;
best_mode = fls(ddata->cfg.midlemodes) - 1;
if (best_mode > SYSC_IDLE_MASK) {
@@ -891,6 +891,14 @@ static int sysc_enable_module(struct device *dev)
reg |= best_mode << regbits->midle_shift;
sysc_write(ddata, ddata->offsets[SYSC_SYSCONFIG], reg);
+set_autoidle:
+ /* Autoidle bit must enabled separately if available */
+ if (regbits->autoidle_shift >= 0 &&
+ ddata->cfg.sysc_val & BIT(regbits->autoidle_shift)) {
+ reg |= 1 << regbits->autoidle_shift;
+ sysc_write(ddata, ddata->offsets[SYSC_SYSCONFIG], reg);
+ }
+
return 0;
}
@@ -952,6 +960,9 @@ static int sysc_disable_module(struct device *dev)
reg &= ~(SYSC_IDLE_MASK << regbits->sidle_shift);
reg |= best_mode << regbits->sidle_shift;
+ if (regbits->autoidle_shift >= 0 &&
+ ddata->cfg.sysc_val & BIT(regbits->autoidle_shift))
+ reg |= 1 << regbits->autoidle_shift;
sysc_write(ddata, ddata->offsets[SYSC_SYSCONFIG], reg);
return 0;
--
2.21.0
[PATCH 03/13] bus: ti-sysc: Make OCP reset work for sysstatus and sysconfig reset bits
We've had minimal OCP softreset support in ti-sysc interconnect target
module driver only used for MCAN driver so far. But it turns out that
MCAN has the sysstatus register resetdone bit inverted compared to most
other modules.
Let's make OCP softreset work for other typical cases with reset status
in sysstatus or sysconfig register so we can use the new functions for
sysc_enable_module() and sysc_disable_module() without "ti,hwmods"
property in the following patches.
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 72 ---
include/linux/platform_data/ti-sysc.h | 1 +
2 files changed, 55 insertions(+), 18 deletions(-)
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
@@ -139,6 +139,26 @@ static u32 sysc_read_revision(struct sysc *ddata)
return sysc_read(ddata, offset);
}
+static u32 sysc_read_sysconfig(struct sysc *ddata)
+{
+ int offset = ddata->offsets[SYSC_SYSCONFIG];
+
+ if (offset < 0)
+ return 0;
+
+ return sysc_read(ddata, offset);
+}
+
+static u32 sysc_read_sysstatus(struct sysc *ddata)
+{
+ int offset = ddata->offsets[SYSC_SYSSTATUS];
+
+ if (offset < 0)
+ return 0;
+
+ return sysc_read(ddata, offset);
+}
+
static int sysc_add_named_clock_from_child(struct sysc *ddata,
const char *name,
const char *optfck_name)
@@ -1356,34 +1376,49 @@ static int sysc_rstctrl_reset_deassert(struct sysc
*ddata, bool reset)
return reset_control_deassert(ddata->rsts);
}
+/*
+ * Note that the caller must ensure the interconnect target module is enabled
+ * before calling reset. Otherwise reset will not complete.
+ */
static int sysc_reset(struct sysc *ddata)
{
- int offset = ddata->offsets[SYSC_SYSCONFIG];
- int val;
+ int sysc_offset, syss_offset, sysc_val, rstval, quirks, error = 0;
+ u32 sysc_mask, syss_done;
+
+ sysc_offset = ddata->offsets[SYSC_SYSCONFIG];
+ syss_offset = ddata->offsets[SYSC_SYSSTATUS];
+ quirks = ddata->cfg.quirks;
- if (ddata->legacy_mode || offset < 0 ||
+ if (ddata->legacy_mode || sysc_offset < 0 ||
+ ddata->cap->regbits->srst_shift < 0 ||
ddata->cfg.quirks & SYSC_QUIRK_NO_RESET_ON_INIT)
return 0;
- /*
-* Currently only support reset status in sysstatus.
-* Warn and return error in all other cases
-*/
- if (!ddata->cfg.syss_mask) {
- dev_err(ddata->dev, "No ti,syss-mask. Reset failed\n");
- return -EINVAL;
- }
+ sysc_mask = BIT(ddata->cap->regbits->srst_shift);
- val = sysc_read(ddata, offset);
- val |= (0x1 << ddata->cap->regbits->srst_shift);
- sysc_write(ddata, offset, val);
+ if (ddata->cfg.quirks & SYSS_QUIRK_RESETDONE_INVERTED)
+ syss_done = 0;
+ else
+ syss_done = ddata->cfg.syss_mask;
+
+ sysc_val = sysc_read_sysconfig(ddata);
+ sysc_val |= sysc_mask;
+ sysc_write(ddata, sysc_offset, sysc_val);
/* Poll on reset status */
- offset = ddata->offsets[SYSC_SYSSTATUS];
+ if (syss_offset >= 0) {
+ error = readx_poll_timeout(sysc_read_sysstatus, ddata, rstval,
+ (rstval & ddata->cfg.syss_mask) ==
+ syss_done,
+ 100, MAX_MODULE_SOFTRESET_WAIT);
+
+ } else if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
+ error = readx_poll_timeout(sysc_read_sysconfig, ddata, rstval,
+ !(rstval & sysc_mask),
+ 100, MAX_MODULE_SOFTRESET_WAIT);
+ }
- return readl_poll_timeout(ddata->module_va + offset, val,
- (val & ddata->cfg.syss_mask) == 0x0,
- 100, MAX_MODULE_SOFTRESET_WAIT);
+ return error;
}
/*
@@ -2086,6 +2121,7 @@ static const struct sysc_capabilities sysc_dra7_mcan = {
.type = TI_SYSC_DRA7_MCAN,
.sysc_mask = SYSC_DRA7_MCAN_ENAWAKEUP | SYSC_OMAP4_SOFTRESET,
.regbits = &sysc_regbits_dra7_mcan,
+ .mod_quirks = SYSS_QUIRK_RESETDONE_INVERTED,
};
static int sysc_init_pdata(struct sysc *ddata)
diff --git a/include/linux/platform_data/ti-sysc.h
b/include/linux/platform_data/ti-sysc.h
--- a/include/linux/platform_data/ti-sysc.h
+++ b/include/linux/platform_data/ti-sysc.h
@@ -47,6 +47,7 @@ struct sysc_regbits {
s8 emufree_shift;
};
+#define SYSS_QUIRK_RESETDONE_INVERTED BIT(14)
#define SYSC_QUIRK_SWSUP_MSTANDBY BIT(13)
#define SYSC_QUIRK_SWSUP_SIDLE_ACT BIT(12)
#define SYSC_QUIRK_SWSUP_SIDLE BIT(11)
--
2.21.0
[PATCH 09/13] bus: ti-sysc: Add support for disabling module without legacy mode
We must not assert reset for modules with no child device drivers
until in runtime_suspend. Otherwise register access will fail without
legacy mode helping us.
Let's add a flag for disable_on_idle and move the reset driver
handling to runtime suspend and resume. We can then also use the
disable_on_idle flag to reconfigure sysconfig register for PM
modes requesting it.
Let's also make the other flags use bitfield while at it instead of
bool.
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
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
@@ -89,9 +89,10 @@ struct sysc {
struct ti_sysc_cookie cookie;
const char *name;
u32 revision;
- bool enabled;
- bool needs_resume;
- bool child_needs_resume;
+ unsigned int enabled:1;
+ unsigned int needs_resume:1;
+ unsigned int child_needs_resume:1;
+ unsigned int disable_on_idle:1;
struct delayed_work idle_work;
};
@@ -1007,6 +1008,9 @@ static int __maybe_unused
sysc_runtime_suspend_legacy(struct device *dev,
dev_err(dev, "%s: could not idle: %i\n",
__func__, error);
+ if (ddata->disable_on_idle)
+ reset_control_assert(ddata->rsts);
+
return 0;
}
@@ -1016,6 +1020,9 @@ static int __maybe_unused
sysc_runtime_resume_legacy(struct device *dev,
struct ti_sysc_platform_data *pdata;
int error;
+ if (ddata->disable_on_idle)
+ reset_control_deassert(ddata->rsts);
+
pdata = dev_get_platdata(ddata->dev);
if (!pdata)
return 0;
@@ -1063,6 +1070,9 @@ static int __maybe_unused sysc_runtime_suspend(struct
device *dev)
err_allow_idle:
sysc_clkdm_allow_idle(ddata);
+ if (ddata->disable_on_idle)
+ reset_control_assert(ddata->rsts);
+
return error;
}
@@ -1076,6 +1086,9 @@ static int __maybe_unused sysc_runtime_resume(struct
device *dev)
if (ddata->enabled)
return 0;
+ if (ddata->disable_on_idle)
+ reset_control_deassert(ddata->rsts);
+
sysc_clkdm_deny_idle(ddata);
if (sysc_opt_clks_needed(ddata)) {
@@ -2293,7 +2306,7 @@ static int sysc_probe(struct platform_device *pdev)
}
if (!of_get_available_child_count(ddata->dev->of_node))
- reset_control_assert(ddata->rsts);
+ ddata->disable_on_idle = true;
return 0;
--
2.21.0
[PATCH 06/13] bus: ti-sysc: Handle clockactivity for enable and disable
Modules with clockactivity need it configured during enable. Signed-off-by: Tony Lindgren --- drivers/bus/ti-sysc.c | 7 +++ 1 file changed, 7 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 @@ -845,6 +845,7 @@ static void sysc_show_registers(struct sysc *ddata) } #define SYSC_IDLE_MASK (SYSC_NR_IDLEMODES - 1) +#define SYSC_CLOCACT_ICK 2 /* Caller needs to manage sysc_clkdm_deny_idle() and sysc_clkdm_allow_idle() */ static int sysc_enable_module(struct device *dev) @@ -860,6 +861,12 @@ static int sysc_enable_module(struct device *dev) regbits = ddata->cap->regbits; reg = sysc_read(ddata, ddata->offsets[SYSC_SYSCONFIG]); + /* Set CLOCKACTIVITY, we only use it for ick */ + if (regbits->clkact_shift >= 0 && + (ddata->cfg.quirks & SYSC_QUIRK_USE_CLOCKACT || +ddata->cfg.sysc_val & BIT(regbits->clkact_shift))) + reg |= SYSC_CLOCACT_ICK << regbits->clkact_shift; + /* Set SIDLE mode */ idlemodes = ddata->cfg.sidlemodes; if (!idlemodes || regbits->sidle_shift < 0) -- 2.21.0
[PATCH 11/13] bus: ti-sysc: Detect uarts also on omap34xx
Looks like we currently only detect UART on omap36xx, let's also
add support for omap34xx. And let's also fix the SWSUP mode, it should
be SWSUP_SIDLE for omap3, not SWSUP_SIDLE_ACT like for omap4 and later.
Note that we are still booting omap3 for most part without ti-sysc,
so no need to treat this change as a fix.
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
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
@@ -1205,8 +1205,10 @@ static const struct sysc_revision_quirk
sysc_revision_quirks[] = {
0),
SYSC_QUIRK("timer", 0, 0, 0x10, -1, 0x4fff1301, 0x00ff,
0),
+ SYSC_QUIRK("uart", 0, 0x50, 0x54, 0x58, 0x0046, 0x,
+ SYSC_QUIRK_SWSUP_SIDLE | SYSC_QUIRK_LEGACY_IDLE),
SYSC_QUIRK("uart", 0, 0x50, 0x54, 0x58, 0x0052, 0x,
- SYSC_QUIRK_SWSUP_SIDLE_ACT | SYSC_QUIRK_LEGACY_IDLE),
+ SYSC_QUIRK_SWSUP_SIDLE | SYSC_QUIRK_LEGACY_IDLE),
/* Uarts on omap4 and later */
SYSC_QUIRK("uart", 0, 0x50, 0x54, 0x58, 0x50411e03, 0x00ff,
SYSC_QUIRK_SWSUP_SIDLE_ACT | SYSC_QUIRK_LEGACY_IDLE),
--
2.21.0
[PATCH 04/13] bus: ti-sysc: Allow QUIRK_LEGACY_IDLE even if legacy_mode is not set
We need to specify QUIRK_LEGACY_IDLE for device drivers that still have
pm_runtime_irq_safe() set like 8250.
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 3 ---
1 file changed, 3 deletions(-)
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
@@ -1779,9 +1779,6 @@ static struct dev_pm_domain sysc_child_pm_domain = {
*/
static void sysc_legacy_idle_quirk(struct sysc *ddata, struct device *child)
{
- if (!ddata->legacy_mode)
- return;
-
if (ddata->cfg.quirks & SYSC_QUIRK_LEGACY_IDLE)
dev_pm_domain_set(child, &sysc_child_pm_domain);
}
--
2.21.0
[PATCH 08/13] bus: ti-sysc: Set ENAWAKEUP if available
Some modules have ENAWAKEUP bit that we need to configure when not relying on platform data callbacks. Signed-off-by: Tony Lindgren --- drivers/bus/ti-sysc.c | 5 + 1 file changed, 5 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 @@ -881,6 +881,11 @@ static int sysc_enable_module(struct device *dev) dev_err(dev, "%s: invalid sidlemode\n", __func__); return -EINVAL; } + + /* Set WAKEUP */ + if (regbits->enwkup_shift >= 0 && + ddata->cfg.sysc_val & BIT(regbits->enwkup_shift)) + reg |= BIT(regbits->enwkup_shift); } reg &= ~(SYSC_IDLE_MASK << regbits->sidle_shift); -- 2.21.0
[PATCH 13/13] ARM: dts: Drop legacy custom hwmods property for omap4 mmc
With recent ti-sysc driver changes, we can now finally probe most
modules without needing the custom ti,hwmods property.
Let's drop it for omap4 MMC as we can test that for runtime PM
for core retention idle mode for wlcore WLAN.
Cc: devicet...@vger.kernel.org
Cc: Rob Herring
Signed-off-by: Tony Lindgren
---
arch/arm/boot/dts/omap4-l4.dtsi | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-l4.dtsi b/arch/arm/boot/dts/omap4-l4.dtsi
--- a/arch/arm/boot/dts/omap4-l4.dtsi
+++ b/arch/arm/boot/dts/omap4-l4.dtsi
@@ -2103,7 +2103,6 @@
target-module@9c000 { /* 0x4809c000, ap 53
36.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
- ti,hwmods = "mmc1";
reg = <0x9c000 0x4>,
<0x9c010 0x4>;
reg-names = "rev", "sysc";
@@ -2171,7 +2170,6 @@
target-module@ad000 { /* 0x480ad000, ap 63
50.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
- ti,hwmods = "mmc3";
reg = <0xad000 0x4>,
<0xad010 0x4>;
reg-names = "rev", "sysc";
@@ -2237,7 +2235,6 @@
target-module@b4000 { /* 0x480b4000, ap 67
46.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
- ti,hwmods = "mmc2";
reg = <0xb4000 0x4>,
<0xb4010 0x4>;
reg-names = "rev", "sysc";
@@ -2332,7 +2329,6 @@
target-module@d1000 { /* 0x480d1000, ap 73
44.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
- ti,hwmods = "mmc4";
reg = <0xd1000 0x4>,
<0xd1010 0x4>;
reg-names = "rev", "sysc";
@@ -2365,7 +2361,6 @@
target-module@d5000 { /* 0x480d5000, ap 75
4e.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
- ti,hwmods = "mmc5";
reg = <0xd5000 0x4>,
<0xd5010 0x4>;
reg-names = "rev", "sysc";
--
2.21.0
[PATCH 12/13] ARM: dts: Drop legacy custom hwmods property for omap4 uart
With recent ti-sysc driver changes, we can now finally probe most
modules without needing the custom ti,hwmods property.
Let's start with omap4 uart as we can test that for runtime PM
for core retention idle mode.
Cc: devicet...@vger.kernel.org
Cc: Rob Herring
Signed-off-by: Tony Lindgren
---
arch/arm/boot/dts/omap4-l4.dtsi | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-l4.dtsi b/arch/arm/boot/dts/omap4-l4.dtsi
--- a/arch/arm/boot/dts/omap4-l4.dtsi
+++ b/arch/arm/boot/dts/omap4-l4.dtsi
@@ -1371,7 +1371,6 @@
target-module@2 { /* 0x4802, ap 3
06.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
- ti,hwmods = "uart3";
reg = <0x20050 0x4>,
<0x20054 0x4>,
<0x20058 0x4>;
@@ -1728,7 +1727,6 @@
target-module@6a000 { /* 0x4806a000, ap 26
18.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
- ti,hwmods = "uart1";
reg = <0x6a050 0x4>,
<0x6a054 0x4>,
<0x6a058 0x4>;
@@ -1758,7 +1756,6 @@
target-module@6c000 { /* 0x4806c000, ap 28
20.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
- ti,hwmods = "uart2";
reg = <0x6c050 0x4>,
<0x6c054 0x4>,
<0x6c058 0x4>;
@@ -1788,7 +1785,6 @@
target-module@6e000 { /* 0x4806e000, ap 30
1c.1 */
compatible = "ti,sysc-omap2", "ti,sysc";
- ti,hwmods = "uart4";
reg = <0x6e050 0x4>,
<0x6e054 0x4>,
<0x6e058 0x4>;
--
2.21.0
[PATCH 02/13] bus: ti-sysc: Support 16-bit writes too
We need to also support 16-bit writes for i2c in addition to the reads
when we start configuring the sysconfig register for reset and idle modes.
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 7 +++
1 file changed, 7 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
@@ -100,6 +100,13 @@ static void sysc_parse_dts_quirks(struct sysc *ddata,
struct device_node *np,
static void sysc_write(struct sysc *ddata, int offset, u32 value)
{
+ if (ddata->cfg.quirks & SYSC_QUIRK_16BIT) {
+ writew_relaxed(value & 0x, ddata->module_va + offset);
+ writew_relaxed(value >> 16, ddata->module_va + offset + 4);
+
+ return;
+ }
+
writel_relaxed(value, ddata->module_va + offset);
}
--
2.21.0
[PATCHv2 00/13] ti-sysc driver changes to drop custom hwmods property
Hi all, Here are changes to improve ti-sysc driver to the point where we can finally drop the custom hwmods property for most cases. This series drops hwmods property only for omap4 UART and MMC as those can be tested with core retention idle. I'll be posting more patches for dropping hwmods properties as they get tested. Regards, Tony Changes since v1: - Repost the series against v5.2-rc1 as the first patch in the series got accidentally left out for patch "bus: ti-sysc: Add support for missing clockdomain handling" Tony Lindgren (13): bus: ti-sysc: Add support for missing clockdomain handling bus: ti-sysc: Support 16-bit writes too bus: ti-sysc: Make OCP reset work for sysstatus and sysconfig reset bits bus: ti-sysc: Allow QUIRK_LEGACY_IDLE even if legacy_mode is not set bus: ti-sysc: Enable interconnect target module autoidle bit on enable bus: ti-sysc: Handle clockactivity for enable and disable bus: ti-sysc: Handle swsup idle mode quirks bus: ti-sysc: Set ENAWAKEUP if available bus: ti-sysc: Add support for disabling module without legacy mode bus: ti-sysc: Do rstctrl reset handling in two phases bus: ti-sysc: Detect uarts also on omap34xx ARM: dts: Drop legacy custom hwmods property for omap4 uart ARM: dts: Drop legacy custom hwmods property for omap4 mmc arch/arm/boot/dts/omap4-l4.dtsi | 9 - arch/arm/mach-omap2/omap_hwmod.c | 39 +--- arch/arm/mach-omap2/pdata-quirks.c| 60 + drivers/bus/ti-sysc.c | 309 -- include/linux/platform_data/ti-sysc.h | 9 + 5 files changed, 314 insertions(+), 112 deletions(-) -- 2.21.0
Re: [PATCH 00/12] ti-sysc driver changes to drop custom hwmods property
* Keerthy [190528 00:58]: > > > On 27/05/19 5:43 PM, Tony Lindgren wrote: > > Hi all, > > > > Here are changes to improve ti-sysc driver to the point where we can > > finally drop the custom hwmods property for most cases. This series > > drops hwmods property only for omap4 UART and MMC as those can be > > tested with core retention idle. > > > > I'll be posting more patches for dropping hwmods properties as they > > get tested. > > Tony, > > What is the base of this series? It does not apply cleanly neither on > linux-next nor on top of 5.2->rc1. If there are dependencies do you have a > branch? Oh thanks for letting me know. It's against v5.2-rc1 but the first patch of the series got accidentally left out. Looks like I used -n option with git format-patch with -n 12 instead of -n13. I will repost the series. Regards, Tony
Re: 5.2-rc1 on droid4: spi crash
* Noralf Trønnes [190527 13:16]:
>
>
> Den 2019-05-27 07:53, skrev Tony Lindgren:
> > Hi,
> >
> > * Sebastian Reichel [190523 09:33]:
> > > Hi,
> > >
> > > On Thu, May 23, 2019 at 11:09:26AM +0200, Pavel Machek wrote:
> > > > This was greeting me overnight... I don't yet know how reproducible it
> > > > is, it happened once so far.
> > >
> > > Please pipe the stacktrace into ./scripts/decode_stacktrace.sh
> > > to get a readable stacktrace, otherwise this is pretty much useless.
> > > FWIW the only SPI device in the Droid 4 is the PMIC.
> >
> > I've seen this too, and looks like reverting commit c9ba7a16d0f1
> > ("spi: Release spi_res after finalizing message") fixes it based
> > several days of testing.
> >
> > Noralf and Mark, any ideas what needs to be fixed here?
>
> Mark has a revert in his for-5.2 branch:
> spi: Fix Raspberry Pi breakage
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/commit/?h=for-5.2&id=0ed56252c9567351344cb7b5cff6140e1bcec943
Oh OK good to hear.
> I don't know when or if he has sent a pull request.
> Sorry about the breakage.
No worries, thanks for the update.
Regards,
Tony
[PATCH 01/12] bus: ti-sysc: Support 16-bit writes too
We need to also support 16-bit writes for i2c in addition to the reads
when we start configuring the sysconfig register for reset and idle modes.
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 7 +++
1 file changed, 7 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
@@ -100,6 +100,13 @@ static void sysc_parse_dts_quirks(struct sysc *ddata,
struct device_node *np,
static void sysc_write(struct sysc *ddata, int offset, u32 value)
{
+ if (ddata->cfg.quirks & SYSC_QUIRK_16BIT) {
+ writew_relaxed(value & 0x, ddata->module_va + offset);
+ writew_relaxed(value >> 16, ddata->module_va + offset + 4);
+
+ return;
+ }
+
writel_relaxed(value, ddata->module_va + offset);
}
--
2.21.0
[PATCH 08/12] bus: ti-sysc: Add support for disabling module without legacy mode
We must not assert reset for modules with no child device drivers
until in runtime_suspend. Otherwise register access will fail without
legacy mode helping us.
Let's add a flag for disable_on_idle and move the reset driver
handling to runtime suspend and resume. We can then also use the
disable_on_idle flag to reconfigure sysconfig register for PM
modes requesting it.
Let's also make the other flags use bitfield while at it instead of
bool.
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
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
@@ -89,9 +89,10 @@ struct sysc {
struct ti_sysc_cookie cookie;
const char *name;
u32 revision;
- bool enabled;
- bool needs_resume;
- bool child_needs_resume;
+ unsigned int enabled:1;
+ unsigned int needs_resume:1;
+ unsigned int child_needs_resume:1;
+ unsigned int disable_on_idle:1;
struct delayed_work idle_work;
};
@@ -1007,6 +1008,9 @@ static int __maybe_unused
sysc_runtime_suspend_legacy(struct device *dev,
dev_err(dev, "%s: could not idle: %i\n",
__func__, error);
+ if (ddata->disable_on_idle)
+ reset_control_assert(ddata->rsts);
+
return 0;
}
@@ -1016,6 +1020,9 @@ static int __maybe_unused
sysc_runtime_resume_legacy(struct device *dev,
struct ti_sysc_platform_data *pdata;
int error;
+ if (ddata->disable_on_idle)
+ reset_control_deassert(ddata->rsts);
+
pdata = dev_get_platdata(ddata->dev);
if (!pdata)
return 0;
@@ -1063,6 +1070,9 @@ static int __maybe_unused sysc_runtime_suspend(struct
device *dev)
err_allow_idle:
sysc_clkdm_allow_idle(ddata);
+ if (ddata->disable_on_idle)
+ reset_control_assert(ddata->rsts);
+
return error;
}
@@ -1076,6 +1086,9 @@ static int __maybe_unused sysc_runtime_resume(struct
device *dev)
if (ddata->enabled)
return 0;
+ if (ddata->disable_on_idle)
+ reset_control_deassert(ddata->rsts);
+
sysc_clkdm_deny_idle(ddata);
if (sysc_opt_clks_needed(ddata)) {
@@ -2293,7 +2306,7 @@ static int sysc_probe(struct platform_device *pdev)
}
if (!of_get_available_child_count(ddata->dev->of_node))
- reset_control_assert(ddata->rsts);
+ ddata->disable_on_idle = true;
return 0;
--
2.21.0
[PATCH 07/12] bus: ti-sysc: Set ENAWAKEUP if available
Some modules have ENAWAKEUP bit that we need to configure when not relying on platform data callbacks. Signed-off-by: Tony Lindgren --- drivers/bus/ti-sysc.c | 5 + 1 file changed, 5 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 @@ -881,6 +881,11 @@ static int sysc_enable_module(struct device *dev) dev_err(dev, "%s: invalid sidlemode\n", __func__); return -EINVAL; } + + /* Set WAKEUP */ + if (regbits->enwkup_shift >= 0 && + ddata->cfg.sysc_val & BIT(regbits->enwkup_shift)) + reg |= BIT(regbits->enwkup_shift); } reg &= ~(SYSC_IDLE_MASK << regbits->sidle_shift); -- 2.21.0
[PATCH 11/12] ARM: dts: Drop legacy custom hwmods property for omap4 uart
With recent ti-sysc driver changes, we can now finally probe most
modules without needing the custom ti,hwmods property.
Let's start with omap4 uart as we can test that for runtime PM
for core retention idle mode.
Cc: devicet...@vger.kernel.org
Cc: Rob Herring
Signed-off-by: Tony Lindgren
---
arch/arm/boot/dts/omap4-l4.dtsi | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-l4.dtsi b/arch/arm/boot/dts/omap4-l4.dtsi
--- a/arch/arm/boot/dts/omap4-l4.dtsi
+++ b/arch/arm/boot/dts/omap4-l4.dtsi
@@ -1371,7 +1371,6 @@
target-module@2 { /* 0x4802, ap 3
06.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
- ti,hwmods = "uart3";
reg = <0x20050 0x4>,
<0x20054 0x4>,
<0x20058 0x4>;
@@ -1728,7 +1727,6 @@
target-module@6a000 { /* 0x4806a000, ap 26
18.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
- ti,hwmods = "uart1";
reg = <0x6a050 0x4>,
<0x6a054 0x4>,
<0x6a058 0x4>;
@@ -1758,7 +1756,6 @@
target-module@6c000 { /* 0x4806c000, ap 28
20.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
- ti,hwmods = "uart2";
reg = <0x6c050 0x4>,
<0x6c054 0x4>,
<0x6c058 0x4>;
@@ -1788,7 +1785,6 @@
target-module@6e000 { /* 0x4806e000, ap 30
1c.1 */
compatible = "ti,sysc-omap2", "ti,sysc";
- ti,hwmods = "uart4";
reg = <0x6e050 0x4>,
<0x6e054 0x4>,
<0x6e058 0x4>;
--
2.21.0
[PATCH 04/12] bus: ti-sysc: Enable interconnect target module autoidle bit on enable
For interconnect target modules with autoidle bit wired, we need to manage
it for enable and disable.
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
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
@@ -879,7 +879,7 @@ static int sysc_enable_module(struct device *dev)
/* Set MIDLE mode */
idlemodes = ddata->cfg.midlemodes;
if (!idlemodes || regbits->midle_shift < 0)
- return 0;
+ goto set_autoidle;
best_mode = fls(ddata->cfg.midlemodes) - 1;
if (best_mode > SYSC_IDLE_MASK) {
@@ -891,6 +891,14 @@ static int sysc_enable_module(struct device *dev)
reg |= best_mode << regbits->midle_shift;
sysc_write(ddata, ddata->offsets[SYSC_SYSCONFIG], reg);
+set_autoidle:
+ /* Autoidle bit must enabled separately if available */
+ if (regbits->autoidle_shift >= 0 &&
+ ddata->cfg.sysc_val & BIT(regbits->autoidle_shift)) {
+ reg |= 1 << regbits->autoidle_shift;
+ sysc_write(ddata, ddata->offsets[SYSC_SYSCONFIG], reg);
+ }
+
return 0;
}
@@ -952,6 +960,9 @@ static int sysc_disable_module(struct device *dev)
reg &= ~(SYSC_IDLE_MASK << regbits->sidle_shift);
reg |= best_mode << regbits->sidle_shift;
+ if (regbits->autoidle_shift >= 0 &&
+ ddata->cfg.sysc_val & BIT(regbits->autoidle_shift))
+ reg |= 1 << regbits->autoidle_shift;
sysc_write(ddata, ddata->offsets[SYSC_SYSCONFIG], reg);
return 0;
--
2.21.0
[PATCH 12/12] ARM: dts: Drop legacy custom hwmods property for omap4 mmc
With recent ti-sysc driver changes, we can now finally probe most
modules without needing the custom ti,hwmods property.
Let's drop it for omap4 MMC as we can test that for runtime PM
for core retention idle mode for wlcore WLAN.
Cc: devicet...@vger.kernel.org
Cc: Rob Herring
Signed-off-by: Tony Lindgren
---
arch/arm/boot/dts/omap4-l4.dtsi | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-l4.dtsi b/arch/arm/boot/dts/omap4-l4.dtsi
--- a/arch/arm/boot/dts/omap4-l4.dtsi
+++ b/arch/arm/boot/dts/omap4-l4.dtsi
@@ -2103,7 +2103,6 @@
target-module@9c000 { /* 0x4809c000, ap 53
36.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
- ti,hwmods = "mmc1";
reg = <0x9c000 0x4>,
<0x9c010 0x4>;
reg-names = "rev", "sysc";
@@ -2171,7 +2170,6 @@
target-module@ad000 { /* 0x480ad000, ap 63
50.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
- ti,hwmods = "mmc3";
reg = <0xad000 0x4>,
<0xad010 0x4>;
reg-names = "rev", "sysc";
@@ -2237,7 +2235,6 @@
target-module@b4000 { /* 0x480b4000, ap 67
46.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
- ti,hwmods = "mmc2";
reg = <0xb4000 0x4>,
<0xb4010 0x4>;
reg-names = "rev", "sysc";
@@ -2332,7 +2329,6 @@
target-module@d1000 { /* 0x480d1000, ap 73
44.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
- ti,hwmods = "mmc4";
reg = <0xd1000 0x4>,
<0xd1010 0x4>;
reg-names = "rev", "sysc";
@@ -2365,7 +2361,6 @@
target-module@d5000 { /* 0x480d5000, ap 75
4e.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
- ti,hwmods = "mmc5";
reg = <0xd5000 0x4>,
<0xd5010 0x4>;
reg-names = "rev", "sysc";
--
2.21.0
[PATCH 10/12] bus: ti-sysc: Detect uarts also on omap34xx
Looks like we currently only detect UART on omap36xx, let's also
add support for omap34xx. And let's also fix the SWSUP mode, it should
be SWSUP_SIDLE for omap3, not SWSUP_SIDLE_ACT like for omap4 and later.
Note that we are still booting omap3 for most part without ti-sysc,
so no need to treat this change as a fix.
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
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
@@ -1205,8 +1205,10 @@ static const struct sysc_revision_quirk
sysc_revision_quirks[] = {
0),
SYSC_QUIRK("timer", 0, 0, 0x10, -1, 0x4fff1301, 0x00ff,
0),
+ SYSC_QUIRK("uart", 0, 0x50, 0x54, 0x58, 0x0046, 0x,
+ SYSC_QUIRK_SWSUP_SIDLE | SYSC_QUIRK_LEGACY_IDLE),
SYSC_QUIRK("uart", 0, 0x50, 0x54, 0x58, 0x0052, 0x,
- SYSC_QUIRK_SWSUP_SIDLE_ACT | SYSC_QUIRK_LEGACY_IDLE),
+ SYSC_QUIRK_SWSUP_SIDLE | SYSC_QUIRK_LEGACY_IDLE),
/* Uarts on omap4 and later */
SYSC_QUIRK("uart", 0, 0x50, 0x54, 0x58, 0x50411e03, 0x00ff,
SYSC_QUIRK_SWSUP_SIDLE_ACT | SYSC_QUIRK_LEGACY_IDLE),
--
2.21.0
[PATCH 03/12] bus: ti-sysc: Allow QUIRK_LEGACY_IDLE even if legacy_mode is not set
We need to specify QUIRK_LEGACY_IDLE for device drivers that still have
pm_runtime_irq_safe() set like 8250.
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 3 ---
1 file changed, 3 deletions(-)
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
@@ -1779,9 +1779,6 @@ static struct dev_pm_domain sysc_child_pm_domain = {
*/
static void sysc_legacy_idle_quirk(struct sysc *ddata, struct device *child)
{
- if (!ddata->legacy_mode)
- return;
-
if (ddata->cfg.quirks & SYSC_QUIRK_LEGACY_IDLE)
dev_pm_domain_set(child, &sysc_child_pm_domain);
}
--
2.21.0
[PATCH 06/12] bus: ti-sysc: Handle swsup idle mode quirks
Some modules have idlemodes wired, but not completely functional. We have
quirks for SWSUP_SIDLE and SWSUP_SIDLE_ACT to manage interconnect target
modules without hardware support, but we've been only using them so far
in legacy mode. Let's add support for SWSUP quirks in non-legacy mode too.
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
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
@@ -872,10 +872,15 @@ static int sysc_enable_module(struct device *dev)
if (!idlemodes || regbits->sidle_shift < 0)
goto set_midle;
- best_mode = fls(ddata->cfg.sidlemodes) - 1;
- if (best_mode > SYSC_IDLE_MASK) {
- dev_err(dev, "%s: invalid sidlemode\n", __func__);
- return -EINVAL;
+ if (ddata->cfg.quirks & (SYSC_QUIRK_SWSUP_SIDLE |
+SYSC_QUIRK_SWSUP_SIDLE_ACT)) {
+ best_mode = SYSC_IDLE_NO;
+ } else {
+ best_mode = fls(ddata->cfg.sidlemodes) - 1;
+ if (best_mode > SYSC_IDLE_MASK) {
+ dev_err(dev, "%s: invalid sidlemode\n", __func__);
+ return -EINVAL;
+ }
}
reg &= ~(SYSC_IDLE_MASK << regbits->sidle_shift);
@@ -959,10 +964,14 @@ static int sysc_disable_module(struct device *dev)
if (!idlemodes || regbits->sidle_shift < 0)
return 0;
- ret = sysc_best_idle_mode(idlemodes, &best_mode);
- if (ret) {
- dev_err(dev, "%s: invalid sidlemode\n", __func__);
- return ret;
+ if (ddata->cfg.quirks & SYSC_QUIRK_SWSUP_SIDLE) {
+ best_mode = SYSC_IDLE_FORCE;
+ } else {
+ ret = sysc_best_idle_mode(idlemodes, &best_mode);
+ if (ret) {
+ dev_err(dev, "%s: invalid sidlemode\n", __func__);
+ return ret;
+ }
}
reg &= ~(SYSC_IDLE_MASK << regbits->sidle_shift);
--
2.21.0
[PATCH 02/12] bus: ti-sysc: Make OCP reset work for sysstatus and sysconfig reset bits
We've had minimal OCP softreset support in ti-sysc interconnect target
module driver only used for MCAN driver so far. But it turns out that
MCAN has the sysstatus register resetdone bit inverted compared to most
other modules.
Let's make OCP softreset work for other typical cases with reset status
in sysstatus or sysconfig register so we can use the new functions for
sysc_enable_module() and sysc_disable_module() without "ti,hwmods"
property in the following patches.
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 72 ---
include/linux/platform_data/ti-sysc.h | 1 +
2 files changed, 55 insertions(+), 18 deletions(-)
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
@@ -139,6 +139,26 @@ static u32 sysc_read_revision(struct sysc *ddata)
return sysc_read(ddata, offset);
}
+static u32 sysc_read_sysconfig(struct sysc *ddata)
+{
+ int offset = ddata->offsets[SYSC_SYSCONFIG];
+
+ if (offset < 0)
+ return 0;
+
+ return sysc_read(ddata, offset);
+}
+
+static u32 sysc_read_sysstatus(struct sysc *ddata)
+{
+ int offset = ddata->offsets[SYSC_SYSSTATUS];
+
+ if (offset < 0)
+ return 0;
+
+ return sysc_read(ddata, offset);
+}
+
static int sysc_add_named_clock_from_child(struct sysc *ddata,
const char *name,
const char *optfck_name)
@@ -1356,34 +1376,49 @@ static int sysc_rstctrl_reset_deassert(struct sysc
*ddata, bool reset)
return reset_control_deassert(ddata->rsts);
}
+/*
+ * Note that the caller must ensure the interconnect target module is enabled
+ * before calling reset. Otherwise reset will not complete.
+ */
static int sysc_reset(struct sysc *ddata)
{
- int offset = ddata->offsets[SYSC_SYSCONFIG];
- int val;
+ int sysc_offset, syss_offset, sysc_val, rstval, quirks, error = 0;
+ u32 sysc_mask, syss_done;
+
+ sysc_offset = ddata->offsets[SYSC_SYSCONFIG];
+ syss_offset = ddata->offsets[SYSC_SYSSTATUS];
+ quirks = ddata->cfg.quirks;
- if (ddata->legacy_mode || offset < 0 ||
+ if (ddata->legacy_mode || sysc_offset < 0 ||
+ ddata->cap->regbits->srst_shift < 0 ||
ddata->cfg.quirks & SYSC_QUIRK_NO_RESET_ON_INIT)
return 0;
- /*
-* Currently only support reset status in sysstatus.
-* Warn and return error in all other cases
-*/
- if (!ddata->cfg.syss_mask) {
- dev_err(ddata->dev, "No ti,syss-mask. Reset failed\n");
- return -EINVAL;
- }
+ sysc_mask = BIT(ddata->cap->regbits->srst_shift);
- val = sysc_read(ddata, offset);
- val |= (0x1 << ddata->cap->regbits->srst_shift);
- sysc_write(ddata, offset, val);
+ if (ddata->cfg.quirks & SYSS_QUIRK_RESETDONE_INVERTED)
+ syss_done = 0;
+ else
+ syss_done = ddata->cfg.syss_mask;
+
+ sysc_val = sysc_read_sysconfig(ddata);
+ sysc_val |= sysc_mask;
+ sysc_write(ddata, sysc_offset, sysc_val);
/* Poll on reset status */
- offset = ddata->offsets[SYSC_SYSSTATUS];
+ if (syss_offset >= 0) {
+ error = readx_poll_timeout(sysc_read_sysstatus, ddata, rstval,
+ (rstval & ddata->cfg.syss_mask) ==
+ syss_done,
+ 100, MAX_MODULE_SOFTRESET_WAIT);
+
+ } else if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
+ error = readx_poll_timeout(sysc_read_sysconfig, ddata, rstval,
+ !(rstval & sysc_mask),
+ 100, MAX_MODULE_SOFTRESET_WAIT);
+ }
- return readl_poll_timeout(ddata->module_va + offset, val,
- (val & ddata->cfg.syss_mask) == 0x0,
- 100, MAX_MODULE_SOFTRESET_WAIT);
+ return error;
}
/*
@@ -2086,6 +2121,7 @@ static const struct sysc_capabilities sysc_dra7_mcan = {
.type = TI_SYSC_DRA7_MCAN,
.sysc_mask = SYSC_DRA7_MCAN_ENAWAKEUP | SYSC_OMAP4_SOFTRESET,
.regbits = &sysc_regbits_dra7_mcan,
+ .mod_quirks = SYSS_QUIRK_RESETDONE_INVERTED,
};
static int sysc_init_pdata(struct sysc *ddata)
diff --git a/include/linux/platform_data/ti-sysc.h
b/include/linux/platform_data/ti-sysc.h
--- a/include/linux/platform_data/ti-sysc.h
+++ b/include/linux/platform_data/ti-sysc.h
@@ -47,6 +47,7 @@ struct sysc_regbits {
s8 emufree_shift;
};
+#define SYSS_QUIRK_RESETDONE_INVERTED BIT(14)
#define SYSC_QUIRK_SWSUP_MSTANDBY BIT(13)
#define SYSC_QUIRK_SWSUP_SIDLE_ACT BIT(12)
#define SYSC_QUIRK_SWSUP_SIDLE BIT(11)
--
2.21.0
[PATCH 09/12] bus: ti-sysc: Do rstctrl reset handling in two phases
We need to deassert rstctrl resets before enabling clocks to avoid clock
"failed to enable" errors. For asserting rstctrl reset, the clocks need
to be enabled.
As the reset controller status is not available for arrays, let's use
devm_reset_control_get_optional() so we can get the status after reset.
Note that depends on a proper PRM rstctrl driver, so far I've only
tested this with earlier reset-simple patches.
Signed-off-by: Tony Lindgren
---
drivers/bus/ti-sysc.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
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
@@ -483,7 +483,7 @@ static void sysc_clkdm_allow_idle(struct sysc *ddata)
static int sysc_init_resets(struct sysc *ddata)
{
ddata->rsts =
- devm_reset_control_array_get_optional_exclusive(ddata->dev);
+ devm_reset_control_get_optional(ddata->dev, "rstctrl");
if (IS_ERR(ddata->rsts))
return PTR_ERR(ddata->rsts);
@@ -1407,7 +1407,7 @@ static int sysc_legacy_init(struct sysc *ddata)
*/
static int sysc_rstctrl_reset_deassert(struct sysc *ddata, bool reset)
{
- int error;
+ int error, val;
if (!ddata->rsts)
return 0;
@@ -1418,7 +1418,14 @@ static int sysc_rstctrl_reset_deassert(struct sysc
*ddata, bool reset)
return error;
}
- return reset_control_deassert(ddata->rsts);
+ error = reset_control_deassert(ddata->rsts);
+ if (error == -EEXIST)
+ return 0;
+
+ error = readx_poll_timeout(reset_control_status, ddata->rsts, val,
+ val == 0, 100, MAX_MODULE_SOFTRESET_WAIT);
+
+ return error;
}
/*
@@ -1476,12 +1483,8 @@ static int sysc_init_module(struct sysc *ddata)
{
int error = 0;
bool manage_clocks = true;
- bool reset = true;
- if (ddata->cfg.quirks & SYSC_QUIRK_NO_RESET_ON_INIT)
- reset = false;
-
- error = sysc_rstctrl_reset_deassert(ddata, reset);
+ error = sysc_rstctrl_reset_deassert(ddata, false);
if (error)
return error;
@@ -1505,6 +1508,12 @@ static int sysc_init_module(struct sysc *ddata)
goto err_opt_clocks;
}
+ if (!(ddata->cfg.quirks & SYSC_QUIRK_NO_RESET_ON_INIT)) {
+ error = sysc_rstctrl_reset_deassert(ddata, true);
+ if (error)
+ goto err_main_clocks;
+ }
+
ddata->revision = sysc_read_revision(ddata);
sysc_init_revision_quirks(ddata);
--
2.21.0
[PATCH 05/12] bus: ti-sysc: Handle clockactivity for enable and disable
Modules with clockactivity need it configured during enable. Signed-off-by: Tony Lindgren --- drivers/bus/ti-sysc.c | 7 +++ 1 file changed, 7 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 @@ -845,6 +845,7 @@ static void sysc_show_registers(struct sysc *ddata) } #define SYSC_IDLE_MASK (SYSC_NR_IDLEMODES - 1) +#define SYSC_CLOCACT_ICK 2 /* Caller needs to manage sysc_clkdm_deny_idle() and sysc_clkdm_allow_idle() */ static int sysc_enable_module(struct device *dev) @@ -860,6 +861,12 @@ static int sysc_enable_module(struct device *dev) regbits = ddata->cap->regbits; reg = sysc_read(ddata, ddata->offsets[SYSC_SYSCONFIG]); + /* Set CLOCKACTIVITY, we only use it for ick */ + if (regbits->clkact_shift >= 0 && + (ddata->cfg.quirks & SYSC_QUIRK_USE_CLOCKACT || +ddata->cfg.sysc_val & BIT(regbits->clkact_shift))) + reg |= SYSC_CLOCACT_ICK << regbits->clkact_shift; + /* Set SIDLE mode */ idlemodes = ddata->cfg.sidlemodes; if (!idlemodes || regbits->sidle_shift < 0) -- 2.21.0
[PATCH 00/12] ti-sysc driver changes to drop custom hwmods property
Hi all, Here are changes to improve ti-sysc driver to the point where we can finally drop the custom hwmods property for most cases. This series drops hwmods property only for omap4 UART and MMC as those can be tested with core retention idle. I'll be posting more patches for dropping hwmods properties as they get tested. Regards, Tony Tony Lindgren (12): bus: ti-sysc: Support 16-bit writes too bus: ti-sysc: Make OCP reset work for sysstatus and sysconfig reset bits bus: ti-sysc: Allow QUIRK_LEGACY_IDLE even if legacy_mode is not set bus: ti-sysc: Enable interconnect target module autoidle bit on enable bus: ti-sysc: Handle clockactivity for enable and disable bus: ti-sysc: Handle swsup idle mode quirks bus: ti-sysc: Set ENAWAKEUP if available bus: ti-sysc: Add support for disabling module without legacy mode bus: ti-sysc: Do rstctrl reset handling in two phases bus: ti-sysc: Detect uarts also on omap34xx ARM: dts: Drop legacy custom hwmods property for omap4 uart ARM: dts: Drop legacy custom hwmods property for omap4 mmc arch/arm/boot/dts/omap4-l4.dtsi | 9 -- drivers/bus/ti-sysc.c | 182 -- include/linux/platform_data/ti-sysc.h | 1 + 3 files changed, 140 insertions(+), 52 deletions(-) -- 2.21.0
Re: [Qemu-devel] Running linux on qemu omap
Hi, * Philippe Mathieu-Daudé [190523 12:01]: > What I use as reference for testing ARM boards [*] is the work of > Guenter Roeck: > https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/run-qemu-arm.sh I think Guenter also has v2.3.50-local-linaro branch in his github repo that has support for few extra boards like Beagleboard. Not sure what's the current branch to use though. Regards, Tony
Re: 5.2-rc1 on droid4: spi crash
Hi,
* Sebastian Reichel [190523 09:33]:
> Hi,
>
> On Thu, May 23, 2019 at 11:09:26AM +0200, Pavel Machek wrote:
> > This was greeting me overnight... I don't yet know how reproducible it
> > is, it happened once so far.
>
> Please pipe the stacktrace into ./scripts/decode_stacktrace.sh
> to get a readable stacktrace, otherwise this is pretty much useless.
> FWIW the only SPI device in the Droid 4 is the PMIC.
I've seen this too, and looks like reverting commit c9ba7a16d0f1
("spi: Release spi_res after finalizing message") fixes it based
several days of testing.
Noralf and Mark, any ideas what needs to be fixed here?
Below is the stacktrace I see without c9ba7a16d0f1 reverted,
not sure how to reproduce but it seems to happen within about
one to two days of uptime.
Regards,
Tony
8< -
Unable to handle kernel NULL pointer dereference at virtual address 0008
pgd = 829f0a5b
[0008] *pgd=
Internal error: Oops: 8005 [#1] SMP ARM
...
CPU: 0 PID: 71 Comm: spi0 Tainted: GW 5.2.0-rc1+ #5983
Hardware name: Generic OMAP4 (Flattened Device Tree)
PC is at 0x8
LR is at spi_res_release+0x54/0x80
pc : [<0008>]lr : []psr: 2113
sp : ed6e3e88 ip : ed6e3eb0 fp : ed6e3eac
r10: c0b9eca8 r9 : 0100 r8 : 0200
r7 : ed65bc00 r6 : ed6e5d3c r5 : ed6e5d0c r4 : c0d05254
r3 : 0008 r2 : c0d05264 r1 : ed6e5d0c r0 : ed65bc00
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: abf3c04a DAC: 0051
Process spi0 (pid: 71, stack limit = 0x0ef66f65)
Stack: (0xed6e3e88 to 0xed6e4000)
3e80: ed6e5cd0 ed6e5d0c ed65bc00 c0daf080 ed510410
3ea0: ed6e3eec ed6e3eb0 c06fd8c4 c06faa00 ed65b800 ed65ba20 ed65bee0
3ec0: ed6e3eec ed65bc00 ed6e5cd0 ed6e5d0c ed510410 ed510410 0001
3ee0: ed6e3f2c ed6e3ef0 c06fdcd4 c06fd560 0004 c0170948 ed6e3f20 ed65bdfc
3f00: e000 ed65be68 ed65be44 e000 c0dc7734 ed65be48 c0166f88
3f20: ed6e3f3c ed6e3f30 c06fe10c c06fd9a4 ed6e3f74 ed6e3f40 c0166f54 c06fe0f8
3f40: ed6e3f74 6eb8f9ff c0166780 ed3bccc0 ed659c00 ed6e2000 ed65be44
3f60: c0166eac ed115c44 ed6e3fac ed6e3f78 c0166e58 c0166eb8 ed3bccdc ed3bccdc
3f80: ed6e3fac ed659c00 c0166cf8
3fa0: ed6e3fb0 c01010e8 c0166d04
3fc0:
3fe0: 0013
Backtrace:
[] (spi_res_release) from []
(spi_transfer_one_message+0x370/0x444)
r9:ed510410 r8: r7:c0daf080 r6:ed65bc00 r5:ed6e5d0c r4:ed6e5cd0
[] (spi_transfer_one_message) from []
(__spi_pump_messages+0x33c/0x754)
r10:0001 r9:ed510410 r8:ed510410 r7: r6:ed6e5d0c r5:ed6e5cd0
r4:ed65bc00
[] (__spi_pump_messages) from []
(spi_pump_messages+0x20/0x24)
r10: r9:c0166f88 r8:ed65be48 r7:c0dc7734 r6:e000 r5:ed65be44
r4:ed65be68
[] (spi_pump_messages) from []
(kthread_worker_fn+0xa8/0x268)
[] (kthread_worker_fn) from [] (kthread+0x160/0x178)
r10:ed115c44 r9:c0166eac r8:ed65be44 r7:ed6e2000 r6:ed659c00 r5:ed3bccc0
r4:
[] (kthread) from [] (ret_from_fork+0x14/0x2c)
Exception stack(0xed6e3fb0 to 0xed6e3ff8)
3fa0:
3fc0:
3fe0: 0013
r10: r9: r8: r7: r6: r5:c0166cf8
r4:ed659c00
Code: bad PC value
---[ end trace a8011e9722dfda5e ]---
Re: [PATCH] arm64: arch_k3: Fix kconfig dependency warning
* Marc Zyngier [190510 18:30]:
> On Fri, 10 May 2019 06:16:38 +0100,
> Lokesh Vutla wrote:
> >
> >
> >
> > On 10/05/19 9:22 AM, YueHaibing wrote:
> > > Fix Kbuild warning when SOC_TI is not set
> > >
> > > WARNING: unmet direct dependencies detected for TI_SCI_INTA_IRQCHIP
> > > Depends on [n]: TI_SCI_PROTOCOL [=y] && SOC_TI [=n]
> > > Selected by [y]:
> > > - ARCH_K3 [=y]
> > >
> > > Fixes: 009669e74813 ("arm64: arch_k3: Enable interrupt controller
> > > drivers")
> > > Signed-off-by: YueHaibing
> >
> > Thanks for catching it.
> >
> > Reviewed-by: Lokesh Vutla
>
> Tony, can you please route this patch via armsoc?
Thanks adding Tero to loop so he can queue it.
Regards,
Tony
