Re: [PATCH] omapfb: reduce stack usage

[Ladislav Michl]

On Fri, Oct 18, 2019 at 05:30:04PM +0100, Sudip Mukherjee wrote:
> The build of xtensa allmodconfig is giving a warning of:
> In function 'dsi_dump_dsidev_irqs':
> warning: the frame size of 1120 bytes is larger than 1024 bytes
> 
> Allocate the memory for 'struct dsi_irq_stats' dynamically instead
> of assigning it in stack.

So now function can fail silently, executes longer, code is sligthly
bigger... And all that to silent warning about exceeding frame size.
Is it really worth "fixing"?

> Signed-off-by: Sudip Mukherjee 
> ---
>  drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 24 ++--
>  1 file changed, 14 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c 
> b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> index d620376216e1..43402467bf40 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> @@ -1536,22 +1536,25 @@ static void dsi_dump_dsidev_irqs(struct 
> platform_device *dsidev,
>  {
>   struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
>   unsigned long flags;
> - struct dsi_irq_stats stats;
> + struct dsi_irq_stats *stats;
>  
> + stats = kmalloc(sizeof(*stats), GFP_KERNEL);
> + if (!stats)
> + return;
>   spin_lock_irqsave(>irq_stats_lock, flags);
>  
> - stats = dsi->irq_stats;
> + memcpy(stats, >irq_stats, sizeof(*stats));
>   memset(>irq_stats, 0, sizeof(dsi->irq_stats));
>   dsi->irq_stats.last_reset = jiffies;
>  
>   spin_unlock_irqrestore(>irq_stats_lock, flags);
>  
>   seq_printf(s, "period %u ms\n",
> - jiffies_to_msecs(jiffies - stats.last_reset));
> + jiffies_to_msecs(jiffies - stats->last_reset));
>  
> - seq_printf(s, "irqs %d\n", stats.irq_count);
> + seq_printf(s, "irqs %d\n", stats->irq_count);
>  #define PIS(x) \
> - seq_printf(s, "%-20s %10d\n", #x, stats.dsi_irqs[ffs(DSI_IRQ_##x)-1]);
> + seq_printf(s, "%-20s %10d\n", #x, stats->dsi_irqs[ffs(DSI_IRQ_##x)-1]);
>  
>   seq_printf(s, "-- DSI%d interrupts --\n", dsi->module_id + 1);
>   PIS(VC0);
> @@ -1575,10 +1578,10 @@ static void dsi_dump_dsidev_irqs(struct 
> platform_device *dsidev,
>  
>  #define PIS(x) \
>   seq_printf(s, "%-20s %10d %10d %10d %10d\n", #x, \
> - stats.vc_irqs[0][ffs(DSI_VC_IRQ_##x)-1], \
> - stats.vc_irqs[1][ffs(DSI_VC_IRQ_##x)-1], \
> - stats.vc_irqs[2][ffs(DSI_VC_IRQ_##x)-1], \
> - stats.vc_irqs[3][ffs(DSI_VC_IRQ_##x)-1]);
> + stats->vc_irqs[0][ffs(DSI_VC_IRQ_##x)-1], \
> + stats->vc_irqs[1][ffs(DSI_VC_IRQ_##x)-1], \
> + stats->vc_irqs[2][ffs(DSI_VC_IRQ_##x)-1], \
> + stats->vc_irqs[3][ffs(DSI_VC_IRQ_##x)-1]);
>  
>   seq_printf(s, "-- VC interrupts --\n");
>   PIS(CS);
> @@ -1594,7 +1597,7 @@ static void dsi_dump_dsidev_irqs(struct platform_device 
> *dsidev,
>  
>  #define PIS(x) \
>   seq_printf(s, "%-20s %10d\n", #x, \
> - stats.cio_irqs[ffs(DSI_CIO_IRQ_##x)-1]);
> + stats->cio_irqs[ffs(DSI_CIO_IRQ_##x)-1]);
>  
>   seq_printf(s, "-- CIO interrupts --\n");
>   PIS(ERRSYNCESC1);
> @@ -1618,6 +1621,7 @@ static void dsi_dump_dsidev_irqs(struct platform_device 
> *dsidev,
>   PIS(ULPSACTIVENOT_ALL0);
>   PIS(ULPSACTIVENOT_ALL1);
>  #undef PIS
> + kfree(stats);
>  }
>  
>  static void dsi1_dump_irqs(struct seq_file *s)
> -- 
> 2.11.0

Re: [alsa-devel] Applied "ASoc: tas2770: Fix build error without GPIOLIB" to the asoc tree

[Ladislav Michl]

Hi YueHaibing & Mark,

On Mon, Oct 07, 2019 at 02:03:09PM +0100, Mark Brown wrote:
> The patch
> 
>ASoc: tas2770: Fix build error without GPIOLIB
> 
> has been applied to the asoc tree at
> 
>https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.5

Hmm, too late it seems...
Patch should actually remove  as this is legacy one (see comment
on the top and also Documentation/driver-api/gpio/consumer.rst)

And that brings a question. Given this is -next only is it actually possible
to squash fixes into 1a476abc723e ("tas2770: add tas2770 smart PA kernel 
driver")
just to make bisect a bit more happy?

l.

> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.  
> 
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
> 
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
> 
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
> 
> Thanks,
> Mark
> 
> >From 03fe492e8346d3da59b6eb7ea306d46ebf22e9d5 Mon Sep 17 00:00:00 2001
> From: YueHaibing 
> Date: Sun, 6 Oct 2019 18:46:31 +0800
> Subject: [PATCH] ASoc: tas2770: Fix build error without GPIOLIB
> 
> If GPIOLIB is not set, building fails:
> 
> sound/soc/codecs/tas2770.c: In function tas2770_reset:
> sound/soc/codecs/tas2770.c:38:3: error: implicit declaration of function 
> gpiod_set_value_cansleep; did you mean gpio_set_value_cansleep? 
> [-Werror=implicit-function-declaration]
>gpiod_set_value_cansleep(tas2770->reset_gpio, 0);
>^~~~
>gpio_set_value_cansleep
> sound/soc/codecs/tas2770.c: In function tas2770_i2c_probe:
> sound/soc/codecs/tas2770.c:749:24: error: implicit declaration of function 
> devm_gpiod_get_optional; did you mean devm_regulator_get_optional? 
> [-Werror=implicit-function-declaration]
>   tas2770->reset_gpio = devm_gpiod_get_optional(tas2770->dev,
> ^~~
> devm_regulator_get_optional
> sound/soc/codecs/tas2770.c:751:13: error: GPIOD_OUT_HIGH undeclared (first 
> use in this function); did you mean GPIOF_INIT_HIGH?
>  GPIOD_OUT_HIGH);
>      ^~
>  GPIOF_INIT_HIGH
> 
> Reported-by: Hulk Robot 
> Fixes: 1a476abc723e ("tas2770: add tas2770 smart PA kernel driver")
> Suggested-by: Ladislav Michl 
> Signed-off-by: YueHaibing 
> Link: https://lore.kernel.org/r/20191006104631.60608-1-yuehaib...@huawei.com
> Signed-off-by: Mark Brown 
> ---
>  sound/soc/codecs/tas2770.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/sound/soc/codecs/tas2770.c b/sound/soc/codecs/tas2770.c
> index dbbb21fe0548..15f6fcc6d87e 100644
> --- a/sound/soc/codecs/tas2770.c
> +++ b/sound/soc/codecs/tas2770.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> -- 
> 2.20.1
> 
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH v2 -next] ASoc: tas2770: Fix build error without GPIOLIB

[Ladislav Michl]

Hi Michał,

On Sun, Oct 06, 2019 at 05:31:58PM +0200, mirq-li...@rere.qmqm.pl wrote:
> On Sun, Oct 06, 2019 at 06:46:31PM +0800, YueHaibing wrote:
> > If GPIOLIB is not set, building fails:
> > 
> > sound/soc/codecs/tas2770.c: In function tas2770_reset:
> > sound/soc/codecs/tas2770.c:38:3: error: implicit declaration of function 
> > gpiod_set_value_cansleep; did you mean gpio_set_value_cansleep? 
> > [-Werror=implicit-function-declaration]
> >gpiod_set_value_cansleep(tas2770->reset_gpio, 0);
> >^~~~
> >gpio_set_value_cansleep
> > sound/soc/codecs/tas2770.c: In function tas2770_i2c_probe:
> > sound/soc/codecs/tas2770.c:749:24: error: implicit declaration of function 
> > devm_gpiod_get_optional; did you mean devm_regulator_get_optional? 
> > [-Werror=implicit-function-declaration]
> >   tas2770->reset_gpio = devm_gpiod_get_optional(tas2770->dev,
> > ^~~
> > devm_regulator_get_optional
> > sound/soc/codecs/tas2770.c:751:13: error: GPIOD_OUT_HIGH undeclared (first 
> > use in this function); did you mean GPIOF_INIT_HIGH?
> >  GPIOD_OUT_HIGH);
> >  ^~
> >  GPIOF_INIT_HIGH
> > 
> > Reported-by: Hulk Robot 
> > Fixes: 1a476abc723e ("tas2770: add tas2770 smart PA kernel driver")
> > Suggested-by: Ladislav Michl 
> > Signed-off-by: YueHaibing 
> > ---
> > v2: Add missing include file
> > ---
> >  sound/soc/codecs/tas2770.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/sound/soc/codecs/tas2770.c b/sound/soc/codecs/tas2770.c
> > index 9da88cc..a36d0d7 100644
> > --- a/sound/soc/codecs/tas2770.c
> > +++ b/sound/soc/codecs/tas2770.c
> > @@ -15,6 +15,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> 
> The Kconfig part is missing - is this intended? If I guess correctly,
> the driver won't work without GPIOLIB, so it should either
> 'select GPIOLIB' or 'depends on GPIOLIB || COMPILE_TEST' or even
> 'select GPIOLIB if !COMPILE_TEST'.

while the first one is actually preferable I won't do this in this patch,
but rather generally. The same you can say about regulator, regmap and
other interfaces, so perhaps leaving that to patchset focusing on this
kind of problem seem to be better.

Btw, I guess linux/gpio/consumer.h is enough for this driver and including
linux/gpio.h should be dropped.

ladis

Re: [alsa-devel] [PATCH -next] ASoc: tas2770: Fix build error without GPIOLIB

[Ladislav Michl]

Dear YueHaibing,

On Sun, Oct 06, 2019 at 03:22:41PM +0800, YueHaibing wrote:
> If GPIOLIB is not set, building fails:
> 
> sound/soc/codecs/tas2770.c: In function tas2770_reset:
> sound/soc/codecs/tas2770.c:38:3: error: implicit declaration of function 
> gpiod_set_value_cansleep; did you mean gpio_set_value_cansleep? 
> [-Werror=implicit-function-declaration]
>gpiod_set_value_cansleep(tas2770->reset_gpio, 0);
>^~~~
>gpio_set_value_cansleep
> sound/soc/codecs/tas2770.c: In function tas2770_i2c_probe:
> sound/soc/codecs/tas2770.c:749:24: error: implicit declaration of function 
> devm_gpiod_get_optional; did you mean devm_regulator_get_optional? 
> [-Werror=implicit-function-declaration]
>   tas2770->reset_gpio = devm_gpiod_get_optional(tas2770->dev,
> ^~~
> devm_regulator_get_optional
> sound/soc/codecs/tas2770.c:751:13: error: GPIOD_OUT_HIGH undeclared (first 
> use in this function); did you mean GPIOF_INIT_HIGH?
>  GPIOD_OUT_HIGH);
>  ^~
>  GPIOF_INIT_HIGH
> 
> Reported-by: Hulk Robot 
> Fixes: 1a476abc723e ("tas2770: add tas2770 smart PA kernel driver")
> Signed-off-by: YueHaibing 
> ---
>  sound/soc/codecs/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> index bcac957..d639f17 100644
> --- a/sound/soc/codecs/Kconfig
> +++ b/sound/soc/codecs/Kconfig
> @@ -1108,6 +1108,7 @@ config SND_SOC_TAS2552
>  config SND_SOC_TAS2770
>   tristate "Texas Instruments TAS2770 speaker amplifier"
>   depends on I2C
> + select GPIOLIB

GPIOLIB API is working perfectly fine even if GPIOLIB is not selected
and gpiod_* functions will merely return -ENOSYS in this case.
Please see  and fix your patch accordingly.

>  config SND_SOC_TAS5086
>   tristate "Texas Instruments TAS5086 speaker amplifier"
> -- 
> 2.7.4
> 
> 
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH] ARM: OMAP2+: Delete an unnecessary kfree() call in omap_hsmmc_pdata_init()

[Ladislav Michl]

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 

Re: [alsa-devel] [PATCH -next] soundwire: Fix -Wunused-function warning

[Ladislav Michl]

On Fri, Aug 16, 2019 at 10:14:09PM +0800, YueHaibing wrote:
> If CONFIG_ACPI is not set, gcc warning this:
> 
> drivers/soundwire/slave.c:16:12: warning:
>  'sdw_slave_add' defined but not used [-Wunused-function]
> 
> move them to #ifdef CONFIG_ACPI block.

...and that makes slave.c empty, right? So it boils down to
obj-$(CONFIG_ACPI) += slave.o

> Reported-by: Hulk Robot 
> Signed-off-by: YueHaibing 
> ---
>  drivers/soundwire/slave.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soundwire/slave.c b/drivers/soundwire/slave.c
> index f39a581..34c7e65 100644
> --- a/drivers/soundwire/slave.c
> +++ b/drivers/soundwire/slave.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include "bus.h"
>  
> +#if IS_ENABLED(CONFIG_ACPI)
>  static void sdw_slave_release(struct device *dev)
>  {
>   struct sdw_slave *slave = dev_to_sdw_dev(dev);
> @@ -60,7 +61,6 @@ static int sdw_slave_add(struct sdw_bus *bus,
>   return ret;
>  }
>  
> -#if IS_ENABLED(CONFIG_ACPI)
>  /*
>   * sdw_acpi_find_slaves() - Find Slave devices in Master ACPI node
>   * @bus: SDW bus instance
> -- 
> 2.7.4
> 
> 
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] [PATCH] sound: soc: codecs: wcd9335: add irqflag IRQF_ONESHOT flag

[Ladislav Michl]

On Fri, Jul 05, 2019 at 12:40:26AM +0530, Hariprasad Kelam wrote:
> Add IRQF_ONESHOT to ensure "Interrupt is not reenabled after the hardirq
> handler finished".
> 
> fixes below issue reported by coccicheck
> 
> sound/soc/codecs/wcd9335.c:4068:8-33: ERROR: Threaded IRQ with no
> primary handler requested without IRQF_ONESHOT
> 
> Signed-off-by: Hariprasad Kelam 
> ---
>  sound/soc/codecs/wcd9335.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/sound/soc/codecs/wcd9335.c b/sound/soc/codecs/wcd9335.c
> index 85737fe..7ab9bf6f 100644
> --- a/sound/soc/codecs/wcd9335.c
> +++ b/sound/soc/codecs/wcd9335.c
> @@ -4056,6 +4056,9 @@ static struct wcd9335_irq wcd9335_irqs[] = {
>  static int wcd9335_setup_irqs(struct wcd9335_codec *wcd)
>  {
>   int irq, ret, i;
> + unsigned long irqflags;
> +
> + irqflags = IRQF_TRIGGER_RISING | IRQF_ONESHOT;

Why does this change trigger adding a variable?

>   for (i = 0; i < ARRAY_SIZE(wcd9335_irqs); i++) {
>   irq = regmap_irq_get_virq(wcd->irq_data, wcd9335_irqs[i].irq);
> @@ -4067,7 +4070,7 @@ static int wcd9335_setup_irqs(struct wcd9335_codec *wcd)
>  
>   ret = devm_request_threaded_irq(wcd->dev, irq, NULL,
>   wcd9335_irqs[i].handler,
> - IRQF_TRIGGER_RISING,
> + irqflags,
>   wcd9335_irqs[i].name, wcd);
>   if (ret) {
>   dev_err(wcd->dev, "Failed to request %s\n",
> -- 
> 2.7.4
> 
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH v3] mtd: rawnand: ams-delta: Drop board specific partition info

[Ladislav Michl]

On Thu, Apr 25, 2019 at 08:42:22PM +0200, Janusz Krzysztofik wrote:
> Hi Ladislav,
> 
> On Thursday, April 25, 2019 12:14:28 AM CEST Ladislav Michl wrote:
> > Hi Janusz,
> > 
> > On Wed, Apr 24, 2019 at 08:02:12PM +0200, Janusz Krzysztofik wrote:
> > > After recent modifications, only a hardcoded partition info makes
> > > the driver device specific.  Other than that, the driver uses GPIO
> > > exclusively and can be used on any hardware.
> > > 
> > > Drop the partition info and use MTD partition parser with default list
> > > of parser names instead.  For the OF parser to work correctly, pass
> > > device of_node to mtd.
> > > 
> > > Amstrad Delta users should append the following partition info to their
> > > kernel command line, possibly embedding it in CONFIG_CMDLINE:
> > > 
> > > mtdparts=ams-delta-nand:3584k(Kernel),256k(u-boot),256k(u-boot_params),\
> > > 256k(Amstrad_LDR),27m(File_system),768k(PBL_reserved)
> > 
> > now, when driver is no longer Amstrad Delta specific, why would you want
> > to have ams-delta-nand hardcoded on kernel cmdline? I'm assuming at some
> > point this driver will become gpio-nand [*] or something like that and
> > asking users to change their kernel cmdline twice is just unwise :)
> 
> Hmm, I have no idea of a good name for the driver if not "gpio-nand". Can you 
> suggest one?

gpio-nand is so good name that it should be worth merging gpio.c and
ams-delta.c into gpio_nand.c :)

> As a workaround, I can add a platform device id table to the driver with "ams-
> delta-nand" as a supported device name in hope that survives possible future 
> driver renaming.
> 
> > [*] btw, it is really shame gpio-nand name is already taken by driver
> > living in drivers/mtd/nand/raw/gpio.c which is more likely gpio-mem-nand
> > used by at least CompuLab CM-X255 and Picochip picoXcell.
> 
> I think the best approach would be to expose NAND data ports of those 
> machines 
> as GPIO ports, possibly reusing the "gpio-nand" driver code while creating a 
> new GPIO driver for them if "basic-mmio-gpio" occurs inappropriate, and use 
> the pure GPIO NAND driver on top.

What about adding two fields into struct ams_delta_nand holding pointers to
either ams_delta_{read,write}_buf (renamed to gpio_nand_...) or mmio r/w
functions depending on driver configuration?

> > Otherwise your work on this driver is so amazing that I just spent
> > couple of hours finding that phone and compiling some decent userspace
> > for it :) Thank you!
> 
> I'm glad you like it :-)
> Janusz

Best regards,
ladis

Re: [PATCH v3] mtd: rawnand: ams-delta: Drop board specific partition info

[Ladislav Michl]

Hi Janusz,

On Wed, Apr 24, 2019 at 08:02:12PM +0200, Janusz Krzysztofik wrote:
> After recent modifications, only a hardcoded partition info makes
> the driver device specific.  Other than that, the driver uses GPIO
> exclusively and can be used on any hardware.
> 
> Drop the partition info and use MTD partition parser with default list
> of parser names instead.  For the OF parser to work correctly, pass
> device of_node to mtd.
> 
> Amstrad Delta users should append the following partition info to their
> kernel command line, possibly embedding it in CONFIG_CMDLINE:
> 
> mtdparts=ams-delta-nand:3584k(Kernel),256k(u-boot),256k(u-boot_params),\
> 256k(Amstrad_LDR),27m(File_system),768k(PBL_reserved)

now, when driver is no longer Amstrad Delta specific, why would you want
to have ams-delta-nand hardcoded on kernel cmdline? I'm assuming at some
point this driver will become gpio-nand [*] or something like that and
asking users to change their kernel cmdline twice is just unwise :)

[*] btw, it is really shame gpio-nand name is already taken by driver
living in drivers/mtd/nand/raw/gpio.c which is more likely gpio-mem-nand
used by at least CompuLab CM-X255 and Picochip picoXcell.

Otherwise your work on this driver is so amazing that I just spent
couple of hours finding that phone and compiling some decent userspace
for it :) Thank you!

> For their convenience, that information is added to the board Kconfig
> entry help text, as well as CONFIG_MTD_CMDLINE_PARTS symbol is selected
> automatically from the board Kconfig entry if the NAND driver is also
> selected.
> 
> Signed-off-by: Janusz Krzysztofik 
> Cc: Tony Lindgren 
> Cc: Aaro Koskinen 
> ---
> Changelog:
> v2->v3:
> - add information on the requirement for passing partition info via
>   kernel command line to the board Kconfig entry help text
> v1->v2:
> - fix a typo poitned out by Aaro - thanks!
> - fix device_node not passed to OF parser via mtd_info
> - commit message reworded and reformatted a bit for better readability
> 
>  arch/arm/mach-omap1/Kconfig  |  7 ++-
>  drivers/mtd/nand/raw/ams-delta.c | 29 ++---
>  2 files changed, 8 insertions(+), 28 deletions(-)
> 
> diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
> index c4694f26b5c4..41a47d251cac 100644
> --- a/arch/arm/mach-omap1/Kconfig
> +++ b/arch/arm/mach-omap1/Kconfig
> @@ -164,17 +164,22 @@ config MACH_NOKIA770
> have such a device.
>  
>  config MACH_AMS_DELTA
> - bool "Amstrad E3 (Delta)"
> + bool "Amstrad E3 (Delta) - see help for important information"
>   depends on ARCH_OMAP1 && ARCH_OMAP15XX
>   select FIQ
>   select GPIO_GENERIC_PLATFORM
>   select LEDS_GPIO_REGISTER
>   select REGULATOR
>   select REGULATOR_FIXED_VOLTAGE
> + select MTD_CMDLINE_PARTS if MTD_NAND_AMS_DELTA
>   help
> Support for the Amstrad E3 (codename Delta) videophone. Say Y here
> if you have such a device.
>  
> +   If you are using built-in NAND, append the following partition
> +   info to kernel command line:
> +   
> mtdparts=ams-delta-nand:3584k(Kernel),256k(u-boot),256k(u-boot_params),256k(Amstrad_LDR),27m(File_system),768k(PBL_reserved)
> +
>  config MACH_OMAP_GENERIC
>   bool "Generic OMAP board"
>   depends on ARCH_OMAP1 && (ARCH_OMAP15XX || ARCH_OMAP16XX)
> diff --git a/drivers/mtd/nand/raw/ams-delta.c 
> b/drivers/mtd/nand/raw/ams-delta.c
> index 8312182088c1..e0f09179bbda 100644
> --- a/drivers/mtd/nand/raw/ams-delta.c
> +++ b/drivers/mtd/nand/raw/ams-delta.c
> @@ -41,31 +41,6 @@ struct ams_delta_nand {
>   booldata_in;
>  };
>  
> -/*
> - * Define partitions for flash devices
> - */
> -
> -static const struct mtd_partition partition_info[] = {
> - { .name = "Kernel",
> -   .offset   = 0,
> -   .size = 3 * SZ_1M + SZ_512K },
> - { .name = "u-boot",
> -   .offset   = 3 * SZ_1M + SZ_512K,
> -   .size = SZ_256K },
> - { .name = "u-boot params",
> -   .offset   = 3 * SZ_1M + SZ_512K + SZ_256K,
> -   .size = SZ_256K },
> - { .name = "Amstrad LDR",
> -   .offset   = 4 * SZ_1M,
> -   .size = SZ_256K },
> - { .name = "File system",
> -   .offset   = 4 * SZ_1M + 1 * SZ_256K,
> -   .size = 27 * SZ_1M },
> - { .name = "PBL reserved",
> -   .offset   = 32 * SZ_1M - 3 * SZ_256K,
> -   .size =  3 * SZ_256K },
> -};
> -
>  static void ams_delta_write_commit(struct ams_delta_nand *priv)
>  {
>   gpiod_set_value(priv->gpiod_nwe, 0);
> @@ -238,6 +213,7 @@ static int ams_delta_init(struct platform_device *pdev)
>   mtd->dev.parent = >dev;
>  
>   nand_set_controller_data(this, priv);
> + nand_set_flash_node(this, pdev->dev.of_node);
>  
>   priv->gpiod_rdy = devm_gpiod_get_optional(>dev, "rdy", GPIOD_IN);
>   if (IS_ERR(priv->gpiod_rdy)) {
> 

Re: [PATCH] clocksource/drivers/timer-ti-dm: Remove omap_dm_timer_set_load_start

[Ladislav Michl]

Hello Nathan,

On Tue, Mar 26, 2019 at 10:01:27PM -0700, Nathan Chancellor wrote:
> Commit 008258d995a6 ("clocksource/drivers/timer-ti-dm: Make
> omap_dm_timer_set_load_start() static") made omap_dm_time_set_load_start
> static because its prototype was not defined in a header. Unfortunately,
> this causes a build warning on multi_v7_defconfig because this function
> is not used anywhere in this translation unit:
> 
> drivers/clocksource/timer-ti-dm.c:589:12: error: unused function
> 'omap_dm_timer_set_load_start' [-Werror,-Wunused-function]
> 
> In fact, omap_dm_timer_set_load_start hasn't been used anywhere since
> commit f190be7f39a5 ("staging: tidspbridge: remove driver") and the
> prototype was removed in commit 592ea6bd1fad ("clocksource: timer-ti-dm:
> Make unexported functions static"), which is probably where this should
> have happened.

Alternatively you might want to look at "clocksource: timer-ti-dm: Add event
capture": https://patchwork.kernel.org/patch/10237217/ (it makes use of
function being removed here). It is a part of an attempt to add event capture
for OMAP. Of course I would like this functionality to be implemented, but
as I do not have a time to continue, I cannot really object removing this
function.

Just in case you'd be interested in finishing this task ;-)

ladis

> Fixes: 592ea6bd1fad ("clocksource: timer-ti-dm: Make unexported functions 
> static")
> Fixes: 008258d995a6 ("clocksource/drivers/timer-ti-dm: Make 
> omap_dm_timer_set_load_start() static")
> Signed-off-by: Nathan Chancellor 
> ---
> 
> My apologies if this has already been sent, I didn't see anything in tip
> or on LKML.
> 
>  drivers/clocksource/timer-ti-dm.c | 28 
>  1 file changed, 28 deletions(-)
> 
> diff --git a/drivers/clocksource/timer-ti-dm.c 
> b/drivers/clocksource/timer-ti-dm.c
> index 3352da6ed61f..ee8ec5a8cb16 100644
> --- a/drivers/clocksource/timer-ti-dm.c
> +++ b/drivers/clocksource/timer-ti-dm.c
> @@ -585,34 +585,6 @@ static int omap_dm_timer_set_load(struct omap_dm_timer 
> *timer, int autoreload,
>   return 0;
>  }
>  
> -/* Optimized set_load which removes costly spin wait in timer_start */
> -static int omap_dm_timer_set_load_start(struct omap_dm_timer *timer,
> - int autoreload, unsigned int load)
> -{
> - u32 l;
> -
> - if (unlikely(!timer))
> - return -EINVAL;
> -
> - omap_dm_timer_enable(timer);
> -
> - l = omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
> - if (autoreload) {
> - l |= OMAP_TIMER_CTRL_AR;
> - omap_dm_timer_write_reg(timer, OMAP_TIMER_LOAD_REG, load);
> - } else {
> - l &= ~OMAP_TIMER_CTRL_AR;
> - }
> - l |= OMAP_TIMER_CTRL_ST;
> -
> - __omap_dm_timer_load_start(timer, l, load, timer->posted);
> -
> - /* Save the context */
> - timer->context.tclr = l;
> - timer->context.tldr = load;
> - timer->context.tcrr = load;
> - return 0;
> -}
>  static int omap_dm_timer_set_match(struct omap_dm_timer *timer, int enable,
>  

[PATCH] PM/runtime: Optimize pm_runtime_autosuspend_expiration()

[Ladislav Michl]

pm_runtime_autosuspend_expiration calls ktime_get_mono_fast_ns
even when its returned value may be unused. Therefore get
current time later and remove gotos while there.

Signed-off-by: Ladislav Michl 
Acked-by: Tony Lindgren 
Acked-by: Vincent Guittot 
---
 This patch is based on top of bleeding-edge branch, where
 "[PATCH v2 ] PM-runtime: fix deadlock with ktime" is sitting.
 I expect v3 of that patch, which should not harm this one.
 It is meant to replace "PM/runtime: Do not needlessly call ktime_get"
 sent earlier.

 drivers/base/power/runtime.c | 19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 65e2b5f48e0c..7bbe28faca8d 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -145,24 +145,21 @@ static void pm_runtime_cancel_pending(struct device *dev)
 u64 pm_runtime_autosuspend_expiration(struct device *dev)
 {
int autosuspend_delay;
-   u64 last_busy, expires = 0;
-   u64 now = ktime_get_mono_fast_ns();
+   u64 expires;
 
if (!dev->power.use_autosuspend)
-   goto out;
+   return 0;
 
autosuspend_delay = READ_ONCE(dev->power.autosuspend_delay);
if (autosuspend_delay < 0)
-   goto out;
-
-   last_busy = READ_ONCE(dev->power.last_busy);
+   return 0;
 
-   expires = last_busy + (u64)autosuspend_delay * NSEC_PER_MSEC;
-   if (expires <= now)
-   expires = 0;/* Already expired. */
+   expires  = READ_ONCE(dev->power.last_busy);
+   expires += (u64)autosuspend_delay * NSEC_PER_MSEC;
+   if (expires > ktime_get_mono_fast_ns())
+   return expires; /* Expires in the future */
 
- out:
-   return expires;
+   return 0;
 }
 EXPORT_SYMBOL_GPL(pm_runtime_autosuspend_expiration);
 
-- 
2.20.1

Re: [PATCH v2 ] PM-runtime: fix deadlock with ktime

[Ladislav Michl]

On Wed, Jan 30, 2019 at 02:06:07PM +0100, Rafael J. Wysocki wrote:
> On Wed, Jan 30, 2019 at 12:16 PM Vincent Guittot
>  wrote:
> >
> > A deadlock has been seen when swicthing clocksources which use PM runtime.
> > The call path is:
> > change_clocksource
> > ...
> > write_seqcount_begin
> > ...
> > timekeeping_update
> > ...
> > sh_cmt_clocksource_enable
> > ...
> > rpm_resume
> > pm_runtime_mark_last_busy
> > ktime_get
> > do
> > read_seqcount_begin
> > while read_seqcount_retry
> > 
> > write_seqcount_end
> >
> > Although we should be safe because we haven't yet changed the clocksource
> > at that time, we can't because of seqcount protection.
> >
> > Use ktime_get_mono_fast_ns() instead which is lock safe for such case
> >
> > With ktime_get_mono_fast_ns, the timestamp is not guaranteed to be
> > monotonic across an update and as a result can goes backward. According to
> > update_fast_timekeeper() description: "In the worst case, this can
> > result is a slightly wrong timestamp (a few nanoseconds)". For
> > PM runtime autosuspend, this means only that the suspend decision can
> > be slightly sub optimal.
> >
> > Fixes: 8234f6734c5d ("PM-runtime: Switch autosuspend over to using 
> > hrtimers")
> > Reported-by: Biju Das 
> > Signed-off-by: Vincent Guittot 
> 
> I've queued this one up as a fix for 5.0, but unfortunately it clashes
> with the patch from Ladislav Michl at
> https://patchwork.kernel.org/patch/10755477/ which has been dropped
> now.
> 
> Can you or Ladislav please rebase that patch on top of this one and repost?
> 
> > ---
> >
> > - v2: Updated commit message to explain the impact of using
> >   ktime_get_mono_fast_ns()
> >
> >  drivers/base/power/runtime.c | 10 +-
> >  include/linux/pm_runtime.h   |  2 +-
> >  2 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> > index 457be03..708a13f 100644
> > --- a/drivers/base/power/runtime.c
> > +++ b/drivers/base/power/runtime.c
> > @@ -130,7 +130,7 @@ u64 pm_runtime_autosuspend_expiration(struct device 
> > *dev)
> >  {
> > int autosuspend_delay;
> > u64 last_busy, expires = 0;
> > -   u64 now = ktime_to_ns(ktime_get());
> > +   u64 now = ktime_get_mono_fast_ns();
> >
> > if (!dev->power.use_autosuspend)
> > goto out;
> > @@ -909,7 +909,7 @@ static enum hrtimer_restart  pm_suspend_timer_fn(struct 
> > hrtimer *timer)
> >  * If 'expires' is after the current time, we've been called
> >  * too early.
> >  */
> > -   if (expires > 0 && expires < ktime_to_ns(ktime_get())) {
> > +   if (expires > 0 && expires < ktime_get_mono_fast_ns()) {
> > dev->power.timer_expires = 0;
> > rpm_suspend(dev, dev->power.timer_autosuspends ?
> > (RPM_ASYNC | RPM_AUTO) : RPM_ASYNC);
> > @@ -928,7 +928,7 @@ static enum hrtimer_restart  pm_suspend_timer_fn(struct 
> > hrtimer *timer)
> >  int pm_schedule_suspend(struct device *dev, unsigned int delay)
> >  {
> > unsigned long flags;
> > -   ktime_t expires;
> > +   u64 expires;
> > int retval;
> >
> > spin_lock_irqsave(>power.lock, flags);
> > @@ -945,8 +945,8 @@ int pm_schedule_suspend(struct device *dev, unsigned 
> > int delay)
> > /* Other scheduled or pending requests need to be canceled. */
> > pm_runtime_cancel_pending(dev);
> >
> > -   expires = ktime_add(ktime_get(), ms_to_ktime(delay));
> > -   dev->power.timer_expires = ktime_to_ns(expires);
> > +   expires = ktime_get_mono_fast_ns() + (u64)delay * NSEC_PER_MSEC);

Just FYI, this one does not compile^
I'm going to send updated optimization patch anyway as fixing this one will not
break it :)

> > +   dev->power.timer_expires = expires;
> > dev->power.timer_autosuspends = 0;
> > hrtimer_start(>power.suspend_timer, expires, HRTIMER_MODE_ABS);
> >
> > diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h
> > index 54af4ee..fed5be7 100644
> > --- a/include/linux/pm_runtime.h
> > +++ b/include/linux/pm_runtime.h
> > @@ -105,7 +105,7 @@ static inline bool pm_runtime_callbacks_present(struct 
> > device *dev)
> >
> >  static inline void pm_runtime_mark_last_busy(struct device *dev)
> >  {
> > -   WRITE_ONCE(dev->power.last_busy, ktime_to_ns(ktime_get()));
> > +   WRITE_ONCE(dev->power.last_busy, ktime_get_mono_fast_ns());
> >  }
> >
> >  static inline bool pm_runtime_is_irq_safe(struct device *dev)
> > --
> > 2.7.4
> >

Re: [PATCH v2 ] PM-runtime: fix deadlock with ktime

[Ladislav Michl]

On Wed, Jan 30, 2019 at 02:18:49PM +0100, Vincent Guittot wrote:
> On Wed, 30 Jan 2019 at 14:06, Rafael J. Wysocki  wrote:
> >
> > On Wed, Jan 30, 2019 at 12:16 PM Vincent Guittot
> >  wrote:
> > >
> > > A deadlock has been seen when swicthing clocksources which use PM runtime.
> > > The call path is:
> > > change_clocksource
> > > ...
> > > write_seqcount_begin
> > > ...
> > > timekeeping_update
> > > ...
> > > sh_cmt_clocksource_enable
> > > ...
> > > rpm_resume
> > > pm_runtime_mark_last_busy
> > > ktime_get
> > > do
> > > read_seqcount_begin
> > > while read_seqcount_retry
> > > 
> > > write_seqcount_end
> > >
> > > Although we should be safe because we haven't yet changed the clocksource
> > > at that time, we can't because of seqcount protection.
> > >
> > > Use ktime_get_mono_fast_ns() instead which is lock safe for such case
> > >
> > > With ktime_get_mono_fast_ns, the timestamp is not guaranteed to be
> > > monotonic across an update and as a result can goes backward. According to
> > > update_fast_timekeeper() description: "In the worst case, this can
> > > result is a slightly wrong timestamp (a few nanoseconds)". For
> > > PM runtime autosuspend, this means only that the suspend decision can
> > > be slightly sub optimal.
> > >
> > > Fixes: 8234f6734c5d ("PM-runtime: Switch autosuspend over to using 
> > > hrtimers")
> > > Reported-by: Biju Das 
> > > Signed-off-by: Vincent Guittot 
> >
> > I've queued this one up as a fix for 5.0, but unfortunately it clashes
> > with the patch from Ladislav Michl at
> > https://patchwork.kernel.org/patch/10755477/ which has been dropped
> > now.
> 
> Thanks for adding Ladislav in this thread.
> I'm sorry I forgot to add him in the loop.
> 
> >
> > Can you or Ladislav please rebase that patch on top of this one and repost?
> 
> Ladislav,
> 
> Let me know if you prefer to rebase and repost your patch of if you
> want me to do.

I'll rebase it on top of Rafael's bleeding-edge branch.

Best regards,
ladis

> Regards,
> Vincent
> 
> >
> > > ---
> > >
> > > - v2: Updated commit message to explain the impact of using
> > >   ktime_get_mono_fast_ns()
> > >
> > >  drivers/base/power/runtime.c | 10 +-
> > >  include/linux/pm_runtime.h   |  2 +-
> > >  2 files changed, 6 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> > > index 457be03..708a13f 100644
> > > --- a/drivers/base/power/runtime.c
> > > +++ b/drivers/base/power/runtime.c
> > > @@ -130,7 +130,7 @@ u64 pm_runtime_autosuspend_expiration(struct device 
> > > *dev)
> > >  {
> > > int autosuspend_delay;
> > > u64 last_busy, expires = 0;
> > > -   u64 now = ktime_to_ns(ktime_get());
> > > +   u64 now = ktime_get_mono_fast_ns();
> > >
> > > if (!dev->power.use_autosuspend)
> > > goto out;
> > > @@ -909,7 +909,7 @@ static enum hrtimer_restart  
> > > pm_suspend_timer_fn(struct hrtimer *timer)
> > >  * If 'expires' is after the current time, we've been called
> > >  * too early.
> > >  */
> > > -   if (expires > 0 && expires < ktime_to_ns(ktime_get())) {
> > > +   if (expires > 0 && expires < ktime_get_mono_fast_ns()) {
> > > dev->power.timer_expires = 0;
> > > rpm_suspend(dev, dev->power.timer_autosuspends ?
> > > (RPM_ASYNC | RPM_AUTO) : RPM_ASYNC);
> > > @@ -928,7 +928,7 @@ static enum hrtimer_restart  
> > > pm_suspend_timer_fn(struct hrtimer *timer)
> > >  int pm_schedule_suspend(struct device *dev, unsigned int delay)
> > >  {
> > > unsigned long flags;
> > > -   ktime_t expires;
> > > +   u64 expires;
> > > int retval;
> > >
> > > spin_lock_irqsave(>power.lock, flags);
> > > @@ -945,8 +945,8 @@ int pm_schedule_suspend(struct device *dev, unsigned 
> > > int delay)
> > > /* Other scheduled

[PATCH] PM/runtime: Do not needlessly call ktime_get

[Ladislav Michl]

pm_runtime_autosuspend_expiration calls ktime_get even when
its returned value may be unused. Therefore get current time
later and remove gotos while there.

Signed-off-by: Ladislav Michl 
---
 NOTE: Depends on Vincent's "[PATCH v2] PM/runtime: Fix autosuspend_delay
   on 32bits arch"!

 drivers/base/power/runtime.c | 19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 457be03b744d..836b1b8784eb 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -129,24 +129,21 @@ static void pm_runtime_cancel_pending(struct device *dev)
 u64 pm_runtime_autosuspend_expiration(struct device *dev)
 {
int autosuspend_delay;
-   u64 last_busy, expires = 0;
-   u64 now = ktime_to_ns(ktime_get());
+   u64 expires;
 
if (!dev->power.use_autosuspend)
-   goto out;
+   return 0;
 
autosuspend_delay = READ_ONCE(dev->power.autosuspend_delay);
if (autosuspend_delay < 0)
-   goto out;
-
-   last_busy = READ_ONCE(dev->power.last_busy);
+   return 0;
 
-   expires = last_busy + (u64)autosuspend_delay * NSEC_PER_MSEC;
-   if (expires <= now)
-   expires = 0;/* Already expired. */
+   expires  = READ_ONCE(dev->power.last_busy);
+   expires += (u64)autosuspend_delay * NSEC_PER_MSEC;
+   if (expires > ktime_to_ns(ktime_get()))
+   return expires; /* Expires in the future */
 
- out:
-   return expires;
+   return 0;
 }
 EXPORT_SYMBOL_GPL(pm_runtime_autosuspend_expiration);
 
-- 
2.20.1

Re: Regression in v5.0-rc1 with autosuspend hrtimers

[Ladislav Michl]

On Thu, Jan 10, 2019 at 08:50:14AM +0100, Vincent Guittot wrote:
> On Thu, 10 Jan 2019 at 08:46, Ladislav Michl  wrote:
> >
> > On Wed, Jan 09, 2019 at 11:06:34PM +0100, Rafael J. Wysocki wrote:
> > > On Wed, Jan 9, 2019 at 7:05 PM Vincent Guittot
> > >  wrote:
> > > >
> > > > On Wed, 9 Jan 2019 at 18:26, Ladislav Michl  
> > > > wrote:
> > > > >
> > > > > On Wed, Jan 09, 2019 at 05:32:31PM +0100, Vincent Guittot wrote:
> > > > > > On Wed, 9 Jan 2019 at 17:07, Ladislav Michl  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Wed, Jan 09, 2019 at 03:12:25PM +0100, Vincent Guittot wrote:
> > > > > > > > Please keep all thread list when replying :-)
> > > > > > >
> > > > > > > Ahh, sorry for that...
> > > > > > > [snip]
> > > > > > > > On Wed, 9 Jan 2019 at 14:33, Ladislav Michl 
> > > > > > > >  wrote:
> > > > > > > > > I agree, but it doea all the magic correctly, so you won't 
> > > > > > > > > need
> > > > > > > > > to touch that code is ktime_t changes (I know, unlikely..)
> > > > > > > >
> > > > > > > > But the current implementation doesn't care of any changes in 
> > > > > > > > ktime_t
> > > > > > > > as it uses raw ns
> > > > > > >
> > > > > > > Fair enough, so let's go back to:
> > > > > >
> > > > > > This one looks good for me
> > > > >
> > > > > Lets split is for 'comments fix' patch, which was just send and 'the 
> > > > > rest'.
> > > > > Now, 'the rest' can either be v2 of your "PM/runtime: Fix 
> > > > > autosuspend_delay on
> > > > > 32bits arch" or will wait for 5.1. You decide :)
> > > >
> > > > I don't really mind.
> > > >
> > > > Rafael,
> > > > Do you prefer to only take the fix for u64 casting problem or do you
> > > > prefer to also take the optimization below in one single patch ?
> > >
> > > The casting problem is a bug and the optimization is next release
> > > material in my view.  Please send the optimization separately.
> >
> > Ok, will send that separately in a few moments...
> > Btw, u64 casting problem seems to be still present in rpm_suspend while
> > computing slack for autosuspend delay greater than 25% of 2^31 (2^33) ns.
> 
> Good point. I will add it to the fix as well

Another nit then, for (u64)(autosuspend_delay) is (u64)autosuspend_delay
enough :)

I'll wait for your v2 before sending optimization patch.

> > Not sure if that triggers any real bug.

Re: Regression in v5.0-rc1 with autosuspend hrtimers

[Ladislav Michl]

On Wed, Jan 09, 2019 at 11:06:34PM +0100, Rafael J. Wysocki wrote:
> On Wed, Jan 9, 2019 at 7:05 PM Vincent Guittot
>  wrote:
> >
> > On Wed, 9 Jan 2019 at 18:26, Ladislav Michl  wrote:
> > >
> > > On Wed, Jan 09, 2019 at 05:32:31PM +0100, Vincent Guittot wrote:
> > > > On Wed, 9 Jan 2019 at 17:07, Ladislav Michl  
> > > > wrote:
> > > > >
> > > > > On Wed, Jan 09, 2019 at 03:12:25PM +0100, Vincent Guittot wrote:
> > > > > > Please keep all thread list when replying :-)
> > > > >
> > > > > Ahh, sorry for that...
> > > > > [snip]
> > > > > > On Wed, 9 Jan 2019 at 14:33, Ladislav Michl  
> > > > > > wrote:
> > > > > > > I agree, but it doea all the magic correctly, so you won't need
> > > > > > > to touch that code is ktime_t changes (I know, unlikely..)
> > > > > >
> > > > > > But the current implementation doesn't care of any changes in 
> > > > > > ktime_t
> > > > > > as it uses raw ns
> > > > >
> > > > > Fair enough, so let's go back to:
> > > >
> > > > This one looks good for me
> > >
> > > Lets split is for 'comments fix' patch, which was just send and 'the 
> > > rest'.
> > > Now, 'the rest' can either be v2 of your "PM/runtime: Fix 
> > > autosuspend_delay on
> > > 32bits arch" or will wait for 5.1. You decide :)
> >
> > I don't really mind.
> >
> > Rafael,
> > Do you prefer to only take the fix for u64 casting problem or do you
> > prefer to also take the optimization below in one single patch ?
> 
> The casting problem is a bug and the optimization is next release
> material in my view.  Please send the optimization separately.

Ok, will send that separately in a few moments...
Btw, u64 casting problem seems to be still present in rpm_suspend while
computing slack for autosuspend delay greater than 25% of 2^31 (2^33) ns.
Not sure if that triggers any real bug.

[PATCH v2] PM/runtime: Fix 'jiffies' in comments after move to hrtimers

[Ladislav Michl]

PM-runtime now uses the hrtimers infrastructure for autosuspend, however
comments still reference 'jiffies'.

Fixes: 8234f6734c5d ("PM-runtime: Switch autosuspend over to using hrtimers")
Signed-off-by: Ladislav Michl 
---
 Changes:
 -v2: Reword comment accoring to Rafael's suggestion

 drivers/base/power/runtime.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 70624695b6d5..a282e74d1a16 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -121,7 +121,7 @@ static void pm_runtime_cancel_pending(struct device *dev)
  * Compute the autosuspend-delay expiration time based on the device's
  * power.last_busy time.  If the delay has already expired or is disabled
  * (negative) or the power.use_autosuspend flag isn't set, return 0.
- * Otherwise return the expiration time in jiffies (adjusted to be nonzero).
+ * Otherwise return the expiration time in nanoseconds (adjusted to be 
nonzero).
  *
  * This function may be called either with or without dev->power.lock held.
  * Either way it can be racy, since power.last_busy may be updated at any time.
@@ -905,7 +905,10 @@ static enum hrtimer_restart  pm_suspend_timer_fn(struct 
hrtimer *timer)
spin_lock_irqsave(>power.lock, flags);
 
expires = dev->power.timer_expires;
-   /* If 'expire' is after 'jiffies' we've been called too early. */
+   /*
+* If 'expires' is after the current time, we've been called
+* too early.
+*/
if (expires > 0 && expires < ktime_to_ns(ktime_get())) {
dev->power.timer_expires = 0;
rpm_suspend(dev, dev->power.timer_autosuspends ?
-- 
2.20.1

Re: Regression in v5.0-rc1 with autosuspend hrtimers

[Ladislav Michl]

On Wed, Jan 09, 2019 at 05:32:31PM +0100, Vincent Guittot wrote:
> On Wed, 9 Jan 2019 at 17:07, Ladislav Michl  wrote:
> >
> > On Wed, Jan 09, 2019 at 03:12:25PM +0100, Vincent Guittot wrote:
> > > Please keep all thread list when replying :-)
> >
> > Ahh, sorry for that...
> > [snip]
> > > On Wed, 9 Jan 2019 at 14:33, Ladislav Michl  wrote:
> > > > I agree, but it doea all the magic correctly, so you won't need
> > > > to touch that code is ktime_t changes (I know, unlikely..)
> > >
> > > But the current implementation doesn't care of any changes in ktime_t
> > > as it uses raw ns
> >
> > Fair enough, so let's go back to:
> 
> This one looks good for me

Lets split is for 'comments fix' patch, which was just send and 'the rest'.
Now, 'the rest' can either be v2 of your "PM/runtime: Fix autosuspend_delay on
32bits arch" or will wait for 5.1. You decide :)

> > diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> > index 70624695b6d5..e61ee9b47a26 100644
> > --- a/drivers/base/power/runtime.c
> > +++ b/drivers/base/power/runtime.c
> > @@ -121,7 +121,7 @@ static void pm_runtime_cancel_pending(struct device 
> > *dev)
> >   * Compute the autosuspend-delay expiration time based on the device's
> >   * power.last_busy time.  If the delay has already expired or is disabled
> >   * (negative) or the power.use_autosuspend flag isn't set, return 0.
> > - * Otherwise return the expiration time in jiffies (adjusted to be 
> > nonzero).
> > + * Otherwise return the expiration time in nanoseconds (adjusted to be 
> > nonzero).
> >   *
> >   * This function may be called either with or without dev->power.lock held.
> >   * Either way it can be racy, since power.last_busy may be updated at any 
> > time.
> > @@ -129,24 +129,21 @@ static void pm_runtime_cancel_pending(struct device 
> > *dev)
> >  u64 pm_runtime_autosuspend_expiration(struct device *dev)
> >  {
> > int autosuspend_delay;
> > -   u64 last_busy, expires = 0;
> > -   u64 now = ktime_to_ns(ktime_get());
> > +   u64 expires;
> >
> > if (!dev->power.use_autosuspend)
> > -   goto out;
> > +   return 0;
> >
> > autosuspend_delay = READ_ONCE(dev->power.autosuspend_delay);
> > if (autosuspend_delay < 0)
> > -   goto out;
> > -
> > -   last_busy = READ_ONCE(dev->power.last_busy);
> > +   return 0;
> >
> > -   expires = last_busy + autosuspend_delay * NSEC_PER_MSEC;
> > -   if (expires <= now)
> > -   expires = 0;/* Already expired. */
> > +   expires  = READ_ONCE(dev->power.last_busy);
> > +   expires += NSEC_PER_MSEC * (u64)autosuspend_delay;
> > +   if (expires > ktime_to_ns(ktime_get()))
> > +   return expires; /* Expires in the future */
> >
> > - out:
> > -   return expires;
> > +   return 0;
> >  }
> >  EXPORT_SYMBOL_GPL(pm_runtime_autosuspend_expiration);
> >
> > Which gives for arm:
> > 0480 :
> >  480:   e92d41f0push{r4, r5, r6, r7, r8, lr}
> >  484:   e5d030d1ldrbr3, [r0, #209]  ; 0xd1
> >  488:   e3130004tst r3, #4
> >  48c:   0a0cbeq 4c4 
> > 
> >  490:   e59030e4ldr r3, [r0, #228]  ; 0xe4
> >  494:   e353cmp r3, #0
> >  498:   ba09blt 4c4 
> > 
> >  49c:   e28050e8add r5, r0, #232; 0xe8
> >  4a0:   e8950030ldm r5, {r4, r5}
> >  4a4:   e59f2030ldr r2, [pc, #48]   ; 4dc 
> > 
> >  4a8:   e0e54392smlal   r4, r5, r2, r3
> >  4ac:   ebfebl  0 
> >  4b0:   e1550001cmp r5, r1
> >  4b4:   0154cmpeq   r4, r0
> >  4b8:   e1a06004mov r6, r4
> >  4bc:   e1a07005mov r7, r5
> >  4c0:   8a01bhi 4cc 
> > 
> >  4c4:   e3a06000mov r6, #0
> >  4c8:   e3a07000mov r7, #0
> >  4cc:   e1a6mov r0, r6
> >  4d0:   e1a01007mov r1, r7
> >  4d4:   e8bd41f0pop {r4, r5, r6, r7, r8, lr}
> >  4d8:   e12fff1ebx  lr
> >  4dc:   000f4240.word   0x000f4240
> >
> > And x86:
> > 0

[PATCH] PM/runtime: Fix 'jiffies' in comments after move to hrtimers

[Ladislav Michl]

PM-runtime now uses the hrtimers infrastructure for autosuspend, however
comments still reference 'jiffies'.

Fixes: 8234f6734c5d ("PM-runtime: Switch autosuspend over to using hrtimers")
Signed-off-by: Ladislav Michl 
---
 drivers/base/power/runtime.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 70624695b6d5..096f7996d914 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -121,7 +121,7 @@ static void pm_runtime_cancel_pending(struct device *dev)
  * Compute the autosuspend-delay expiration time based on the device's
  * power.last_busy time.  If the delay has already expired or is disabled
  * (negative) or the power.use_autosuspend flag isn't set, return 0.
- * Otherwise return the expiration time in jiffies (adjusted to be nonzero).
+ * Otherwise return the expiration time in nanoseconds (adjusted to be 
nonzero).
  *
  * This function may be called either with or without dev->power.lock held.
  * Either way it can be racy, since power.last_busy may be updated at any time.
@@ -905,7 +905,7 @@ static enum hrtimer_restart  pm_suspend_timer_fn(struct 
hrtimer *timer)
spin_lock_irqsave(>power.lock, flags);
 
expires = dev->power.timer_expires;
-   /* If 'expire' is after 'jiffies' we've been called too early. */
+   /* If 'timer_expires' after 'now' we've been called too early. */
if (expires > 0 && expires < ktime_to_ns(ktime_get())) {
dev->power.timer_expires = 0;
rpm_suspend(dev, dev->power.timer_autosuspends ?
-- 
2.20.1

Re: Regression in v5.0-rc1 with autosuspend hrtimers

[Ladislav Michl]

On Wed, Jan 09, 2019 at 03:12:25PM +0100, Vincent Guittot wrote:
> Please keep all thread list when replying :-)

Ahh, sorry for that...
[snip]
> On Wed, 9 Jan 2019 at 14:33, Ladislav Michl  wrote:
> > I agree, but it doea all the magic correctly, so you won't need
> > to touch that code is ktime_t changes (I know, unlikely..)
> 
> But the current implementation doesn't care of any changes in ktime_t
> as it uses raw ns

Fair enough, so let's go back to:
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 70624695b6d5..e61ee9b47a26 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -121,7 +121,7 @@ static void pm_runtime_cancel_pending(struct device *dev)
  * Compute the autosuspend-delay expiration time based on the device's
  * power.last_busy time.  If the delay has already expired or is disabled
  * (negative) or the power.use_autosuspend flag isn't set, return 0.
- * Otherwise return the expiration time in jiffies (adjusted to be nonzero).
+ * Otherwise return the expiration time in nanoseconds (adjusted to be 
nonzero).
  *
  * This function may be called either with or without dev->power.lock held.
  * Either way it can be racy, since power.last_busy may be updated at any time.
@@ -129,24 +129,21 @@ static void pm_runtime_cancel_pending(struct device *dev)
 u64 pm_runtime_autosuspend_expiration(struct device *dev)
 {
int autosuspend_delay;
-   u64 last_busy, expires = 0;
-   u64 now = ktime_to_ns(ktime_get());
+   u64 expires;
 
if (!dev->power.use_autosuspend)
-   goto out;
+   return 0;
 
autosuspend_delay = READ_ONCE(dev->power.autosuspend_delay);
if (autosuspend_delay < 0)
-   goto out;
-
-   last_busy = READ_ONCE(dev->power.last_busy);
+   return 0;
 
-   expires = last_busy + autosuspend_delay * NSEC_PER_MSEC;
-   if (expires <= now)
-   expires = 0;/* Already expired. */
+   expires  = READ_ONCE(dev->power.last_busy);
+   expires += NSEC_PER_MSEC * (u64)autosuspend_delay;
+   if (expires > ktime_to_ns(ktime_get()))
+   return expires; /* Expires in the future */
 
- out:
-   return expires;
+   return 0;
 }
 EXPORT_SYMBOL_GPL(pm_runtime_autosuspend_expiration);

Which gives for arm: 
0480 :
 480:   e92d41f0push{r4, r5, r6, r7, r8, lr}
 484:   e5d030d1ldrbr3, [r0, #209]  ; 0xd1
 488:   e3130004tst r3, #4
 48c:   0a0cbeq 4c4 

 490:   e59030e4ldr r3, [r0, #228]  ; 0xe4
 494:   e353cmp r3, #0
 498:   ba09blt 4c4 

 49c:   e28050e8add r5, r0, #232; 0xe8
 4a0:   e8950030ldm r5, {r4, r5}
 4a4:   e59f2030ldr r2, [pc, #48]   ; 4dc 

 4a8:   e0e54392smlal   r4, r5, r2, r3
 4ac:   ebfebl  0 
 4b0:   e1550001cmp r5, r1
 4b4:   0154cmpeq   r4, r0
 4b8:   e1a06004mov r6, r4
 4bc:   e1a07005mov r7, r5
 4c0:   8a01bhi 4cc 

 4c4:   e3a06000mov r6, #0
 4c8:   e3a07000mov r7, #0
 4cc:   e1a6mov r0, r6
 4d0:   e1a01007mov r1, r7
 4d4:   e8bd41f0pop {r4, r5, r6, r7, r8, lr}
 4d8:   e12fff1ebx  lr
 4dc:   000f4240.word   0x000f4240

And x86:
0230 :
 230:   8b 87 a4 01 00 00   mov0x1a4(%rdi),%eax
 236:   53  push   %rbx
 237:   85 c0   test   %eax,%eax
 239:   78 1e   js 259 

 23b:   48 63 d8movslq %eax,%rbx
 23e:   48 8b 97 a8 01 00 00mov0x1a8(%rdi),%rdx
 245:   48 69 db 40 42 0f 00imul   $0xf4240,%rbx,%rbx
 24c:   48 01 d3add%rdx,%rbx
 24f:   e8 00 00 00 00  callq  254 

 254:   48 39 c3cmp%rax,%rbx
 257:   77 02   ja 25b 

 259:   31 db   xor%ebx,%ebx
 25b:   48 89 d8mov%rbx,%rax
 25e:   5b  pop%rbx
 25f:   c3  retq   

02a0 :
 2a0:   f6 87 91 01 00 00 04testb  $0x4,0x191(%rdi)
 2a7:   74 02   je 2ab 

 2a9:   eb 85   jmp230 

 2ab:   31 c0   xor%eax,%eax
 2ad:   c3  retq   
 2ae:   66 90   xchg   %ax,%ax


[snip]
> > Well, main concern was not to call ktime_get at the beginning of function
> > as it is not too cheap.

Re: Regression in v5.0-rc1 with autosuspend hrtimers

[Ladislav Michl]

On Wed, Jan 09, 2019 at 02:42:18AM +0100, Vincent Guittot wrote:
> Le Tuesday 08 Jan 2019 à 13:37:43 (-0800), Tony Lindgren a écrit :
> > * Vincent Guittot  [190108 16:42]:
> > > On Tue, 8 Jan 2019 at 16:53, Tony Lindgren  wrote:
> > > > Hmm so could it be that we now rely on timers that that may
> > > > not be capable of waking up the system from idle states with
> > > > hrtimer?
> > > 
> > > With nohz and hrtimer enabled,  timer relies on hrtimer to generate
> > > the tick so you should use the same interrupt.
> > 
> > OK yeah looks like that part is working just fine.
> > 
> > Adding some printks and debugging over ssh, looks like
> > omap8250_runtime_resume() gets called just fine based on a wakeirq,
> > but then omap8250_runtime_suspend() runs immediately instead of
> > waiting for the three second timeout.
> > 
> > Lowering the autosuspend_delay_ms to 2100 ms makes things work again.
> > Anything higher than 2200 ms seems to somehow time out immediately
> > now :)
> 
> This is quite close to the max ns of an int on arm 32bits
> 
> Could you try the patch below ?
> 
> ---
>  drivers/base/power/runtime.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> index 7062469..44c5c76 100644
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -141,7 +141,7 @@ u64 pm_runtime_autosuspend_expiration(struct device *dev)
>  
>   last_busy = READ_ONCE(dev->power.last_busy);
>  
> - expires = last_busy + autosuspend_delay * NSEC_PER_MSEC;
> + expires = last_busy + (u64)(autosuspend_delay) * NSEC_PER_MSEC;
>   if (expires <= now)
>   expires = 0;/* Already expired. */

Hmm, comment above function states it returns "the expiration time in jiffies
(adjusted to be nonzero)", so there's probably more to fix...

You can also consider change like this (still does not return jiffies):
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 70624695b6d5..c72eaf21a61c 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -129,23 +129,20 @@ static void pm_runtime_cancel_pending(struct device *dev)
 u64 pm_runtime_autosuspend_expiration(struct device *dev)
 {
int autosuspend_delay;
-   u64 last_busy, expires = 0;
-   u64 now = ktime_to_ns(ktime_get());
+   ktime_t expires;
 
if (!dev->power.use_autosuspend)
-   goto out;
+   return 0;
 
autosuspend_delay = READ_ONCE(dev->power.autosuspend_delay);
if (autosuspend_delay < 0)
-   goto out;
-
-   last_busy = READ_ONCE(dev->power.last_busy);
+   return 0;
 
-   expires = last_busy + autosuspend_delay * NSEC_PER_MSEC;
-   if (expires <= now)
-   expires = 0;/* Already expired. */
+   expires = ktime_add_ns(ms_to_ktime(autosuspend_delay),
+  READ_ONCE(dev->power.last_busy));
+   if (expires <= ktime_get())
+   return 0;   /* Already expired. */
 
- out:
return expires;
 }
 EXPORT_SYMBOL_GPL(pm_runtime_autosuspend_expiration);

Regards,
ladis

Re: [PATCH v2] tps65218: Use devm_regmap_add_irq_chip and clean up error path in probe

[Ladislav Michl]

On Fri, Dec 07, 2018 at 06:19:48AM +0530, Keerthy wrote:
> Use devm_regmap_add_irq_chip and clean up error path in probe.
> Hence clean up the probe error path and the remove function.
> 
> Reported-by: Christian Hohnstaedt 
> Signed-off-by: Keerthy 
> ---
> 
> Changes in v2:
> 
>   * Cleaned up remove function as well.

v3: Remove remove function? :)

>  drivers/mfd/tps65218.c | 18 +++---
>  1 file changed, 3 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
> index 910f569..d2d4e3a 100644
> --- a/drivers/mfd/tps65218.c
> +++ b/drivers/mfd/tps65218.c
> @@ -235,9 +235,9 @@ static int tps65218_probe(struct i2c_client *client,
>  
>   mutex_init(>tps_lock);
>  
> - ret = regmap_add_irq_chip(tps->regmap, tps->irq,
> - IRQF_ONESHOT, 0, _irq_chip,
> - >irq_data);
> + ret = devm_regmap_add_irq_chip(>dev, tps->regmap, tps->irq,
> +IRQF_ONESHOT, 0, _irq_chip,
> +>irq_data);
>   if (ret < 0)
>   return ret;
>  
> @@ -253,23 +253,11 @@ static int tps65218_probe(struct i2c_client *client,
> ARRAY_SIZE(tps65218_cells), NULL, 0,
> regmap_irq_get_domain(tps->irq_data));
>  
> - if (ret < 0)
> - goto err_irq;
> -
> - return 0;
> -
> -err_irq:
> - regmap_del_irq_chip(tps->irq, tps->irq_data);
> -
>   return ret;
>  }
>  
>  static int tps65218_remove(struct i2c_client *client)
>  {
> - struct tps65218 *tps = i2c_get_clientdata(client);
> -
> - regmap_del_irq_chip(tps->irq, tps->irq_data);
> -
>   return 0;
>  }
>  
> -- 
> 1.9.1

Re: [PATCH v2] tps65218: Use devm_regmap_add_irq_chip and clean up error path in probe

[Ladislav Michl]

On Fri, Dec 07, 2018 at 06:19:48AM +0530, Keerthy wrote:
> Use devm_regmap_add_irq_chip and clean up error path in probe.
> Hence clean up the probe error path and the remove function.
> 
> Reported-by: Christian Hohnstaedt 
> Signed-off-by: Keerthy 
> ---
> 
> Changes in v2:
> 
>   * Cleaned up remove function as well.

v3: Remove remove function? :)

>  drivers/mfd/tps65218.c | 18 +++---
>  1 file changed, 3 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
> index 910f569..d2d4e3a 100644
> --- a/drivers/mfd/tps65218.c
> +++ b/drivers/mfd/tps65218.c
> @@ -235,9 +235,9 @@ static int tps65218_probe(struct i2c_client *client,
>  
>   mutex_init(>tps_lock);
>  
> - ret = regmap_add_irq_chip(tps->regmap, tps->irq,
> - IRQF_ONESHOT, 0, _irq_chip,
> - >irq_data);
> + ret = devm_regmap_add_irq_chip(>dev, tps->regmap, tps->irq,
> +IRQF_ONESHOT, 0, _irq_chip,
> +>irq_data);
>   if (ret < 0)
>   return ret;
>  
> @@ -253,23 +253,11 @@ static int tps65218_probe(struct i2c_client *client,
> ARRAY_SIZE(tps65218_cells), NULL, 0,
> regmap_irq_get_domain(tps->irq_data));
>  
> - if (ret < 0)
> - goto err_irq;
> -
> - return 0;
> -
> -err_irq:
> - regmap_del_irq_chip(tps->irq, tps->irq_data);
> -
>   return ret;
>  }
>  
>  static int tps65218_remove(struct i2c_client *client)
>  {
> - struct tps65218 *tps = i2c_get_clientdata(client);
> -
> - regmap_del_irq_chip(tps->irq, tps->irq_data);
> -
>   return 0;
>  }
>  
> -- 
> 1.9.1

[PATCH v2] ASoC: max9867: Remove useless assignment

[Ladislav Michl]

ret is assigned later, no need to initialize it.

Signed-off-by: Ladislav Michl 
---
 CHANGES:
 -v2: add missing Signed-off-by
 (I'm sorry for that...)

 sound/soc/codecs/max9867.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/sound/soc/codecs/max9867.c b/sound/soc/codecs/max9867.c
index 1cda54b59854..1b155f40b106 100644
--- a/sound/soc/codecs/max9867.c
+++ b/sound/soc/codecs/max9867.c
@@ -476,7 +476,7 @@ static int max9867_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
 {
struct max9867_priv *max9867;
-   int ret = 0, reg;
+   int ret, reg;
 
max9867 = devm_kzalloc(>dev, sizeof(*max9867), GFP_KERNEL);
if (!max9867)
@@ -497,10 +497,8 @@ static int max9867_i2c_probe(struct i2c_client *i2c,
dev_info(>dev, "device revision: %x\n", reg);
ret = devm_snd_soc_register_component(>dev, _component,
max9867_dai, ARRAY_SIZE(max9867_dai));
-   if (ret < 0) {
+   if (ret < 0)
dev_err(>dev, "Failed to register component: %d\n", ret);
-   return ret;
-   }
return ret;
 }
 
-- 
2.20.0.rc2

[PATCH v2] ASoC: max9867: Remove useless assignment

[Ladislav Michl]

ret is assigned later, no need to initialize it.

Signed-off-by: Ladislav Michl 
---
 CHANGES:
 -v2: add missing Signed-off-by
 (I'm sorry for that...)

 sound/soc/codecs/max9867.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/sound/soc/codecs/max9867.c b/sound/soc/codecs/max9867.c
index 1cda54b59854..1b155f40b106 100644
--- a/sound/soc/codecs/max9867.c
+++ b/sound/soc/codecs/max9867.c
@@ -476,7 +476,7 @@ static int max9867_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
 {
struct max9867_priv *max9867;
-   int ret = 0, reg;
+   int ret, reg;
 
max9867 = devm_kzalloc(>dev, sizeof(*max9867), GFP_KERNEL);
if (!max9867)
@@ -497,10 +497,8 @@ static int max9867_i2c_probe(struct i2c_client *i2c,
dev_info(>dev, "device revision: %x\n", reg);
ret = devm_snd_soc_register_component(>dev, _component,
max9867_dai, ARRAY_SIZE(max9867_dai));
-   if (ret < 0) {
+   if (ret < 0)
dev_err(>dev, "Failed to register component: %d\n", ret);
-   return ret;
-   }
return ret;
 }
 
-- 
2.20.0.rc2

Re: [PATCH] MMC: OMAP: fix broken MMC on OMAP15XX/OMAP5912/OMAP310

[Ladislav Michl]

Aaro,

On Sun, Nov 18, 2018 at 10:19:19PM +0200, Aaro Koskinen wrote:
> Since v2.6.22 or so there has been reports [1] about OMAP MMC being
> broken on OMAP15XX based hardware (OMAP5912 and OMAP310). The breakage
> seems to have been caused by commit 46a6730e3ff9 ("mmc-omap: Fix
> omap to use MMC_POWER_ON") that changed clock enabling to be done
> on MMC_POWER_ON. This can happen multiple times in a row, and on 15XX
> the hardware doesn't seem to like it and the MMC just stops responding.
> Fix by memorizing the power mode and do the init only when necessary.

I'm going to use this patch as an argument against anybody complaining
kernel bugs do not get fixed. People just need to teach themselves to
be patient.

Tested-by: Ladislav Michl 

> Before the patch (on Palm TE):
> 
>   mmc0: new SD card at address b368
>   mmcblk0: mmc0:b368 SDC   977 MiB
>   mmci-omap mmci-omap.0: command timeout (CMD18)
>   mmci-omap mmci-omap.0: command timeout (CMD13)
>   mmci-omap mmci-omap.0: command timeout (CMD13)
>   mmci-omap mmci-omap.0: command timeout (CMD12) [x 6]
>   mmci-omap mmci-omap.0: command timeout (CMD13) [x 6]
>   mmcblk0: error -110 requesting status
>   mmci-omap mmci-omap.0: command timeout (CMD8)
>   mmci-omap mmci-omap.0: command timeout (CMD18)
>   mmci-omap mmci-omap.0: command timeout (CMD13)
>   mmci-omap mmci-omap.0: command timeout (CMD13)
>   mmci-omap mmci-omap.0: command timeout (CMD12) [x 6]
>   mmci-omap mmci-omap.0: command timeout (CMD13) [x 6]
>   mmcblk0: error -110 requesting status
>   mmcblk0: recovery failed!
>   print_req_error: I/O error, dev mmcblk0, sector 0
>   Buffer I/O error on dev mmcblk0, logical block 0, async page read
>mmcblk0: unable to read partition table
> 
> After the patch:
> 
>   mmc0: new SD card at address b368
>   mmcblk0: mmc0:b368 SDC   977 MiB
>mmcblk0: p1
> 
> The patch is based on a fix and analysis done by Ladislav Michl.
> 
> Tested on OMAP15XX/OMAP310 (Palm TE), OMAP1710 (Nokia 770)
> and OMAP2420 (Nokia N810).
> 
> [1] https://marc.info/?t=12317519703=1=2
> 
> Fixes: 46a6730e3ff9 ("mmc-omap: Fix omap to use MMC_POWER_ON")
> Reported-by: Ladislav Michl 
> Reported-by: Andrzej Zaborowski 
> Signed-off-by: Aaro Koskinen 
> ---
>  drivers/mmc/host/omap.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
> index adf32682f27a..c60a7625b1fa 100644
> --- a/drivers/mmc/host/omap.c
> +++ b/drivers/mmc/host/omap.c
> @@ -104,6 +104,7 @@ struct mmc_omap_slot {
>   unsigned intvdd;
>   u16 saved_con;
>   u16 bus_mode;
> + u16 power_mode;
>   unsigned intfclk_freq;
>  
>   struct tasklet_struct   cover_tasklet;
> @@ -1157,7 +1158,7 @@ static void mmc_omap_set_ios(struct mmc_host *mmc, 
> struct mmc_ios *ios)
>   struct mmc_omap_slot *slot = mmc_priv(mmc);
>   struct mmc_omap_host *host = slot->host;
>   int i, dsor;
> - int clk_enabled;
> + int clk_enabled, init_stream;
>  
>   mmc_omap_select_slot(slot, 0);
>  
> @@ -1167,6 +1168,7 @@ static void mmc_omap_set_ios(struct mmc_host *mmc, 
> struct mmc_ios *ios)
>   slot->vdd = ios->vdd;
>  
>   clk_enabled = 0;
> + init_stream = 0;
>   switch (ios->power_mode) {
>   case MMC_POWER_OFF:
>   mmc_omap_set_power(slot, 0, ios->vdd);
> @@ -1174,13 +1176,17 @@ static void mmc_omap_set_ios(struct mmc_host *mmc, 
> struct mmc_ios *ios)
>   case MMC_POWER_UP:
>   /* Cannot touch dsor yet, just power up MMC */
>   mmc_omap_set_power(slot, 1, ios->vdd);
> + slot->power_mode = ios->power_mode;
>   goto exit;
>   case MMC_POWER_ON:
>   mmc_omap_fclk_enable(host, 1);
>   clk_enabled = 1;
>   dsor |= 1 << 11;
> + if (slot->power_mode != MMC_POWER_ON)
> + init_stream = 1;
>   break;
>   }
> + slot->power_mode = ios->power_mode;
>  
>   if (slot->bus_mode != ios->bus_mode) {
>   if (slot->pdata->set_bus_mode != NULL)
> @@ -1196,7 +1202,7 @@ static void mmc_omap_set_ios(struct mmc_host *mmc, 
> struct mmc_ios *ios)
>   for (i = 0; i < 2; i++)
>   OMAP_MMC_WRITE(host, CON, dsor);
>   slot->saved_con = dsor;
> - if (ios->power_mode == MMC_POWER_ON) {
> + if (init_stream) {
>   /* worst case at 400kHz, 80 cycles makes 200 microsecs */
>   int usecs = 250;
>  
> @@ -1234,6 +1240,7 @@ static int mmc_omap_new_slot(struct mmc_omap_host 
> *host, int id)
>   slot->host = host;
>   slot->mmc = mmc;
>   slot->id = id;
> + slot->power_mode = MMC_POWER_UNDEFINED;
>   slot->pdata = >pdata->slots[id];
>  
>   host->slots[id] = slot;
> -- 
> 2.17.0

Re: [PATCH] MMC: OMAP: fix broken MMC on OMAP15XX/OMAP5912/OMAP310

[Ladislav Michl]

Aaro,

On Sun, Nov 18, 2018 at 10:19:19PM +0200, Aaro Koskinen wrote:
> Since v2.6.22 or so there has been reports [1] about OMAP MMC being
> broken on OMAP15XX based hardware (OMAP5912 and OMAP310). The breakage
> seems to have been caused by commit 46a6730e3ff9 ("mmc-omap: Fix
> omap to use MMC_POWER_ON") that changed clock enabling to be done
> on MMC_POWER_ON. This can happen multiple times in a row, and on 15XX
> the hardware doesn't seem to like it and the MMC just stops responding.
> Fix by memorizing the power mode and do the init only when necessary.

I'm going to use this patch as an argument against anybody complaining
kernel bugs do not get fixed. People just need to teach themselves to
be patient.

Tested-by: Ladislav Michl 

> Before the patch (on Palm TE):
> 
>   mmc0: new SD card at address b368
>   mmcblk0: mmc0:b368 SDC   977 MiB
>   mmci-omap mmci-omap.0: command timeout (CMD18)
>   mmci-omap mmci-omap.0: command timeout (CMD13)
>   mmci-omap mmci-omap.0: command timeout (CMD13)
>   mmci-omap mmci-omap.0: command timeout (CMD12) [x 6]
>   mmci-omap mmci-omap.0: command timeout (CMD13) [x 6]
>   mmcblk0: error -110 requesting status
>   mmci-omap mmci-omap.0: command timeout (CMD8)
>   mmci-omap mmci-omap.0: command timeout (CMD18)
>   mmci-omap mmci-omap.0: command timeout (CMD13)
>   mmci-omap mmci-omap.0: command timeout (CMD13)
>   mmci-omap mmci-omap.0: command timeout (CMD12) [x 6]
>   mmci-omap mmci-omap.0: command timeout (CMD13) [x 6]
>   mmcblk0: error -110 requesting status
>   mmcblk0: recovery failed!
>   print_req_error: I/O error, dev mmcblk0, sector 0
>   Buffer I/O error on dev mmcblk0, logical block 0, async page read
>mmcblk0: unable to read partition table
> 
> After the patch:
> 
>   mmc0: new SD card at address b368
>   mmcblk0: mmc0:b368 SDC   977 MiB
>mmcblk0: p1
> 
> The patch is based on a fix and analysis done by Ladislav Michl.
> 
> Tested on OMAP15XX/OMAP310 (Palm TE), OMAP1710 (Nokia 770)
> and OMAP2420 (Nokia N810).
> 
> [1] https://marc.info/?t=12317519703=1=2
> 
> Fixes: 46a6730e3ff9 ("mmc-omap: Fix omap to use MMC_POWER_ON")
> Reported-by: Ladislav Michl 
> Reported-by: Andrzej Zaborowski 
> Signed-off-by: Aaro Koskinen 
> ---
>  drivers/mmc/host/omap.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
> index adf32682f27a..c60a7625b1fa 100644
> --- a/drivers/mmc/host/omap.c
> +++ b/drivers/mmc/host/omap.c
> @@ -104,6 +104,7 @@ struct mmc_omap_slot {
>   unsigned intvdd;
>   u16 saved_con;
>   u16 bus_mode;
> + u16 power_mode;
>   unsigned intfclk_freq;
>  
>   struct tasklet_struct   cover_tasklet;
> @@ -1157,7 +1158,7 @@ static void mmc_omap_set_ios(struct mmc_host *mmc, 
> struct mmc_ios *ios)
>   struct mmc_omap_slot *slot = mmc_priv(mmc);
>   struct mmc_omap_host *host = slot->host;
>   int i, dsor;
> - int clk_enabled;
> + int clk_enabled, init_stream;
>  
>   mmc_omap_select_slot(slot, 0);
>  
> @@ -1167,6 +1168,7 @@ static void mmc_omap_set_ios(struct mmc_host *mmc, 
> struct mmc_ios *ios)
>   slot->vdd = ios->vdd;
>  
>   clk_enabled = 0;
> + init_stream = 0;
>   switch (ios->power_mode) {
>   case MMC_POWER_OFF:
>   mmc_omap_set_power(slot, 0, ios->vdd);
> @@ -1174,13 +1176,17 @@ static void mmc_omap_set_ios(struct mmc_host *mmc, 
> struct mmc_ios *ios)
>   case MMC_POWER_UP:
>   /* Cannot touch dsor yet, just power up MMC */
>   mmc_omap_set_power(slot, 1, ios->vdd);
> + slot->power_mode = ios->power_mode;
>   goto exit;
>   case MMC_POWER_ON:
>   mmc_omap_fclk_enable(host, 1);
>   clk_enabled = 1;
>   dsor |= 1 << 11;
> + if (slot->power_mode != MMC_POWER_ON)
> + init_stream = 1;
>   break;
>   }
> + slot->power_mode = ios->power_mode;
>  
>   if (slot->bus_mode != ios->bus_mode) {
>   if (slot->pdata->set_bus_mode != NULL)
> @@ -1196,7 +1202,7 @@ static void mmc_omap_set_ios(struct mmc_host *mmc, 
> struct mmc_ios *ios)
>   for (i = 0; i < 2; i++)
>   OMAP_MMC_WRITE(host, CON, dsor);
>   slot->saved_con = dsor;
> - if (ios->power_mode == MMC_POWER_ON) {
> + if (init_stream) {
>   /* worst case at 400kHz, 80 cycles makes 200 microsecs */
>   int usecs = 250;
>  
> @@ -1234,6 +1240,7 @@ static int mmc_omap_new_slot(struct mmc_omap_host 
> *host, int id)
>   slot->host = host;
>   slot->mmc = mmc;
>   slot->id = id;
> + slot->power_mode = MMC_POWER_UNDEFINED;
>   slot->pdata = >pdata->slots[id];
>  
>   host->slots[id] = slot;
> -- 
> 2.17.0

Re: [PATCH] pwm: pwm-omap-dmtimer: fix probing problems by returning EPROBE_DEFER

[Ladislav Michl]

On Sun, Jul 29, 2018 at 08:32:41AM +0200, H. Nikolaus Schaller wrote:
> Hi,
> 
> > Am 28.07.2018 um 22:35 schrieb Ladislav Michl :
> > 
> > Hi Andreas,
> > 
> > On Sat, Jul 28, 2018 at 06:59:14PM +0200, Andreas Kemnade wrote:
> >> I got this in the kernel log:
> >> [0.756042] omap-dmtimer-pwm dmtimer-pwm: dmtimer pdata structure NULL
> >> [0.756134] omap-dmtimer-pwm: probe of dmtimer-pwm failed with error -22
> >> 
> >> the probe function has to wait until omap_dm_timer_probe() in
> >> clocksource/timer-ti-dm.c has initialized pdata, so defer probing
> > 
> > There already is a patch by David Rivshin addressing the same issue...
> 
> Here it is:
> 
> https://patchwork.ozlabs.org/patch/943148/
> 
> but hasn't arrived in linux-next.

That's because there'll be v3.

> But it is questionable if a driver should dev_info() about doing deferred 
> probing.
> IMHO, it should just do it which is how Andreas' patch works.

See here: https://patchwork.ozlabs.org/patch/949659/

> >> Fixes: b7290cf6ff78 (pwm: pwm-omap-dmtimer: Adapt driver to utilize 
> >> dmtimer pdata ops)
> >> Signed-off-by: Andreas Kemnade 
> >> ---
> >> drivers/pwm/pwm-omap-dmtimer.c | 3 +--
> >> 1 file changed, 1 insertion(+), 2 deletions(-)
> >> 
> >> diff --git a/drivers/pwm/pwm-omap-dmtimer.c 
> >> b/drivers/pwm/pwm-omap-dmtimer.c
> >> index 665da3c8fbce..808835179c2e 100644
> >> --- a/drivers/pwm/pwm-omap-dmtimer.c
> >> +++ b/drivers/pwm/pwm-omap-dmtimer.c
> >> @@ -264,8 +264,7 @@ static int pwm_omap_dmtimer_probe(struct 
> >> platform_device *pdev)
> >> 
> >>timer_pdata = dev_get_platdata(_pdev->dev);
> >>if (!timer_pdata) {
> >> -  dev_err(>dev, "dmtimer pdata structure NULL\n");
> >> -  ret = -EINVAL;
> >> +  ret = -EPROBE_DEFER;
> >>goto put;
> >>}
> >> 
> >> -- 
> >> 2.11.0
> >> 
> 
> BR,
> Nikolaus
> 

Re: [PATCH] pwm: pwm-omap-dmtimer: fix probing problems by returning EPROBE_DEFER

[Ladislav Michl]

On Sun, Jul 29, 2018 at 08:32:41AM +0200, H. Nikolaus Schaller wrote:
> Hi,
> 
> > Am 28.07.2018 um 22:35 schrieb Ladislav Michl :
> > 
> > Hi Andreas,
> > 
> > On Sat, Jul 28, 2018 at 06:59:14PM +0200, Andreas Kemnade wrote:
> >> I got this in the kernel log:
> >> [0.756042] omap-dmtimer-pwm dmtimer-pwm: dmtimer pdata structure NULL
> >> [0.756134] omap-dmtimer-pwm: probe of dmtimer-pwm failed with error -22
> >> 
> >> the probe function has to wait until omap_dm_timer_probe() in
> >> clocksource/timer-ti-dm.c has initialized pdata, so defer probing
> > 
> > There already is a patch by David Rivshin addressing the same issue...
> 
> Here it is:
> 
> https://patchwork.ozlabs.org/patch/943148/
> 
> but hasn't arrived in linux-next.

That's because there'll be v3.

> But it is questionable if a driver should dev_info() about doing deferred 
> probing.
> IMHO, it should just do it which is how Andreas' patch works.

See here: https://patchwork.ozlabs.org/patch/949659/

> >> Fixes: b7290cf6ff78 (pwm: pwm-omap-dmtimer: Adapt driver to utilize 
> >> dmtimer pdata ops)
> >> Signed-off-by: Andreas Kemnade 
> >> ---
> >> drivers/pwm/pwm-omap-dmtimer.c | 3 +--
> >> 1 file changed, 1 insertion(+), 2 deletions(-)
> >> 
> >> diff --git a/drivers/pwm/pwm-omap-dmtimer.c 
> >> b/drivers/pwm/pwm-omap-dmtimer.c
> >> index 665da3c8fbce..808835179c2e 100644
> >> --- a/drivers/pwm/pwm-omap-dmtimer.c
> >> +++ b/drivers/pwm/pwm-omap-dmtimer.c
> >> @@ -264,8 +264,7 @@ static int pwm_omap_dmtimer_probe(struct 
> >> platform_device *pdev)
> >> 
> >>timer_pdata = dev_get_platdata(_pdev->dev);
> >>if (!timer_pdata) {
> >> -  dev_err(>dev, "dmtimer pdata structure NULL\n");
> >> -  ret = -EINVAL;
> >> +  ret = -EPROBE_DEFER;
> >>goto put;
> >>}
> >> 
> >> -- 
> >> 2.11.0
> >> 
> 
> BR,
> Nikolaus
> 

Re: [PATCH] pwm: pwm-omap-dmtimer: fix probing problems by returning EPROBE_DEFER

[Ladislav Michl]

Hi Andreas,

On Sat, Jul 28, 2018 at 06:59:14PM +0200, Andreas Kemnade wrote:
> I got this in the kernel log:
> [0.756042] omap-dmtimer-pwm dmtimer-pwm: dmtimer pdata structure NULL
> [0.756134] omap-dmtimer-pwm: probe of dmtimer-pwm failed with error -22
> 
> the probe function has to wait until omap_dm_timer_probe() in
> clocksource/timer-ti-dm.c has initialized pdata, so defer probing

There already is a patch by David Rivshin addressing the same issue...

> Fixes: b7290cf6ff78 (pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer 
> pdata ops)
> Signed-off-by: Andreas Kemnade 
> ---
>  drivers/pwm/pwm-omap-dmtimer.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
> index 665da3c8fbce..808835179c2e 100644
> --- a/drivers/pwm/pwm-omap-dmtimer.c
> +++ b/drivers/pwm/pwm-omap-dmtimer.c
> @@ -264,8 +264,7 @@ static int pwm_omap_dmtimer_probe(struct platform_device 
> *pdev)
>  
>   timer_pdata = dev_get_platdata(_pdev->dev);
>   if (!timer_pdata) {
> - dev_err(>dev, "dmtimer pdata structure NULL\n");
> - ret = -EINVAL;
> + ret = -EPROBE_DEFER;
>   goto put;
>   }
>  
> -- 
> 2.11.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pwm: pwm-omap-dmtimer: fix probing problems by returning EPROBE_DEFER

[Ladislav Michl]

Hi Andreas,

On Sat, Jul 28, 2018 at 06:59:14PM +0200, Andreas Kemnade wrote:
> I got this in the kernel log:
> [0.756042] omap-dmtimer-pwm dmtimer-pwm: dmtimer pdata structure NULL
> [0.756134] omap-dmtimer-pwm: probe of dmtimer-pwm failed with error -22
> 
> the probe function has to wait until omap_dm_timer_probe() in
> clocksource/timer-ti-dm.c has initialized pdata, so defer probing

There already is a patch by David Rivshin addressing the same issue...

> Fixes: b7290cf6ff78 (pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer 
> pdata ops)
> Signed-off-by: Andreas Kemnade 
> ---
>  drivers/pwm/pwm-omap-dmtimer.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
> index 665da3c8fbce..808835179c2e 100644
> --- a/drivers/pwm/pwm-omap-dmtimer.c
> +++ b/drivers/pwm/pwm-omap-dmtimer.c
> @@ -264,8 +264,7 @@ static int pwm_omap_dmtimer_probe(struct platform_device 
> *pdev)
>  
>   timer_pdata = dev_get_platdata(_pdev->dev);
>   if (!timer_pdata) {
> - dev_err(>dev, "dmtimer pdata structure NULL\n");
> - ret = -EINVAL;
> + ret = -EPROBE_DEFER;
>   goto put;
>   }
>  
> -- 
> 2.11.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Letux-kernel] [PATCH 09/32] ARM: dts: omap3-gta04: make NAND partitions compatible with recent U-Boot

[Ladislav Michl]

On Wed, Jul 25, 2018 at 06:27:45PM +0200, Andreas Kemnade wrote:
> On Wed, 25 Jul 2018 10:33:05 +0200
> Ladislav Michl  wrote:
> 
> > On Wed, Jul 25, 2018 at 10:18:28AM +0200, H. Nikolaus Schaller wrote:
> > >   
> > > > Am 25.07.2018 um 10:07 schrieb Ladislav Michl :
> > > > 
> > > > On Wed, Jul 25, 2018 at 08:58:41AM +0200, H. Nikolaus Schaller wrote:  
> > > >> Vendor defined U-Boot has changed the partition scheme a while ago:
> > > >> 
> > > >> * kernel partition 6MB
> > > >> * file system partition uses the remainder up to end of the NAND
> > > >> * increased size of the environment partition (to get an OneNAND 
> > > >> compatible base address)
> > > >> * shrink the U-Boot partition
> > > >> 
> > > >> Let's be compatible (e.g. Debian kernel built from upstream).  
> > > > 
> > > > That, in fact, is breaking compatibility.  
> > > 
> > > With what? Nobody is using the old u-boot partition scheme any more
> > > (it is >5 years old).
> > >   
> > > > So once you are touching this
> > > > what about relying on partitioning provided by bootloader just to 
> > > > prevent
> > > > something like this happening again?  
> > > 
> > > Well, we define what compatible means here (since we are the vendor).
> > > And people complain with us. We simply recommend them to upgrade the
> > > boot-loader.  
> > 
> > Fair enough. Suggestion was to remove partitioning scheme from DTB 
> > alltogether
> > and let U-Boot provide one. But you being vendor you decide, of course :)
> > (I'd use only two partitions: MLO and UBI, latter one with BCH8, and store
> > everything in UBI volumes. That's a bit more flexible approach)
> > 
> hmm, so using mtdparts kernel commandline parameter? Somehow it sounds
> to be sane to not have partition tables in kernel. What only is needed
> is to have a nice transition scheme for systems in the wild, can
> commandline mtdparts overwrite dtb? So dtb is a fallback?

That's beginning to be offtopic here...  Anyway, see U-Boot's
CONFIG_FDT_FIXUP_PARTITIONS. Probably better to start a thread on
U-Boot mailing list if needed.

> But I think all that is a future improvement?

Depends on vendor decision, it could be done in a few days :)

Best regards,
ladis

Re: [Letux-kernel] [PATCH 09/32] ARM: dts: omap3-gta04: make NAND partitions compatible with recent U-Boot

[Ladislav Michl]

On Wed, Jul 25, 2018 at 06:27:45PM +0200, Andreas Kemnade wrote:
> On Wed, 25 Jul 2018 10:33:05 +0200
> Ladislav Michl  wrote:
> 
> > On Wed, Jul 25, 2018 at 10:18:28AM +0200, H. Nikolaus Schaller wrote:
> > >   
> > > > Am 25.07.2018 um 10:07 schrieb Ladislav Michl :
> > > > 
> > > > On Wed, Jul 25, 2018 at 08:58:41AM +0200, H. Nikolaus Schaller wrote:  
> > > >> Vendor defined U-Boot has changed the partition scheme a while ago:
> > > >> 
> > > >> * kernel partition 6MB
> > > >> * file system partition uses the remainder up to end of the NAND
> > > >> * increased size of the environment partition (to get an OneNAND 
> > > >> compatible base address)
> > > >> * shrink the U-Boot partition
> > > >> 
> > > >> Let's be compatible (e.g. Debian kernel built from upstream).  
> > > > 
> > > > That, in fact, is breaking compatibility.  
> > > 
> > > With what? Nobody is using the old u-boot partition scheme any more
> > > (it is >5 years old).
> > >   
> > > > So once you are touching this
> > > > what about relying on partitioning provided by bootloader just to 
> > > > prevent
> > > > something like this happening again?  
> > > 
> > > Well, we define what compatible means here (since we are the vendor).
> > > And people complain with us. We simply recommend them to upgrade the
> > > boot-loader.  
> > 
> > Fair enough. Suggestion was to remove partitioning scheme from DTB 
> > alltogether
> > and let U-Boot provide one. But you being vendor you decide, of course :)
> > (I'd use only two partitions: MLO and UBI, latter one with BCH8, and store
> > everything in UBI volumes. That's a bit more flexible approach)
> > 
> hmm, so using mtdparts kernel commandline parameter? Somehow it sounds
> to be sane to not have partition tables in kernel. What only is needed
> is to have a nice transition scheme for systems in the wild, can
> commandline mtdparts overwrite dtb? So dtb is a fallback?

That's beginning to be offtopic here...  Anyway, see U-Boot's
CONFIG_FDT_FIXUP_PARTITIONS. Probably better to start a thread on
U-Boot mailing list if needed.

> But I think all that is a future improvement?

Depends on vendor decision, it could be done in a few days :)

Best regards,
ladis

Re: [PATCH 09/32] ARM: dts: omap3-gta04: make NAND partitions compatible with recent U-Boot

[Ladislav Michl]

On Wed, Jul 25, 2018 at 02:27:31PM +0200, H. Nikolaus Schaller wrote:
> 
> > Am 25.07.2018 um 10:33 schrieb Ladislav Michl :
> > 
> > On Wed, Jul 25, 2018 at 10:18:28AM +0200, H. Nikolaus Schaller wrote:
> >> 
> >>> Am 25.07.2018 um 10:07 schrieb Ladislav Michl :
> >>> 
> >>> On Wed, Jul 25, 2018 at 08:58:41AM +0200, H. Nikolaus Schaller wrote:
> >>>> Vendor defined U-Boot has changed the partition scheme a while ago:
> >>>> 
> >>>> * kernel partition 6MB
> >>>> * file system partition uses the remainder up to end of the NAND
> >>>> * increased size of the environment partition (to get an OneNAND 
> >>>> compatible base address)
> >>>> * shrink the U-Boot partition
> >>>> 
> >>>> Let's be compatible (e.g. Debian kernel built from upstream).
> >>> 
> >>> That, in fact, is breaking compatibility.
> >> 
> >> With what? Nobody is using the old u-boot partition scheme any more
> >> (it is >5 years old).
> >> 
> >>> So once you are touching this
> >>> what about relying on partitioning provided by bootloader just to prevent
> >>> something like this happening again?
> >> 
> >> Well, we define what compatible means here (since we are the vendor).
> >> And people complain with us. We simply recommend them to upgrade the
> >> boot-loader.
> > 
> > Fair enough. Suggestion was to remove partitioning scheme from DTB 
> > alltogether
> > and let U-Boot provide one. But you being vendor you decide, of course :)
> > (I'd use only two partitions: MLO and UBI, latter one with BCH8, and store
> > everything in UBI volumes. That's a bit more flexible approach)
> 
> Yes, that is a good goal for a future setup and would of course be better.
> Like U-Boot already provides the memory layout for RAM.
> 
> Hopefully, someone will work out patches for u-boot plus kernel (which is 
> always
> painful to keep these two in sync and tested). But I don't want to do that 
> now.

At kernel side the only patch needed is to remove partitioning scheme from DTB
and u-boot setup can be merely copied from board/isee/igep00x0
Not having hardware I cannot really test it ;-)

Best regards,
ladis

Re: [PATCH 09/32] ARM: dts: omap3-gta04: make NAND partitions compatible with recent U-Boot

[Ladislav Michl]

On Wed, Jul 25, 2018 at 02:27:31PM +0200, H. Nikolaus Schaller wrote:
> 
> > Am 25.07.2018 um 10:33 schrieb Ladislav Michl :
> > 
> > On Wed, Jul 25, 2018 at 10:18:28AM +0200, H. Nikolaus Schaller wrote:
> >> 
> >>> Am 25.07.2018 um 10:07 schrieb Ladislav Michl :
> >>> 
> >>> On Wed, Jul 25, 2018 at 08:58:41AM +0200, H. Nikolaus Schaller wrote:
> >>>> Vendor defined U-Boot has changed the partition scheme a while ago:
> >>>> 
> >>>> * kernel partition 6MB
> >>>> * file system partition uses the remainder up to end of the NAND
> >>>> * increased size of the environment partition (to get an OneNAND 
> >>>> compatible base address)
> >>>> * shrink the U-Boot partition
> >>>> 
> >>>> Let's be compatible (e.g. Debian kernel built from upstream).
> >>> 
> >>> That, in fact, is breaking compatibility.
> >> 
> >> With what? Nobody is using the old u-boot partition scheme any more
> >> (it is >5 years old).
> >> 
> >>> So once you are touching this
> >>> what about relying on partitioning provided by bootloader just to prevent
> >>> something like this happening again?
> >> 
> >> Well, we define what compatible means here (since we are the vendor).
> >> And people complain with us. We simply recommend them to upgrade the
> >> boot-loader.
> > 
> > Fair enough. Suggestion was to remove partitioning scheme from DTB 
> > alltogether
> > and let U-Boot provide one. But you being vendor you decide, of course :)
> > (I'd use only two partitions: MLO and UBI, latter one with BCH8, and store
> > everything in UBI volumes. That's a bit more flexible approach)
> 
> Yes, that is a good goal for a future setup and would of course be better.
> Like U-Boot already provides the memory layout for RAM.
> 
> Hopefully, someone will work out patches for u-boot plus kernel (which is 
> always
> painful to keep these two in sync and tested). But I don't want to do that 
> now.

At kernel side the only patch needed is to remove partitioning scheme from DTB
and u-boot setup can be merely copied from board/isee/igep00x0
Not having hardware I cannot really test it ;-)

Best regards,
ladis

Re: [PATCH 09/32] ARM: dts: omap3-gta04: make NAND partitions compatible with recent U-Boot

[Ladislav Michl]

On Wed, Jul 25, 2018 at 10:18:28AM +0200, H. Nikolaus Schaller wrote:
> 
> > Am 25.07.2018 um 10:07 schrieb Ladislav Michl :
> > 
> > On Wed, Jul 25, 2018 at 08:58:41AM +0200, H. Nikolaus Schaller wrote:
> >> Vendor defined U-Boot has changed the partition scheme a while ago:
> >> 
> >> * kernel partition 6MB
> >> * file system partition uses the remainder up to end of the NAND
> >> * increased size of the environment partition (to get an OneNAND 
> >> compatible base address)
> >> * shrink the U-Boot partition
> >> 
> >> Let's be compatible (e.g. Debian kernel built from upstream).
> > 
> > That, in fact, is breaking compatibility.
> 
> With what? Nobody is using the old u-boot partition scheme any more
> (it is >5 years old).
> 
> > So once you are touching this
> > what about relying on partitioning provided by bootloader just to prevent
> > something like this happening again?
> 
> Well, we define what compatible means here (since we are the vendor).
> And people complain with us. We simply recommend them to upgrade the
> boot-loader.

Fair enough. Suggestion was to remove partitioning scheme from DTB alltogether
and let U-Boot provide one. But you being vendor you decide, of course :)
(I'd use only two partitions: MLO and UBI, latter one with BCH8, and store
everything in UBI volumes. That's a bit more flexible approach)

ladis

> BR,
> Nikolaus
> 
> > 
> > ladis
> > 
> >> Signed-off-by: H. Nikolaus Schaller 
> >> ---
> >> arch/arm/boot/dts/omap3-gta04.dtsi | 12 ++--
> >> 1 file changed, 6 insertions(+), 6 deletions(-)
> >> 
> >> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
> >> b/arch/arm/boot/dts/omap3-gta04.dtsi
> >> index 65f77a0b5dd4..03fe404cbf56 100644
> >> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> >> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> >> @@ -645,22 +645,22 @@
> >> 
> >>bootloaders@8 {
> >>label = "U-Boot";
> >> -  reg = <0x8 0x1e>;
> >> +  reg = <0x8 0x1c>;
> >>};
> >> 
> >> -  bootloaders_env@26 {
> >> +  bootloaders_env@24 {
> >>label = "U-Boot Env";
> >> -  reg = <0x26 0x2>;
> >> +  reg = <0x24 0x4>;
> >>};
> >> 
> >>kernel@28 {
> >>label = "Kernel";
> >> -  reg = <0x28 0x40>;
> >> +  reg = <0x28 0x60>;
> >>};
> >> 
> >> -  filesystem@68 {
> >> +  filesystem@88 {
> >>label = "File System";
> >> -  reg = <0x68 0xf98>;
> >> +  reg = <0x88 0>; /* 0 = MTDPART_SIZ_FULL */
> >>};
> >>};
> >> };
> >> -- 
> >> 2.12.2
> >> 
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> >> the body of a message to majord...@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/32] ARM: dts: omap3-gta04: make NAND partitions compatible with recent U-Boot

[Ladislav Michl]

On Wed, Jul 25, 2018 at 10:18:28AM +0200, H. Nikolaus Schaller wrote:
> 
> > Am 25.07.2018 um 10:07 schrieb Ladislav Michl :
> > 
> > On Wed, Jul 25, 2018 at 08:58:41AM +0200, H. Nikolaus Schaller wrote:
> >> Vendor defined U-Boot has changed the partition scheme a while ago:
> >> 
> >> * kernel partition 6MB
> >> * file system partition uses the remainder up to end of the NAND
> >> * increased size of the environment partition (to get an OneNAND 
> >> compatible base address)
> >> * shrink the U-Boot partition
> >> 
> >> Let's be compatible (e.g. Debian kernel built from upstream).
> > 
> > That, in fact, is breaking compatibility.
> 
> With what? Nobody is using the old u-boot partition scheme any more
> (it is >5 years old).
> 
> > So once you are touching this
> > what about relying on partitioning provided by bootloader just to prevent
> > something like this happening again?
> 
> Well, we define what compatible means here (since we are the vendor).
> And people complain with us. We simply recommend them to upgrade the
> boot-loader.

Fair enough. Suggestion was to remove partitioning scheme from DTB alltogether
and let U-Boot provide one. But you being vendor you decide, of course :)
(I'd use only two partitions: MLO and UBI, latter one with BCH8, and store
everything in UBI volumes. That's a bit more flexible approach)

ladis

> BR,
> Nikolaus
> 
> > 
> > ladis
> > 
> >> Signed-off-by: H. Nikolaus Schaller 
> >> ---
> >> arch/arm/boot/dts/omap3-gta04.dtsi | 12 ++--
> >> 1 file changed, 6 insertions(+), 6 deletions(-)
> >> 
> >> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
> >> b/arch/arm/boot/dts/omap3-gta04.dtsi
> >> index 65f77a0b5dd4..03fe404cbf56 100644
> >> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> >> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> >> @@ -645,22 +645,22 @@
> >> 
> >>bootloaders@8 {
> >>label = "U-Boot";
> >> -  reg = <0x8 0x1e>;
> >> +  reg = <0x8 0x1c>;
> >>};
> >> 
> >> -  bootloaders_env@26 {
> >> +  bootloaders_env@24 {
> >>label = "U-Boot Env";
> >> -  reg = <0x26 0x2>;
> >> +  reg = <0x24 0x4>;
> >>};
> >> 
> >>kernel@28 {
> >>label = "Kernel";
> >> -  reg = <0x28 0x40>;
> >> +  reg = <0x28 0x60>;
> >>};
> >> 
> >> -  filesystem@68 {
> >> +  filesystem@88 {
> >>label = "File System";
> >> -  reg = <0x68 0xf98>;
> >> +  reg = <0x88 0>; /* 0 = MTDPART_SIZ_FULL */
> >>};
> >>};
> >> };
> >> -- 
> >> 2.12.2
> >> 
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> >> the body of a message to majord...@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/32] ARM: dts: omap3-gta04: update gpmc NAND setup

[Ladislav Michl]

On Wed, Jul 25, 2018 at 10:16:28AM +0200, H. Nikolaus Schaller wrote:
> Hi,
> 
> > Am 25.07.2018 um 10:10 schrieb Ladislav Michl :
> > 
> > On Wed, Jul 25, 2018 at 08:58:42AM +0200, H. Nikolaus Schaller wrote:
> >> to better match omap3-beagle.dts (which was the basis
> >> of designing the GTA04).
> >> 
> >> Signed-off-by: H. Nikolaus Schaller 
> >> ---
> >> arch/arm/boot/dts/omap3-gta04.dtsi | 14 +++---
> >> 1 file changed, 7 insertions(+), 7 deletions(-)
> >> 
> >> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
> >> b/arch/arm/boot/dts/omap3-gta04.dtsi
> >> index 03fe404cbf56..9568e0c4d4bf 100644
> >> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> >> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> >> @@ -616,27 +616,27 @@
> >>interrupt-parent = <>;
> >>interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */
> >> <1 IRQ_TYPE_NONE>; /* termcount */
> >> +  ti,nand-ecc-opt = "ham1";
> >> +  rb-gpios = < 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
> >>nand-bus-width = <16>;
> >> -  ti,nand-ecc-opt = "bch8";
> > 
> > You are using weeker ECC scheme just to be compatible with another machine?
> 
> No not another machine. The GTA04 uses the same SoC and NAND chip as the 
> BeagleBoard,
> so you can imagine GTA04 being a BeagleBoard + a lot of other things.
> 
> The key reason is to change the ecc scheme is to be compatible with the 
> U-Boot used.
> 
> BootROM can only handle ham1 for the MLO. And there is no nand-ecc-opt
> for each partition. So we either can't mix ECC schemes if we want to be able
> to read/write MLO as the first partition from kernel.
> 
> > So now you cannot boot already deployed filesystem...
> 
> No. We always used ham1 and bch8 wasn't working at all here. Therefore nobody
> did use upstream kernel for NAND yet...
> 
> > Also is it enough for
> > NAND chip used?
> 
> Well, the chip is recommended to use bch8 but BootROM imposes above mentioned 
> limits.

Then common way to handle such a situation is to use 1bit hamming for MLO and 
BCH8 for
the rest. You will end with corrupted filesystem with ham1 which I'd consider 
very
unfortunate.

(I know there were endless discussions how to handle this situation. It is 
already
solved in U-Boot and for updating MLO from Linux I'm using writeloader tool)

ladis

> BR,
> Nikolaus
> 
> > 
> > ladis
> > 
> >> +  #address-cells = <1>;
> >> +  #size-cells = <1>;
> >> 
> >> -  gpmc,sync-clk-ps = <0>;
> >> +  gpmc,device-width = <2>;
> >>gpmc,cs-on-ns = <0>;
> >>gpmc,cs-rd-off-ns = <44>;
> >>gpmc,cs-wr-off-ns = <44>;
> >>gpmc,adv-on-ns = <6>;
> >>gpmc,adv-rd-off-ns = <34>;
> >>gpmc,adv-wr-off-ns = <44>;
> >> -  gpmc,we-off-ns = <40>;
> >>gpmc,oe-off-ns = <54>;
> >> +  gpmc,we-off-ns = <40>;
> >>gpmc,access-ns = <64>;
> >>gpmc,rd-cycle-ns = <82>;
> >>gpmc,wr-cycle-ns = <82>;
> >>gpmc,wr-access-ns = <40>;
> >>gpmc,wr-data-mux-bus-ns = <0>;
> >> -  gpmc,device-width = <2>;
> >> -
> >> -  #address-cells = <1>;
> >> -  #size-cells = <1>;
> >> +  gpmc,sync-clk-ps = <0>;
> >> 
> >>x-loader@0 {
> >>label = "X-Loader";
> >> -- 
> >> 2.12.2
> >> 
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> >> the body of a message to majord...@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/32] ARM: dts: omap3-gta04: update gpmc NAND setup

[Ladislav Michl]

On Wed, Jul 25, 2018 at 10:16:28AM +0200, H. Nikolaus Schaller wrote:
> Hi,
> 
> > Am 25.07.2018 um 10:10 schrieb Ladislav Michl :
> > 
> > On Wed, Jul 25, 2018 at 08:58:42AM +0200, H. Nikolaus Schaller wrote:
> >> to better match omap3-beagle.dts (which was the basis
> >> of designing the GTA04).
> >> 
> >> Signed-off-by: H. Nikolaus Schaller 
> >> ---
> >> arch/arm/boot/dts/omap3-gta04.dtsi | 14 +++---
> >> 1 file changed, 7 insertions(+), 7 deletions(-)
> >> 
> >> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
> >> b/arch/arm/boot/dts/omap3-gta04.dtsi
> >> index 03fe404cbf56..9568e0c4d4bf 100644
> >> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> >> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> >> @@ -616,27 +616,27 @@
> >>interrupt-parent = <>;
> >>interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */
> >> <1 IRQ_TYPE_NONE>; /* termcount */
> >> +  ti,nand-ecc-opt = "ham1";
> >> +  rb-gpios = < 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
> >>nand-bus-width = <16>;
> >> -  ti,nand-ecc-opt = "bch8";
> > 
> > You are using weeker ECC scheme just to be compatible with another machine?
> 
> No not another machine. The GTA04 uses the same SoC and NAND chip as the 
> BeagleBoard,
> so you can imagine GTA04 being a BeagleBoard + a lot of other things.
> 
> The key reason is to change the ecc scheme is to be compatible with the 
> U-Boot used.
> 
> BootROM can only handle ham1 for the MLO. And there is no nand-ecc-opt
> for each partition. So we either can't mix ECC schemes if we want to be able
> to read/write MLO as the first partition from kernel.
> 
> > So now you cannot boot already deployed filesystem...
> 
> No. We always used ham1 and bch8 wasn't working at all here. Therefore nobody
> did use upstream kernel for NAND yet...
> 
> > Also is it enough for
> > NAND chip used?
> 
> Well, the chip is recommended to use bch8 but BootROM imposes above mentioned 
> limits.

Then common way to handle such a situation is to use 1bit hamming for MLO and 
BCH8 for
the rest. You will end with corrupted filesystem with ham1 which I'd consider 
very
unfortunate.

(I know there were endless discussions how to handle this situation. It is 
already
solved in U-Boot and for updating MLO from Linux I'm using writeloader tool)

ladis

> BR,
> Nikolaus
> 
> > 
> > ladis
> > 
> >> +  #address-cells = <1>;
> >> +  #size-cells = <1>;
> >> 
> >> -  gpmc,sync-clk-ps = <0>;
> >> +  gpmc,device-width = <2>;
> >>gpmc,cs-on-ns = <0>;
> >>gpmc,cs-rd-off-ns = <44>;
> >>gpmc,cs-wr-off-ns = <44>;
> >>gpmc,adv-on-ns = <6>;
> >>gpmc,adv-rd-off-ns = <34>;
> >>gpmc,adv-wr-off-ns = <44>;
> >> -  gpmc,we-off-ns = <40>;
> >>gpmc,oe-off-ns = <54>;
> >> +  gpmc,we-off-ns = <40>;
> >>gpmc,access-ns = <64>;
> >>gpmc,rd-cycle-ns = <82>;
> >>gpmc,wr-cycle-ns = <82>;
> >>gpmc,wr-access-ns = <40>;
> >>gpmc,wr-data-mux-bus-ns = <0>;
> >> -  gpmc,device-width = <2>;
> >> -
> >> -  #address-cells = <1>;
> >> -  #size-cells = <1>;
> >> +  gpmc,sync-clk-ps = <0>;
> >> 
> >>x-loader@0 {
> >>label = "X-Loader";
> >> -- 
> >> 2.12.2
> >> 
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> >> the body of a message to majord...@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 32/32] ARM: dts: omap3-gta04a5one: define GTA04A5 variant with OneNAND

[Ladislav Michl]

On Wed, Jul 25, 2018 at 08:59:04AM +0200, H. Nikolaus Schaller wrote:
> GTA04A5 has been produced with MCP chips either with
>  512MB RAM +  512MB NAND
>  512MB RAM + 1024MB NAND
> 1024MB RAM +  512MB OneNAND
> 
> RAM setup is done by U-Boot (MLO/SPL) but OneNAND needs
> a different setup of the GPMC. So we need to derive a
> DTB variant that modifies the gpmc and nand setup.

Just a suggestion... This way your user needs to know which variant is dealing
with. It is similar situation as with IGEPv2 with cames with various setup
either with NAND or OneNAND. Both NAND and OneNAND nodes are present in DTB
and enabled by U-Boot approriately. So single U-Boot binary and DTB is enough
to deal with all variants.

ladis

> Signed-off-by: H. Nikolaus Schaller 
> ---
>  arch/arm/boot/dts/omap3-gta04a5one.dts | 114 
> +
>  1 file changed, 114 insertions(+)
>  create mode 100644 arch/arm/boot/dts/omap3-gta04a5one.dts
> 
> diff --git a/arch/arm/boot/dts/omap3-gta04a5one.dts 
> b/arch/arm/boot/dts/omap3-gta04a5one.dts
> new file mode 100644
> index ..9b7bbdc344b3
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3-gta04a5one.dts
> @@ -0,0 +1,114 @@
> +/*
> + * Copyright (C) 2014-18 H. Nikolaus Schaller 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include "omap3-gta04a5.dts"
> +
> +_pmx_core {
> + model = "Goldelico GTA04A5/Letux 2804 with OneNAND";
> +
> + gpmc_pins: pinmux_gpmc_pins {
> + pinctrl-single,pins = <
> +
> + /* address lines */
> + OMAP3_CORE1_IOPAD(0x207a, PIN_OUTPUT | MUX_MODE0)   
> /* gpmc_a1.gpmc_a1 */
> + OMAP3_CORE1_IOPAD(0x207c, PIN_OUTPUT | MUX_MODE0)   
> /* gpmc_a2.gpmc_a2 */
> + OMAP3_CORE1_IOPAD(0x207e, PIN_OUTPUT | MUX_MODE0)   
> /* gpmc_a3.gpmc_a3 */
> +
> + /* data lines, gpmc_d0..d7 not muxable according to TRM 
> */
> + OMAP3_CORE1_IOPAD(0x209e, PIN_INPUT | MUX_MODE0)
> /* gpmc_d8.gpmc_d8 */
> + OMAP3_CORE1_IOPAD(0x20a0, PIN_INPUT | MUX_MODE0)
> /* gpmc_d9.gpmc_d9 */
> + OMAP3_CORE1_IOPAD(0x20a2, PIN_INPUT | MUX_MODE0)
> /* gpmc_d10.gpmc_d10 */
> + OMAP3_CORE1_IOPAD(0x20a4, PIN_INPUT | MUX_MODE0)
> /* gpmc_d11.gpmc_d11 */
> + OMAP3_CORE1_IOPAD(0x20a6, PIN_INPUT | MUX_MODE0)
> /* gpmc_d12.gpmc_d12 */
> + OMAP3_CORE1_IOPAD(0x20a8, PIN_INPUT | MUX_MODE0)
> /* gpmc_d13.gpmc_d13 */
> + OMAP3_CORE1_IOPAD(0x20aa, PIN_INPUT | MUX_MODE0)
> /* gpmc_d14.gpmc_d14 */
> + OMAP3_CORE1_IOPAD(0x20ac, PIN_INPUT | MUX_MODE0)
> /* gpmc_d15.gpmc_d15 */
> +
> + /*
> +  * gpmc_ncs0, gpmc_nadv_ale, gpmc_noe, gpmc_nwe, 
> gpmc_wait0 not muxable
> +  * according to TRM. OneNAND seems to require PIN_INPUT 
> on clock.
> +  */
> + OMAP3_CORE1_IOPAD(0x20b0, PIN_OUTPUT | MUX_MODE0)   
> /* gpmc_ncs1.gpmc_ncs1 */
> + OMAP3_CORE1_IOPAD(0x20be, PIN_INPUT | MUX_MODE0)
> /* gpmc_clk.gpmc_clk */
> + >;
> + };
> +};
> +
> + {
> + /* switch inherited setup to OneNAND */
> +
> + ranges = <0 0 0x0400 0x100>;/* CS0: 16MB for OneNAND */
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + /delete-node/ nand@0,0;
> +
> + onenand@0,0 {
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "ti,omap2-onenand";
> + reg = <0 0 0x2>;/* CS0, offset 0, IO size 128K */
> +
> + gpmc,sync-read;
> + gpmc,sync-write;
> + gpmc,burst-length = <16>;
> + gpmc,burst-read;
> + gpmc,burst-wrap;
> + gpmc,burst-write;
> + gpmc,device-width = <2>;
> + gpmc,mux-add-data = <2>;
> + gpmc,cs-on-ns = <0>;
> + gpmc,cs-rd-off-ns = <87>;
> + gpmc,cs-wr-off-ns = <87>;
> + gpmc,adv-on-ns = <0>;
> + gpmc,adv-rd-off-ns = <10>;
> + gpmc,adv-wr-off-ns = <10>;
> + gpmc,oe-on-ns = <15>;
> + gpmc,oe-off-ns = <87>;
> + gpmc,we-on-ns = <0>;
> + gpmc,we-off-ns = <87>;
> + gpmc,rd-cycle-ns = <112>;
> + gpmc,wr-cycle-ns = <112>;
> + gpmc,access-ns = <81>;
> + gpmc,page-burst-access-ns = <15>;
> + gpmc,bus-turnaround-ns = <0>;
> + gpmc,cycle2cycle-delay-ns = <0>;
> + gpmc,wait-monitoring-ns = <0>;
> + gpmc,clk-activation-ns = <5>;
> +

Re: [PATCH 32/32] ARM: dts: omap3-gta04a5one: define GTA04A5 variant with OneNAND

[Ladislav Michl]

On Wed, Jul 25, 2018 at 08:59:04AM +0200, H. Nikolaus Schaller wrote:
> GTA04A5 has been produced with MCP chips either with
>  512MB RAM +  512MB NAND
>  512MB RAM + 1024MB NAND
> 1024MB RAM +  512MB OneNAND
> 
> RAM setup is done by U-Boot (MLO/SPL) but OneNAND needs
> a different setup of the GPMC. So we need to derive a
> DTB variant that modifies the gpmc and nand setup.

Just a suggestion... This way your user needs to know which variant is dealing
with. It is similar situation as with IGEPv2 with cames with various setup
either with NAND or OneNAND. Both NAND and OneNAND nodes are present in DTB
and enabled by U-Boot approriately. So single U-Boot binary and DTB is enough
to deal with all variants.

ladis

> Signed-off-by: H. Nikolaus Schaller 
> ---
>  arch/arm/boot/dts/omap3-gta04a5one.dts | 114 
> +
>  1 file changed, 114 insertions(+)
>  create mode 100644 arch/arm/boot/dts/omap3-gta04a5one.dts
> 
> diff --git a/arch/arm/boot/dts/omap3-gta04a5one.dts 
> b/arch/arm/boot/dts/omap3-gta04a5one.dts
> new file mode 100644
> index ..9b7bbdc344b3
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3-gta04a5one.dts
> @@ -0,0 +1,114 @@
> +/*
> + * Copyright (C) 2014-18 H. Nikolaus Schaller 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include "omap3-gta04a5.dts"
> +
> +_pmx_core {
> + model = "Goldelico GTA04A5/Letux 2804 with OneNAND";
> +
> + gpmc_pins: pinmux_gpmc_pins {
> + pinctrl-single,pins = <
> +
> + /* address lines */
> + OMAP3_CORE1_IOPAD(0x207a, PIN_OUTPUT | MUX_MODE0)   
> /* gpmc_a1.gpmc_a1 */
> + OMAP3_CORE1_IOPAD(0x207c, PIN_OUTPUT | MUX_MODE0)   
> /* gpmc_a2.gpmc_a2 */
> + OMAP3_CORE1_IOPAD(0x207e, PIN_OUTPUT | MUX_MODE0)   
> /* gpmc_a3.gpmc_a3 */
> +
> + /* data lines, gpmc_d0..d7 not muxable according to TRM 
> */
> + OMAP3_CORE1_IOPAD(0x209e, PIN_INPUT | MUX_MODE0)
> /* gpmc_d8.gpmc_d8 */
> + OMAP3_CORE1_IOPAD(0x20a0, PIN_INPUT | MUX_MODE0)
> /* gpmc_d9.gpmc_d9 */
> + OMAP3_CORE1_IOPAD(0x20a2, PIN_INPUT | MUX_MODE0)
> /* gpmc_d10.gpmc_d10 */
> + OMAP3_CORE1_IOPAD(0x20a4, PIN_INPUT | MUX_MODE0)
> /* gpmc_d11.gpmc_d11 */
> + OMAP3_CORE1_IOPAD(0x20a6, PIN_INPUT | MUX_MODE0)
> /* gpmc_d12.gpmc_d12 */
> + OMAP3_CORE1_IOPAD(0x20a8, PIN_INPUT | MUX_MODE0)
> /* gpmc_d13.gpmc_d13 */
> + OMAP3_CORE1_IOPAD(0x20aa, PIN_INPUT | MUX_MODE0)
> /* gpmc_d14.gpmc_d14 */
> + OMAP3_CORE1_IOPAD(0x20ac, PIN_INPUT | MUX_MODE0)
> /* gpmc_d15.gpmc_d15 */
> +
> + /*
> +  * gpmc_ncs0, gpmc_nadv_ale, gpmc_noe, gpmc_nwe, 
> gpmc_wait0 not muxable
> +  * according to TRM. OneNAND seems to require PIN_INPUT 
> on clock.
> +  */
> + OMAP3_CORE1_IOPAD(0x20b0, PIN_OUTPUT | MUX_MODE0)   
> /* gpmc_ncs1.gpmc_ncs1 */
> + OMAP3_CORE1_IOPAD(0x20be, PIN_INPUT | MUX_MODE0)
> /* gpmc_clk.gpmc_clk */
> + >;
> + };
> +};
> +
> + {
> + /* switch inherited setup to OneNAND */
> +
> + ranges = <0 0 0x0400 0x100>;/* CS0: 16MB for OneNAND */
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + /delete-node/ nand@0,0;
> +
> + onenand@0,0 {
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "ti,omap2-onenand";
> + reg = <0 0 0x2>;/* CS0, offset 0, IO size 128K */
> +
> + gpmc,sync-read;
> + gpmc,sync-write;
> + gpmc,burst-length = <16>;
> + gpmc,burst-read;
> + gpmc,burst-wrap;
> + gpmc,burst-write;
> + gpmc,device-width = <2>;
> + gpmc,mux-add-data = <2>;
> + gpmc,cs-on-ns = <0>;
> + gpmc,cs-rd-off-ns = <87>;
> + gpmc,cs-wr-off-ns = <87>;
> + gpmc,adv-on-ns = <0>;
> + gpmc,adv-rd-off-ns = <10>;
> + gpmc,adv-wr-off-ns = <10>;
> + gpmc,oe-on-ns = <15>;
> + gpmc,oe-off-ns = <87>;
> + gpmc,we-on-ns = <0>;
> + gpmc,we-off-ns = <87>;
> + gpmc,rd-cycle-ns = <112>;
> + gpmc,wr-cycle-ns = <112>;
> + gpmc,access-ns = <81>;
> + gpmc,page-burst-access-ns = <15>;
> + gpmc,bus-turnaround-ns = <0>;
> + gpmc,cycle2cycle-delay-ns = <0>;
> + gpmc,wait-monitoring-ns = <0>;
> + gpmc,clk-activation-ns = <5>;
> +

Re: [PATCH 20/32] ARM: dts: omap3-gta04: add devconf0 setup for mcbsp1 clock pins

[Ladislav Michl]

On Wed, Jul 25, 2018 at 08:58:52AM +0200, H. Nikolaus Schaller wrote:
> McBSP1 needs sepcial "pinctrl" for the clocks.

Nit: "special" perhaps?

> Signed-off-by: H. Nikolaus Schaller 
> ---
>  arch/arm/boot/dts/omap3-gta04.dtsi | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
> b/arch/arm/boot/dts/omap3-gta04.dtsi
> index 935a2a707737..f6abdef556c1 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> @@ -187,6 +187,24 @@
>   reset-gpios = < 0 GPIO_ACTIVE_LOW>; /* W2CBW003 
> reset through tca6507 */
>   };
>  
> + /* devconf0 setup for mcbsp1 clock pins */
> + pinmux_mcbsp1@48002274 {
> + compatible = "pinctrl-single";
> + reg = <0x48002274 4>;   /* CONTROL_DEVCONF0 */
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-single,bit-per-mux;
> + pinctrl-single,register-width = <32>;
> + pinctrl-single,function-mask = <0x7>;   /* MCBSP1 CLK pinmux */
> + #pinctrl-cells = <2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_devconf0_pins>;
> + mcbsp1_devconf0_pins: pinmux_mcbsp1_devconf0_pins {
> + /*   offset bits mask */
> + pinctrl-single,bits = <0x00 0x08 0x1c>; /* set 
> MCBSP1_CLKR */
> + };
> + };
> +
>   /* devconf1 setup for tvout pins */
>   pinmux_tv_out@480022d8 {
>   compatible = "pinctrl-single";
> -- 
> 2.12.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 20/32] ARM: dts: omap3-gta04: add devconf0 setup for mcbsp1 clock pins

[Ladislav Michl]

On Wed, Jul 25, 2018 at 08:58:52AM +0200, H. Nikolaus Schaller wrote:
> McBSP1 needs sepcial "pinctrl" for the clocks.

Nit: "special" perhaps?

> Signed-off-by: H. Nikolaus Schaller 
> ---
>  arch/arm/boot/dts/omap3-gta04.dtsi | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
> b/arch/arm/boot/dts/omap3-gta04.dtsi
> index 935a2a707737..f6abdef556c1 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> @@ -187,6 +187,24 @@
>   reset-gpios = < 0 GPIO_ACTIVE_LOW>; /* W2CBW003 
> reset through tca6507 */
>   };
>  
> + /* devconf0 setup for mcbsp1 clock pins */
> + pinmux_mcbsp1@48002274 {
> + compatible = "pinctrl-single";
> + reg = <0x48002274 4>;   /* CONTROL_DEVCONF0 */
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-single,bit-per-mux;
> + pinctrl-single,register-width = <32>;
> + pinctrl-single,function-mask = <0x7>;   /* MCBSP1 CLK pinmux */
> + #pinctrl-cells = <2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_devconf0_pins>;
> + mcbsp1_devconf0_pins: pinmux_mcbsp1_devconf0_pins {
> + /*   offset bits mask */
> + pinctrl-single,bits = <0x00 0x08 0x1c>; /* set 
> MCBSP1_CLKR */
> + };
> + };
> +
>   /* devconf1 setup for tvout pins */
>   pinmux_tv_out@480022d8 {
>   compatible = "pinctrl-single";
> -- 
> 2.12.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/32] ARM: dts: omap3-gta04: update gpmc NAND setup

[Ladislav Michl]

On Wed, Jul 25, 2018 at 08:58:42AM +0200, H. Nikolaus Schaller wrote:
> to better match omap3-beagle.dts (which was the basis
> of designing the GTA04).
> 
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  arch/arm/boot/dts/omap3-gta04.dtsi | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
> b/arch/arm/boot/dts/omap3-gta04.dtsi
> index 03fe404cbf56..9568e0c4d4bf 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> @@ -616,27 +616,27 @@
>   interrupt-parent = <>;
>   interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */
><1 IRQ_TYPE_NONE>; /* termcount */
> + ti,nand-ecc-opt = "ham1";
> + rb-gpios = < 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
>   nand-bus-width = <16>;
> - ti,nand-ecc-opt = "bch8";

You are using weeker ECC scheme just to be compatible with another machine?
So now you cannot boot already deployed filesystem... Also is it enough for
NAND chip used?

ladis

> + #address-cells = <1>;
> + #size-cells = <1>;
>  
> - gpmc,sync-clk-ps = <0>;
> + gpmc,device-width = <2>;
>   gpmc,cs-on-ns = <0>;
>   gpmc,cs-rd-off-ns = <44>;
>   gpmc,cs-wr-off-ns = <44>;
>   gpmc,adv-on-ns = <6>;
>   gpmc,adv-rd-off-ns = <34>;
>   gpmc,adv-wr-off-ns = <44>;
> - gpmc,we-off-ns = <40>;
>   gpmc,oe-off-ns = <54>;
> + gpmc,we-off-ns = <40>;
>   gpmc,access-ns = <64>;
>   gpmc,rd-cycle-ns = <82>;
>   gpmc,wr-cycle-ns = <82>;
>   gpmc,wr-access-ns = <40>;
>   gpmc,wr-data-mux-bus-ns = <0>;
> - gpmc,device-width = <2>;
> -
> - #address-cells = <1>;
> - #size-cells = <1>;
> + gpmc,sync-clk-ps = <0>;
>  
>   x-loader@0 {
>   label = "X-Loader";
> -- 
> 2.12.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/32] ARM: dts: omap3-gta04: update gpmc NAND setup

[Ladislav Michl]

On Wed, Jul 25, 2018 at 08:58:42AM +0200, H. Nikolaus Schaller wrote:
> to better match omap3-beagle.dts (which was the basis
> of designing the GTA04).
> 
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  arch/arm/boot/dts/omap3-gta04.dtsi | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
> b/arch/arm/boot/dts/omap3-gta04.dtsi
> index 03fe404cbf56..9568e0c4d4bf 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> @@ -616,27 +616,27 @@
>   interrupt-parent = <>;
>   interrupts = <0 IRQ_TYPE_NONE>, /* fifoevent */
><1 IRQ_TYPE_NONE>; /* termcount */
> + ti,nand-ecc-opt = "ham1";
> + rb-gpios = < 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
>   nand-bus-width = <16>;
> - ti,nand-ecc-opt = "bch8";

You are using weeker ECC scheme just to be compatible with another machine?
So now you cannot boot already deployed filesystem... Also is it enough for
NAND chip used?

ladis

> + #address-cells = <1>;
> + #size-cells = <1>;
>  
> - gpmc,sync-clk-ps = <0>;
> + gpmc,device-width = <2>;
>   gpmc,cs-on-ns = <0>;
>   gpmc,cs-rd-off-ns = <44>;
>   gpmc,cs-wr-off-ns = <44>;
>   gpmc,adv-on-ns = <6>;
>   gpmc,adv-rd-off-ns = <34>;
>   gpmc,adv-wr-off-ns = <44>;
> - gpmc,we-off-ns = <40>;
>   gpmc,oe-off-ns = <54>;
> + gpmc,we-off-ns = <40>;
>   gpmc,access-ns = <64>;
>   gpmc,rd-cycle-ns = <82>;
>   gpmc,wr-cycle-ns = <82>;
>   gpmc,wr-access-ns = <40>;
>   gpmc,wr-data-mux-bus-ns = <0>;
> - gpmc,device-width = <2>;
> -
> - #address-cells = <1>;
> - #size-cells = <1>;
> + gpmc,sync-clk-ps = <0>;
>  
>   x-loader@0 {
>   label = "X-Loader";
> -- 
> 2.12.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/32] ARM: dts: omap3-gta04: make NAND partitions compatible with recent U-Boot

[Ladislav Michl]

On Wed, Jul 25, 2018 at 08:58:41AM +0200, H. Nikolaus Schaller wrote:
> Vendor defined U-Boot has changed the partition scheme a while ago:
> 
> * kernel partition 6MB
> * file system partition uses the remainder up to end of the NAND
> * increased size of the environment partition (to get an OneNAND compatible 
> base address)
> * shrink the U-Boot partition
> 
> Let's be compatible (e.g. Debian kernel built from upstream).

That, in fact, is breaking compatibility. So once you are touching this
what about relying on partitioning provided by bootloader just to prevent
something like this happening again?

ladis

> Signed-off-by: H. Nikolaus Schaller 
> ---
>  arch/arm/boot/dts/omap3-gta04.dtsi | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
> b/arch/arm/boot/dts/omap3-gta04.dtsi
> index 65f77a0b5dd4..03fe404cbf56 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> @@ -645,22 +645,22 @@
>  
>   bootloaders@8 {
>   label = "U-Boot";
> - reg = <0x8 0x1e>;
> + reg = <0x8 0x1c>;
>   };
>  
> - bootloaders_env@26 {
> + bootloaders_env@24 {
>   label = "U-Boot Env";
> - reg = <0x26 0x2>;
> + reg = <0x24 0x4>;
>   };
>  
>   kernel@28 {
>   label = "Kernel";
> - reg = <0x28 0x40>;
> + reg = <0x28 0x60>;
>   };
>  
> - filesystem@68 {
> + filesystem@88 {
>   label = "File System";
> - reg = <0x68 0xf98>;
> + reg = <0x88 0>; /* 0 = MTDPART_SIZ_FULL */
>   };
>   };
>  };
> -- 
> 2.12.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/32] ARM: dts: omap3-gta04: make NAND partitions compatible with recent U-Boot

[Ladislav Michl]

On Wed, Jul 25, 2018 at 08:58:41AM +0200, H. Nikolaus Schaller wrote:
> Vendor defined U-Boot has changed the partition scheme a while ago:
> 
> * kernel partition 6MB
> * file system partition uses the remainder up to end of the NAND
> * increased size of the environment partition (to get an OneNAND compatible 
> base address)
> * shrink the U-Boot partition
> 
> Let's be compatible (e.g. Debian kernel built from upstream).

That, in fact, is breaking compatibility. So once you are touching this
what about relying on partitioning provided by bootloader just to prevent
something like this happening again?

ladis

> Signed-off-by: H. Nikolaus Schaller 
> ---
>  arch/arm/boot/dts/omap3-gta04.dtsi | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
> b/arch/arm/boot/dts/omap3-gta04.dtsi
> index 65f77a0b5dd4..03fe404cbf56 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> @@ -645,22 +645,22 @@
>  
>   bootloaders@8 {
>   label = "U-Boot";
> - reg = <0x8 0x1e>;
> + reg = <0x8 0x1c>;
>   };
>  
> - bootloaders_env@26 {
> + bootloaders_env@24 {
>   label = "U-Boot Env";
> - reg = <0x26 0x2>;
> + reg = <0x24 0x4>;
>   };
>  
>   kernel@28 {
>   label = "Kernel";
> - reg = <0x28 0x40>;
> + reg = <0x28 0x60>;
>   };
>  
> - filesystem@68 {
> + filesystem@88 {
>   label = "File System";
> - reg = <0x68 0xf98>;
> + reg = <0x88 0>; /* 0 = MTDPART_SIZ_FULL */
>   };
>   };
>  };
> -- 
> 2.12.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: droid 4: connection refused from voltage_now

[Ladislav Michl]

On Wed, Jul 04, 2018 at 07:11:56PM +0200, Pavel Machek wrote:
> Hi!
> 
> I started to use droid 4 as my primary phone... so I have battery
> monitor running for hours... Once every few days it dies with
> "connection refused" error reading battery's "voltage_now". I restart
> it and it continues working...

Ha! What exactly that "connection refused" means? Is it ECONNREFUSED (111)?
I have custom at91 based board here with few custom power supply drivers
and it sometimes ends with voltage_now of my driver being unreadable.
(I modified userspace code and waiting what's in errno in case reading fails)

> That was with v4.17; in v4.18, I'm getting "red screen" a lot.

Tests are also done v4.17.
Adding linux...@vger.kernel.org as it seems to be subsytem, specific.

ladis

Re: droid 4: connection refused from voltage_now

[Ladislav Michl]

On Wed, Jul 04, 2018 at 07:11:56PM +0200, Pavel Machek wrote:
> Hi!
> 
> I started to use droid 4 as my primary phone... so I have battery
> monitor running for hours... Once every few days it dies with
> "connection refused" error reading battery's "voltage_now". I restart
> it and it continues working...

Ha! What exactly that "connection refused" means? Is it ECONNREFUSED (111)?
I have custom at91 based board here with few custom power supply drivers
and it sometimes ends with voltage_now of my driver being unreadable.
(I modified userspace code and waiting what's in errno in case reading fails)

> That was with v4.17; in v4.18, I'm getting "red screen" a lot.

Tests are also done v4.17.
Adding linux...@vger.kernel.org as it seems to be subsytem, specific.

ladis

Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD

[Ladislav Michl]

On Tue, Jul 03, 2018 at 09:39:51AM -0700, Florian Fainelli wrote:
> 
> 
> On 06/29/2018 02:40 AM, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski 
> > 
> > On da850-evm board we can read the MAC address from MTD. It's currently
> > done in the relevant board file, but we want to get rid of all the MAC
> > reading callbacks from the board file (SPI and NAND). Move the reading
> > of the MAC address from SPI to the emac driver's probe function.
> 
> This should be made something generic to all drivers, not just something
> the davinci_emac driver does, something like this actually:
> 
> https://lkml.org/lkml/2018/3/24/312

...and that's would also make it work when MAC address is stored
in 24c08 EEPROM, which is quite common.

> > Signed-off-by: Bartosz Golaszewski 
> > ---
> >  drivers/net/ethernet/ti/davinci_emac.c | 20 ++--
> >  1 file changed, 18 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/ti/davinci_emac.c 
> > b/drivers/net/ethernet/ti/davinci_emac.c
> > index a1a6445b5a7e..48e6a7755811 100644
> > --- a/drivers/net/ethernet/ti/davinci_emac.c
> > +++ b/drivers/net/ethernet/ti/davinci_emac.c
> > @@ -67,7 +67,7 @@
> >  #include 
> >  #include 
> >  #include 
> > -
> > +#include 
> >  #include 
> >  #include 
> >  
> > @@ -1783,7 +1783,10 @@ static int davinci_emac_probe(struct platform_device 
> > *pdev)
> > struct cpdma_params dma_params;
> > struct clk *emac_clk;
> > unsigned long emac_bus_frequency;
> > -
> > +#ifdef CONFIG_MTD
> > +   size_t mac_addr_len;
> > +   struct mtd_info *mtd;
> > +#endif /* CONFIG_MTD */
> >  
> > /* obtain emac clock from kernel */
> > emac_clk = devm_clk_get(>dev, NULL);
> > @@ -1815,6 +1818,19 @@ static int davinci_emac_probe(struct platform_device 
> > *pdev)
> > goto err_free_netdev;
> > }
> >  
> > +#ifdef CONFIG_MTD
> > +   mtd = get_mtd_device_nm("MAC-Address");
> > +   if (!IS_ERR(mtd)) {
> > +   rc = mtd_read(mtd, 0, ETH_ALEN,
> > + _addr_len, priv->mac_addr);
> > +   if (rc == 0)
> > +   dev_info(>dev,
> > +"Read MAC addr from SPI Flash: %pM\n",
> > +priv->mac_addr);
> > +   put_mtd_device(mtd);
> > +   }
> > +#endif /* CONFIG_MTD */
> > +
> > /* MAC addr and PHY mask , RMII enable info from platform_data */
> > memcpy(priv->mac_addr, pdata->mac_addr, ETH_ALEN);
> > priv->phy_id = pdata->phy_id;
> > 
> 
> -- 
> Florian
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD

[Ladislav Michl]

On Tue, Jul 03, 2018 at 09:39:51AM -0700, Florian Fainelli wrote:
> 
> 
> On 06/29/2018 02:40 AM, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski 
> > 
> > On da850-evm board we can read the MAC address from MTD. It's currently
> > done in the relevant board file, but we want to get rid of all the MAC
> > reading callbacks from the board file (SPI and NAND). Move the reading
> > of the MAC address from SPI to the emac driver's probe function.
> 
> This should be made something generic to all drivers, not just something
> the davinci_emac driver does, something like this actually:
> 
> https://lkml.org/lkml/2018/3/24/312

...and that's would also make it work when MAC address is stored
in 24c08 EEPROM, which is quite common.

> > Signed-off-by: Bartosz Golaszewski 
> > ---
> >  drivers/net/ethernet/ti/davinci_emac.c | 20 ++--
> >  1 file changed, 18 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/ti/davinci_emac.c 
> > b/drivers/net/ethernet/ti/davinci_emac.c
> > index a1a6445b5a7e..48e6a7755811 100644
> > --- a/drivers/net/ethernet/ti/davinci_emac.c
> > +++ b/drivers/net/ethernet/ti/davinci_emac.c
> > @@ -67,7 +67,7 @@
> >  #include 
> >  #include 
> >  #include 
> > -
> > +#include 
> >  #include 
> >  #include 
> >  
> > @@ -1783,7 +1783,10 @@ static int davinci_emac_probe(struct platform_device 
> > *pdev)
> > struct cpdma_params dma_params;
> > struct clk *emac_clk;
> > unsigned long emac_bus_frequency;
> > -
> > +#ifdef CONFIG_MTD
> > +   size_t mac_addr_len;
> > +   struct mtd_info *mtd;
> > +#endif /* CONFIG_MTD */
> >  
> > /* obtain emac clock from kernel */
> > emac_clk = devm_clk_get(>dev, NULL);
> > @@ -1815,6 +1818,19 @@ static int davinci_emac_probe(struct platform_device 
> > *pdev)
> > goto err_free_netdev;
> > }
> >  
> > +#ifdef CONFIG_MTD
> > +   mtd = get_mtd_device_nm("MAC-Address");
> > +   if (!IS_ERR(mtd)) {
> > +   rc = mtd_read(mtd, 0, ETH_ALEN,
> > + _addr_len, priv->mac_addr);
> > +   if (rc == 0)
> > +   dev_info(>dev,
> > +"Read MAC addr from SPI Flash: %pM\n",
> > +priv->mac_addr);
> > +   put_mtd_device(mtd);
> > +   }
> > +#endif /* CONFIG_MTD */
> > +
> > /* MAC addr and PHY mask , RMII enable info from platform_data */
> > memcpy(priv->mac_addr, pdata->mac_addr, ETH_ALEN);
> > priv->phy_id = pdata->phy_id;
> > 
> 
> -- 
> Florian
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 5/6] mtd: rawnand: ams-delta: use GPIO lookup table

[Ladislav Michl]

On Sat, May 19, 2018 at 11:55:51PM +0200, Janusz Krzysztofik wrote:
> On Saturday, May 19, 2018 8:00:38 PM CEST Andy Shevchenko wrote:
> > On Sat, May 19, 2018 at 2:15 AM, Janusz Krzysztofik  
> wrote:
> > > On Friday, May 18, 2018 11:21:14 PM CEST Andy Shevchenko wrote:
> > >> On Sat, May 19, 2018 at 12:09 AM, Janusz Krzysztofik
> > >> 
> > >>  wrote:
> > >> > +   gpiod_rdy = devm_gpiod_get_optional(>dev, "rdy",
> > >> > GPIOD_IN);
> > >> > +   if (!IS_ERR_OR_NULL(gpiod_rdy)) {
> > >> 
> > >> So, is it optional or not at the end?
> > >> If it is, why do we check for NULL?
> > > 
> > > As far as I can understand, nand_chip->dev_ready() callback is optional.
> > > That's why I decided to use the _optional variant of devm_gpiod_get(). In
> > > case of ams-delta, the dev_ready() callback depends on availability of
> > > the 'rdy' GPIO pin. As a consequence, I'm checking for both NULL and ERR
> > > in order to decide if dev_ready() will be supported.
> > > 
> > > I can pretty well replace it with the standard form and check for ERR only
> > > if the purpose of the _optional form is different.
> > 
> > NULL check in practice discards the _optional part of gpiod_get(). So,
> > either you use non-optional variant and decide how to handle an
> > errors, or user _optional w/o NULL check.
> 
> OK, I'm going to use something like the below while submitting v2:
> 
> - gpiod_rdy = devm_gpiod_get_optional(>dev, "rdy", GPIOD_IN);
> - if (!IS_ERR_OR_NULL(gpiod_rdy)) {
> - this->dev_ready = ams_delta_nand_ready;
> - } else {
> - this->dev_ready = NULL;
> - pr_notice("Couldn't request gpio for Delta NAND ready.\n");
> + priv->gpiod_rdy = devm_gpiod_get_optional(>dev, "rdy",
> +   GPIOD_IN);
> + if (IS_ERR(priv->gpiod_rdy)) {
> + err = PTR_ERR(priv->gpiod_nwp);
??? ^
> + dev_warn(>dev, "RDY GPIO request failed (%d)\n", err);
> + goto err_gpiod;

Driver will just use worst case delay instead of RDY signal, so this
is perhaps too strict. I will work with degraded performance.

ladis

>   }
>  
> + if (priv->gpiod_rdy)
> + this->dev_ready = ams_delta_nand_ready;
> 
> > 
> > >> > +err_gpiod:
> > >> > +   if (err == -ENODEV || err == -ENOENT)
> > >> > +   err = -EPROBE_DEFER;
> > >> 
> > >> Hmm...
> > > 
> > > Amstrad Delta uses gpio-mmio driver. Unfortunatelty that driver is not
> > > availble before device init phase, unlike other crucial GPIO drivers which
> > > are initialized earlier, e.g. during the postcore or at latetst the
> > > subsys phase. Hence, devices which depend on GPIO pins provided by
> > > gpio-mmio must either be declared late or fail softly so they get another
> > > chance of being probed succesfully.
> > > 
> > > I thought of replacing the gpio-mmio platform driver with bgpio functions
> > > it exports but for now I haven't implemented it, not even shared the
> > > idea.
> > > 
> > > Does it really hurt to return -EPROBE_DEFER if a GPIO pin can't be
> > > obtained?
> > I'm only concerned if it would be an infinite defer in the case when
> > driver will never appear.
> > But I don't remember the details.
> 
> Deferred probes are handled effectively during late_initcall, no risk of 
> infinite defer, see drivers/base/dd.c for details.
> 
> Thanks,
> Janusz
> 
> 
> 
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] [PATCH 5/6] mtd: rawnand: ams-delta: use GPIO lookup table

[Ladislav Michl]

On Sat, May 19, 2018 at 11:55:51PM +0200, Janusz Krzysztofik wrote:
> On Saturday, May 19, 2018 8:00:38 PM CEST Andy Shevchenko wrote:
> > On Sat, May 19, 2018 at 2:15 AM, Janusz Krzysztofik  
> wrote:
> > > On Friday, May 18, 2018 11:21:14 PM CEST Andy Shevchenko wrote:
> > >> On Sat, May 19, 2018 at 12:09 AM, Janusz Krzysztofik
> > >> 
> > >>  wrote:
> > >> > +   gpiod_rdy = devm_gpiod_get_optional(>dev, "rdy",
> > >> > GPIOD_IN);
> > >> > +   if (!IS_ERR_OR_NULL(gpiod_rdy)) {
> > >> 
> > >> So, is it optional or not at the end?
> > >> If it is, why do we check for NULL?
> > > 
> > > As far as I can understand, nand_chip->dev_ready() callback is optional.
> > > That's why I decided to use the _optional variant of devm_gpiod_get(). In
> > > case of ams-delta, the dev_ready() callback depends on availability of
> > > the 'rdy' GPIO pin. As a consequence, I'm checking for both NULL and ERR
> > > in order to decide if dev_ready() will be supported.
> > > 
> > > I can pretty well replace it with the standard form and check for ERR only
> > > if the purpose of the _optional form is different.
> > 
> > NULL check in practice discards the _optional part of gpiod_get(). So,
> > either you use non-optional variant and decide how to handle an
> > errors, or user _optional w/o NULL check.
> 
> OK, I'm going to use something like the below while submitting v2:
> 
> - gpiod_rdy = devm_gpiod_get_optional(>dev, "rdy", GPIOD_IN);
> - if (!IS_ERR_OR_NULL(gpiod_rdy)) {
> - this->dev_ready = ams_delta_nand_ready;
> - } else {
> - this->dev_ready = NULL;
> - pr_notice("Couldn't request gpio for Delta NAND ready.\n");
> + priv->gpiod_rdy = devm_gpiod_get_optional(>dev, "rdy",
> +   GPIOD_IN);
> + if (IS_ERR(priv->gpiod_rdy)) {
> + err = PTR_ERR(priv->gpiod_nwp);
??? ^
> + dev_warn(>dev, "RDY GPIO request failed (%d)\n", err);
> + goto err_gpiod;

Driver will just use worst case delay instead of RDY signal, so this
is perhaps too strict. I will work with degraded performance.

ladis

>   }
>  
> + if (priv->gpiod_rdy)
> + this->dev_ready = ams_delta_nand_ready;
> 
> > 
> > >> > +err_gpiod:
> > >> > +   if (err == -ENODEV || err == -ENOENT)
> > >> > +   err = -EPROBE_DEFER;
> > >> 
> > >> Hmm...
> > > 
> > > Amstrad Delta uses gpio-mmio driver. Unfortunatelty that driver is not
> > > availble before device init phase, unlike other crucial GPIO drivers which
> > > are initialized earlier, e.g. during the postcore or at latetst the
> > > subsys phase. Hence, devices which depend on GPIO pins provided by
> > > gpio-mmio must either be declared late or fail softly so they get another
> > > chance of being probed succesfully.
> > > 
> > > I thought of replacing the gpio-mmio platform driver with bgpio functions
> > > it exports but for now I haven't implemented it, not even shared the
> > > idea.
> > > 
> > > Does it really hurt to return -EPROBE_DEFER if a GPIO pin can't be
> > > obtained?
> > I'm only concerned if it would be an infinite defer in the case when
> > driver will never appear.
> > But I don't remember the details.
> 
> Deferred probes are handled effectively during late_initcall, no risk of 
> infinite defer, see drivers/base/dd.c for details.
> 
> Thanks,
> Janusz
> 
> 
> 
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

[PATCH v3] mtd: onenand: omap2: Disable DMA for HIGHMEM buffers

[Ladislav Michl]

dma_map_single does not work for vmalloc-ed buffers,
so disable DMA in this case.

Signed-off-by: Ladislav Michl <la...@linux-mips.org>
Reported-by: "H. Nikolaus Schaller" <h...@goldelico.com>
Tested-by: "H. Nikolaus Schaller" <h...@goldelico.com>
---
 Changes:
  -v2: Added Tested-by tag, based on v4.17-rc1 (no change in patch itself)
  -v3: Reworded commit log

 drivers/mtd/nand/onenand/omap2.c | 105 +++
 1 file changed, 38 insertions(+), 67 deletions(-)

diff --git a/drivers/mtd/nand/onenand/omap2.c b/drivers/mtd/nand/onenand/omap2.c
index 9c159f0dd9a6..321137158ff3 100644
--- a/drivers/mtd/nand/onenand/omap2.c
+++ b/drivers/mtd/nand/onenand/omap2.c
@@ -375,56 +375,42 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
*mtd, int area,
 {
struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
struct onenand_chip *this = mtd->priv;
-   dma_addr_t dma_src, dma_dst;
-   int bram_offset;
+   struct device *dev = >pdev->dev;
void *buf = (void *)buffer;
+   dma_addr_t dma_src, dma_dst;
+   int bram_offset, err;
size_t xtra;
-   int ret;
 
bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
-   if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
-   goto out_copy;
-
-   /* panic_write() may be in an interrupt context */
-   if (in_interrupt() || oops_in_progress)
+   /*
+* If the buffer address is not DMA-able, len is not long enough to make
+* DMA transfers profitable or panic_write() may be in an interrupt
+* context fallback to PIO mode.
+*/
+   if (!virt_addr_valid(buf) || bram_offset & 3 || (size_t)buf & 3 ||
+   count < 384 || in_interrupt() || oops_in_progress )
goto out_copy;
 
-   if (buf >= high_memory) {
-   struct page *p1;
-
-   if (((size_t)buf & PAGE_MASK) !=
-   ((size_t)(buf + count - 1) & PAGE_MASK))
-   goto out_copy;
-   p1 = vmalloc_to_page(buf);
-   if (!p1)
-   goto out_copy;
-   buf = page_address(p1) + ((size_t)buf & ~PAGE_MASK);
-   }
-
xtra = count & 3;
if (xtra) {
count -= xtra;
memcpy(buf + count, this->base + bram_offset + count, xtra);
}
 
+   dma_dst = dma_map_single(dev, buf, count, DMA_FROM_DEVICE);
dma_src = c->phys_base + bram_offset;
-   dma_dst = dma_map_single(>pdev->dev, buf, count, DMA_FROM_DEVICE);
-   if (dma_mapping_error(>pdev->dev, dma_dst)) {
-   dev_err(>pdev->dev,
-   "Couldn't DMA map a %d byte buffer\n",
-   count);
-   goto out_copy;
-   }
 
-   ret = omap2_onenand_dma_transfer(c, dma_src, dma_dst, count);
-   dma_unmap_single(>pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
-
-   if (ret) {
-   dev_err(>pdev->dev, "timeout waiting for DMA\n");
+   if (dma_mapping_error(dev, dma_dst)) {
+   dev_err(dev, "Couldn't DMA map a %d byte buffer\n", count);
goto out_copy;
}
 
-   return 0;
+   err = omap2_onenand_dma_transfer(c, dma_src, dma_dst, count);
+   dma_unmap_single(dev, dma_dst, count, DMA_FROM_DEVICE);
+   if (!err)
+   return 0;
+
+   dev_err(dev, "timeout waiting for DMA\n");
 
 out_copy:
memcpy(buf, this->base + bram_offset, count);
@@ -437,49 +423,34 @@ static int omap2_onenand_write_bufferram(struct mtd_info 
*mtd, int area,
 {
struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
struct onenand_chip *this = mtd->priv;
-   dma_addr_t dma_src, dma_dst;
-   int bram_offset;
+   struct device *dev = >pdev->dev;
void *buf = (void *)buffer;
-   int ret;
+   dma_addr_t dma_src, dma_dst;
+   int bram_offset, err;
 
bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
-   if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
-   goto out_copy;
-
-   /* panic_write() may be in an interrupt context */
-   if (in_interrupt() || oops_in_progress)
+   /*
+* If the buffer address is not DMA-able, len is not long enough to make
+* DMA transfers profitable or panic_write() may be in an interrupt
+* context fallback to PIO mode.
+*/
+   if (!virt_addr_valid(buf) || bram_offset & 3 || (size_t)buf & 3 ||
+   count < 384 || in_interrupt() || oops_in_progress )
goto out_copy;
 
-   if (buf >= high_memory) {
-   struct page *p1;
-
-   if (((size_t)buf & PAGE_MASK) !=

[PATCH v3] mtd: onenand: omap2: Disable DMA for HIGHMEM buffers

[Ladislav Michl]

dma_map_single does not work for vmalloc-ed buffers,
so disable DMA in this case.

Signed-off-by: Ladislav Michl 
Reported-by: "H. Nikolaus Schaller" 
Tested-by: "H. Nikolaus Schaller" 
---
 Changes:
  -v2: Added Tested-by tag, based on v4.17-rc1 (no change in patch itself)
  -v3: Reworded commit log

 drivers/mtd/nand/onenand/omap2.c | 105 +++
 1 file changed, 38 insertions(+), 67 deletions(-)

diff --git a/drivers/mtd/nand/onenand/omap2.c b/drivers/mtd/nand/onenand/omap2.c
index 9c159f0dd9a6..321137158ff3 100644
--- a/drivers/mtd/nand/onenand/omap2.c
+++ b/drivers/mtd/nand/onenand/omap2.c
@@ -375,56 +375,42 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
*mtd, int area,
 {
struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
struct onenand_chip *this = mtd->priv;
-   dma_addr_t dma_src, dma_dst;
-   int bram_offset;
+   struct device *dev = >pdev->dev;
void *buf = (void *)buffer;
+   dma_addr_t dma_src, dma_dst;
+   int bram_offset, err;
size_t xtra;
-   int ret;
 
bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
-   if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
-   goto out_copy;
-
-   /* panic_write() may be in an interrupt context */
-   if (in_interrupt() || oops_in_progress)
+   /*
+* If the buffer address is not DMA-able, len is not long enough to make
+* DMA transfers profitable or panic_write() may be in an interrupt
+* context fallback to PIO mode.
+*/
+   if (!virt_addr_valid(buf) || bram_offset & 3 || (size_t)buf & 3 ||
+   count < 384 || in_interrupt() || oops_in_progress )
goto out_copy;
 
-   if (buf >= high_memory) {
-   struct page *p1;
-
-   if (((size_t)buf & PAGE_MASK) !=
-   ((size_t)(buf + count - 1) & PAGE_MASK))
-   goto out_copy;
-   p1 = vmalloc_to_page(buf);
-   if (!p1)
-   goto out_copy;
-   buf = page_address(p1) + ((size_t)buf & ~PAGE_MASK);
-   }
-
xtra = count & 3;
if (xtra) {
count -= xtra;
memcpy(buf + count, this->base + bram_offset + count, xtra);
}
 
+   dma_dst = dma_map_single(dev, buf, count, DMA_FROM_DEVICE);
dma_src = c->phys_base + bram_offset;
-   dma_dst = dma_map_single(>pdev->dev, buf, count, DMA_FROM_DEVICE);
-   if (dma_mapping_error(>pdev->dev, dma_dst)) {
-   dev_err(>pdev->dev,
-   "Couldn't DMA map a %d byte buffer\n",
-   count);
-   goto out_copy;
-   }
 
-   ret = omap2_onenand_dma_transfer(c, dma_src, dma_dst, count);
-   dma_unmap_single(>pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
-
-   if (ret) {
-   dev_err(>pdev->dev, "timeout waiting for DMA\n");
+   if (dma_mapping_error(dev, dma_dst)) {
+   dev_err(dev, "Couldn't DMA map a %d byte buffer\n", count);
goto out_copy;
}
 
-   return 0;
+   err = omap2_onenand_dma_transfer(c, dma_src, dma_dst, count);
+   dma_unmap_single(dev, dma_dst, count, DMA_FROM_DEVICE);
+   if (!err)
+   return 0;
+
+   dev_err(dev, "timeout waiting for DMA\n");
 
 out_copy:
memcpy(buf, this->base + bram_offset, count);
@@ -437,49 +423,34 @@ static int omap2_onenand_write_bufferram(struct mtd_info 
*mtd, int area,
 {
struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
struct onenand_chip *this = mtd->priv;
-   dma_addr_t dma_src, dma_dst;
-   int bram_offset;
+   struct device *dev = >pdev->dev;
void *buf = (void *)buffer;
-   int ret;
+   dma_addr_t dma_src, dma_dst;
+   int bram_offset, err;
 
bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
-   if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
-   goto out_copy;
-
-   /* panic_write() may be in an interrupt context */
-   if (in_interrupt() || oops_in_progress)
+   /*
+* If the buffer address is not DMA-able, len is not long enough to make
+* DMA transfers profitable or panic_write() may be in an interrupt
+* context fallback to PIO mode.
+*/
+   if (!virt_addr_valid(buf) || bram_offset & 3 || (size_t)buf & 3 ||
+   count < 384 || in_interrupt() || oops_in_progress )
goto out_copy;
 
-   if (buf >= high_memory) {
-   struct page *p1;
-
-   if (((size_t)buf & PAGE_MASK) !=
-   ((size_t)(buf + count - 1) & PAGE_MASK))
-

Re: [PATCH v2] mtd: onenand: omap2: Disable DMA for HIGHMEM buffers

[Ladislav Michl]

Hi Boris,

(and apologies for delay)

On Fri, Apr 20, 2018 at 10:01:34PM +0200, Boris Brezillon wrote:
> Hi Ladislav,
> 
> On Mon, 16 Apr 2018 08:52:59 +0200
> Ladislav Michl <la...@linux-mips.org> wrote:
> 
> > dma_map_single doesn't get the proper DMA address for vmalloced area,
> 
> That's not true, it returns the right DMA (physical) address, it's just
> that:

To be honest I used log message from commit dcf08227e964 which is dealing
with the same issue.

> 1/ the memory location is not necessarily physically contiguous
> 2/ in case your arch is VIVT ot VIPT, there may be several entries in
>the cache pointing to the same physical location, and the cache
>maintenance operations done by dma_map_single() will only operate on
>one of these entries.

Well, there are few things suspicious here: DMA is used to transfer data
to system memory from bufferram which is 3kB in size. Nikolaus reported
Internal error: Oops: 805 [#1] PREEMPT SMP ARM
PC is at v7_dma_inv_range+0x30/0x48
LR is at dma_cache_maint_page+0xd0/0xe0
but I do not see how could it happen if it would be caused by 1/ or 2/ above.
Cache issue would cause data inconsistencies which should be caught by upper
MTD layers.

And given that replacing dma_map_single with dma_map_page done in first
version of patch also fixed oops, it is not caused by 1/
CPU is OMAP3630 based on Cortex-A8, D-cache is often described as PIPT but
seems to be VIPT with built-in alias detection mechanism - anyone with
better knowledge will eventually correct me, thank you.

> > so disable DMA in this case.
> > 
> 
> The fix looks good though. Can you rephrase your commit message to make
> it clearer.

Sure, I'd like to, but I do not know what's root cause yet :)

> Thanks,
> 
> Boris

Best regards,
ladis

Re: [PATCH v2] mtd: onenand: omap2: Disable DMA for HIGHMEM buffers

[Ladislav Michl]

Hi Boris,

(and apologies for delay)

On Fri, Apr 20, 2018 at 10:01:34PM +0200, Boris Brezillon wrote:
> Hi Ladislav,
> 
> On Mon, 16 Apr 2018 08:52:59 +0200
> Ladislav Michl  wrote:
> 
> > dma_map_single doesn't get the proper DMA address for vmalloced area,
> 
> That's not true, it returns the right DMA (physical) address, it's just
> that:

To be honest I used log message from commit dcf08227e964 which is dealing
with the same issue.

> 1/ the memory location is not necessarily physically contiguous
> 2/ in case your arch is VIVT ot VIPT, there may be several entries in
>the cache pointing to the same physical location, and the cache
>maintenance operations done by dma_map_single() will only operate on
>one of these entries.

Well, there are few things suspicious here: DMA is used to transfer data
to system memory from bufferram which is 3kB in size. Nikolaus reported
Internal error: Oops: 805 [#1] PREEMPT SMP ARM
PC is at v7_dma_inv_range+0x30/0x48
LR is at dma_cache_maint_page+0xd0/0xe0
but I do not see how could it happen if it would be caused by 1/ or 2/ above.
Cache issue would cause data inconsistencies which should be caught by upper
MTD layers.

And given that replacing dma_map_single with dma_map_page done in first
version of patch also fixed oops, it is not caused by 1/
CPU is OMAP3630 based on Cortex-A8, D-cache is often described as PIPT but
seems to be VIPT with built-in alias detection mechanism - anyone with
better knowledge will eventually correct me, thank you.

> > so disable DMA in this case.
> > 
> 
> The fix looks good though. Can you rephrase your commit message to make
> it clearer.

Sure, I'd like to, but I do not know what's root cause yet :)

> Thanks,
> 
> Boris

Best regards,
ladis

Re: [PATCH v2] mtd: onenand: omap2: Disable DMA for HIGHMEM buffers

[Ladislav Michl]

Hi Péter,

On Mon, Apr 16, 2018 at 02:34:54PM +0300, Peter Ujfalusi wrote:
> On 2018-04-16 09:52, Ladislav Michl wrote:
> > dma_map_single doesn't get the proper DMA address for vmalloced area,
> 
> Which is not a big surprise as vmalloc will allocate contiguous virtual
> memory (which might corresponds to non-contiguous physical memory). Even
> if you somehow get the physical address of the start of the vmalloced
> buffer, you don't really know how long that chunk is and where the
> buffer continues in physical memory.
> 
> Creating sg_list of the vmalloced buffer should be possible also by
> walking the virt memory and get the pages with vmalloc_to_page().
> I don't think there is a generic vmalloc_to_sg(), one can be implemented.

Please see previous bugreport here:
https://marc.info/?l=linux-omap=152337752611812=2

Unfortunately issue was noticed after v4.16 come out and v4.17-rc1 was
about to released. Thus safe change was introduced.

Best regards,
ladis

> > so disable DMA in this case.
> > 
> > Signed-off-by: Ladislav Michl <la...@linux-mips.org>
> > Reported-by: "H. Nikolaus Schaller" <h...@goldelico.com>
> > Tested-by: "H. Nikolaus Schaller" <h...@goldelico.com>
> > ---
> >  Changes:
> >  -v2: Added Tested-by tag, based on v4.17-rc1 (no change in patch itself)
> > 
> >  drivers/mtd/nand/onenand/omap2.c | 105 +++
> >  1 file changed, 38 insertions(+), 67 deletions(-)
> > 
> > diff --git a/drivers/mtd/nand/onenand/omap2.c 
> > b/drivers/mtd/nand/onenand/omap2.c
> > index 9c159f0dd9a6..321137158ff3 100644
> > --- a/drivers/mtd/nand/onenand/omap2.c
> > +++ b/drivers/mtd/nand/onenand/omap2.c
> > @@ -375,56 +375,42 @@ static int omap2_onenand_read_bufferram(struct 
> > mtd_info *mtd, int area,
> >  {
> > struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> > struct onenand_chip *this = mtd->priv;
> > -   dma_addr_t dma_src, dma_dst;
> > -   int bram_offset;
> > +   struct device *dev = >pdev->dev;
> > void *buf = (void *)buffer;
> > +   dma_addr_t dma_src, dma_dst;
> > +   int bram_offset, err;
> > size_t xtra;
> > -   int ret;
> >  
> > bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> > -   if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> > -   goto out_copy;
> > -
> > -   /* panic_write() may be in an interrupt context */
> > -   if (in_interrupt() || oops_in_progress)
> > +   /*
> > +* If the buffer address is not DMA-able, len is not long enough to make
> > +* DMA transfers profitable or panic_write() may be in an interrupt
> > +* context fallback to PIO mode.
> > +*/
> > +   if (!virt_addr_valid(buf) || bram_offset & 3 || (size_t)buf & 3 ||
> > +   count < 384 || in_interrupt() || oops_in_progress )
> > goto out_copy;
> >  
> > -   if (buf >= high_memory) {
> > -   struct page *p1;
> > -
> > -   if (((size_t)buf & PAGE_MASK) !=
> > -   ((size_t)(buf + count - 1) & PAGE_MASK))
> > -   goto out_copy;
> > -   p1 = vmalloc_to_page(buf);
> > -   if (!p1)
> > -   goto out_copy;
> > -   buf = page_address(p1) + ((size_t)buf & ~PAGE_MASK);
> > -   }
> > -
> > xtra = count & 3;
> > if (xtra) {
> > count -= xtra;
> > memcpy(buf + count, this->base + bram_offset + count, xtra);
> > }
> >  
> > +   dma_dst = dma_map_single(dev, buf, count, DMA_FROM_DEVICE);
> > dma_src = c->phys_base + bram_offset;
> > -   dma_dst = dma_map_single(>pdev->dev, buf, count, DMA_FROM_DEVICE);
> > -   if (dma_mapping_error(>pdev->dev, dma_dst)) {
> > -   dev_err(>pdev->dev,
> > -   "Couldn't DMA map a %d byte buffer\n",
> > -   count);
> > -   goto out_copy;
> > -   }
> >  
> > -   ret = omap2_onenand_dma_transfer(c, dma_src, dma_dst, count);
> > -   dma_unmap_single(>pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
> > -
> > -   if (ret) {
> > -   dev_err(>pdev->dev, "timeout waiting for DMA\n");
> > +   if (dma_mapping_error(dev, dma_dst)) {
> > +   dev_err(dev, "Couldn't DMA map a %d byte buffer\n", count);
> > goto out_copy;
> > }
> >  
> > -   return 0;
> > +   err = omap2_onenand_dm

Re: [PATCH v2] mtd: onenand: omap2: Disable DMA for HIGHMEM buffers

[Ladislav Michl]

Hi Péter,

On Mon, Apr 16, 2018 at 02:34:54PM +0300, Peter Ujfalusi wrote:
> On 2018-04-16 09:52, Ladislav Michl wrote:
> > dma_map_single doesn't get the proper DMA address for vmalloced area,
> 
> Which is not a big surprise as vmalloc will allocate contiguous virtual
> memory (which might corresponds to non-contiguous physical memory). Even
> if you somehow get the physical address of the start of the vmalloced
> buffer, you don't really know how long that chunk is and where the
> buffer continues in physical memory.
> 
> Creating sg_list of the vmalloced buffer should be possible also by
> walking the virt memory and get the pages with vmalloc_to_page().
> I don't think there is a generic vmalloc_to_sg(), one can be implemented.

Please see previous bugreport here:
https://marc.info/?l=linux-omap=152337752611812=2

Unfortunately issue was noticed after v4.16 come out and v4.17-rc1 was
about to released. Thus safe change was introduced.

Best regards,
ladis

> > so disable DMA in this case.
> > 
> > Signed-off-by: Ladislav Michl 
> > Reported-by: "H. Nikolaus Schaller" 
> > Tested-by: "H. Nikolaus Schaller" 
> > ---
> >  Changes:
> >  -v2: Added Tested-by tag, based on v4.17-rc1 (no change in patch itself)
> > 
> >  drivers/mtd/nand/onenand/omap2.c | 105 +++
> >  1 file changed, 38 insertions(+), 67 deletions(-)
> > 
> > diff --git a/drivers/mtd/nand/onenand/omap2.c 
> > b/drivers/mtd/nand/onenand/omap2.c
> > index 9c159f0dd9a6..321137158ff3 100644
> > --- a/drivers/mtd/nand/onenand/omap2.c
> > +++ b/drivers/mtd/nand/onenand/omap2.c
> > @@ -375,56 +375,42 @@ static int omap2_onenand_read_bufferram(struct 
> > mtd_info *mtd, int area,
> >  {
> > struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> > struct onenand_chip *this = mtd->priv;
> > -   dma_addr_t dma_src, dma_dst;
> > -   int bram_offset;
> > +   struct device *dev = >pdev->dev;
> > void *buf = (void *)buffer;
> > +   dma_addr_t dma_src, dma_dst;
> > +   int bram_offset, err;
> > size_t xtra;
> > -   int ret;
> >  
> > bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> > -   if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> > -   goto out_copy;
> > -
> > -   /* panic_write() may be in an interrupt context */
> > -   if (in_interrupt() || oops_in_progress)
> > +   /*
> > +* If the buffer address is not DMA-able, len is not long enough to make
> > +* DMA transfers profitable or panic_write() may be in an interrupt
> > +* context fallback to PIO mode.
> > +*/
> > +   if (!virt_addr_valid(buf) || bram_offset & 3 || (size_t)buf & 3 ||
> > +   count < 384 || in_interrupt() || oops_in_progress )
> > goto out_copy;
> >  
> > -   if (buf >= high_memory) {
> > -   struct page *p1;
> > -
> > -   if (((size_t)buf & PAGE_MASK) !=
> > -   ((size_t)(buf + count - 1) & PAGE_MASK))
> > -   goto out_copy;
> > -   p1 = vmalloc_to_page(buf);
> > -   if (!p1)
> > -   goto out_copy;
> > -   buf = page_address(p1) + ((size_t)buf & ~PAGE_MASK);
> > -   }
> > -
> > xtra = count & 3;
> > if (xtra) {
> > count -= xtra;
> > memcpy(buf + count, this->base + bram_offset + count, xtra);
> > }
> >  
> > +   dma_dst = dma_map_single(dev, buf, count, DMA_FROM_DEVICE);
> > dma_src = c->phys_base + bram_offset;
> > -   dma_dst = dma_map_single(>pdev->dev, buf, count, DMA_FROM_DEVICE);
> > -   if (dma_mapping_error(>pdev->dev, dma_dst)) {
> > -   dev_err(>pdev->dev,
> > -   "Couldn't DMA map a %d byte buffer\n",
> > -   count);
> > -   goto out_copy;
> > -   }
> >  
> > -   ret = omap2_onenand_dma_transfer(c, dma_src, dma_dst, count);
> > -   dma_unmap_single(>pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
> > -
> > -   if (ret) {
> > -   dev_err(>pdev->dev, "timeout waiting for DMA\n");
> > +   if (dma_mapping_error(dev, dma_dst)) {
> > +   dev_err(dev, "Couldn't DMA map a %d byte buffer\n", count);
> > goto out_copy;
> > }
> >  
> > -   return 0;
> > +   err = omap2_onenand_dma_transfer(c, dma_src, dma_dst, count);
> > +   dma_unmap_single(dev,

[PATCH v2] mtd: onenand: omap2: Disable DMA for HIGHMEM buffers

[Ladislav Michl]

dma_map_single doesn't get the proper DMA address for vmalloced area,
so disable DMA in this case.

Signed-off-by: Ladislav Michl <la...@linux-mips.org>
Reported-by: "H. Nikolaus Schaller" <h...@goldelico.com>
Tested-by: "H. Nikolaus Schaller" <h...@goldelico.com>
---
 Changes:
 -v2: Added Tested-by tag, based on v4.17-rc1 (no change in patch itself)

 drivers/mtd/nand/onenand/omap2.c | 105 +++
 1 file changed, 38 insertions(+), 67 deletions(-)

diff --git a/drivers/mtd/nand/onenand/omap2.c b/drivers/mtd/nand/onenand/omap2.c
index 9c159f0dd9a6..321137158ff3 100644
--- a/drivers/mtd/nand/onenand/omap2.c
+++ b/drivers/mtd/nand/onenand/omap2.c
@@ -375,56 +375,42 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
*mtd, int area,
 {
struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
struct onenand_chip *this = mtd->priv;
-   dma_addr_t dma_src, dma_dst;
-   int bram_offset;
+   struct device *dev = >pdev->dev;
void *buf = (void *)buffer;
+   dma_addr_t dma_src, dma_dst;
+   int bram_offset, err;
size_t xtra;
-   int ret;
 
bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
-   if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
-   goto out_copy;
-
-   /* panic_write() may be in an interrupt context */
-   if (in_interrupt() || oops_in_progress)
+   /*
+* If the buffer address is not DMA-able, len is not long enough to make
+* DMA transfers profitable or panic_write() may be in an interrupt
+* context fallback to PIO mode.
+*/
+   if (!virt_addr_valid(buf) || bram_offset & 3 || (size_t)buf & 3 ||
+   count < 384 || in_interrupt() || oops_in_progress )
goto out_copy;
 
-   if (buf >= high_memory) {
-   struct page *p1;
-
-   if (((size_t)buf & PAGE_MASK) !=
-   ((size_t)(buf + count - 1) & PAGE_MASK))
-   goto out_copy;
-   p1 = vmalloc_to_page(buf);
-   if (!p1)
-   goto out_copy;
-   buf = page_address(p1) + ((size_t)buf & ~PAGE_MASK);
-   }
-
xtra = count & 3;
if (xtra) {
count -= xtra;
memcpy(buf + count, this->base + bram_offset + count, xtra);
}
 
+   dma_dst = dma_map_single(dev, buf, count, DMA_FROM_DEVICE);
dma_src = c->phys_base + bram_offset;
-   dma_dst = dma_map_single(>pdev->dev, buf, count, DMA_FROM_DEVICE);
-   if (dma_mapping_error(>pdev->dev, dma_dst)) {
-   dev_err(>pdev->dev,
-   "Couldn't DMA map a %d byte buffer\n",
-   count);
-   goto out_copy;
-   }
 
-   ret = omap2_onenand_dma_transfer(c, dma_src, dma_dst, count);
-   dma_unmap_single(>pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
-
-   if (ret) {
-   dev_err(>pdev->dev, "timeout waiting for DMA\n");
+   if (dma_mapping_error(dev, dma_dst)) {
+   dev_err(dev, "Couldn't DMA map a %d byte buffer\n", count);
goto out_copy;
}
 
-   return 0;
+   err = omap2_onenand_dma_transfer(c, dma_src, dma_dst, count);
+   dma_unmap_single(dev, dma_dst, count, DMA_FROM_DEVICE);
+   if (!err)
+   return 0;
+
+   dev_err(dev, "timeout waiting for DMA\n");
 
 out_copy:
memcpy(buf, this->base + bram_offset, count);
@@ -437,49 +423,34 @@ static int omap2_onenand_write_bufferram(struct mtd_info 
*mtd, int area,
 {
struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
struct onenand_chip *this = mtd->priv;
-   dma_addr_t dma_src, dma_dst;
-   int bram_offset;
+   struct device *dev = >pdev->dev;
void *buf = (void *)buffer;
-   int ret;
+   dma_addr_t dma_src, dma_dst;
+   int bram_offset, err;
 
bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
-   if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
-   goto out_copy;
-
-   /* panic_write() may be in an interrupt context */
-   if (in_interrupt() || oops_in_progress)
+   /*
+* If the buffer address is not DMA-able, len is not long enough to make
+* DMA transfers profitable or panic_write() may be in an interrupt
+* context fallback to PIO mode.
+*/
+   if (!virt_addr_valid(buf) || bram_offset & 3 || (size_t)buf & 3 ||
+   count < 384 || in_interrupt() || oops_in_progress )
goto out_copy;
 
-   if (buf >= high_memory) {
-   struct page *p1;
-
-   if (((size_t)buf & PAGE_MASK) !=
-   (

[PATCH v2] mtd: onenand: omap2: Disable DMA for HIGHMEM buffers

[Ladislav Michl]

dma_map_single doesn't get the proper DMA address for vmalloced area,
so disable DMA in this case.

Signed-off-by: Ladislav Michl 
Reported-by: "H. Nikolaus Schaller" 
Tested-by: "H. Nikolaus Schaller" 
---
 Changes:
 -v2: Added Tested-by tag, based on v4.17-rc1 (no change in patch itself)

 drivers/mtd/nand/onenand/omap2.c | 105 +++
 1 file changed, 38 insertions(+), 67 deletions(-)

diff --git a/drivers/mtd/nand/onenand/omap2.c b/drivers/mtd/nand/onenand/omap2.c
index 9c159f0dd9a6..321137158ff3 100644
--- a/drivers/mtd/nand/onenand/omap2.c
+++ b/drivers/mtd/nand/onenand/omap2.c
@@ -375,56 +375,42 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
*mtd, int area,
 {
struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
struct onenand_chip *this = mtd->priv;
-   dma_addr_t dma_src, dma_dst;
-   int bram_offset;
+   struct device *dev = >pdev->dev;
void *buf = (void *)buffer;
+   dma_addr_t dma_src, dma_dst;
+   int bram_offset, err;
size_t xtra;
-   int ret;
 
bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
-   if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
-   goto out_copy;
-
-   /* panic_write() may be in an interrupt context */
-   if (in_interrupt() || oops_in_progress)
+   /*
+* If the buffer address is not DMA-able, len is not long enough to make
+* DMA transfers profitable or panic_write() may be in an interrupt
+* context fallback to PIO mode.
+*/
+   if (!virt_addr_valid(buf) || bram_offset & 3 || (size_t)buf & 3 ||
+   count < 384 || in_interrupt() || oops_in_progress )
goto out_copy;
 
-   if (buf >= high_memory) {
-   struct page *p1;
-
-   if (((size_t)buf & PAGE_MASK) !=
-   ((size_t)(buf + count - 1) & PAGE_MASK))
-   goto out_copy;
-   p1 = vmalloc_to_page(buf);
-   if (!p1)
-   goto out_copy;
-   buf = page_address(p1) + ((size_t)buf & ~PAGE_MASK);
-   }
-
xtra = count & 3;
if (xtra) {
count -= xtra;
memcpy(buf + count, this->base + bram_offset + count, xtra);
}
 
+   dma_dst = dma_map_single(dev, buf, count, DMA_FROM_DEVICE);
dma_src = c->phys_base + bram_offset;
-   dma_dst = dma_map_single(>pdev->dev, buf, count, DMA_FROM_DEVICE);
-   if (dma_mapping_error(>pdev->dev, dma_dst)) {
-   dev_err(>pdev->dev,
-   "Couldn't DMA map a %d byte buffer\n",
-   count);
-   goto out_copy;
-   }
 
-   ret = omap2_onenand_dma_transfer(c, dma_src, dma_dst, count);
-   dma_unmap_single(>pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
-
-   if (ret) {
-   dev_err(>pdev->dev, "timeout waiting for DMA\n");
+   if (dma_mapping_error(dev, dma_dst)) {
+   dev_err(dev, "Couldn't DMA map a %d byte buffer\n", count);
goto out_copy;
}
 
-   return 0;
+   err = omap2_onenand_dma_transfer(c, dma_src, dma_dst, count);
+   dma_unmap_single(dev, dma_dst, count, DMA_FROM_DEVICE);
+   if (!err)
+   return 0;
+
+   dev_err(dev, "timeout waiting for DMA\n");
 
 out_copy:
memcpy(buf, this->base + bram_offset, count);
@@ -437,49 +423,34 @@ static int omap2_onenand_write_bufferram(struct mtd_info 
*mtd, int area,
 {
struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
struct onenand_chip *this = mtd->priv;
-   dma_addr_t dma_src, dma_dst;
-   int bram_offset;
+   struct device *dev = >pdev->dev;
void *buf = (void *)buffer;
-   int ret;
+   dma_addr_t dma_src, dma_dst;
+   int bram_offset, err;
 
bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
-   if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
-   goto out_copy;
-
-   /* panic_write() may be in an interrupt context */
-   if (in_interrupt() || oops_in_progress)
+   /*
+* If the buffer address is not DMA-able, len is not long enough to make
+* DMA transfers profitable or panic_write() may be in an interrupt
+* context fallback to PIO mode.
+*/
+   if (!virt_addr_valid(buf) || bram_offset & 3 || (size_t)buf & 3 ||
+   count < 384 || in_interrupt() || oops_in_progress )
goto out_copy;
 
-   if (buf >= high_memory) {
-   struct page *p1;
-
-   if (((size_t)buf & PAGE_MASK) !=
-   ((size_t)(buf + count - 1) & PAGE_MASK))
-

Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

[Ladislav Michl]

On Wed, Apr 11, 2018 at 10:52:01AM +0200, Boris Brezillon wrote:
> On Wed, 11 Apr 2018 10:27:46 +0200
> Ladislav Michl <la...@linux-mips.org> wrote:
> 
> > On Wed, Apr 11, 2018 at 10:08:06AM +0200, Boris Brezillon wrote:
> > > On Wed, 11 Apr 2018 09:36:56 +0200
> > > Ladislav Michl <la...@linux-mips.org> wrote:
> > >   
> > > > Hi Boris,
> > > > 
> > > > On Wed, Apr 11, 2018 at 09:15:28AM +0200, Boris Brezillon wrote:  
> > [...]
> > > > > Not sure this approach is safe on all archs: if the cache is VIVT or
> > > > > VIPT, you may have several entries pointing to the same phys page, and
> > > > > then, when dma_map_page() does its cache maintenance operations, it's
> > > > > only taking one of these entries into account.
> > > > 
> > > > Hmm, I used the same approach Samsung OneNAND driver does since commit
> > > > dcf08227e964a53a2cb39130b74842c7dcb6adde.
> > > > Both TI OMAP3630 and Samsung S5PC110 are using Cortex-A8 which
> > > > is VIPT. In that case samsung's driver code has the same problem.
> > > >   
> > > > > In other parts of the MTD subsystem, we tend to not do DMA on buffers
> > > > > that have been vmalloc-ed.
> > > > > 
> > > > > You can do something like
> > > > > 
> > > > >   if (virt_addr_valid(buf))
> > > > >   /* Use DMA */
> > > > >   else
> > > > >   /*
> > > > >* Do not use DMA, or use a bounce buffer
> > > > >* allocated with kmalloc
> > > > >*/
> > > > 
> > > > Okay, I'll use this approach then, but first I'd like to be sure above 
> > > > is
> > > > correct. Anyone?  
> > > 
> > > See this discussion [1]. The problem came up a few times already, so
> > > might find other threads describing why it's not safe.
> > > 
> > > [1]https://lists.linuxfoundation.org/pipermail/iommu/2016-March/016240.html
> > >   
> > 
> > Question was more likely whenever there might exist more that one mapping
> > of the same page.
> 
> I'm clearly not an expert, so I might be wrong, but I think a physical
> page can be both in the identity mapping and mapped in the vmalloc
> space. Now, is there a real risk that both ends are accessed in
> parallel thus making different cache entries pointing to the same phys
> page dirty, I'm not sure. Or maybe there are other corner case, but
> you'll have to ask Russell (or any other ARM expert) to get a clearer
> answer.

Thank you anyway. As DMA was disabled completely for all DT enabled boards
until 4.16 let's play safe and disable it for HIGHMEM case as you suggested.
Later, we might eventually use the same {read,write}_bufferram for both
OMAP and S5PC110.

> > But okay, I'll disable DMA for highmem. Patch will follow.
> > 
> > ladis

Andreas, Nikolaus, could you please test patch bellow? It is against
linux.git and should apply also against 4.16 once you modify path.

Thank you,
ladis

--- >8 ---

From: Ladislav Michl <la...@linux-mips.org>
Subject: [PATCH] mtd: onenand: omap2: Disable DMA for HIGHMEM buffers

dma_map_single doesn't get the proper DMA address for vmalloced area,
so disable DMA in this case.

Signed-off-by: Ladislav Michl <la...@linux-mips.org>
Reported-by: "H. Nikolaus Schaller" <h...@goldelico.com>
---
 drivers/mtd/nand/onenand/omap2.c | 105 +++
 1 file changed, 38 insertions(+), 67 deletions(-)

diff --git a/drivers/mtd/nand/onenand/omap2.c b/drivers/mtd/nand/onenand/omap2.c
index 9c159f0dd9a6..321137158ff3 100644
--- a/drivers/mtd/nand/onenand/omap2.c
+++ b/drivers/mtd/nand/onenand/omap2.c
@@ -375,56 +375,42 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
*mtd, int area,
 {
struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
struct onenand_chip *this = mtd->priv;
-   dma_addr_t dma_src, dma_dst;
-   int bram_offset;
+   struct device *dev = >pdev->dev;
void *buf = (void *)buffer;
+   dma_addr_t dma_src, dma_dst;
+   int bram_offset, err;
size_t xtra;
-   int ret;
 
bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
-   if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
-   goto out_copy;
-
-   /* panic_write() may be in an interrupt context */
-   if (in_interrupt() || oops_in_progress)
+   

Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

[Ladislav Michl]

On Wed, Apr 11, 2018 at 10:52:01AM +0200, Boris Brezillon wrote:
> On Wed, 11 Apr 2018 10:27:46 +0200
> Ladislav Michl  wrote:
> 
> > On Wed, Apr 11, 2018 at 10:08:06AM +0200, Boris Brezillon wrote:
> > > On Wed, 11 Apr 2018 09:36:56 +0200
> > > Ladislav Michl  wrote:
> > >   
> > > > Hi Boris,
> > > > 
> > > > On Wed, Apr 11, 2018 at 09:15:28AM +0200, Boris Brezillon wrote:  
> > [...]
> > > > > Not sure this approach is safe on all archs: if the cache is VIVT or
> > > > > VIPT, you may have several entries pointing to the same phys page, and
> > > > > then, when dma_map_page() does its cache maintenance operations, it's
> > > > > only taking one of these entries into account.
> > > > 
> > > > Hmm, I used the same approach Samsung OneNAND driver does since commit
> > > > dcf08227e964a53a2cb39130b74842c7dcb6adde.
> > > > Both TI OMAP3630 and Samsung S5PC110 are using Cortex-A8 which
> > > > is VIPT. In that case samsung's driver code has the same problem.
> > > >   
> > > > > In other parts of the MTD subsystem, we tend to not do DMA on buffers
> > > > > that have been vmalloc-ed.
> > > > > 
> > > > > You can do something like
> > > > > 
> > > > >   if (virt_addr_valid(buf))
> > > > >   /* Use DMA */
> > > > >   else
> > > > >   /*
> > > > >* Do not use DMA, or use a bounce buffer
> > > > >* allocated with kmalloc
> > > > >*/
> > > > 
> > > > Okay, I'll use this approach then, but first I'd like to be sure above 
> > > > is
> > > > correct. Anyone?  
> > > 
> > > See this discussion [1]. The problem came up a few times already, so
> > > might find other threads describing why it's not safe.
> > > 
> > > [1]https://lists.linuxfoundation.org/pipermail/iommu/2016-March/016240.html
> > >   
> > 
> > Question was more likely whenever there might exist more that one mapping
> > of the same page.
> 
> I'm clearly not an expert, so I might be wrong, but I think a physical
> page can be both in the identity mapping and mapped in the vmalloc
> space. Now, is there a real risk that both ends are accessed in
> parallel thus making different cache entries pointing to the same phys
> page dirty, I'm not sure. Or maybe there are other corner case, but
> you'll have to ask Russell (or any other ARM expert) to get a clearer
> answer.

Thank you anyway. As DMA was disabled completely for all DT enabled boards
until 4.16 let's play safe and disable it for HIGHMEM case as you suggested.
Later, we might eventually use the same {read,write}_bufferram for both
OMAP and S5PC110.

> > But okay, I'll disable DMA for highmem. Patch will follow.
> > 
> > ladis

Andreas, Nikolaus, could you please test patch bellow? It is against
linux.git and should apply also against 4.16 once you modify path.

Thank you,
ladis

--- >8 ---

From: Ladislav Michl 
Subject: [PATCH] mtd: onenand: omap2: Disable DMA for HIGHMEM buffers

dma_map_single doesn't get the proper DMA address for vmalloced area,
so disable DMA in this case.

Signed-off-by: Ladislav Michl 
Reported-by: "H. Nikolaus Schaller" 
---
 drivers/mtd/nand/onenand/omap2.c | 105 +++
 1 file changed, 38 insertions(+), 67 deletions(-)

diff --git a/drivers/mtd/nand/onenand/omap2.c b/drivers/mtd/nand/onenand/omap2.c
index 9c159f0dd9a6..321137158ff3 100644
--- a/drivers/mtd/nand/onenand/omap2.c
+++ b/drivers/mtd/nand/onenand/omap2.c
@@ -375,56 +375,42 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
*mtd, int area,
 {
struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
struct onenand_chip *this = mtd->priv;
-   dma_addr_t dma_src, dma_dst;
-   int bram_offset;
+   struct device *dev = >pdev->dev;
void *buf = (void *)buffer;
+   dma_addr_t dma_src, dma_dst;
+   int bram_offset, err;
size_t xtra;
-   int ret;
 
bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
-   if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
-   goto out_copy;
-
-   /* panic_write() may be in an interrupt context */
-   if (in_interrupt() || oops_in_progress)
+   /*
+* If the buffer address is not DMA-able, len is not long enough to make
+* DMA transfers profitable or panic_write() may be in an int

Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

[Ladislav Michl]

On Wed, Apr 11, 2018 at 10:08:06AM +0200, Boris Brezillon wrote:
> On Wed, 11 Apr 2018 09:36:56 +0200
> Ladislav Michl <la...@linux-mips.org> wrote:
> 
> > Hi Boris,
> > 
> > On Wed, Apr 11, 2018 at 09:15:28AM +0200, Boris Brezillon wrote:
[...]
> > > Not sure this approach is safe on all archs: if the cache is VIVT or
> > > VIPT, you may have several entries pointing to the same phys page, and
> > > then, when dma_map_page() does its cache maintenance operations, it's
> > > only taking one of these entries into account.  
> > 
> > Hmm, I used the same approach Samsung OneNAND driver does since commit
> > dcf08227e964a53a2cb39130b74842c7dcb6adde.
> > Both TI OMAP3630 and Samsung S5PC110 are using Cortex-A8 which
> > is VIPT. In that case samsung's driver code has the same problem.
> > 
> > > In other parts of the MTD subsystem, we tend to not do DMA on buffers
> > > that have been vmalloc-ed.
> > > 
> > > You can do something like
> > > 
> > >   if (virt_addr_valid(buf))
> > >   /* Use DMA */
> > >   else
> > >   /*
> > >* Do not use DMA, or use a bounce buffer
> > >* allocated with kmalloc
> > >*/  
> > 
> > Okay, I'll use this approach then, but first I'd like to be sure above is
> > correct. Anyone?
> 
> See this discussion [1]. The problem came up a few times already, so
> might find other threads describing why it's not safe.
> 
> [1]https://lists.linuxfoundation.org/pipermail/iommu/2016-March/016240.html

Question was more likely whenever there might exist more that one mapping
of the same page. But okay, I'll disable DMA for highmem. Patch will follow.

ladis

Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

[Ladislav Michl]

On Wed, Apr 11, 2018 at 10:08:06AM +0200, Boris Brezillon wrote:
> On Wed, 11 Apr 2018 09:36:56 +0200
> Ladislav Michl  wrote:
> 
> > Hi Boris,
> > 
> > On Wed, Apr 11, 2018 at 09:15:28AM +0200, Boris Brezillon wrote:
[...]
> > > Not sure this approach is safe on all archs: if the cache is VIVT or
> > > VIPT, you may have several entries pointing to the same phys page, and
> > > then, when dma_map_page() does its cache maintenance operations, it's
> > > only taking one of these entries into account.  
> > 
> > Hmm, I used the same approach Samsung OneNAND driver does since commit
> > dcf08227e964a53a2cb39130b74842c7dcb6adde.
> > Both TI OMAP3630 and Samsung S5PC110 are using Cortex-A8 which
> > is VIPT. In that case samsung's driver code has the same problem.
> > 
> > > In other parts of the MTD subsystem, we tend to not do DMA on buffers
> > > that have been vmalloc-ed.
> > > 
> > > You can do something like
> > > 
> > >   if (virt_addr_valid(buf))
> > >   /* Use DMA */
> > >   else
> > >   /*
> > >* Do not use DMA, or use a bounce buffer
> > >* allocated with kmalloc
> > >*/  
> > 
> > Okay, I'll use this approach then, but first I'd like to be sure above is
> > correct. Anyone?
> 
> See this discussion [1]. The problem came up a few times already, so
> might find other threads describing why it's not safe.
> 
> [1]https://lists.linuxfoundation.org/pipermail/iommu/2016-March/016240.html

Question was more likely whenever there might exist more that one mapping
of the same page. But okay, I'll disable DMA for highmem. Patch will follow.

ladis

Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

[Ladislav Michl]

Hi Boris,

On Wed, Apr 11, 2018 at 09:15:28AM +0200, Boris Brezillon wrote:
> Hi Ladislav,
> 
> On Wed, 11 Apr 2018 08:26:07 +0200
> Ladislav Michl <la...@linux-mips.org> wrote:
> 
> > Hi Andreas,
> > 
> > On Wed, Apr 11, 2018 at 06:59:03AM +0200, Andreas Kemnade wrote:
> > > Hi Ladis,
> > > 
> > > On Tue, 10 Apr 2018 22:56:43 +0200
> > > Ladislav Michl <la...@linux-mips.org> wrote:
> > >   
> > > > Hi Nikolaus,
> > > > 
> > > > On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote:  
> > > > > Hi,
> > > > > we just started testing the v4.16 kernel and found the
> > > > > device no longer bootable (works with v4.15). It turned
> > > > > out that there was a harmful modification somewhere between
> > > > > v4.15.0 and v4.16-rc1.
> > > > > 
> > > > > A git bisect points to this patch:
> > > > 
> > > > Well, that's a shame... However, this code is in production for several
> > > > months now, so could you, please put 'goto out_copy' if 'buf >= 
> > > > high_memory'
> > > > condition is met, ie:
> > > > --- a/drivers/mtd/nand/onenand/omap2.c
> > > > +++ b/drivers/mtd/nand/onenand/omap2.c
> > > > @@ -392,6 +392,7 @@ static int omap2_onenand_read_bufferram(struct 
> > > > mtd_info *mtd, int area,
> > > > if (buf >= high_memory) {
> > > > struct page *p1;
> > > >  
> > > > +   goto out_copy;
> > > > if (((size_t)buf & PAGE_MASK) !=
> > > > ((size_t)(buf + count - 1) & PAGE_MASK))
> > > > goto out_copy;  
> > > 
> > > I had the same problem here, and that snippet  helps here. ubiattach
> > > -p /dev/mtdX does not cause kernel oopses here anymore  
> > 
> > It seems reviving old code always comes at a price :-) Could you try
> > following patch, so far compile tested only?
> > (we'll need to do the same for omap2_onenand_write_bufferram, but
> > it sould be enough for testing purposes now)
> > 
> > diff --git a/drivers/mtd/nand/onenand/omap2.c 
> > b/drivers/mtd/nand/onenand/omap2.c
> > index 9c159f0dd9a6..04cefd7a6487 100644
> > --- a/drivers/mtd/nand/onenand/omap2.c
> > +++ b/drivers/mtd/nand/onenand/omap2.c
> > @@ -375,11 +375,12 @@ static int omap2_onenand_read_bufferram(struct 
> > mtd_info *mtd, int area,
> >  {
> > struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> > struct onenand_chip *this = mtd->priv;
> > +   struct device *dev = >pdev->dev;
> > dma_addr_t dma_src, dma_dst;
> > int bram_offset;
> > void *buf = (void *)buffer;
> > size_t xtra;
> > -   int ret;
> > +   int ret, page_dma = 0;
> >  
> > bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> > if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> > @@ -389,38 +390,43 @@ static int omap2_onenand_read_bufferram(struct 
> > mtd_info *mtd, int area,
> > if (in_interrupt() || oops_in_progress)
> > goto out_copy;
> >  
> > +   xtra = count & 3;
> > +   if (xtra) {
> > +   count -= xtra;
> > +   memcpy(buf + count, this->base + bram_offset + count, xtra);
> > +   }
> > +
> > +   /* Handle vmalloc address */
> > if (buf >= high_memory) {
> > -   struct page *p1;
> > +   struct page *page;
> >  
> > if (((size_t)buf & PAGE_MASK) !=
> > ((size_t)(buf + count - 1) & PAGE_MASK))
> > goto out_copy;
> > -   p1 = vmalloc_to_page(buf);
> > -   if (!p1)
> > +   page = vmalloc_to_page(buf);
> 
> Not sure this approach is safe on all archs: if the cache is VIVT or
> VIPT, you may have several entries pointing to the same phys page, and
> then, when dma_map_page() does its cache maintenance operations, it's
> only taking one of these entries into account.

Hmm, I used the same approach Samsung OneNAND driver does since commit
dcf08227e964a53a2cb39130b74842c7dcb6adde.
Both TI OMAP3630 and Samsung S5PC110 are using Cortex-A8 which
is VIPT. In that case samsung's driver code has the same problem.

> In other parts of the MTD subsystem, we tend to not do DMA on buffers
> that have been vmalloc-ed.
> 
> You can do something like
> 
>

Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

[Ladislav Michl]

Hi Boris,

On Wed, Apr 11, 2018 at 09:15:28AM +0200, Boris Brezillon wrote:
> Hi Ladislav,
> 
> On Wed, 11 Apr 2018 08:26:07 +0200
> Ladislav Michl  wrote:
> 
> > Hi Andreas,
> > 
> > On Wed, Apr 11, 2018 at 06:59:03AM +0200, Andreas Kemnade wrote:
> > > Hi Ladis,
> > > 
> > > On Tue, 10 Apr 2018 22:56:43 +0200
> > > Ladislav Michl  wrote:
> > >   
> > > > Hi Nikolaus,
> > > > 
> > > > On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote:  
> > > > > Hi,
> > > > > we just started testing the v4.16 kernel and found the
> > > > > device no longer bootable (works with v4.15). It turned
> > > > > out that there was a harmful modification somewhere between
> > > > > v4.15.0 and v4.16-rc1.
> > > > > 
> > > > > A git bisect points to this patch:
> > > > 
> > > > Well, that's a shame... However, this code is in production for several
> > > > months now, so could you, please put 'goto out_copy' if 'buf >= 
> > > > high_memory'
> > > > condition is met, ie:
> > > > --- a/drivers/mtd/nand/onenand/omap2.c
> > > > +++ b/drivers/mtd/nand/onenand/omap2.c
> > > > @@ -392,6 +392,7 @@ static int omap2_onenand_read_bufferram(struct 
> > > > mtd_info *mtd, int area,
> > > > if (buf >= high_memory) {
> > > > struct page *p1;
> > > >  
> > > > +   goto out_copy;
> > > > if (((size_t)buf & PAGE_MASK) !=
> > > > ((size_t)(buf + count - 1) & PAGE_MASK))
> > > > goto out_copy;  
> > > 
> > > I had the same problem here, and that snippet  helps here. ubiattach
> > > -p /dev/mtdX does not cause kernel oopses here anymore  
> > 
> > It seems reviving old code always comes at a price :-) Could you try
> > following patch, so far compile tested only?
> > (we'll need to do the same for omap2_onenand_write_bufferram, but
> > it sould be enough for testing purposes now)
> > 
> > diff --git a/drivers/mtd/nand/onenand/omap2.c 
> > b/drivers/mtd/nand/onenand/omap2.c
> > index 9c159f0dd9a6..04cefd7a6487 100644
> > --- a/drivers/mtd/nand/onenand/omap2.c
> > +++ b/drivers/mtd/nand/onenand/omap2.c
> > @@ -375,11 +375,12 @@ static int omap2_onenand_read_bufferram(struct 
> > mtd_info *mtd, int area,
> >  {
> > struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> > struct onenand_chip *this = mtd->priv;
> > +   struct device *dev = >pdev->dev;
> > dma_addr_t dma_src, dma_dst;
> > int bram_offset;
> > void *buf = (void *)buffer;
> > size_t xtra;
> > -   int ret;
> > +   int ret, page_dma = 0;
> >  
> > bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> > if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> > @@ -389,38 +390,43 @@ static int omap2_onenand_read_bufferram(struct 
> > mtd_info *mtd, int area,
> > if (in_interrupt() || oops_in_progress)
> > goto out_copy;
> >  
> > +   xtra = count & 3;
> > +   if (xtra) {
> > +   count -= xtra;
> > +   memcpy(buf + count, this->base + bram_offset + count, xtra);
> > +   }
> > +
> > +   /* Handle vmalloc address */
> > if (buf >= high_memory) {
> > -   struct page *p1;
> > +   struct page *page;
> >  
> > if (((size_t)buf & PAGE_MASK) !=
> > ((size_t)(buf + count - 1) & PAGE_MASK))
> > goto out_copy;
> > -   p1 = vmalloc_to_page(buf);
> > -   if (!p1)
> > +   page = vmalloc_to_page(buf);
> 
> Not sure this approach is safe on all archs: if the cache is VIVT or
> VIPT, you may have several entries pointing to the same phys page, and
> then, when dma_map_page() does its cache maintenance operations, it's
> only taking one of these entries into account.

Hmm, I used the same approach Samsung OneNAND driver does since commit
dcf08227e964a53a2cb39130b74842c7dcb6adde.
Both TI OMAP3630 and Samsung S5PC110 are using Cortex-A8 which
is VIPT. In that case samsung's driver code has the same problem.

> In other parts of the MTD subsystem, we tend to not do DMA on buffers
> that have been vmalloc-ed.
> 
> You can do something like
> 
>   if (virt_addr_valid(buf))
> 

Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

[Ladislav Michl]

Hi Andreas,

On Wed, Apr 11, 2018 at 06:59:03AM +0200, Andreas Kemnade wrote:
> Hi Ladis,
> 
> On Tue, 10 Apr 2018 22:56:43 +0200
> Ladislav Michl <la...@linux-mips.org> wrote:
> 
> > Hi Nikolaus,
> > 
> > On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote:
> > > Hi,
> > > we just started testing the v4.16 kernel and found the
> > > device no longer bootable (works with v4.15). It turned
> > > out that there was a harmful modification somewhere between
> > > v4.15.0 and v4.16-rc1.
> > > 
> > > A git bisect points to this patch:  
> > 
> > Well, that's a shame... However, this code is in production for several
> > months now, so could you, please put 'goto out_copy' if 'buf >= high_memory'
> > condition is met, ie:
> > --- a/drivers/mtd/nand/onenand/omap2.c
> > +++ b/drivers/mtd/nand/onenand/omap2.c
> > @@ -392,6 +392,7 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
> > *mtd, int area,
> > if (buf >= high_memory) {
> > struct page *p1;
> >  
> > +   goto out_copy;
> > if (((size_t)buf & PAGE_MASK) !=
> > ((size_t)(buf + count - 1) & PAGE_MASK))
> > goto out_copy;
> 
> I had the same problem here, and that snippet  helps here. ubiattach
> -p /dev/mtdX does not cause kernel oopses here anymore

It seems reviving old code always comes at a price :-) Could you try
following patch, so far compile tested only?
(we'll need to do the same for omap2_onenand_write_bufferram, but
it sould be enough for testing purposes now)

diff --git a/drivers/mtd/nand/onenand/omap2.c b/drivers/mtd/nand/onenand/omap2.c
index 9c159f0dd9a6..04cefd7a6487 100644
--- a/drivers/mtd/nand/onenand/omap2.c
+++ b/drivers/mtd/nand/onenand/omap2.c
@@ -375,11 +375,12 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
*mtd, int area,
 {
struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
struct onenand_chip *this = mtd->priv;
+   struct device *dev = >pdev->dev;
dma_addr_t dma_src, dma_dst;
int bram_offset;
void *buf = (void *)buffer;
size_t xtra;
-   int ret;
+   int ret, page_dma = 0;
 
bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
@@ -389,38 +390,43 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
*mtd, int area,
if (in_interrupt() || oops_in_progress)
goto out_copy;
 
+   xtra = count & 3;
+   if (xtra) {
+   count -= xtra;
+   memcpy(buf + count, this->base + bram_offset + count, xtra);
+   }
+
+   /* Handle vmalloc address */
if (buf >= high_memory) {
-   struct page *p1;
+   struct page *page;
 
if (((size_t)buf & PAGE_MASK) !=
((size_t)(buf + count - 1) & PAGE_MASK))
goto out_copy;
-   p1 = vmalloc_to_page(buf);
-   if (!p1)
+   page = vmalloc_to_page(buf);
+   if (!page)
goto out_copy;
-   buf = page_address(p1) + ((size_t)buf & ~PAGE_MASK);
-   }
-
-   xtra = count & 3;
-   if (xtra) {
-   count -= xtra;
-   memcpy(buf + count, this->base + bram_offset + count, xtra);
+   page_dma = 1;
+   dma_dst = dma_map_page(dev, page, (size_t) buf & ~PAGE_MASK,
+  count, DMA_FROM_DEVICE);
+   } else {
+   dma_dst = dma_map_single(dev, buf, count, DMA_FROM_DEVICE);
}
-
dma_src = c->phys_base + bram_offset;
-   dma_dst = dma_map_single(>pdev->dev, buf, count, DMA_FROM_DEVICE);
-   if (dma_mapping_error(>pdev->dev, dma_dst)) {
-   dev_err(>pdev->dev,
-   "Couldn't DMA map a %d byte buffer\n",
-   count);
+
+   if (dma_mapping_error(dev, dma_dst)) {
+   dev_err(dev, "Couldn't DMA map a %d byte buffer\n", count);
goto out_copy;
}
 
ret = omap2_onenand_dma_transfer(c, dma_src, dma_dst, count);
-   dma_unmap_single(>pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
+   if (page_dma)
+   dma_unmap_page(dev, dma_dst, count, DMA_FROM_DEVICE);
+   else
+   dma_unmap_single(dev, dma_dst, count, DMA_FROM_DEVICE);
 
if (ret) {
-   dev_err(>pdev->dev, "timeout waiting for DMA\n");
+   dev_err(dev, "timeout waiting for DMA\n");
goto out_copy;
}
 

Re: [Letux-kernel] [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

[Ladislav Michl]

Hi Andreas,

On Wed, Apr 11, 2018 at 06:59:03AM +0200, Andreas Kemnade wrote:
> Hi Ladis,
> 
> On Tue, 10 Apr 2018 22:56:43 +0200
> Ladislav Michl  wrote:
> 
> > Hi Nikolaus,
> > 
> > On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote:
> > > Hi,
> > > we just started testing the v4.16 kernel and found the
> > > device no longer bootable (works with v4.15). It turned
> > > out that there was a harmful modification somewhere between
> > > v4.15.0 and v4.16-rc1.
> > > 
> > > A git bisect points to this patch:  
> > 
> > Well, that's a shame... However, this code is in production for several
> > months now, so could you, please put 'goto out_copy' if 'buf >= high_memory'
> > condition is met, ie:
> > --- a/drivers/mtd/nand/onenand/omap2.c
> > +++ b/drivers/mtd/nand/onenand/omap2.c
> > @@ -392,6 +392,7 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
> > *mtd, int area,
> > if (buf >= high_memory) {
> > struct page *p1;
> >  
> > +   goto out_copy;
> > if (((size_t)buf & PAGE_MASK) !=
> > ((size_t)(buf + count - 1) & PAGE_MASK))
> > goto out_copy;
> 
> I had the same problem here, and that snippet  helps here. ubiattach
> -p /dev/mtdX does not cause kernel oopses here anymore

It seems reviving old code always comes at a price :-) Could you try
following patch, so far compile tested only?
(we'll need to do the same for omap2_onenand_write_bufferram, but
it sould be enough for testing purposes now)

diff --git a/drivers/mtd/nand/onenand/omap2.c b/drivers/mtd/nand/onenand/omap2.c
index 9c159f0dd9a6..04cefd7a6487 100644
--- a/drivers/mtd/nand/onenand/omap2.c
+++ b/drivers/mtd/nand/onenand/omap2.c
@@ -375,11 +375,12 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
*mtd, int area,
 {
struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
struct onenand_chip *this = mtd->priv;
+   struct device *dev = >pdev->dev;
dma_addr_t dma_src, dma_dst;
int bram_offset;
void *buf = (void *)buffer;
size_t xtra;
-   int ret;
+   int ret, page_dma = 0;
 
bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
@@ -389,38 +390,43 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
*mtd, int area,
if (in_interrupt() || oops_in_progress)
goto out_copy;
 
+   xtra = count & 3;
+   if (xtra) {
+   count -= xtra;
+   memcpy(buf + count, this->base + bram_offset + count, xtra);
+   }
+
+   /* Handle vmalloc address */
if (buf >= high_memory) {
-   struct page *p1;
+   struct page *page;
 
if (((size_t)buf & PAGE_MASK) !=
((size_t)(buf + count - 1) & PAGE_MASK))
goto out_copy;
-   p1 = vmalloc_to_page(buf);
-   if (!p1)
+   page = vmalloc_to_page(buf);
+   if (!page)
goto out_copy;
-   buf = page_address(p1) + ((size_t)buf & ~PAGE_MASK);
-   }
-
-   xtra = count & 3;
-   if (xtra) {
-   count -= xtra;
-   memcpy(buf + count, this->base + bram_offset + count, xtra);
+   page_dma = 1;
+   dma_dst = dma_map_page(dev, page, (size_t) buf & ~PAGE_MASK,
+  count, DMA_FROM_DEVICE);
+   } else {
+   dma_dst = dma_map_single(dev, buf, count, DMA_FROM_DEVICE);
}
-
dma_src = c->phys_base + bram_offset;
-   dma_dst = dma_map_single(>pdev->dev, buf, count, DMA_FROM_DEVICE);
-   if (dma_mapping_error(>pdev->dev, dma_dst)) {
-   dev_err(>pdev->dev,
-   "Couldn't DMA map a %d byte buffer\n",
-   count);
+
+   if (dma_mapping_error(dev, dma_dst)) {
+   dev_err(dev, "Couldn't DMA map a %d byte buffer\n", count);
goto out_copy;
}
 
ret = omap2_onenand_dma_transfer(c, dma_src, dma_dst, count);
-   dma_unmap_single(>pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
+   if (page_dma)
+   dma_unmap_page(dev, dma_dst, count, DMA_FROM_DEVICE);
+   else
+   dma_unmap_single(dev, dma_dst, count, DMA_FROM_DEVICE);
 
if (ret) {
-   dev_err(>pdev->dev, "timeout waiting for DMA\n");
+   dev_err(dev, "timeout waiting for DMA\n");
goto out_copy;
}
 

Re: [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

[Ladislav Michl]

Hi Nikolaus,

On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote:
> Hi,
> we just started testing the v4.16 kernel and found the
> device no longer bootable (works with v4.15). It turned
> out that there was a harmful modification somewhere between
> v4.15.0 and v4.16-rc1.
> 
> A git bisect points to this patch:

Well, that's a shame... However, this code is in production for several
months now, so could you, please put 'goto out_copy' if 'buf >= high_memory'
condition is met, ie:
--- a/drivers/mtd/nand/onenand/omap2.c
+++ b/drivers/mtd/nand/onenand/omap2.c
@@ -392,6 +392,7 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
*mtd, int area,
if (buf >= high_memory) {
struct page *p1;
 
+   goto out_copy;
if (((size_t)buf & PAGE_MASK) !=
((size_t)(buf + count - 1) & PAGE_MASK))
goto out_copy;
and in case it does not help put the same goto at the very beginning of
omap2_onenand_read_bufferram function and report result?

Thank you for cooperation,
ladis

> commit bdaca9345d41fd9420995469d27603ea62054691
> Author: Ladislav Michl <la...@linux-mips.org>
> Date:   Fri Jan 12 14:16:57 2018 +0100
> 
>mtd: onenand: omap2: Decouple DMA enabling from INT pin availability
> 
>INT pin (gpio_irq) is not really needed for DMA but only for notification
>when a command that needs wait has completed. DMA memcpy can be still used
>even without gpio_irq available, so enable it unconditionally.
> 
>Signed-off-by: Ladislav Michl <la...@linux-mips.org>
>Reviewed-by: Peter Ujfalusi <peter.ujfal...@ti.com>
>Tested-by: Tony Lindgren <t...@atomide.com>
>Tested-by: Aaro Koskinen <aaro.koski...@iki.fi>
>Acked-by: Roger Quadros <rog...@ti.com>
>Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> 
> Kernel panic log is attached which indeed indicates a DMA problem.
> 
> Note that we have added compatible = "ti,omap2-onenand";
> 
> Any suggestions, fixes?
> 
> BR and thanks,
> Nikolaus Schaller
> 
> 
> 
> ## Booting kernel from Legacy Image at 8200 ...
>Image Name:   Linux-4.16.0-letux+
>Image Type:   ARM Linux Kernel Image (uncompressed)
>Data Size:4456744 Bytes = 4.3 MiB
>Load Address: 80008000
>Entry Point:  80008000
>Verifying Checksum ... OK
> ## Flattened Device Tree blob at 81c0
>Booting using the fdt blob at 0x81c0
>Loading Kernel Image ... OK
>Using Device Tree in place at 81c0, end 81c14a1e
> 
> Starting kernel ...
> 
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Linux version 4.16.0-letux+ (hns@iMac.local) (gcc version 
> 4.9.2 (GCC)) #2187 SMP PREEMPT Tue Apr 10 16:23:45 CEST 2018
> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache
> [0.00] OF: fdt: Machine model: Goldelico GTA04A5/Letux 2804
> [0.00] debug: ignoring loglevel setting.
> [0.00] Memory policy: Data cache writeback
> [0.00] cma: Reserved 16 MiB at 0xbe80
> [0.00] On node 0 totalpages: 261632
> [0.00]   Normal zone: 1536 pages used for memmap
> [0.00]   Normal zone: 0 pages reserved
> [0.00]   Normal zone: 196608 pages, LIFO batch:31
> [0.00]   HighMem zone: 65024 pages, LIFO batch:15
> [0.00] CPU: All CPU(s) started in SVC mode.
> [0.00] OMAP3630/DM3730 ES1.2 (l2cache iva sgx neon isp 192mhz_clk)
> [0.00] random: fast init done
> [0.00] percpu: Embedded 17 pages/cpu @(ptrval) s39744 r8192 d21696 
> u69632
> [0.00] pcpu-alloc: s39744 r8192 d21696 u69632 alloc=17*4096
> [0.00] pcpu-alloc: [0] 0 
> [0.00] Built 1 zonelists, mobility grouping on.  Total pages: 260096
> [0.00] Kernel command line: console=ttyO2,115200n8 
> mtdoops.mtddev=omap2.nand ubi.mtd=4 root=/dev/mmcblk0p1 rw 
> rootfstype=ext4,ext3 rootwait console=ttyO2,115200n8 vram=12M 
> omapfb.vram=0:8M,1:4M omapfb.rotate_type=0 omapdss.def_disp=lcd rootwait 
> twl4030_charger.allow_usb=1 log_buf_len=8M ignore_loglevel earlyprintk
> [0.00] log_buf_len: 8388608 bytes
> [0.00] early log buf free: 63924(97%)
> [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 
> bytes)
> [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> [0.00] Memory: 1002524K/1046528K available (6169K kernel code, 626K 
> rwdata, 1660K rodata, 1024K init, 218K bss, 27620K reserved, 16384K 
> cma-reserved, 243712K highmem)
> [   

Re: [Bug]: mtd: onenand: omap2plus: kernel panic with OneNAND on OMAP3 (DM3730) device GTA04A5

[Ladislav Michl]

Hi Nikolaus,

On Tue, Apr 10, 2018 at 06:25:17PM +0200, H. Nikolaus Schaller wrote:
> Hi,
> we just started testing the v4.16 kernel and found the
> device no longer bootable (works with v4.15). It turned
> out that there was a harmful modification somewhere between
> v4.15.0 and v4.16-rc1.
> 
> A git bisect points to this patch:

Well, that's a shame... However, this code is in production for several
months now, so could you, please put 'goto out_copy' if 'buf >= high_memory'
condition is met, ie:
--- a/drivers/mtd/nand/onenand/omap2.c
+++ b/drivers/mtd/nand/onenand/omap2.c
@@ -392,6 +392,7 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
*mtd, int area,
if (buf >= high_memory) {
struct page *p1;
 
+   goto out_copy;
if (((size_t)buf & PAGE_MASK) !=
((size_t)(buf + count - 1) & PAGE_MASK))
goto out_copy;
and in case it does not help put the same goto at the very beginning of
omap2_onenand_read_bufferram function and report result?

Thank you for cooperation,
ladis

> commit bdaca9345d41fd9420995469d27603ea62054691
> Author: Ladislav Michl 
> Date:   Fri Jan 12 14:16:57 2018 +0100
> 
>mtd: onenand: omap2: Decouple DMA enabling from INT pin availability
> 
>INT pin (gpio_irq) is not really needed for DMA but only for notification
>when a command that needs wait has completed. DMA memcpy can be still used
>even without gpio_irq available, so enable it unconditionally.
> 
>Signed-off-by: Ladislav Michl 
>Reviewed-by: Peter Ujfalusi 
>Tested-by: Tony Lindgren 
>Tested-by: Aaro Koskinen 
>Acked-by: Roger Quadros 
>Signed-off-by: Boris Brezillon 
> 
> Kernel panic log is attached which indeed indicates a DMA problem.
> 
> Note that we have added compatible = "ti,omap2-onenand";
> 
> Any suggestions, fixes?
> 
> BR and thanks,
> Nikolaus Schaller
> 
> 
> 
> ## Booting kernel from Legacy Image at 8200 ...
>Image Name:   Linux-4.16.0-letux+
>Image Type:   ARM Linux Kernel Image (uncompressed)
>Data Size:4456744 Bytes = 4.3 MiB
>Load Address: 80008000
>Entry Point:  80008000
>Verifying Checksum ... OK
> ## Flattened Device Tree blob at 81c0
>Booting using the fdt blob at 0x81c0
>Loading Kernel Image ... OK
>Using Device Tree in place at 81c0, end 81c14a1e
> 
> Starting kernel ...
> 
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Linux version 4.16.0-letux+ (hns@iMac.local) (gcc version 
> 4.9.2 (GCC)) #2187 SMP PREEMPT Tue Apr 10 16:23:45 CEST 2018
> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache
> [0.00] OF: fdt: Machine model: Goldelico GTA04A5/Letux 2804
> [0.00] debug: ignoring loglevel setting.
> [0.00] Memory policy: Data cache writeback
> [0.00] cma: Reserved 16 MiB at 0xbe80
> [0.00] On node 0 totalpages: 261632
> [0.00]   Normal zone: 1536 pages used for memmap
> [0.00]   Normal zone: 0 pages reserved
> [0.00]   Normal zone: 196608 pages, LIFO batch:31
> [0.00]   HighMem zone: 65024 pages, LIFO batch:15
> [0.00] CPU: All CPU(s) started in SVC mode.
> [0.00] OMAP3630/DM3730 ES1.2 (l2cache iva sgx neon isp 192mhz_clk)
> [0.00] random: fast init done
> [0.00] percpu: Embedded 17 pages/cpu @(ptrval) s39744 r8192 d21696 
> u69632
> [0.00] pcpu-alloc: s39744 r8192 d21696 u69632 alloc=17*4096
> [0.00] pcpu-alloc: [0] 0 
> [0.00] Built 1 zonelists, mobility grouping on.  Total pages: 260096
> [0.00] Kernel command line: console=ttyO2,115200n8 
> mtdoops.mtddev=omap2.nand ubi.mtd=4 root=/dev/mmcblk0p1 rw 
> rootfstype=ext4,ext3 rootwait console=ttyO2,115200n8 vram=12M 
> omapfb.vram=0:8M,1:4M omapfb.rotate_type=0 omapdss.def_disp=lcd rootwait 
> twl4030_charger.allow_usb=1 log_buf_len=8M ignore_loglevel earlyprintk
> [0.00] log_buf_len: 8388608 bytes
> [0.00] early log buf free: 63924(97%)
> [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 
> bytes)
> [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> [0.00] Memory: 1002524K/1046528K available (6169K kernel code, 626K 
> rwdata, 1660K rodata, 1024K init, 218K bss, 27620K reserved, 16384K 
> cma-reserved, 243712K highmem)
> [0.00] Virtual kernel memory layout:
> [0.00] vector  : 0x - 0x1000   (   4 kB)
> [0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
> [0.00] 

Re: [alsa-devel] [PATCH] ASoC: atmel_ssc_dai: fix spelling mistake: "Stoping" -> "Stopping"

[Ladislav Michl]

On Wed, Apr 04, 2018 at 11:41:23AM +0100, Colin Ian King wrote:
> On 04/04/18 11:24, Dan Carpenter wrote:
> > On Tue, Apr 03, 2018 at 03:45:40PM +0200, Ladislav Michl wrote:
> >> On Fri, Mar 30, 2018 at 04:44:20PM +0100, Colin King wrote:
> >>> From: Colin Ian King <colin.k...@canonical.com>
> >>
> >> Hello Colin,
> >>
> >>> Trivial fix to spelling mistake in pr_debug message text
> >>
> >> would you mind making this patch a bit less non-trivial and
> >> change pr_debug to dev_dbg dropping Atmel_ssc_dai prefix?
> >>
> >> Thank you.
> >>
> > 
> > Trivial patches should just be trivial instead of evolving into a thread
> > that lasts for days.
> 
> Yep, this feels like this scenario for sure.

And this scenario happens because I wanted to avoid all that work preparing
trivial patch. In the other words, this thread could be few mails shorter
if anyone else took a chance ;-)

[...]

> > space character?  And I think about it for 10 minutes and then delete my
> > patch because it's too much hassle to deal with for something small.

...leading into many small glitches never polished...

> Same here. Hence stuff never gets fixed.

For sure, hassle with sending a patch and crediting everyone who contributed
properly is order of magnitude more time consuming than preparing patch itself.

So here's my last contribution to this painful thread. If you do not like it,
it's your turn :)

(and it'll be needed as Mark does not like patches being sended this way,
oh well, whoever sent original patch should first figure out why driver
outputs debug message just after warning one - so the simplest fix would
be just deleting that line)

-- >8 -- 

From: Joe Perches <j...@perches.com>
Subject: [PATCH] ASoC: atmel_ssc_dai: Replace pr_debug with dev_dbg

Use dev_dbg for debug output, remove registration error message
as every user of atmel_ssc_set_audio prints its own error.

Signed-off-by: Joe Perches <j...@perches.com>
Signed-off-by: Ladislav Michl <la...@linux-mips.org>
[Colin Ian King: fix spelling mistake: "Stoping" -> "Stopping"]
Signed-off-by: Colin Ian King <colin.k...@canonical.com>
---
 sound/soc/atmel/atmel_ssc_dai.c | 42 +
 1 file changed, 17 insertions(+), 25 deletions(-)

diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index a1e2c5682dcd..45c4730e9939 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -291,11 +291,10 @@ static int atmel_ssc_startup(struct snd_pcm_substream 
*substream,
int dir, dir_mask;
int ret;
 
-   pr_debug("atmel_ssc_startup: SSC_SR=0x%x\n",
-   ssc_readl(ssc_p->ssc->regs, SR));
+   dev_dbg(dai->dev, "SSC_SR=0x%x\n", ssc_readl(ssc_p->ssc->regs, SR));
 
/* Enable PMC peripheral clock for this SSC */
-   pr_debug("atmel_ssc_dai: Starting clock\n");
+   dev_dbg(dai->dev, "Starting clock\n");
clk_enable(ssc_p->ssc->clk);
ssc_p->mck_rate = clk_get_rate(ssc_p->ssc->clk);
 
@@ -385,7 +384,7 @@ static void atmel_ssc_shutdown(struct snd_pcm_substream 
*substream,
spin_unlock_irq(_p->lock);
 
/* Shutdown the SSC clock. */
-   pr_debug("atmel_ssc_dai: Stopping clock\n");
+   dev_dbg(dai->dev, "Stopping clock\n");
clk_disable(ssc_p->ssc->clk);
 }
 
@@ -794,13 +793,12 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream 
*substream,
break;
 
default:
-   printk(KERN_WARNING "atmel_ssc_dai: unsupported DAI format 
0x%x\n",
-   ssc_p->daifmt);
+   dev_warn(dai->dev, "unsupported DAI format 0x%x\n",
+ssc_p->daifmt);
return -EINVAL;
}
-   pr_debug("atmel_ssc_hw_params: "
-   "RCMR=%08x RFMR=%08x TCMR=%08x TFMR=%08x\n",
-   rcmr, rfmr, tcmr, tfmr);
+   dev_dbg(dai->dev, "RCMR=%08x RFMR=%08x TCMR=%08x TFMR=%08x\n",
+   rcmr, rfmr, tcmr, tfmr);
 
if (!ssc_p->initialized) {
if (!ssc_p->ssc->pdata->use_dma) {
@@ -818,9 +816,9 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream 
*substream,
ret = request_irq(ssc_p->ssc->irq, atmel_ssc_interrupt, 0,
ssc_p->name, ssc_p);
if (ret < 0) {
-   printk(KERN_WARNING
-   "atmel_ssc_dai: request_irq failure\n");
-   pr_debug("Atmel_ssc_dai: Stoping clock\n");
+   dev_warn(dai->dev,
+  

Re: [alsa-devel] [PATCH] ASoC: atmel_ssc_dai: fix spelling mistake: "Stoping" -> "Stopping"

[Ladislav Michl]

On Wed, Apr 04, 2018 at 11:41:23AM +0100, Colin Ian King wrote:
> On 04/04/18 11:24, Dan Carpenter wrote:
> > On Tue, Apr 03, 2018 at 03:45:40PM +0200, Ladislav Michl wrote:
> >> On Fri, Mar 30, 2018 at 04:44:20PM +0100, Colin King wrote:
> >>> From: Colin Ian King 
> >>
> >> Hello Colin,
> >>
> >>> Trivial fix to spelling mistake in pr_debug message text
> >>
> >> would you mind making this patch a bit less non-trivial and
> >> change pr_debug to dev_dbg dropping Atmel_ssc_dai prefix?
> >>
> >> Thank you.
> >>
> > 
> > Trivial patches should just be trivial instead of evolving into a thread
> > that lasts for days.
> 
> Yep, this feels like this scenario for sure.

And this scenario happens because I wanted to avoid all that work preparing
trivial patch. In the other words, this thread could be few mails shorter
if anyone else took a chance ;-)

[...]

> > space character?  And I think about it for 10 minutes and then delete my
> > patch because it's too much hassle to deal with for something small.

...leading into many small glitches never polished...

> Same here. Hence stuff never gets fixed.

For sure, hassle with sending a patch and crediting everyone who contributed
properly is order of magnitude more time consuming than preparing patch itself.

So here's my last contribution to this painful thread. If you do not like it,
it's your turn :)

(and it'll be needed as Mark does not like patches being sended this way,
oh well, whoever sent original patch should first figure out why driver
outputs debug message just after warning one - so the simplest fix would
be just deleting that line)

-- >8 -- 

From: Joe Perches 
Subject: [PATCH] ASoC: atmel_ssc_dai: Replace pr_debug with dev_dbg

Use dev_dbg for debug output, remove registration error message
as every user of atmel_ssc_set_audio prints its own error.

Signed-off-by: Joe Perches 
Signed-off-by: Ladislav Michl 
[Colin Ian King: fix spelling mistake: "Stoping" -> "Stopping"]
Signed-off-by: Colin Ian King 
---
 sound/soc/atmel/atmel_ssc_dai.c | 42 +
 1 file changed, 17 insertions(+), 25 deletions(-)

diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index a1e2c5682dcd..45c4730e9939 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -291,11 +291,10 @@ static int atmel_ssc_startup(struct snd_pcm_substream 
*substream,
int dir, dir_mask;
int ret;
 
-   pr_debug("atmel_ssc_startup: SSC_SR=0x%x\n",
-   ssc_readl(ssc_p->ssc->regs, SR));
+   dev_dbg(dai->dev, "SSC_SR=0x%x\n", ssc_readl(ssc_p->ssc->regs, SR));
 
/* Enable PMC peripheral clock for this SSC */
-   pr_debug("atmel_ssc_dai: Starting clock\n");
+   dev_dbg(dai->dev, "Starting clock\n");
clk_enable(ssc_p->ssc->clk);
ssc_p->mck_rate = clk_get_rate(ssc_p->ssc->clk);
 
@@ -385,7 +384,7 @@ static void atmel_ssc_shutdown(struct snd_pcm_substream 
*substream,
spin_unlock_irq(_p->lock);
 
/* Shutdown the SSC clock. */
-   pr_debug("atmel_ssc_dai: Stopping clock\n");
+   dev_dbg(dai->dev, "Stopping clock\n");
clk_disable(ssc_p->ssc->clk);
 }
 
@@ -794,13 +793,12 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream 
*substream,
break;
 
default:
-   printk(KERN_WARNING "atmel_ssc_dai: unsupported DAI format 
0x%x\n",
-   ssc_p->daifmt);
+   dev_warn(dai->dev, "unsupported DAI format 0x%x\n",
+ssc_p->daifmt);
return -EINVAL;
}
-   pr_debug("atmel_ssc_hw_params: "
-   "RCMR=%08x RFMR=%08x TCMR=%08x TFMR=%08x\n",
-   rcmr, rfmr, tcmr, tfmr);
+   dev_dbg(dai->dev, "RCMR=%08x RFMR=%08x TCMR=%08x TFMR=%08x\n",
+   rcmr, rfmr, tcmr, tfmr);
 
if (!ssc_p->initialized) {
if (!ssc_p->ssc->pdata->use_dma) {
@@ -818,9 +816,9 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream 
*substream,
ret = request_irq(ssc_p->ssc->irq, atmel_ssc_interrupt, 0,
ssc_p->name, ssc_p);
if (ret < 0) {
-   printk(KERN_WARNING
-   "atmel_ssc_dai: request_irq failure\n");
-   pr_debug("Atmel_ssc_dai: Stoping clock\n");
+   dev_warn(dai->dev,
+"unable to request irq (%d), stopping clock\n",
+ret);
   

Re: [alsa-devel] [PATCH] ASoC: atmel_ssc_dai: fix spelling mistake: "Stoping" -> "Stopping"

[Ladislav Michl]

On Tue, Apr 03, 2018 at 11:17:03AM -0700, Joe Perches wrote:
> On Tue, 2018-04-03 at 19:30 +0200, Ladislav Michl wrote:
> > On Tue, Apr 03, 2018 at 08:49:57AM -0700, Joe Perches wrote:
> > > On Tue, 2018-04-03 at 15:45 +0200, Ladislav Michl wrote:
> > > > On Fri, Mar 30, 2018 at 04:44:20PM +0100, Colin King wrote:
> > > > > From: Colin Ian King <colin.k...@canonical.com>
> > > > 
> > > > Hello Colin,
> > > > 
> > > > > Trivial fix to spelling mistake in pr_debug message text
> > > > 
> > > > would you mind making this patch a bit less non-trivial and
> > > > change pr_debug to dev_dbg dropping Atmel_ssc_dai prefix?
> > > 
> > > Presumably, then all the pr_ calls should be changed.
> > Yes, that's what non-trivial means here :)
> 
> More useful would be less specific originally.
> 
> > > diff --git a/sound/soc/atmel/atmel_ssc_dai.c 
> > > b/sound/soc/atmel/atmel_ssc_dai.c
> []
> > > @@ -1050,21 +1047,18 @@ static void asoc_ssc_exit(struct device *dev)
> > >  int atmel_ssc_set_audio(int ssc_id)
> > >  {
> > >   struct ssc_device *ssc;
> > > - int ret;
> > >  
> > >   /* If we can grab the SSC briefly to parent the DAI device off it */
> > >   ssc = ssc_request(ssc_id);
> > >   if (IS_ERR(ssc)) {
> > >   pr_err("Unable to parent ASoC SSC DAI on SSC: %ld\n",
> > > - PTR_ERR(ssc));
> > > +PTR_ERR(ssc));
> > 
> > Well, these are usefull, but unrelated changes. But while there, above
> > pr_error deserves to be replaced with dev_err as well.
> 
> No  dai device.

As all call sites are already providing error message, so what about just
removing this one completely?

Re: [alsa-devel] [PATCH] ASoC: atmel_ssc_dai: fix spelling mistake: "Stoping" -> "Stopping"

[Ladislav Michl]

On Tue, Apr 03, 2018 at 11:17:03AM -0700, Joe Perches wrote:
> On Tue, 2018-04-03 at 19:30 +0200, Ladislav Michl wrote:
> > On Tue, Apr 03, 2018 at 08:49:57AM -0700, Joe Perches wrote:
> > > On Tue, 2018-04-03 at 15:45 +0200, Ladislav Michl wrote:
> > > > On Fri, Mar 30, 2018 at 04:44:20PM +0100, Colin King wrote:
> > > > > From: Colin Ian King 
> > > > 
> > > > Hello Colin,
> > > > 
> > > > > Trivial fix to spelling mistake in pr_debug message text
> > > > 
> > > > would you mind making this patch a bit less non-trivial and
> > > > change pr_debug to dev_dbg dropping Atmel_ssc_dai prefix?
> > > 
> > > Presumably, then all the pr_ calls should be changed.
> > Yes, that's what non-trivial means here :)
> 
> More useful would be less specific originally.
> 
> > > diff --git a/sound/soc/atmel/atmel_ssc_dai.c 
> > > b/sound/soc/atmel/atmel_ssc_dai.c
> []
> > > @@ -1050,21 +1047,18 @@ static void asoc_ssc_exit(struct device *dev)
> > >  int atmel_ssc_set_audio(int ssc_id)
> > >  {
> > >   struct ssc_device *ssc;
> > > - int ret;
> > >  
> > >   /* If we can grab the SSC briefly to parent the DAI device off it */
> > >   ssc = ssc_request(ssc_id);
> > >   if (IS_ERR(ssc)) {
> > >   pr_err("Unable to parent ASoC SSC DAI on SSC: %ld\n",
> > > - PTR_ERR(ssc));
> > > +PTR_ERR(ssc));
> > 
> > Well, these are usefull, but unrelated changes. But while there, above
> > pr_error deserves to be replaced with dev_err as well.
> 
> No  dai device.

As all call sites are already providing error message, so what about just
removing this one completely?

Re: [alsa-devel] [PATCH] ASoC: atmel_ssc_dai: fix spelling mistake: "Stoping" -> "Stopping"

[Ladislav Michl]

On Tue, Apr 03, 2018 at 08:49:57AM -0700, Joe Perches wrote:
> On Tue, 2018-04-03 at 15:45 +0200, Ladislav Michl wrote:
> > On Fri, Mar 30, 2018 at 04:44:20PM +0100, Colin King wrote:
> > > From: Colin Ian King <colin.k...@canonical.com>
> > 
> > Hello Colin,
> > 
> > > Trivial fix to spelling mistake in pr_debug message text
> > 
> > would you mind making this patch a bit less non-trivial and
> > change pr_debug to dev_dbg dropping Atmel_ssc_dai prefix?
> 
> Presumably, then all the pr_ calls should be changed.

Yes, that's what non-trivial means here :)

> Something like:
> ---
>  sound/soc/atmel/atmel_ssc_dai.c | 38 --
>  1 file changed, 16 insertions(+), 22 deletions(-)
> 
> diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
> index a1e2c5682dcd..594228156b2d 100644
> --- a/sound/soc/atmel/atmel_ssc_dai.c
> +++ b/sound/soc/atmel/atmel_ssc_dai.c
> @@ -291,11 +291,10 @@ static int atmel_ssc_startup(struct snd_pcm_substream 
> *substream,
>   int dir, dir_mask;
>   int ret;
>  
> - pr_debug("atmel_ssc_startup: SSC_SR=0x%x\n",
> - ssc_readl(ssc_p->ssc->regs, SR));
> + dev_dbg(dai->dev, "SSC_SR=0x%x\n", ssc_readl(ssc_p->ssc->regs, SR));
>  
>   /* Enable PMC peripheral clock for this SSC */
> - pr_debug("atmel_ssc_dai: Starting clock\n");
> + dev_dbg(dai->dev, "Starting clock\n");
>   clk_enable(ssc_p->ssc->clk);
>   ssc_p->mck_rate = clk_get_rate(ssc_p->ssc->clk);
>  
> @@ -385,7 +384,7 @@ static void atmel_ssc_shutdown(struct snd_pcm_substream 
> *substream,
>   spin_unlock_irq(_p->lock);
>  
>   /* Shutdown the SSC clock. */
> - pr_debug("atmel_ssc_dai: Stopping clock\n");
> + dev_dbg(dai->dev, "Stopping clock\n");
>   clk_disable(ssc_p->ssc->clk);
>  }
>  
> @@ -794,13 +793,12 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream 
> *substream,
>   break;
>  
>   default:
> - printk(KERN_WARNING "atmel_ssc_dai: unsupported DAI format 
> 0x%x\n",
> - ssc_p->daifmt);
> + dev_warn(dai->dev, "unsupported DAI format 0x%x\n",
> +  ssc_p->daifmt);
>   return -EINVAL;
>   }
> - pr_debug("atmel_ssc_hw_params: "
> - "RCMR=%08x RFMR=%08x TCMR=%08x TFMR=%08x\n",
> - rcmr, rfmr, tcmr, tfmr);
> + dev_dbg(dai->dev, "RCMR=%08x RFMR=%08x TCMR=%08x TFMR=%08x\n",
> + rcmr, rfmr, tcmr, tfmr);
>  
>   if (!ssc_p->initialized) {
>   if (!ssc_p->ssc->pdata->use_dma) {
> @@ -818,9 +816,8 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream 
> *substream,
>   ret = request_irq(ssc_p->ssc->irq, atmel_ssc_interrupt, 0,
>   ssc_p->name, ssc_p);
>   if (ret < 0) {
> - printk(KERN_WARNING
> - "atmel_ssc_dai: request_irq failure\n");
> - pr_debug("Atmel_ssc_dai: Stoping clock\n");
> + dev_warn(dai->dev, "request_irq failure\n");
> + dev_dbg(dai->dev, "Stopping clock\n");
>   clk_disable(ssc_p->ssc->clk);
>   return ret;
>   }
> @@ -839,7 +836,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream 
> *substream,
>   ssc_writel(ssc_p->ssc->regs, TCMR, tcmr);
>   ssc_writel(ssc_p->ssc->regs, TFMR, tfmr);
>  
> - pr_debug("atmel_ssc_dai,hw_params: SSC initialized\n");
> + dev_dbg(dai->dev, "SSC initialized\n");
>   return 0;
>  }
>  
> @@ -862,9 +859,9 @@ static int atmel_ssc_prepare(struct snd_pcm_substream 
> *substream,
>   ssc_writel(ssc_p->ssc->regs, CR, dma_params->mask->ssc_disable);
>   ssc_writel(ssc_p->ssc->regs, IDR, dma_params->mask->ssc_error);
>  
> - pr_debug("%s enabled SSC_SR=0x%08x\n",
> - dir ? "receive" : "transmit",
> - ssc_readl(ssc_p->ssc->regs, SR));
> + dev_dbg(dai->dev, "%s enabled SSC_SR=0x%08x\n",
> + dir ? "receive" : "transmit",
> + ssc_readl(ssc_p->ssc->regs, SR));
>   return 0;
>  }
>  
> @@ -1050,21 +1047,18 @@ static void asoc_ssc_exit(struct device 

Re: [alsa-devel] [PATCH] ASoC: atmel_ssc_dai: fix spelling mistake: "Stoping" -> "Stopping"

[Ladislav Michl]

On Tue, Apr 03, 2018 at 08:49:57AM -0700, Joe Perches wrote:
> On Tue, 2018-04-03 at 15:45 +0200, Ladislav Michl wrote:
> > On Fri, Mar 30, 2018 at 04:44:20PM +0100, Colin King wrote:
> > > From: Colin Ian King 
> > 
> > Hello Colin,
> > 
> > > Trivial fix to spelling mistake in pr_debug message text
> > 
> > would you mind making this patch a bit less non-trivial and
> > change pr_debug to dev_dbg dropping Atmel_ssc_dai prefix?
> 
> Presumably, then all the pr_ calls should be changed.

Yes, that's what non-trivial means here :)

> Something like:
> ---
>  sound/soc/atmel/atmel_ssc_dai.c | 38 --
>  1 file changed, 16 insertions(+), 22 deletions(-)
> 
> diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
> index a1e2c5682dcd..594228156b2d 100644
> --- a/sound/soc/atmel/atmel_ssc_dai.c
> +++ b/sound/soc/atmel/atmel_ssc_dai.c
> @@ -291,11 +291,10 @@ static int atmel_ssc_startup(struct snd_pcm_substream 
> *substream,
>   int dir, dir_mask;
>   int ret;
>  
> - pr_debug("atmel_ssc_startup: SSC_SR=0x%x\n",
> - ssc_readl(ssc_p->ssc->regs, SR));
> + dev_dbg(dai->dev, "SSC_SR=0x%x\n", ssc_readl(ssc_p->ssc->regs, SR));
>  
>   /* Enable PMC peripheral clock for this SSC */
> - pr_debug("atmel_ssc_dai: Starting clock\n");
> + dev_dbg(dai->dev, "Starting clock\n");
>   clk_enable(ssc_p->ssc->clk);
>   ssc_p->mck_rate = clk_get_rate(ssc_p->ssc->clk);
>  
> @@ -385,7 +384,7 @@ static void atmel_ssc_shutdown(struct snd_pcm_substream 
> *substream,
>   spin_unlock_irq(_p->lock);
>  
>   /* Shutdown the SSC clock. */
> - pr_debug("atmel_ssc_dai: Stopping clock\n");
> + dev_dbg(dai->dev, "Stopping clock\n");
>   clk_disable(ssc_p->ssc->clk);
>  }
>  
> @@ -794,13 +793,12 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream 
> *substream,
>   break;
>  
>   default:
> - printk(KERN_WARNING "atmel_ssc_dai: unsupported DAI format 
> 0x%x\n",
> - ssc_p->daifmt);
> + dev_warn(dai->dev, "unsupported DAI format 0x%x\n",
> +  ssc_p->daifmt);
>   return -EINVAL;
>   }
> - pr_debug("atmel_ssc_hw_params: "
> - "RCMR=%08x RFMR=%08x TCMR=%08x TFMR=%08x\n",
> - rcmr, rfmr, tcmr, tfmr);
> + dev_dbg(dai->dev, "RCMR=%08x RFMR=%08x TCMR=%08x TFMR=%08x\n",
> + rcmr, rfmr, tcmr, tfmr);
>  
>   if (!ssc_p->initialized) {
>   if (!ssc_p->ssc->pdata->use_dma) {
> @@ -818,9 +816,8 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream 
> *substream,
>   ret = request_irq(ssc_p->ssc->irq, atmel_ssc_interrupt, 0,
>   ssc_p->name, ssc_p);
>   if (ret < 0) {
> - printk(KERN_WARNING
> - "atmel_ssc_dai: request_irq failure\n");
> - pr_debug("Atmel_ssc_dai: Stoping clock\n");
> + dev_warn(dai->dev, "request_irq failure\n");
> + dev_dbg(dai->dev, "Stopping clock\n");
>   clk_disable(ssc_p->ssc->clk);
>   return ret;
>   }
> @@ -839,7 +836,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream 
> *substream,
>   ssc_writel(ssc_p->ssc->regs, TCMR, tcmr);
>   ssc_writel(ssc_p->ssc->regs, TFMR, tfmr);
>  
> - pr_debug("atmel_ssc_dai,hw_params: SSC initialized\n");
> + dev_dbg(dai->dev, "SSC initialized\n");
>   return 0;
>  }
>  
> @@ -862,9 +859,9 @@ static int atmel_ssc_prepare(struct snd_pcm_substream 
> *substream,
>   ssc_writel(ssc_p->ssc->regs, CR, dma_params->mask->ssc_disable);
>   ssc_writel(ssc_p->ssc->regs, IDR, dma_params->mask->ssc_error);
>  
> - pr_debug("%s enabled SSC_SR=0x%08x\n",
> - dir ? "receive" : "transmit",
> - ssc_readl(ssc_p->ssc->regs, SR));
> + dev_dbg(dai->dev, "%s enabled SSC_SR=0x%08x\n",
> + dir ? "receive" : "transmit",
> + ssc_readl(ssc_p->ssc->regs, SR));
>   return 0;
>  }
>  
> @@ -1050,21 +1047,18 @@ static void asoc_ssc_exit(struct device *dev)
>  int atmel_ssc_set_audio(

Re: [alsa-devel] [PATCH] ASoC: atmel_ssc_dai: fix spelling mistake: "Stoping" -> "Stopping"

[Ladislav Michl]

On Fri, Mar 30, 2018 at 04:44:20PM +0100, Colin King wrote:
> From: Colin Ian King 

Hello Colin,

> Trivial fix to spelling mistake in pr_debug message text

would you mind making this patch a bit less non-trivial and
change pr_debug to dev_dbg dropping Atmel_ssc_dai prefix?

Thank you.

> Signed-off-by: Colin Ian King 
> ---
>  sound/soc/atmel/atmel_ssc_dai.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
> index a1e2c5682dcd..1c7af0ca98ec 100644
> --- a/sound/soc/atmel/atmel_ssc_dai.c
> +++ b/sound/soc/atmel/atmel_ssc_dai.c
> @@ -820,7 +820,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream 
> *substream,
>   if (ret < 0) {
>   printk(KERN_WARNING
>   "atmel_ssc_dai: request_irq failure\n");
> - pr_debug("Atmel_ssc_dai: Stoping clock\n");
> + pr_debug("Atmel_ssc_dai: Stopping clock\n");
>   clk_disable(ssc_p->ssc->clk);
>   return ret;
>   }
> -- 
> 2.15.1
> 
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] [PATCH] ASoC: atmel_ssc_dai: fix spelling mistake: "Stoping" -> "Stopping"

[Ladislav Michl]

On Fri, Mar 30, 2018 at 04:44:20PM +0100, Colin King wrote:
> From: Colin Ian King 

Hello Colin,

> Trivial fix to spelling mistake in pr_debug message text

would you mind making this patch a bit less non-trivial and
change pr_debug to dev_dbg dropping Atmel_ssc_dai prefix?

Thank you.

> Signed-off-by: Colin Ian King 
> ---
>  sound/soc/atmel/atmel_ssc_dai.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
> index a1e2c5682dcd..1c7af0ca98ec 100644
> --- a/sound/soc/atmel/atmel_ssc_dai.c
> +++ b/sound/soc/atmel/atmel_ssc_dai.c
> @@ -820,7 +820,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream 
> *substream,
>   if (ret < 0) {
>   printk(KERN_WARNING
>   "atmel_ssc_dai: request_irq failure\n");
> - pr_debug("Atmel_ssc_dai: Stoping clock\n");
> + pr_debug("Atmel_ssc_dai: Stopping clock\n");
>   clk_disable(ssc_p->ssc->clk);
>   return ret;
>   }
> -- 
> 2.15.1
> 
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] [PATCH 1/3] sound: usb: line6: Replace mdelay with msleep in line6_read_data

[Ladislav Michl]

On Sun, Mar 18, 2018 at 10:51:33PM +0800, Jia-Ju Bai wrote:
> line6_read_data() is never called in atomic context.
> 
> The call chains ending up at line6_read_data() are:
> [1] line6_read_data() <- line6_read_serial_number() -> pod_startup4()
> [2] line6_read_data() <- line6_read_serial_number() <- 
>   podhd_startup_workqueue()
> [3] line6_read_data() <- podhd_dev_start() <- podhd_startup_workqueue()
> [4] line6_read_data() <- line6_read_serial_number() <- toneport_init()
>   <- line6_probe()
> [5] line6_read_data() <- toneport_init() <- line6_probe()
> 
> pod_startup4() and podhd_startup_workqueue() are set in INIT_WORK().
> line6_probe() is called in toneport_probe(), pod_probe(), podhd_probe() 
> and variax_probe(), which are set as ".probe" in usb_driver structure.
> These functions are not called in atomic context.
> 
> Despite never getting called from atomic context, line6_read_data()
> calls mdelay for busy wait.
> That is not necessary and can be replaced with msleep to 
> avoid busy waiting.

Can we have usleep_range here? Please see Documentation/timers/timers-howto.txt
for rationale and range settings.

> This is found by a static analysis tool named DCNS written by myself.

Here I'm assuming you do not have hardware and do not know how it works,
therefore few more people from 'git log --follow sound/usb/line6/driver.c'
were added to Cc list. Hopefully they can clarify the right range value.

Thank you.

> Signed-off-by: Jia-Ju Bai 
> ---
>  sound/usb/line6/driver.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
> index 0ff5a7d..af99e73 100644
> --- a/sound/usb/line6/driver.c
> +++ b/sound/usb/line6/driver.c
> @@ -356,7 +356,7 @@ int line6_read_data(struct usb_line6 *line6, unsigned 
> address, void *data,
>  
>   /* Wait for data length. We'll get 0xff until length arrives. */
>   for (count = 0; count < LINE6_READ_WRITE_MAX_RETRIES; count++) {
> - mdelay(LINE6_READ_WRITE_STATUS_DELAY);
> + msleep(LINE6_READ_WRITE_STATUS_DELAY);
>  
>   ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0), 0x67,
> USB_TYPE_VENDOR | USB_RECIP_DEVICE |
> -- 
> 1.9.1
> 
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] [PATCH 1/3] sound: usb: line6: Replace mdelay with msleep in line6_read_data

[Ladislav Michl]

On Sun, Mar 18, 2018 at 10:51:33PM +0800, Jia-Ju Bai wrote:
> line6_read_data() is never called in atomic context.
> 
> The call chains ending up at line6_read_data() are:
> [1] line6_read_data() <- line6_read_serial_number() -> pod_startup4()
> [2] line6_read_data() <- line6_read_serial_number() <- 
>   podhd_startup_workqueue()
> [3] line6_read_data() <- podhd_dev_start() <- podhd_startup_workqueue()
> [4] line6_read_data() <- line6_read_serial_number() <- toneport_init()
>   <- line6_probe()
> [5] line6_read_data() <- toneport_init() <- line6_probe()
> 
> pod_startup4() and podhd_startup_workqueue() are set in INIT_WORK().
> line6_probe() is called in toneport_probe(), pod_probe(), podhd_probe() 
> and variax_probe(), which are set as ".probe" in usb_driver structure.
> These functions are not called in atomic context.
> 
> Despite never getting called from atomic context, line6_read_data()
> calls mdelay for busy wait.
> That is not necessary and can be replaced with msleep to 
> avoid busy waiting.

Can we have usleep_range here? Please see Documentation/timers/timers-howto.txt
for rationale and range settings.

> This is found by a static analysis tool named DCNS written by myself.

Here I'm assuming you do not have hardware and do not know how it works,
therefore few more people from 'git log --follow sound/usb/line6/driver.c'
were added to Cc list. Hopefully they can clarify the right range value.

Thank you.

> Signed-off-by: Jia-Ju Bai 
> ---
>  sound/usb/line6/driver.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
> index 0ff5a7d..af99e73 100644
> --- a/sound/usb/line6/driver.c
> +++ b/sound/usb/line6/driver.c
> @@ -356,7 +356,7 @@ int line6_read_data(struct usb_line6 *line6, unsigned 
> address, void *data,
>  
>   /* Wait for data length. We'll get 0xff until length arrives. */
>   for (count = 0; count < LINE6_READ_WRITE_MAX_RETRIES; count++) {
> - mdelay(LINE6_READ_WRITE_STATUS_DELAY);
> + msleep(LINE6_READ_WRITE_STATUS_DELAY);
>  
>   ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0), 0x67,
> USB_TYPE_VENDOR | USB_RECIP_DEVICE |
> -- 
> 1.9.1
> 
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH v11 04/10] clocksource: timer-ti-dm: Replace architecture

[Ladislav Michl]

On Thu, Feb 15, 2018 at 11:31:45AM +0530, Keerthy wrote:
> Replace architecture specific guard with clocksource guard.
> 
> Signed-off-by: Keerthy 
> Replace architecture specific defines with clocksource

This looks like a bit unussual commit log. Also, what about merging
it with previous patch?

Btw, I tested whole serie again on the top of today's -next and it is
still working fine. What is preventing these patches from being merged?

Thank you,
ladis

> ---
>  include/clocksource/timer-ti-dm.h | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/include/clocksource/timer-ti-dm.h 
> b/include/clocksource/timer-ti-dm.h
> index 831174f..4f31095 100644
> --- a/include/clocksource/timer-ti-dm.h
> +++ b/include/clocksource/timer-ti-dm.h
> @@ -1,6 +1,4 @@
>  /*
> - * arch/arm/plat-omap/include/plat/dmtimer.h
> - *
>   * OMAP Dual-Mode Timers
>   *
>   * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
> @@ -36,8 +34,8 @@
>  #include 
>  #include 
>  
> -#ifndef __ASM_ARCH_DMTIMER_H
> -#define __ASM_ARCH_DMTIMER_H
> +#ifndef __CLOCKSOURCE_DMTIMER_H
> +#define __CLOCKSOURCE_DMTIMER_H
>  
>  /* clock sources */
>  #define OMAP_TIMER_SRC_SYS_CLK   0x00
> @@ -426,4 +424,4 @@ static inline void __omap_dm_timer_write_status(struct 
> omap_dm_timer *timer,
>   writel_relaxed(value, timer->irq_stat);
>  }
>  #endif /* CONFIG_ARCH_OMAP1 || CONFIG_ARCH_OMAP2PLUS */
> -#endif /* __ASM_ARCH_DMTIMER_H */
> +#endif /* __CLOCKSOURCE_DMTIMER_H */
> -- 
> 1.9.1

Re: [PATCH v11 04/10] clocksource: timer-ti-dm: Replace architecture

[Ladislav Michl]

On Thu, Feb 15, 2018 at 11:31:45AM +0530, Keerthy wrote:
> Replace architecture specific guard with clocksource guard.
> 
> Signed-off-by: Keerthy 
> Replace architecture specific defines with clocksource

This looks like a bit unussual commit log. Also, what about merging
it with previous patch?

Btw, I tested whole serie again on the top of today's -next and it is
still working fine. What is preventing these patches from being merged?

Thank you,
ladis

> ---
>  include/clocksource/timer-ti-dm.h | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/include/clocksource/timer-ti-dm.h 
> b/include/clocksource/timer-ti-dm.h
> index 831174f..4f31095 100644
> --- a/include/clocksource/timer-ti-dm.h
> +++ b/include/clocksource/timer-ti-dm.h
> @@ -1,6 +1,4 @@
>  /*
> - * arch/arm/plat-omap/include/plat/dmtimer.h
> - *
>   * OMAP Dual-Mode Timers
>   *
>   * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
> @@ -36,8 +34,8 @@
>  #include 
>  #include 
>  
> -#ifndef __ASM_ARCH_DMTIMER_H
> -#define __ASM_ARCH_DMTIMER_H
> +#ifndef __CLOCKSOURCE_DMTIMER_H
> +#define __CLOCKSOURCE_DMTIMER_H
>  
>  /* clock sources */
>  #define OMAP_TIMER_SRC_SYS_CLK   0x00
> @@ -426,4 +424,4 @@ static inline void __omap_dm_timer_write_status(struct 
> omap_dm_timer *timer,
>   writel_relaxed(value, timer->irq_stat);
>  }
>  #endif /* CONFIG_ARCH_OMAP1 || CONFIG_ARCH_OMAP2PLUS */
> -#endif /* __ASM_ARCH_DMTIMER_H */
> +#endif /* __CLOCKSOURCE_DMTIMER_H */
> -- 
> 1.9.1

Re: [alsa-devel] [PATCH 1/1] ASoC: stm32: add of dependency for stm32 drivers

[Ladislav Michl]

On Thu, Feb 01, 2018 at 09:54:41AM +0100, Olivier Moysan wrote:
> Add of dependency for STM32 ASoC drivers.
> DFSDM of dependency is already inherited
> from STM32_DFSDM_ADC dependency.
> 
> Signed-off-by: olivier moysan 
> ---
>  sound/soc/stm/Kconfig | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/sound/soc/stm/Kconfig b/sound/soc/stm/Kconfig
> index 3ad881f..b5375f9 100644
> --- a/sound/soc/stm/Kconfig
> +++ b/sound/soc/stm/Kconfig
> @@ -3,6 +3,7 @@ menu "STMicroelectronics STM32 SOC audio support"
>  config SND_SOC_STM32_SAI
>   tristate "STM32 SAI interface (Serial Audio Interface) support"
>   depends on ARCH_STM32 || COMPILE_TEST
> + depends on OF

depends on (ARCH_STM32 && OF) || COMPILE_TEST ?

>   depends on SND_SOC
>   select SND_SOC_GENERIC_DMAENGINE_PCM
>   select REGMAP_MMIO
> @@ -12,6 +13,7 @@ config SND_SOC_STM32_SAI
>  config SND_SOC_STM32_I2S
>   tristate "STM32 I2S interface (SPI/I2S block) support"
>   depends on ARCH_STM32 || COMPILE_TEST
> + depends on OF
>   depends on SND_SOC
>   select SND_SOC_GENERIC_DMAENGINE_PCM
>   select REGMAP_MMIO
> @@ -21,6 +23,7 @@ config SND_SOC_STM32_I2S
>  config SND_SOC_STM32_SPDIFRX
>   tristate "STM32 S/PDIF receiver (SPDIFRX) support"
>   depends on ARCH_STM32 || COMPILE_TEST
> + depends on OF
>   depends on SND_SOC
>   select SND_SOC_GENERIC_DMAENGINE_PCM
>   select REGMAP_MMIO
> -- 
> 1.9.1
> 
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [alsa-devel] [PATCH 1/1] ASoC: stm32: add of dependency for stm32 drivers

[Ladislav Michl]

On Thu, Feb 01, 2018 at 09:54:41AM +0100, Olivier Moysan wrote:
> Add of dependency for STM32 ASoC drivers.
> DFSDM of dependency is already inherited
> from STM32_DFSDM_ADC dependency.
> 
> Signed-off-by: olivier moysan 
> ---
>  sound/soc/stm/Kconfig | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/sound/soc/stm/Kconfig b/sound/soc/stm/Kconfig
> index 3ad881f..b5375f9 100644
> --- a/sound/soc/stm/Kconfig
> +++ b/sound/soc/stm/Kconfig
> @@ -3,6 +3,7 @@ menu "STMicroelectronics STM32 SOC audio support"
>  config SND_SOC_STM32_SAI
>   tristate "STM32 SAI interface (Serial Audio Interface) support"
>   depends on ARCH_STM32 || COMPILE_TEST
> + depends on OF

depends on (ARCH_STM32 && OF) || COMPILE_TEST ?

>   depends on SND_SOC
>   select SND_SOC_GENERIC_DMAENGINE_PCM
>   select REGMAP_MMIO
> @@ -12,6 +13,7 @@ config SND_SOC_STM32_SAI
>  config SND_SOC_STM32_I2S
>   tristate "STM32 I2S interface (SPI/I2S block) support"
>   depends on ARCH_STM32 || COMPILE_TEST
> + depends on OF
>   depends on SND_SOC
>   select SND_SOC_GENERIC_DMAENGINE_PCM
>   select REGMAP_MMIO
> @@ -21,6 +23,7 @@ config SND_SOC_STM32_I2S
>  config SND_SOC_STM32_SPDIFRX
>   tristate "STM32 S/PDIF receiver (SPDIFRX) support"
>   depends on ARCH_STM32 || COMPILE_TEST
> + depends on OF
>   depends on SND_SOC
>   select SND_SOC_GENERIC_DMAENGINE_PCM
>   select REGMAP_MMIO
> -- 
> 1.9.1
> 
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH] sound/tlv320dac33: Add device tree support

[Ladislav Michl]

On Tue, Jan 30, 2018 at 11:35:38AM +0100, Pavel Machek wrote:
> On Tue 2018-01-30 11:10:46, Ladislav Michl wrote:
> > On Tue, Jan 30, 2018 at 11:00:23AM +0100, Pavel Machek wrote:
> > > On Tue 2018-01-30 10:38:38, Ladislav Michl wrote:
> > > > On Tue, Jan 30, 2018 at 10:11:02AM +0100, Filip Matijević wrote:
> > > > > Hi,
> > > > > 
> > > 
> > > > > > Well, notice I'm converting existing driver to device tree. And that
> > > > > > one already has GPIO dependency. It is possible that more work needs
> > > > > > to be done there, but that should not be a reason to delay this. 
> > > > > > Feel
> > > > > > free to help.
> > > > 
> > > > Adding DT properties that need to be maintained for compatibility 
> > > > reasons
> > > > is a bad idea and very good reason to delay merging unfinished stuff.
> > > > And meanwhile it turned out it is not power-gpio :)
> > > 
> > > I believe reset-gpios and power-gpios are commonly used like
> > > this... and that's what the old code does.
> > 
> > Why do you care about old code when introducing new DT property?
> > Either it is reset, then lets call it reset-gpios or it is power supply
> > and then voltage regulator should be used (VAUX4.OUT is such a regulator
> > although it is unclear to me how it is controlled (*)).
> 
> power gpio = !reset gpio. Difference is only in polarity.

Quick grep:
Documentation/devicetree/bindings/net/smsc-lan91c111.txt
- power-gpios: GPIO to control the PWRDWN pin
- reset-gpios: GPIO to control the RESET pin
Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
- ti,power-gpio : GPIO connected to chip's PMEN pin
Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
- power-gpios : Specification for the pin connected to the gsl1680's
shutdown input. This needs to be driven high to 
take the
gsl1680 out of its low power state
Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt
- power-gpios : GPIO specification for the pin connected to the
ektf2127's wake input. This needs to be driven high
to take ektf2127 out of it's low power state

As you can see others are using it to drive pins different from nRESET. As
stated in datasheet:
"The TLV320DAC32 requires a hardware reset after power-up for proper operation.
After all power supplies are at their specified values, the nRESET pin must be
driven low for at least 10ns. If this reset sequence is not performed, the DAC32
may not respond properly to register reads/writes". That does not sound like
anything to do with power.

(It seems the only difference between TLV320DAC33 and TLV320DAC32 is uses a ball
grid array package vs QFN32)

> > > You are not helping.
> > 
> > The only way I can help here is to resend your patch with "reset-gpios"
> > used, which I'm pretty sure you can handle yourself.
> 
> Well, you can do that, and then you can argue with the next person who
> feels one of the properties has to get his preferred color. Hard part
> is not changing code :-(.

Indeed, hard part is not to break DT compatibility later. Consider someone
will have to add regulator support later, which you omitted to do - having
both power supply and power gpio is a bit confusing, don't you think?

Anyway, time to stop arguing, feel free to do what you think is right, I do
not have anything important to add :)

ladis

Re: [PATCH] sound/tlv320dac33: Add device tree support

[Ladislav Michl]

On Tue, Jan 30, 2018 at 11:35:38AM +0100, Pavel Machek wrote:
> On Tue 2018-01-30 11:10:46, Ladislav Michl wrote:
> > On Tue, Jan 30, 2018 at 11:00:23AM +0100, Pavel Machek wrote:
> > > On Tue 2018-01-30 10:38:38, Ladislav Michl wrote:
> > > > On Tue, Jan 30, 2018 at 10:11:02AM +0100, Filip Matijević wrote:
> > > > > Hi,
> > > > > 
> > > 
> > > > > > Well, notice I'm converting existing driver to device tree. And that
> > > > > > one already has GPIO dependency. It is possible that more work needs
> > > > > > to be done there, but that should not be a reason to delay this. 
> > > > > > Feel
> > > > > > free to help.
> > > > 
> > > > Adding DT properties that need to be maintained for compatibility 
> > > > reasons
> > > > is a bad idea and very good reason to delay merging unfinished stuff.
> > > > And meanwhile it turned out it is not power-gpio :)
> > > 
> > > I believe reset-gpios and power-gpios are commonly used like
> > > this... and that's what the old code does.
> > 
> > Why do you care about old code when introducing new DT property?
> > Either it is reset, then lets call it reset-gpios or it is power supply
> > and then voltage regulator should be used (VAUX4.OUT is such a regulator
> > although it is unclear to me how it is controlled (*)).
> 
> power gpio = !reset gpio. Difference is only in polarity.

Quick grep:
Documentation/devicetree/bindings/net/smsc-lan91c111.txt
- power-gpios: GPIO to control the PWRDWN pin
- reset-gpios: GPIO to control the RESET pin
Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
- ti,power-gpio : GPIO connected to chip's PMEN pin
Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
- power-gpios : Specification for the pin connected to the gsl1680's
shutdown input. This needs to be driven high to 
take the
gsl1680 out of its low power state
Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt
- power-gpios : GPIO specification for the pin connected to the
ektf2127's wake input. This needs to be driven high
to take ektf2127 out of it's low power state

As you can see others are using it to drive pins different from nRESET. As
stated in datasheet:
"The TLV320DAC32 requires a hardware reset after power-up for proper operation.
After all power supplies are at their specified values, the nRESET pin must be
driven low for at least 10ns. If this reset sequence is not performed, the DAC32
may not respond properly to register reads/writes". That does not sound like
anything to do with power.

(It seems the only difference between TLV320DAC33 and TLV320DAC32 is uses a ball
grid array package vs QFN32)

> > > You are not helping.
> > 
> > The only way I can help here is to resend your patch with "reset-gpios"
> > used, which I'm pretty sure you can handle yourself.
> 
> Well, you can do that, and then you can argue with the next person who
> feels one of the properties has to get his preferred color. Hard part
> is not changing code :-(.

Indeed, hard part is not to break DT compatibility later. Consider someone
will have to add regulator support later, which you omitted to do - having
both power supply and power gpio is a bit confusing, don't you think?

Anyway, time to stop arguing, feel free to do what you think is right, I do
not have anything important to add :)

ladis

Re: [PATCH] sound/tlv320dac33: Add device tree support

[Ladislav Michl]

On Tue, Jan 30, 2018 at 11:00:23AM +0100, Pavel Machek wrote:
> On Tue 2018-01-30 10:38:38, Ladislav Michl wrote:
> > On Tue, Jan 30, 2018 at 10:11:02AM +0100, Filip Matijević wrote:
> > > Hi,
> > > 
> 
> > > > Well, notice I'm converting existing driver to device tree. And that
> > > > one already has GPIO dependency. It is possible that more work needs
> > > > to be done there, but that should not be a reason to delay this. Feel
> > > > free to help.
> > 
> > Adding DT properties that need to be maintained for compatibility reasons
> > is a bad idea and very good reason to delay merging unfinished stuff.
> > And meanwhile it turned out it is not power-gpio :)
> 
> I believe reset-gpios and power-gpios are commonly used like
> this... and that's what the old code does.

Why do you care about old code when introducing new DT property?
Either it is reset, then lets call it reset-gpios or it is power supply
and then voltage regulator should be used (VAUX4.OUT is such a regulator
although it is unclear to me how it is controlled (*)).

> You are not helping.

The only way I can help here is to resend your patch with "reset-gpios"
used, which I'm pretty sure you can handle yourself.

(*) Remark "DAC33 enabled (for example, plug in a headset to the 3.5mm
AV connector and start music playback from the device)" in schematics
suggests it is controlled somehow.

Re: [PATCH] sound/tlv320dac33: Add device tree support

[Ladislav Michl]

On Tue, Jan 30, 2018 at 11:00:23AM +0100, Pavel Machek wrote:
> On Tue 2018-01-30 10:38:38, Ladislav Michl wrote:
> > On Tue, Jan 30, 2018 at 10:11:02AM +0100, Filip Matijević wrote:
> > > Hi,
> > > 
> 
> > > > Well, notice I'm converting existing driver to device tree. And that
> > > > one already has GPIO dependency. It is possible that more work needs
> > > > to be done there, but that should not be a reason to delay this. Feel
> > > > free to help.
> > 
> > Adding DT properties that need to be maintained for compatibility reasons
> > is a bad idea and very good reason to delay merging unfinished stuff.
> > And meanwhile it turned out it is not power-gpio :)
> 
> I believe reset-gpios and power-gpios are commonly used like
> this... and that's what the old code does.

Why do you care about old code when introducing new DT property?
Either it is reset, then lets call it reset-gpios or it is power supply
and then voltage regulator should be used (VAUX4.OUT is such a regulator
although it is unclear to me how it is controlled (*)).

> You are not helping.

The only way I can help here is to resend your patch with "reset-gpios"
used, which I'm pretty sure you can handle yourself.

(*) Remark "DAC33 enabled (for example, plug in a headset to the 3.5mm
AV connector and start music playback from the device)" in schematics
suggests it is controlled somehow.

Re: [PATCH] sound/tlv320dac33: Add device tree support

[Ladislav Michl]

On Tue, Jan 30, 2018 at 10:11:02AM +0100, Filip Matijević wrote:
> Hi,
> 
> On 01/30/2018 09:53 AM, Pavel Machek wrote:
> > On Tue 2018-01-30 09:34:46, Ladislav Michl wrote:
> >> On Tue, Jan 30, 2018 at 12:33:01AM +0100, Pavel Machek wrote:
> >>> On Tue 2018-01-30 00:20:31, Ladislav Michl wrote:
> >>>> On Tue, Jan 30, 2018 at 12:05:39AM +0100, Pavel Machek wrote:
> >>>>>
> >>>>> This adds device tree support to tlv320dac33.c.
> >>>>>
> >>>>> Signed-off-by: Pavel Machek <pa...@ucw.cz>
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/sound/tlv320dac33.txt 
> >>>>> b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> >>>>> new file mode 100644
> >>>>> index 000..6cbd311
> >>>>> --- /dev/null
> >>>>> +++ b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> >>>>> @@ -0,0 +1,32 @@
> >>>>> +Texas Instruments - tlv320dac33 Codec module
> >>>>> +
> >>>>> +The tlv320dac33 serial control bus communicates through I2C protocols.
> >>>>> +
> >>>>> +Required properties:
> >>>>> +
> >>>>> +- compatible - "ti,tlv320dac33"
> >>>>> +- reg - I2C slave address
> >>>>> +
> >>>>> +Optional properties:
> >>>>> +
> >>>>> +- power-gpios - gpio pin to power the device, active high
> >>>>
> >>>> While driver used gpio in platform data, isn't it more likely
> >>>> regulator which powers device?
> >>>
> >>> power-gpios = < 28 0>; /* gpio_60 */
> >>>
> >>> Looks like GPIO to me -- example is from Nokia N9. So this appears to
> >>> be correct.
> >>
> >> Device datasheet doesn't list any pin which looks like "power-gpio"
> >> http://www.ti.com/lit/ds/symlink/tlv320dac32.pdf
> >> Unfortunately I do not know much about N9, but was able to find Nokia 5610
> >> scheme to get clue how could be tlv320dac33 hardwired (see page 2):
> >> http://mastermobile.spb.ru/service/nokia_5610_rm-242_service_schematics.pdf
> >> Here AVDD is powered by LP3985 voltage regulator which is enabled using
> >> VEN pin which might be connected to gpio. Or there could be completely
> >> different voltage regulator with different controls. And since Linux
> >> already has voltage regulator class, lets not limit ourselves to gpio
> >> pins.
> > 
> > Well, notice I'm converting existing driver to device tree. And that
> > one already has GPIO dependency. It is possible that more work needs
> > to be done there, but that should not be a reason to delay this. Feel
> > free to help.

Adding DT properties that need to be maintained for compatibility reasons
is a bad idea and very good reason to delay merging unfinished stuff.
And meanwhile it turned out it is not power-gpio :)

> According to N9 schematics
> http://www.s-manuals.com/manuals/phone/nokia/nokia_n9_rm-696_service_schematics_v1.pdf
> it's in fact GPIO pin that is connected to reset line (labeled
> CODEC_RST). So calling it "power" might be misleading, but the driver
> code is quite clear as it labels that GPIO as "tlv320dac33 reset"

Thanks a lot! So now it is clear that gpio is connected to codec's nRESET pin,
therefore "reset-gpios" property seems reasonable here.

ladis

Re: [PATCH] sound/tlv320dac33: Add device tree support

[Ladislav Michl]

On Tue, Jan 30, 2018 at 10:11:02AM +0100, Filip Matijević wrote:
> Hi,
> 
> On 01/30/2018 09:53 AM, Pavel Machek wrote:
> > On Tue 2018-01-30 09:34:46, Ladislav Michl wrote:
> >> On Tue, Jan 30, 2018 at 12:33:01AM +0100, Pavel Machek wrote:
> >>> On Tue 2018-01-30 00:20:31, Ladislav Michl wrote:
> >>>> On Tue, Jan 30, 2018 at 12:05:39AM +0100, Pavel Machek wrote:
> >>>>>
> >>>>> This adds device tree support to tlv320dac33.c.
> >>>>>
> >>>>> Signed-off-by: Pavel Machek 
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/sound/tlv320dac33.txt 
> >>>>> b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> >>>>> new file mode 100644
> >>>>> index 000..6cbd311
> >>>>> --- /dev/null
> >>>>> +++ b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> >>>>> @@ -0,0 +1,32 @@
> >>>>> +Texas Instruments - tlv320dac33 Codec module
> >>>>> +
> >>>>> +The tlv320dac33 serial control bus communicates through I2C protocols.
> >>>>> +
> >>>>> +Required properties:
> >>>>> +
> >>>>> +- compatible - "ti,tlv320dac33"
> >>>>> +- reg - I2C slave address
> >>>>> +
> >>>>> +Optional properties:
> >>>>> +
> >>>>> +- power-gpios - gpio pin to power the device, active high
> >>>>
> >>>> While driver used gpio in platform data, isn't it more likely
> >>>> regulator which powers device?
> >>>
> >>> power-gpios = < 28 0>; /* gpio_60 */
> >>>
> >>> Looks like GPIO to me -- example is from Nokia N9. So this appears to
> >>> be correct.
> >>
> >> Device datasheet doesn't list any pin which looks like "power-gpio"
> >> http://www.ti.com/lit/ds/symlink/tlv320dac32.pdf
> >> Unfortunately I do not know much about N9, but was able to find Nokia 5610
> >> scheme to get clue how could be tlv320dac33 hardwired (see page 2):
> >> http://mastermobile.spb.ru/service/nokia_5610_rm-242_service_schematics.pdf
> >> Here AVDD is powered by LP3985 voltage regulator which is enabled using
> >> VEN pin which might be connected to gpio. Or there could be completely
> >> different voltage regulator with different controls. And since Linux
> >> already has voltage regulator class, lets not limit ourselves to gpio
> >> pins.
> > 
> > Well, notice I'm converting existing driver to device tree. And that
> > one already has GPIO dependency. It is possible that more work needs
> > to be done there, but that should not be a reason to delay this. Feel
> > free to help.

Adding DT properties that need to be maintained for compatibility reasons
is a bad idea and very good reason to delay merging unfinished stuff.
And meanwhile it turned out it is not power-gpio :)

> According to N9 schematics
> http://www.s-manuals.com/manuals/phone/nokia/nokia_n9_rm-696_service_schematics_v1.pdf
> it's in fact GPIO pin that is connected to reset line (labeled
> CODEC_RST). So calling it "power" might be misleading, but the driver
> code is quite clear as it labels that GPIO as "tlv320dac33 reset"

Thanks a lot! So now it is clear that gpio is connected to codec's nRESET pin,
therefore "reset-gpios" property seems reasonable here.

ladis

Re: [PATCH] sound/tlv320dac33: Add device tree support

[Ladislav Michl]

On Tue, Jan 30, 2018 at 12:33:01AM +0100, Pavel Machek wrote:
> On Tue 2018-01-30 00:20:31, Ladislav Michl wrote:
> > On Tue, Jan 30, 2018 at 12:05:39AM +0100, Pavel Machek wrote:
> > > 
> > > This adds device tree support to tlv320dac33.c.
> > > 
> > > Signed-off-by: Pavel Machek <pa...@ucw.cz>
> > > 
> > > diff --git a/Documentation/devicetree/bindings/sound/tlv320dac33.txt 
> > > b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> > > new file mode 100644
> > > index 000..6cbd311
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> > > @@ -0,0 +1,32 @@
> > > +Texas Instruments - tlv320dac33 Codec module
> > > +
> > > +The tlv320dac33 serial control bus communicates through I2C protocols.
> > > +
> > > +Required properties:
> > > +
> > > +- compatible - "ti,tlv320dac33"
> > > +- reg - I2C slave address
> > > +
> > > +Optional properties:
> > > +
> > > +- power-gpios - gpio pin to power the device, active high
> > 
> > While driver used gpio in platform data, isn't it more likely
> > regulator which powers device?
> 
> power-gpios = < 28 0>; /* gpio_60 */
> 
> Looks like GPIO to me -- example is from Nokia N9. So this appears to
> be correct.

Device datasheet doesn't list any pin which looks like "power-gpio"
http://www.ti.com/lit/ds/symlink/tlv320dac32.pdf
Unfortunately I do not know much about N9, but was able to find Nokia 5610
scheme to get clue how could be tlv320dac33 hardwired (see page 2):
http://mastermobile.spb.ru/service/nokia_5610_rm-242_service_schematics.pdf
Here AVDD is powered by LP3985 voltage regulator which is enabled using
VEN pin which might be connected to gpio. Or there could be completely
different voltage regulator with different controls. And since Linux
already has voltage regulator class, lets not limit ourselves to gpio
pins.

See also here about deprecated power-gpios:
Documentation/devicetree/bindings/mmc/cavium-mmc.txt
so it seems others already fallen into that trap.

ladis

Re: [PATCH] sound/tlv320dac33: Add device tree support

[Ladislav Michl]

On Tue, Jan 30, 2018 at 12:33:01AM +0100, Pavel Machek wrote:
> On Tue 2018-01-30 00:20:31, Ladislav Michl wrote:
> > On Tue, Jan 30, 2018 at 12:05:39AM +0100, Pavel Machek wrote:
> > > 
> > > This adds device tree support to tlv320dac33.c.
> > > 
> > > Signed-off-by: Pavel Machek 
> > > 
> > > diff --git a/Documentation/devicetree/bindings/sound/tlv320dac33.txt 
> > > b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> > > new file mode 100644
> > > index 000..6cbd311
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> > > @@ -0,0 +1,32 @@
> > > +Texas Instruments - tlv320dac33 Codec module
> > > +
> > > +The tlv320dac33 serial control bus communicates through I2C protocols.
> > > +
> > > +Required properties:
> > > +
> > > +- compatible - "ti,tlv320dac33"
> > > +- reg - I2C slave address
> > > +
> > > +Optional properties:
> > > +
> > > +- power-gpios - gpio pin to power the device, active high
> > 
> > While driver used gpio in platform data, isn't it more likely
> > regulator which powers device?
> 
> power-gpios = < 28 0>; /* gpio_60 */
> 
> Looks like GPIO to me -- example is from Nokia N9. So this appears to
> be correct.

Device datasheet doesn't list any pin which looks like "power-gpio"
http://www.ti.com/lit/ds/symlink/tlv320dac32.pdf
Unfortunately I do not know much about N9, but was able to find Nokia 5610
scheme to get clue how could be tlv320dac33 hardwired (see page 2):
http://mastermobile.spb.ru/service/nokia_5610_rm-242_service_schematics.pdf
Here AVDD is powered by LP3985 voltage regulator which is enabled using
VEN pin which might be connected to gpio. Or there could be completely
different voltage regulator with different controls. And since Linux
already has voltage regulator class, lets not limit ourselves to gpio
pins.

See also here about deprecated power-gpios:
Documentation/devicetree/bindings/mmc/cavium-mmc.txt
so it seems others already fallen into that trap.

ladis

Re: [PATCH] sound/tlv320dac33: Add device tree support

[Ladislav Michl]

On Tue, Jan 30, 2018 at 12:05:39AM +0100, Pavel Machek wrote:
> 
> This adds device tree support to tlv320dac33.c.
> 
> Signed-off-by: Pavel Machek 
> 
> diff --git a/Documentation/devicetree/bindings/sound/tlv320dac33.txt 
> b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> new file mode 100644
> index 000..6cbd311
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> @@ -0,0 +1,32 @@
> +Texas Instruments - tlv320dac33 Codec module
> +
> +The tlv320dac33 serial control bus communicates through I2C protocols.
> +
> +Required properties:
> +
> +- compatible - "ti,tlv320dac33"
> +- reg - I2C slave address
> +
> +Optional properties:
> +
> +- power-gpios - gpio pin to power the device, active high

While driver used gpio in platform data, isn't it more likely
regulator which powers device?

> +- interrupts   - The interrupt output from the device.
> +- interrupt-parent - The parent interrupt controller.
> +
> +- ti,keep-bclk   - Keep the BCLK running in FIFO modes
> +- ti,burst-bclkdiv - BCLK divider value in burst mode
> +
> +Example:
> +
> +tlv320dac33: audio-codec@19 {
> + compatible = "ti,tlv320dac33";
> + reg = <0x19>;
> +
> + interrupt-parent = <>;
> + interrupts = <21 1>; /* gpio_53, IRQF_TRIGGER_RISING */
> + power-gpio = < 28 0>; /* gpio_60 */
> +
> + ti,keep-bclk;
> + ti,burst-bclkdiv = <3>;
> +};
> diff --git a/sound/soc/codecs/tlv320dac33.c b/sound/soc/codecs/tlv320dac33.c
> index 5b94a15..2a0fe06 100644
> --- a/sound/soc/codecs/tlv320dac33.c
> +++ b/sound/soc/codecs/tlv320dac33.c
> @@ -30,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -105,7 +108,7 @@ struct tlv320dac33_priv {
>   unsigned int nsample;   /* burst read amount from host */
>   int mode1_latency;  /* latency caused by the i2c writes in
>* us */
> - u8 burst_bclkdiv;   /* BCLK divider value in burst mode */
> + u32 burst_bclkdiv;  /* BCLK divider value in burst mode */
>   unsigned int burst_rate;/* Interface speed in Burst modes */
>  
>   int keep_bclk;  /* Keep the BCLK continuously running
> @@ -1484,16 +1487,11 @@ static struct snd_soc_dai_driver dac33_dai = {
>  static int dac33_i2c_probe(struct i2c_client *client,
>  const struct i2c_device_id *id)
>  {
> - struct tlv320dac33_platform_data *pdata;
> + struct tlv320dac33_platform_data *pdata = client->dev.platform_data;
>   struct tlv320dac33_priv *dac33;
> + struct device_node *np = client->dev.of_node;
>   int ret, i;
>  
> - if (client->dev.platform_data == NULL) {
> - dev_err(>dev, "Platform data not set\n");
> - return -ENODEV;
> - }
> - pdata = client->dev.platform_data;
> -
>   dac33 = devm_kzalloc(>dev, sizeof(struct tlv320dac33_priv),
>GFP_KERNEL);
>   if (dac33 == NULL)
> @@ -1505,10 +1503,26 @@ static int dac33_i2c_probe(struct i2c_client *client,
>  
>   i2c_set_clientdata(client, dac33);
>  
> - dac33->power_gpio = pdata->power_gpio;
> - dac33->burst_bclkdiv = pdata->burst_bclkdiv;
> - dac33->keep_bclk = pdata->keep_bclk;
> - dac33->mode1_latency = pdata->mode1_latency;
> + if (pdata) {
> + dac33->power_gpio = pdata->power_gpio;
> + dac33->burst_bclkdiv = pdata->burst_bclkdiv;
> + dac33->keep_bclk = pdata->keep_bclk;
> + dac33->mode1_latency = pdata->mode1_latency;
> + } else if (np) {
> + ret = of_get_named_gpio(np, "power-gpios", 0);
> + if (ret >= 0)
> + dac33->power_gpio = ret;
> + else
> + dac33->power_gpio = -1;
> +
> + if (of_property_read_bool(np, "ti,keep-bclk"))
> + dac33->keep_bclk = true;
> +
> + of_property_read_u32(np, "ti,burst-bclkdiv", 
> >burst_bclkdiv);
> + } else {
> + dev_err(>dev, "Platform data not set\n");
> + return -ENODEV;
> + }
>   if (!dac33->mode1_latency)
>   dac33->mode1_latency = 1; /* 10ms */
>   dac33->irq = client->irq;
> @@ -1574,9 +1588,16 @@ static const struct i2c_device_id tlv320dac33_i2c_id[] 
> = {
>  };
>  MODULE_DEVICE_TABLE(i2c, tlv320dac33_i2c_id);
>  
> +static const struct of_device_id tlv320dac33_of_match[] = {
> + { .compatible = "ti,tlv320dac33", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(i2c, tlv320dac33_of_match);
> +
>  static struct i2c_driver tlv320dac33_i2c_driver = {
>   .driver = {
>   .name = "tlv320dac33-codec",
> + .of_match_table = of_match_ptr(tlv320dac33_of_match),
>   },
>   .probe  = dac33_i2c_probe,
>   .remove = dac33_i2c_remove,
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> 

Re: [PATCH] sound/tlv320dac33: Add device tree support

[Ladislav Michl]

On Tue, Jan 30, 2018 at 12:05:39AM +0100, Pavel Machek wrote:
> 
> This adds device tree support to tlv320dac33.c.
> 
> Signed-off-by: Pavel Machek 
> 
> diff --git a/Documentation/devicetree/bindings/sound/tlv320dac33.txt 
> b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> new file mode 100644
> index 000..6cbd311
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/tlv320dac33.txt
> @@ -0,0 +1,32 @@
> +Texas Instruments - tlv320dac33 Codec module
> +
> +The tlv320dac33 serial control bus communicates through I2C protocols.
> +
> +Required properties:
> +
> +- compatible - "ti,tlv320dac33"
> +- reg - I2C slave address
> +
> +Optional properties:
> +
> +- power-gpios - gpio pin to power the device, active high

While driver used gpio in platform data, isn't it more likely
regulator which powers device?

> +- interrupts   - The interrupt output from the device.
> +- interrupt-parent - The parent interrupt controller.
> +
> +- ti,keep-bclk   - Keep the BCLK running in FIFO modes
> +- ti,burst-bclkdiv - BCLK divider value in burst mode
> +
> +Example:
> +
> +tlv320dac33: audio-codec@19 {
> + compatible = "ti,tlv320dac33";
> + reg = <0x19>;
> +
> + interrupt-parent = <>;
> + interrupts = <21 1>; /* gpio_53, IRQF_TRIGGER_RISING */
> + power-gpio = < 28 0>; /* gpio_60 */
> +
> + ti,keep-bclk;
> + ti,burst-bclkdiv = <3>;
> +};
> diff --git a/sound/soc/codecs/tlv320dac33.c b/sound/soc/codecs/tlv320dac33.c
> index 5b94a15..2a0fe06 100644
> --- a/sound/soc/codecs/tlv320dac33.c
> +++ b/sound/soc/codecs/tlv320dac33.c
> @@ -30,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -105,7 +108,7 @@ struct tlv320dac33_priv {
>   unsigned int nsample;   /* burst read amount from host */
>   int mode1_latency;  /* latency caused by the i2c writes in
>* us */
> - u8 burst_bclkdiv;   /* BCLK divider value in burst mode */
> + u32 burst_bclkdiv;  /* BCLK divider value in burst mode */
>   unsigned int burst_rate;/* Interface speed in Burst modes */
>  
>   int keep_bclk;  /* Keep the BCLK continuously running
> @@ -1484,16 +1487,11 @@ static struct snd_soc_dai_driver dac33_dai = {
>  static int dac33_i2c_probe(struct i2c_client *client,
>  const struct i2c_device_id *id)
>  {
> - struct tlv320dac33_platform_data *pdata;
> + struct tlv320dac33_platform_data *pdata = client->dev.platform_data;
>   struct tlv320dac33_priv *dac33;
> + struct device_node *np = client->dev.of_node;
>   int ret, i;
>  
> - if (client->dev.platform_data == NULL) {
> - dev_err(>dev, "Platform data not set\n");
> - return -ENODEV;
> - }
> - pdata = client->dev.platform_data;
> -
>   dac33 = devm_kzalloc(>dev, sizeof(struct tlv320dac33_priv),
>GFP_KERNEL);
>   if (dac33 == NULL)
> @@ -1505,10 +1503,26 @@ static int dac33_i2c_probe(struct i2c_client *client,
>  
>   i2c_set_clientdata(client, dac33);
>  
> - dac33->power_gpio = pdata->power_gpio;
> - dac33->burst_bclkdiv = pdata->burst_bclkdiv;
> - dac33->keep_bclk = pdata->keep_bclk;
> - dac33->mode1_latency = pdata->mode1_latency;
> + if (pdata) {
> + dac33->power_gpio = pdata->power_gpio;
> + dac33->burst_bclkdiv = pdata->burst_bclkdiv;
> + dac33->keep_bclk = pdata->keep_bclk;
> + dac33->mode1_latency = pdata->mode1_latency;
> + } else if (np) {
> + ret = of_get_named_gpio(np, "power-gpios", 0);
> + if (ret >= 0)
> + dac33->power_gpio = ret;
> + else
> + dac33->power_gpio = -1;
> +
> + if (of_property_read_bool(np, "ti,keep-bclk"))
> + dac33->keep_bclk = true;
> +
> + of_property_read_u32(np, "ti,burst-bclkdiv", 
> >burst_bclkdiv);
> + } else {
> + dev_err(>dev, "Platform data not set\n");
> + return -ENODEV;
> + }
>   if (!dac33->mode1_latency)
>   dac33->mode1_latency = 1; /* 10ms */
>   dac33->irq = client->irq;
> @@ -1574,9 +1588,16 @@ static const struct i2c_device_id tlv320dac33_i2c_id[] 
> = {
>  };
>  MODULE_DEVICE_TABLE(i2c, tlv320dac33_i2c_id);
>  
> +static const struct of_device_id tlv320dac33_of_match[] = {
> + { .compatible = "ti,tlv320dac33", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(i2c, tlv320dac33_of_match);
> +
>  static struct i2c_driver tlv320dac33_i2c_driver = {
>   .driver = {
>   .name = "tlv320dac33-codec",
> + .of_match_table = of_match_ptr(tlv320dac33_of_match),
>   },
>   .probe  = dac33_i2c_probe,
>   .remove = dac33_i2c_remove,
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 

Re: [PATCH v2 2/3] devres: Add devm_ioremap_shared_resource()

[Ladislav Michl]

On Wed, Jan 24, 2018 at 06:21:38PM +0200, Andy Shevchenko wrote:
> On Wed, Jan 24, 2018 at 12:07 PM, Ladislav Michl <la...@linux-mips.org> wrote:
> > Implement managed ioremap function for shared resources.
> 
> > +#define devm_ioremap_resource(dev, res) \
> > +   __devm_ioremap_resource(dev, res, false)
> > +#define devm_ioremap_shared_resource(dev, res) \
> > +   __devm_ioremap_resource(dev, res, true)
> > +void __iomem *__devm_ioremap_resource(struct device *dev, struct resource 
> > *res,
> > + bool shared);
> 
> I would rather do the following:
> 
> _resource() ->  _resource_exclusive()
> 
> #define _resource()  _resource_exclusive()
> 
> Add _resource_shared()
> 
> And use long names below in this file whenever refer to exclusive or
> shared variant.

Two separate functions were also considered, but I was unable to find small
common implementation. If code size does not matter or you can provide a hint
to make this solution small and nice, I'll go for it.

> >  void devm_iounmap(struct device *dev, void __iomem *addr);
> >  int check_signature(const volatile void __iomem *io_addr,
> > const unsigned char *signature, int length);
> > +
> >  void devm_ioremap_release(struct device *dev, void *res);
> 
> This part doesn't belong to the change.
> 
> > + * When possible, use devm_ioremap_resource() or
> > + * devm_ioremap_shared_resource() instead.
> > - * Checks that a resource is a valid memory region, requests the memory
> > - * region and ioremaps it. All operations are managed and will be undone
> > - * on driver detach.
> > + * Checks that a resource is a valid memory region, eventually requests the
> > + * memory region and ioremaps it. All operations are managed and will be
> > + * undone on driver detach.
> 
> Wording is changed and no clue in commit message why.

Above will be moved to separate patch.

ladis

Re: [PATCH v2 2/3] devres: Add devm_ioremap_shared_resource()

[Ladislav Michl]

On Wed, Jan 24, 2018 at 06:21:38PM +0200, Andy Shevchenko wrote:
> On Wed, Jan 24, 2018 at 12:07 PM, Ladislav Michl  wrote:
> > Implement managed ioremap function for shared resources.
> 
> > +#define devm_ioremap_resource(dev, res) \
> > +   __devm_ioremap_resource(dev, res, false)
> > +#define devm_ioremap_shared_resource(dev, res) \
> > +   __devm_ioremap_resource(dev, res, true)
> > +void __iomem *__devm_ioremap_resource(struct device *dev, struct resource 
> > *res,
> > + bool shared);
> 
> I would rather do the following:
> 
> _resource() ->  _resource_exclusive()
> 
> #define _resource()  _resource_exclusive()
> 
> Add _resource_shared()
> 
> And use long names below in this file whenever refer to exclusive or
> shared variant.

Two separate functions were also considered, but I was unable to find small
common implementation. If code size does not matter or you can provide a hint
to make this solution small and nice, I'll go for it.

> >  void devm_iounmap(struct device *dev, void __iomem *addr);
> >  int check_signature(const volatile void __iomem *io_addr,
> > const unsigned char *signature, int length);
> > +
> >  void devm_ioremap_release(struct device *dev, void *res);
> 
> This part doesn't belong to the change.
> 
> > + * When possible, use devm_ioremap_resource() or
> > + * devm_ioremap_shared_resource() instead.
> > - * Checks that a resource is a valid memory region, requests the memory
> > - * region and ioremaps it. All operations are managed and will be undone
> > - * on driver detach.
> > + * Checks that a resource is a valid memory region, eventually requests the
> > + * memory region and ioremaps it. All operations are managed and will be
> > + * undone on driver detach.
> 
> Wording is changed and no clue in commit message why.

Above will be moved to separate patch.

ladis

[PATCH v2 0/3] Add managed ioremap function for shared resources

[Ladislav Michl]

Many drivers can simplified by using devm_ioremap_resource()
instead of open coding its functionality. However, as pointed
by Wei Yongjun, that function cannot be used when memory region
is already taken. See previous discussion here:
https://www.spinics.net/lists/linux-pci/msg68495.html

To ease job of driver developers, new function for that
purpose is implemented and its usage shown on davinci
mtd driver.

Changes from previous version:
- moved function prototype in headers other way around (PATCH 1/3),
  the rest of patches was dropped.

Ladislav Michl (3):
  devres: Move devm_ioremap_resource() out of device.h
  devres: Add devm_ioremap_shared_resource()
  mtd: nand: davinci: Use devm_ioremap_shared_resource()

 drivers/mtd/nand/davinci_nand.c | 24 +++-
 include/linux/device.h  |  2 --
 include/linux/io.h  |  7 +++
 lib/devres.c| 22 ++
 4 files changed, 28 insertions(+), 27 deletions(-)

-- 
2.15.1

[PATCH v2 0/3] Add managed ioremap function for shared resources

[Ladislav Michl]

Many drivers can simplified by using devm_ioremap_resource()
instead of open coding its functionality. However, as pointed
by Wei Yongjun, that function cannot be used when memory region
is already taken. See previous discussion here:
https://www.spinics.net/lists/linux-pci/msg68495.html

To ease job of driver developers, new function for that
purpose is implemented and its usage shown on davinci
mtd driver.

Changes from previous version:
- moved function prototype in headers other way around (PATCH 1/3),
  the rest of patches was dropped.

Ladislav Michl (3):
  devres: Move devm_ioremap_resource() out of device.h
  devres: Add devm_ioremap_shared_resource()
  mtd: nand: davinci: Use devm_ioremap_shared_resource()

 drivers/mtd/nand/davinci_nand.c | 24 +++-
 include/linux/device.h  |  2 --
 include/linux/io.h  |  7 +++
 lib/devres.c| 22 ++
 4 files changed, 28 insertions(+), 27 deletions(-)

-- 
2.15.1

[PATCH v2 2/3] devres: Add devm_ioremap_shared_resource()

[Ladislav Michl]

Implement managed ioremap function for shared resources.

Signed-off-by: Ladislav Michl <la...@linux-mips.org>
---
 Changes:
 - v2: Rebased on top of PATCH v2 1/3

 include/linux/io.h |  8 +++-
 lib/devres.c   | 22 ++
 2 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/include/linux/io.h b/include/linux/io.h
index 2aea3363bfb2..2b9eb48e0f49 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -79,10 +79,16 @@ void __iomem *devm_ioremap_nocache(struct device *dev, 
resource_size_t offset,
   resource_size_t size);
 void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
   resource_size_t size);
-void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
+#define devm_ioremap_resource(dev, res) \
+   __devm_ioremap_resource(dev, res, false)
+#define devm_ioremap_shared_resource(dev, res) \
+   __devm_ioremap_resource(dev, res, true)
+void __iomem *__devm_ioremap_resource(struct device *dev, struct resource *res,
+ bool shared);
 void devm_iounmap(struct device *dev, void __iomem *addr);
 int check_signature(const volatile void __iomem *io_addr,
const unsigned char *signature, int length);
+
 void devm_ioremap_release(struct device *dev, void *res);
 
 void *devm_memremap(struct device *dev, resource_size_t offset,
diff --git a/lib/devres.c b/lib/devres.c
index 5f2aedd58bc5..7711ff40a572 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -22,6 +22,9 @@ static int devm_ioremap_match(struct device *dev, void *res, 
void *match_data)
  * @size: Size of map
  *
  * Managed ioremap().  Map is automatically unmapped on driver detach.
+ *
+ * When possible, use devm_ioremap_resource() or
+ * devm_ioremap_shared_resource() instead.
  */
 void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,
   resource_size_t size)
@@ -116,13 +119,14 @@ void devm_iounmap(struct device *dev, void __iomem *addr)
 EXPORT_SYMBOL(devm_iounmap);
 
 /**
- * devm_ioremap_resource() - check, request region, and ioremap resource
+ * __devm_ioremap_resource() - check, request region, and ioremap resource
  * @dev: generic device to handle the resource for
  * @res: resource to be handled
+ * @shared: region is not requested when true
  *
- * Checks that a resource is a valid memory region, requests the memory
- * region and ioremaps it. All operations are managed and will be undone
- * on driver detach.
+ * Checks that a resource is a valid memory region, eventually requests the
+ * memory region and ioremaps it. All operations are managed and will be
+ * undone on driver detach.
  *
  * Returns a pointer to the remapped memory or an ERR_PTR() encoded error code
  * on failure. Usage example:
@@ -132,7 +136,8 @@ EXPORT_SYMBOL(devm_iounmap);
  * if (IS_ERR(base))
  * return PTR_ERR(base);
  */
-void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res)
+void __iomem *__devm_ioremap_resource(struct device *dev, struct resource *res,
+ bool shared)
 {
resource_size_t size;
const char *name;
@@ -148,7 +153,7 @@ void __iomem *devm_ioremap_resource(struct device *dev, 
struct resource *res)
size = resource_size(res);
name = res->name ?: dev_name(dev);
 
-   if (!devm_request_mem_region(dev, res->start, size, name)) {
+   if (!shared && !devm_request_mem_region(dev, res->start, size, name)) {
dev_err(dev, "can't request region for resource %pR\n", res);
return IOMEM_ERR_PTR(-EBUSY);
}
@@ -156,13 +161,14 @@ void __iomem *devm_ioremap_resource(struct device *dev, 
struct resource *res)
dest_ptr = devm_ioremap(dev, res->start, size);
if (!dest_ptr) {
dev_err(dev, "ioremap failed for resource %pR\n", res);
-   devm_release_mem_region(dev, res->start, size);
+   if (!shared)
+   devm_release_mem_region(dev, res->start, size);
dest_ptr = IOMEM_ERR_PTR(-ENOMEM);
}
 
return dest_ptr;
 }
-EXPORT_SYMBOL(devm_ioremap_resource);
+EXPORT_SYMBOL(__devm_ioremap_resource);
 
 #ifdef CONFIG_HAS_IOPORT_MAP
 /*
-- 
2.15.1