From: Arnd Bergmann <arnd@arndb.de>

This revisits a series I sent a few years ago:

https://lore.kernel.org/lkml/20191018154052.1276506-1-arnd@arndb.de/

All the other ARMv5 conversions are under way now, with
OMAP1 being the only one still not in linux-next yet,
and PXA completing the set.

Most of the patches are unchanged from before, furtunately
the PXA code is fairly stable. I addressed Robert's comments,
pulled in two patches from Dmitry, and added the last a the
final four patches to finish off the multiplatform conversion.

I hope someone is left to test these on PXA: if this works,
I'd like to merge it for 5.19. A git tree with these is avaialable
for testing at

https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/log/?h=pxa-multiplatform-5.18

    Arnd

Arnd Bergmann (46):
  ARM: pxa: split mach/generic.h
  ARM: pxa: make mainstone.h private
  ARM: pxa: make mach/regs-uart.h private
  ARM: pxa: remove mach/dma.h
  ARM: pxa: split up mach/hardware.h
  ARM: pxa: stop using mach/bitfield.h
  ARM: pxa: move mach/sound.h to linux/platform_data/
  ARM: pxa: move regs-lcd.h into driver
  watchdog: sa1100: use platform device registration
  ARM: pxa: pxa2xx-ac97-lib: use IRQ resource
  ARM: pxa: move pcmcia board data into mach-pxa
  ARM: pxa: make addr-map.h header local
  ARM: pxa: use pdev resource for palmld mmio
  ARM: pxa: maybe fix gpio lookup tables
  ARM: pxa: tosa: use gpio descriptor for audio
  ARM: pxa: poodle: use platform data for poodle asoc driver
  ARM: pxa: corgi: use gpio descriptors for audio
  ARM: pxa: hx4700: use gpio descriptors for audio
  ARM: pxa: lubbock: pass udc irqs as resource
  ARM: pxa: spitz: use gpio descriptors for audio
  ARM: pxa: eseries: use gpio lookup for audio
  ARM: pxa: z2: use gpio lookup for audio device
  ARM: pxa: magician: use platform driver for audio
  ARM: pxa: mainstone-wm97xx: use gpio lookup table
  ARM: pxa: zylonite: use gpio lookup instead mfp header
  input: touchscreen: mainstone: fix pxa2xx+pxa3xx configuration
  input: touchscreen: mainstone: sync with zylonite driver
  Input: touchscreen: use wrapper for pxa2xx ac97 registers
  ASoC: pxa: use pdev resource for FIFO regs
  ASoC: pxa: ac97: use normal MMIO accessors
  ASoC: pxa: i2s: use normal MMIO accessors
  ARM: pxa: pcmcia: move smemc configuration back to arch
  ARM: pxa: remove get_clk_frequency_khz()
  cpufreq: pxa3: move clk register access to clk driver
  ARM: pxa: move smemc register access from clk to platform
  ARM: pxa: move clk register definitions to driver
  power: tosa: simplify probe function
  ARM: pxa: tosa: use gpio lookup for battery
  ARM: pxa: remove unused mach/bitfield.h
  ARM: mmp: remove tavorevb board support
  ARM: mmp: rename pxa_register_device
  ARM: pxa: move plat-pxa to drivers/soc/
  ARM: PXA: fix multi-cpu build of xsc3
  ARM: pxa: move mach/*.h to mach-pxa/
  ARM: pxa: remove support for MTD_XIP
  ARM: pxa: convert to multiplatform

Dmitry Torokhov (2):
  Input: wm97xx - switch to using threaded IRQ
  Input: wm97xx - get rid of irq_enable method in wm97xx_mach_ops

 arch/arm/Kconfig                              |  22 --
 arch/arm/Makefile                             |   1 -
 arch/arm/common/locomo.c                      |   1 -
 arch/arm/common/sa1111.c                      |   5 +-
 arch/arm/include/asm/hardware/sa1111.h        |   2 -
 arch/arm/mach-mmp/Kconfig                     |  10 +-
 arch/arm/mach-mmp/Makefile                    |   1 -
 arch/arm/mach-mmp/devices.c                   |   2 +-
 arch/arm/mach-mmp/devices.h                   |  10 +-
 arch/arm/mach-mmp/mfp.h                       |   2 +-
 arch/arm/mach-mmp/mmp2.h                      |  48 ++---
 arch/arm/mach-mmp/pxa168.h                    |  60 +++---
 arch/arm/mach-mmp/pxa910.h                    |  38 ++--
 arch/arm/mach-mmp/tavorevb.c                  | 113 -----------
 arch/arm/mach-mmp/ttc_dkb.c                   |   6 +-
 arch/arm/mach-pxa/Kconfig                     |  14 ++
 arch/arm/mach-pxa/Makefile                    |  18 +-
 arch/arm/mach-pxa/Makefile.boot               |   3 -
 .../mach-pxa/{include/mach => }/addr-map.h    |   0
 arch/arm/mach-pxa/am300epd.c                  |   2 +-
 .../arm/mach-pxa/balloon3-pcmcia.c            |   4 +-
 arch/arm/mach-pxa/balloon3.c                  |   4 +-
 .../mach-pxa/{include/mach => }/balloon3.h    |   0
 arch/arm/mach-pxa/cm-x300.c                   |  12 +-
 arch/arm/mach-pxa/colibri-evalboard.c         |   1 -
 .../arm/mach-pxa/colibri-pcmcia.c             |   2 +-
 arch/arm/mach-pxa/colibri-pxa270-income.c     |   1 -
 arch/arm/mach-pxa/colibri-pxa270.c            |   2 +-
 arch/arm/mach-pxa/colibri-pxa300.c            |   3 +-
 arch/arm/mach-pxa/colibri-pxa320.c            |   2 +-
 arch/arm/mach-pxa/colibri-pxa3xx.c            |   3 +-
 arch/arm/mach-pxa/colibri.h                   |   2 +-
 arch/arm/mach-pxa/corgi.c                     |  23 ++-
 arch/arm/mach-pxa/{include/mach => }/corgi.h  |   0
 arch/arm/mach-pxa/corgi_pm.c                  |   5 +-
 arch/arm/mach-pxa/csb726.c                    |   5 +-
 arch/arm/mach-pxa/csb726.h                    |   2 +-
 arch/arm/mach-pxa/devices.c                   |  17 +-
 .../arm/mach-pxa/e740-pcmcia.c                |   4 +-
 .../{include/mach => }/eseries-gpio.h         |   0
 arch/arm/mach-pxa/eseries.c                   |  36 +++-
 arch/arm/mach-pxa/ezx.c                       |   1 -
 arch/arm/mach-pxa/generic.c                   |  62 ++++--
 arch/arm/mach-pxa/generic.h                   |   9 -
 arch/arm/mach-pxa/gumstix.c                   |   1 -
 arch/arm/mach-pxa/gumstix.h                   |   2 +-
 arch/arm/mach-pxa/h5000.c                     |   2 +-
 .../arm/mach-pxa/hx4700-pcmcia.c              |   4 +-
 arch/arm/mach-pxa/hx4700.c                    |  18 +-
 arch/arm/mach-pxa/{include/mach => }/hx4700.h |   0
 arch/arm/mach-pxa/idp.c                       |   2 -
 arch/arm/mach-pxa/idp.h                       |   2 +-
 arch/arm/mach-pxa/include/mach/bitfield.h     | 114 -----------
 arch/arm/mach-pxa/include/mach/dma.h          |  17 --
 arch/arm/mach-pxa/include/mach/generic.h      |   1 -
 arch/arm/mach-pxa/include/mach/mtd-xip.h      |  36 ----
 arch/arm/mach-pxa/include/mach/uncompress.h   |  70 -------
 arch/arm/mach-pxa/irq.c                       |   5 +-
 arch/arm/mach-pxa/{include/mach => }/irqs.h   |   0
 arch/arm/mach-pxa/littleton.c                 |   1 -
 arch/arm/mach-pxa/lpd270.c                    |   6 +-
 arch/arm/mach-pxa/lubbock.c                   |  17 +-
 .../arm/mach-pxa/{include/mach => }/lubbock.h |   4 +-
 arch/arm/mach-pxa/magician.c                  |  56 +++++-
 .../mach-pxa/{include/mach => }/magician.h    |   2 +-
 arch/arm/mach-pxa/mainstone.c                 |  17 +-
 .../mach-pxa/{include/mach => }/mainstone.h   |   4 +-
 arch/arm/mach-pxa/mfp-pxa2xx.c                |   3 +-
 arch/arm/mach-pxa/mfp-pxa2xx.h                |   2 +-
 arch/arm/mach-pxa/mfp-pxa3xx.c                |   3 +-
 arch/arm/mach-pxa/mfp-pxa3xx.h                |   2 +-
 arch/arm/mach-pxa/{include/mach => }/mfp.h    |   2 +-
 arch/arm/mach-pxa/mioa701.c                   |   4 +-
 arch/arm/mach-pxa/mxm8x10.c                   |   8 +-
 arch/arm/mach-pxa/palm27x.c                   |   2 +-
 .../arm/mach-pxa/palmld-pcmcia.c              |   5 +-
 arch/arm/mach-pxa/palmld.c                    |  23 ++-
 arch/arm/mach-pxa/{include/mach => }/palmld.h |   0
 arch/arm/mach-pxa/palmt5.c                    |  11 +-
 arch/arm/mach-pxa/palmt5.h                    |   2 +-
 .../arm/mach-pxa/palmtc-pcmcia.c              |   4 +-
 arch/arm/mach-pxa/palmtc.c                    |   4 +-
 arch/arm/mach-pxa/{include/mach => }/palmtc.h |   0
 arch/arm/mach-pxa/palmte2.c                   |   2 +-
 arch/arm/mach-pxa/palmtreo.c                  |   4 +-
 .../arm/mach-pxa/palmtx-pcmcia.c              |   4 +-
 arch/arm/mach-pxa/palmtx.c                    |  13 +-
 arch/arm/mach-pxa/{include/mach => }/palmtx.h |   0
 arch/arm/mach-pxa/palmz72.c                   |   2 +-
 arch/arm/mach-pxa/pcm027.h                    |   2 +-
 arch/arm/mach-pxa/pcm990-baseboard.c          |   2 +-
 arch/arm/mach-pxa/pcm990_baseboard.h          |   2 +-
 arch/arm/mach-pxa/poodle.c                    |  31 ++-
 arch/arm/mach-pxa/{include/mach => }/poodle.h |   2 -
 arch/arm/mach-pxa/pxa-dt.c                    |   2 +-
 arch/arm/mach-pxa/pxa-regs.h                  |  52 +++++
 arch/arm/mach-pxa/pxa25x.c                    |  12 +-
 arch/arm/mach-pxa/pxa25x.h                    |   6 +-
 arch/arm/mach-pxa/pxa27x-udc.h                |   2 +
 arch/arm/mach-pxa/pxa27x.c                    |  12 +-
 arch/arm/mach-pxa/pxa27x.h                    |   6 +-
 .../mach-pxa/{include/mach => }/pxa2xx-regs.h |  47 +----
 arch/arm/mach-pxa/pxa2xx.c                    |  30 ++-
 arch/arm/mach-pxa/pxa300.c                    |   1 +
 arch/arm/mach-pxa/pxa320.c                    |   1 +
 .../mach-pxa/{include/mach => }/pxa3xx-regs.h |  71 +------
 arch/arm/mach-pxa/pxa3xx-ulpi.c               |   2 +-
 arch/arm/mach-pxa/pxa3xx.c                    |  19 +-
 arch/arm/mach-pxa/pxa3xx.h                    |   6 +-
 arch/arm/mach-pxa/pxa930.c                    |   1 +
 .../mach-pxa/{include/mach => }/regs-ost.h    |   4 +-
 arch/arm/mach-pxa/regs-rtc.h                  |   2 +-
 arch/arm/mach-pxa/regs-u2d.h                  |   2 -
 .../mach-pxa/{include/mach => }/regs-uart.h   |   2 +
 arch/arm/mach-pxa/reset.c                     |   9 +-
 arch/arm/mach-pxa/{include/mach => }/reset.h  |   2 +-
 arch/arm/mach-pxa/sharpsl_pm.c                |   2 +-
 arch/arm/mach-pxa/sleep.S                     |   9 +-
 arch/arm/mach-pxa/smemc.c                     |  13 +-
 arch/arm/mach-pxa/{include/mach => }/smemc.h  |   0
 arch/arm/mach-pxa/spitz.c                     |  37 +++-
 arch/arm/mach-pxa/{include/mach => }/spitz.h  |   0
 arch/arm/mach-pxa/spitz_pm.c                  |   3 +-
 arch/arm/mach-pxa/standby.S                   |   3 +-
 arch/arm/mach-pxa/tosa.c                      |  47 ++++-
 arch/arm/mach-pxa/{include/mach => }/tosa.h   |   0
 .../arm/mach-pxa/trizeps4-pcmcia.c            |   6 +-
 arch/arm/mach-pxa/trizeps4.c                  |   6 +-
 .../mach-pxa/{include/mach => }/trizeps4.h    |   1 +
 .../arm/mach-pxa/viper-pcmcia.c               |   6 +-
 .../arm/mach-pxa/viper-pcmcia.h               |   0
 arch/arm/mach-pxa/viper.c                     |   8 +-
 .../arm/mach-pxa/vpac270-pcmcia.c             |   4 +-
 arch/arm/mach-pxa/vpac270.c                   |   4 +-
 .../arm/mach-pxa/{include/mach => }/vpac270.h |   0
 arch/arm/mach-pxa/xcep.c                      |   4 +-
 arch/arm/mach-pxa/z2.c                        |  13 +-
 arch/arm/mach-pxa/{include/mach => }/z2.h     |   0
 arch/arm/mach-pxa/zeus.c                      |   8 +-
 arch/arm/mach-pxa/zylonite.c                  |  34 +++-
 arch/arm/mach-pxa/zylonite.h                  |   2 +
 arch/arm/mach-pxa/zylonite_pxa300.c           |   1 +
 arch/arm/mach-pxa/zylonite_pxa320.c           |   1 +
 arch/arm/mach-sa1100/generic.c                |   6 +-
 arch/arm/mach-sa1100/include/mach/reset.h     |   1 -
 arch/arm/mm/copypage-xsc3.c                   |   2 +
 arch/mips/alchemy/devboards/db1300.c          |   9 -
 drivers/ata/pata_palmld.c                     |   3 +-
 drivers/clk/pxa/clk-pxa.c                     |   8 +-
 drivers/clk/pxa/clk-pxa.h                     |   9 +-
 drivers/clk/pxa/clk-pxa25x.c                  |  46 ++---
 drivers/clk/pxa/clk-pxa27x.c                  |  68 +++----
 drivers/clk/pxa/clk-pxa2xx.h                  |  58 ++++++
 drivers/clk/pxa/clk-pxa3xx.c                  | 139 +++++++++++--
 drivers/cpufreq/pxa2xx-cpufreq.c              |   6 +-
 drivers/cpufreq/pxa3xx-cpufreq.c              |  65 +++---
 drivers/input/mouse/pxa930_trkball.c          |   1 -
 drivers/input/touchscreen/Kconfig             |   2 +
 drivers/input/touchscreen/mainstone-wm97xx.c  | 130 ++++++------
 drivers/input/touchscreen/wm97xx-core.c       |  42 +---
 drivers/input/touchscreen/zylonite-wm97xx.c   |  43 ++--
 drivers/leds/leds-locomo.c                    |   1 -
 drivers/mmc/host/pxamci.c                     |   2 +-
 drivers/mtd/maps/pxa2xx-flash.c               |   2 -
 drivers/pcmcia/Makefile                       |  13 --
 drivers/pcmcia/pxa2xx_base.c                  |  48 ++---
 drivers/pcmcia/pxa2xx_sharpsl.c               |   3 +-
 drivers/pcmcia/sa1111_generic.c               |   1 -
 drivers/pcmcia/sa1111_lubbock.c               |   1 -
 drivers/pcmcia/soc_common.c                   |   2 -
 drivers/pcmcia/soc_common.h                   | 120 +----------
 drivers/power/supply/tosa_battery.c           | 189 ++++++++++--------
 drivers/rtc/rtc-pxa.c                         |   2 -
 drivers/soc/Kconfig                           |   1 +
 drivers/soc/Makefile                          |   1 +
 .../arm/plat-pxa => drivers/soc/pxa}/Kconfig  |   5 +-
 .../arm/plat-pxa => drivers/soc/pxa}/Makefile |   4 -
 {arch/arm/plat-pxa => drivers/soc/pxa}/mfp.c  |   2 +-
 {arch/arm/plat-pxa => drivers/soc/pxa}/ssp.c  |   0
 drivers/usb/gadget/udc/pxa25x_udc.c           |  37 ++--
 drivers/usb/gadget/udc/pxa25x_udc.h           |   7 +-
 drivers/usb/host/ohci-pxa27x.c                |   3 +-
 .../video/fbdev/pxa3xx-regs.h                 |  24 +--
 drivers/video/fbdev/pxafb.c                   |   4 +-
 drivers/watchdog/sa1100_wdt.c                 |  88 +++++---
 include/linux/clk/pxa.h                       |  16 ++
 include/linux/platform_data/asoc-poodle.h     |  16 ++
 .../linux/platform_data/asoc-pxa.h            |   4 +-
 include/linux/platform_data/video-pxafb.h     |  22 +-
 .../hardware.h => include/linux/soc/pxa/cpu.h |  61 +-----
 .../plat => include/linux/soc/pxa}/mfp.h      |   6 +-
 include/linux/soc/pxa/smemc.h                 |  13 ++
 include/linux/wm97xx.h                        |   4 -
 include/pcmcia/soc_common.h                   | 125 ++++++++++++
 include/sound/pxa2xx-lib.h                    |   4 +
 sound/arm/pxa2xx-ac97-lib.c                   | 145 +++++++++-----
 .../arm/pxa2xx-ac97-regs.h                    |  42 ++--
 sound/arm/pxa2xx-ac97.c                       |   3 +-
 sound/soc/pxa/corgi.c                         |  43 ++--
 sound/soc/pxa/e740_wm9705.c                   |  37 ++--
 sound/soc/pxa/e750_wm9705.c                   |  33 ++-
 sound/soc/pxa/e800_wm9712.c                   |  33 ++-
 sound/soc/pxa/em-x270.c                       |   2 +-
 sound/soc/pxa/hx4700.c                        |  34 ++--
 sound/soc/pxa/magician.c                      | 141 ++++---------
 sound/soc/pxa/mioa701_wm9713.c                |   2 +-
 sound/soc/pxa/palm27x.c                       |   2 +-
 sound/soc/pxa/poodle.c                        |  51 ++---
 sound/soc/pxa/pxa2xx-ac97.c                   |  24 ++-
 sound/soc/pxa/pxa2xx-i2s.c                    | 112 ++++++-----
 sound/soc/pxa/spitz.c                         |  58 +++---
 sound/soc/pxa/tosa.c                          |  18 +-
 sound/soc/pxa/z2.c                            |   8 +-
 213 files changed, 1902 insertions(+), 1936 deletions(-)
 delete mode 100644 arch/arm/mach-mmp/tavorevb.c
 delete mode 100644 arch/arm/mach-pxa/Makefile.boot
 rename arch/arm/mach-pxa/{include/mach => }/addr-map.h (100%)
 rename drivers/pcmcia/pxa2xx_balloon3.c => arch/arm/mach-pxa/balloon3-pcmcia.c (98%)
 rename arch/arm/mach-pxa/{include/mach => }/balloon3.h (100%)
 rename drivers/pcmcia/pxa2xx_colibri.c => arch/arm/mach-pxa/colibri-pcmcia.c (99%)
 rename arch/arm/mach-pxa/{include/mach => }/corgi.h (100%)
 rename drivers/pcmcia/pxa2xx_e740.c => arch/arm/mach-pxa/e740-pcmcia.c (98%)
 rename arch/arm/mach-pxa/{include/mach => }/eseries-gpio.h (100%)
 rename drivers/pcmcia/pxa2xx_hx4700.c => arch/arm/mach-pxa/hx4700-pcmcia.c (98%)
 rename arch/arm/mach-pxa/{include/mach => }/hx4700.h (100%)
 delete mode 100644 arch/arm/mach-pxa/include/mach/bitfield.h
 delete mode 100644 arch/arm/mach-pxa/include/mach/dma.h
 delete mode 100644 arch/arm/mach-pxa/include/mach/generic.h
 delete mode 100644 arch/arm/mach-pxa/include/mach/mtd-xip.h
 delete mode 100644 arch/arm/mach-pxa/include/mach/uncompress.h
 rename arch/arm/mach-pxa/{include/mach => }/irqs.h (100%)
 rename arch/arm/mach-pxa/{include/mach => }/lubbock.h (95%)
 rename arch/arm/mach-pxa/{include/mach => }/magician.h (99%)
 rename arch/arm/mach-pxa/{include/mach => }/mainstone.h (98%)
 rename arch/arm/mach-pxa/{include/mach => }/mfp.h (91%)
 rename drivers/pcmcia/pxa2xx_palmld.c => arch/arm/mach-pxa/palmld-pcmcia.c (98%)
 rename arch/arm/mach-pxa/{include/mach => }/palmld.h (100%)
 rename drivers/pcmcia/pxa2xx_palmtc.c => arch/arm/mach-pxa/palmtc-pcmcia.c (98%)
 rename arch/arm/mach-pxa/{include/mach => }/palmtc.h (100%)
 rename drivers/pcmcia/pxa2xx_palmtx.c => arch/arm/mach-pxa/palmtx-pcmcia.c (98%)
 rename arch/arm/mach-pxa/{include/mach => }/palmtx.h (100%)
 rename arch/arm/mach-pxa/{include/mach => }/poodle.h (98%)
 create mode 100644 arch/arm/mach-pxa/pxa-regs.h
 rename arch/arm/mach-pxa/{include/mach => }/pxa2xx-regs.h (76%)
 rename arch/arm/mach-pxa/{include/mach => }/pxa3xx-regs.h (61%)
 rename arch/arm/mach-pxa/{include/mach => }/regs-ost.h (94%)
 rename arch/arm/mach-pxa/{include/mach => }/regs-uart.h (99%)
 rename arch/arm/mach-pxa/{include/mach => }/reset.h (92%)
 rename arch/arm/mach-pxa/{include/mach => }/smemc.h (100%)
 rename arch/arm/mach-pxa/{include/mach => }/spitz.h (100%)
 rename arch/arm/mach-pxa/{include/mach => }/tosa.h (100%)
 rename drivers/pcmcia/pxa2xx_trizeps4.c => arch/arm/mach-pxa/trizeps4-pcmcia.c (98%)
 rename arch/arm/mach-pxa/{include/mach => }/trizeps4.h (99%)
 rename drivers/pcmcia/pxa2xx_viper.c => arch/arm/mach-pxa/viper-pcmcia.c (97%)
 rename include/linux/platform_data/pcmcia-pxa2xx_viper.h => arch/arm/mach-pxa/viper-pcmcia.h (100%)
 rename drivers/pcmcia/pxa2xx_vpac270.c => arch/arm/mach-pxa/vpac270-pcmcia.c (98%)
 rename arch/arm/mach-pxa/{include/mach => }/vpac270.h (100%)
 rename arch/arm/mach-pxa/{include/mach => }/z2.h (100%)
 create mode 100644 drivers/clk/pxa/clk-pxa2xx.h
 rename {arch/arm/plat-pxa => drivers/soc/pxa}/Kconfig (83%)
 rename {arch/arm/plat-pxa => drivers/soc/pxa}/Makefile (51%)
 rename {arch/arm/plat-pxa => drivers/soc/pxa}/mfp.c (99%)
 rename {arch/arm/plat-pxa => drivers/soc/pxa}/ssp.c (100%)
 rename arch/arm/mach-pxa/include/mach/regs-lcd.h => drivers/video/fbdev/pxa3xx-regs.h (90%)
 create mode 100644 include/linux/clk/pxa.h
 create mode 100644 include/linux/platform_data/asoc-poodle.h
 rename arch/arm/mach-pxa/include/mach/audio.h => include/linux/platform_data/asoc-pxa.h (93%)
 rename arch/arm/mach-pxa/include/mach/hardware.h => include/linux/soc/pxa/cpu.h (75%)
 rename {arch/arm/plat-pxa/include/plat => include/linux/soc/pxa}/mfp.h (98%)
 create mode 100644 include/linux/soc/pxa/smemc.h
 create mode 100644 include/pcmcia/soc_common.h
 rename arch/arm/mach-pxa/include/mach/regs-ac97.h => sound/arm/pxa2xx-ac97-regs.h (71%)

-- 
2.29.2

Cc: Daniel Mack <daniel@zonque.org>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Philipp Zabel <philipp.zabel@gmail.com>
Cc: Lubomir Rintel <lkundrak@v3.sk>
Cc: Paul Parsons <lost.distance@yahoo.com>
Cc: Tomas Cech <sleep_walker@suse.com>
Cc: Sergey Lapin <slapin@ossfans.org>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Helge Deller <deller@gmx.de>
Cc: Mark Brown <broonie@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@vger.kernel.org
Cc: linux-ide@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-input@vger.kernel.org
Cc: patches@opensource.cirrus.com
Cc: linux-leds@vger.kernel.org
Cc: linux-mmc@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-rtc@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: alsa-devel@alsa-project.org

On Tue, Apr 19, 2022 at 06:37:22PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> This revisits a series I sent a few years ago:
> 
> https://lore.kernel.org/lkml/20191018154052.1276506-1-arnd@arndb.de/
> 
> All the other ARMv5 conversions are under way now, with
> OMAP1 being the only one still not in linux-next yet,
> and PXA completing the set.
> 
> Most of the patches are unchanged from before, furtunately
> the PXA code is fairly stable. I addressed Robert's comments,
> pulled in two patches from Dmitry, and added the last a the
> final four patches to finish off the multiplatform conversion.
> 
> I hope someone is left to test these on PXA: if this works,
> I'd like to merge it for 5.19. A git tree with these is avaialable
> for testing at
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/log/?h=pxa-multiplatform-5.18
> 

Unfortunately that crashes for me when trying to boot from ide.
Bisect points to the last patch of the series.

Guenter

---
[    1.403715] 8<--- cut here ---
[    1.403848] Unable to handle kernel paging request at virtual address feeb000e
[    1.404097] [feeb000e] *pgd=00000000
[    1.404400] Internal error: Oops: 805 [#1] PREEMPT ARM
[    1.404648] Modules linked in:
[    1.404890] CPU: 0 PID: 22 Comm: pccardd Not tainted 5.18.0-rc3-next-20220422 #1
[    1.405159] Hardware name: SHARP Borzoi
[    1.405319] PC is at pcmcia_init_one+0xf8/0x27c
[    1.405476] LR is at devres_add+0x40/0x6c
[    1.405611] pc : [<c04bdea0>]    lr : [<c044d808>]    psr: a0000113
[    1.405846] sp : c48a5d00  ip : c15f4220  fp : 60000113
[    1.406026] r10: 00000000  r9 : c48b000e  r8 : c48b0000
[    1.406195] r7 : feeb0000  r6 : feeb000e  r5 : c15ec090  r4 : c15ec020
[    1.406395] r3 : 00000002  r2 : 00000000  r1 : c15f4200  r0 : feeb000e
[    1.406615] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[    1.406847] Control: 00007977  Table: a0004000  DAC: 00000071
[    1.407042] Register r0 information: 0-page vmalloc region starting at 0xfee00000 allocated at pci_reserve_io+0x0/0x38
[    1.407453] Register r1 information: slab
[    1.407721] Register r2 information: NULL pointer
[    1.407885] Register r3 information: non-paged memory
[    1.408047] Register r4 information: slab
[    1.408179] Register r5 information: slab
[    1.408310] Register r6 information: 0-page vmalloc region starting at 0xfee00000 allocated at pci_reserve_io+0x0/0x38
[    1.408622] Register r7 information: 0-page vmalloc region starting at 0xfee00000 allocated at pci_reserve_io+0x0/0x38
[    1.408941] Register r8 information: 0-page vmalloc region starting at 0xc48b0000 allocated at soc_pcmcia_add_one+0xf0/0x370
[    1.409291] Register r9 information: 0-page vmalloc region starting at 0xc48b0000 allocated at soc_pcmcia_add_one+0xf0/0x370
[    1.409617] Register r10 information: NULL pointer
[    1.409768] Register r11 information: non-paged memory
[    1.409924] Register r12 information: slab
[    1.410066] Process pccardd (pid: 22, stack limit = 0x(ptrval))
[    1.410268] Stack: (0xc48a5d00 to 0xc48a6000)
[    1.410448] 5d00: c15ebb78 00000000 0000001a 00000110 00000000 c0ad702c ff00051a c15ec090
[    1.410694] 5d20: c0b713ec c0b713ec c12f6048 c0b644fc 00000000 00000000 60000113 c053f6bc
[    1.410938] 5d40: c16b3bf0 c15efa88 c09d4e48 00000001 00000007 00000200 0000000f 00000000
[    1.411174] 5d60: 00000000 00000000 c0b71300 c0ad702c c0b644fc 00000000 c15ec090 c0b713ec
[    1.411410] 5d80: c0b9f980 c04491a8 c15ec090 00000000 60000113 c15ec090 c0b713ec c15ec090
[    1.411644] 5da0: 00000003 c0449530 c078a988 c0399c90 ffffff08 c0be4d7c c0b713ec c15ec090
[    1.411882] 5dc0: 00000003 c0b644fc 00000000 00000000 60000113 c04496e0 00000001 c0b713ec
[    1.412117] 5de0: c48a5e2c c15ec090 c0b644fc c0449aa0 00000000 c48a5e2c c04499fc c0be4d50
[    1.412352] 5e00: c0b644fc c044702c 00000000 c12f407c c16b3bd4 c0ad702c c15ec090 00000001
[    1.412587] 5e20: c15ec0d4 c0449030 c15ec090 c15ec090 00000001 c0ad702c c15ec090 c15ec090
[    1.412827] 5e40: c0b77a9c c0448044 c15ec090 00000000 c12f5030 c04458bc 00000001 c009c720
[    1.413065] 5e60: c15ec090 c04590e4 c15ec090 00000002 c12f6048 c12f6150 c15ec088 c0ad702c
[    1.413307] 5e80: c15ec090 c15ec020 c12f6150 c12f6048 c12f6150 c15ec088 c15ec090 c12f6160
[    1.413551] 5ea0: 60000113 c0540820 00000000 c12f6048 c12f6150 ffffffe4 c12f6178 c12f6900
[    1.413804] 5ec0: c0bb6828 c05409e8 00000000 00000011 c12f6048 00000000 c12f6150 c0ba35c8
[    1.414050] 5ee0: c12f6178 c12f6900 c0bb6828 c074c3a8 c48a5f04 c0ad702c c48a5f10 c074c44c
[    1.414294] 5f00: c098de10 c09acdc0 c12f4fa0 c48a5f1c 000031d0 c0ad702c c12f6048 c12f6048
[    1.414538] 5f20: 00000000 c12f6150 c0ba35c8 c0540af8 c12f6048 00000000 c12f6150 c053dcd4
[    1.414791] 5f40: c12f6048 00000000 00000080 c12f6144 c12f6900 c053e704 00000000 c12f6178
[    1.415037] 5f60: 000030d0 c0ad702c c12f6900 c12f4fe0 c12f21a0 c053e36c c12f6048 c12f6900
[    1.415282] 5f80: c4809cc0 00000000 00000000 c004d67c c12f4fe0 c004d5a0 00000000 00000000
[    1.415531] 5fa0: 00000000 00000000 00000000 c0008368 00000000 00000000 00000000 00000000
[    1.415780] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    1.416025] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[    1.416643]  pcmcia_init_one from pcmcia_device_probe+0xe4/0x2a0
[    1.416882]  pcmcia_device_probe from really_probe+0xc8/0x3b4
[    1.417070]  really_probe from __driver_probe_device+0x9c/0x214
[    1.417255]  __driver_probe_device from driver_probe_device+0x38/0xe0
[    1.417454]  driver_probe_device from __device_attach_driver+0xa4/0x11c
[    1.417657]  __device_attach_driver from bus_for_each_drv+0x88/0xd8
[    1.417864]  bus_for_each_drv from __device_attach+0xf4/0x194
[    1.418047]  __device_attach from bus_probe_device+0x8c/0x94
[    1.418224]  bus_probe_device from device_add+0x3d0/0x894
[    1.418395]  device_add from pcmcia_device_add+0x2ec/0x3e0
[    1.418568]  pcmcia_device_add from pcmcia_card_add+0xd4/0x1a0
[    1.418756]  pcmcia_card_add from pcmcia_bus_add+0x44/0x4c
[    1.418930]  pcmcia_bus_add from socket_insert+0x12c/0x150
[    1.419103]  socket_insert from pccardd+0x398/0x44c
[    1.419257]  pccardd from kthread+0xdc/0x114
[    1.419400]  kthread from ret_from_fork+0x14/0x2c
[    1.419569] Exception stack(0xc48a5fb0 to 0xc48a5ff8)
[    1.419735] 5fa0:                                     00000000 00000000 00000000 00000000
[    1.419979] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    1.420222] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    1.420501] Code: 13570000 e1a06000 0a000043 e3a03002 (e5c03000)
[    1.420874] ---[ end trace 0000000000000000 ]---

---
# bad: [7643a9ca9f8e08f71e15f89dd74863635e981e03] ARM: pxa: convert to multiplatform
# good: [3123109284176b1532874591f7c81f3837bbdc17] Linux 5.18-rc1
git bisect start 'HEAD' 'v5.18-rc1'
# good: [9b03d7f95bd4d97101ecb8ea1e822103b81fdb2d] ARM: pxa: mainstone-wm97xx: use gpio lookup table
git bisect good 9b03d7f95bd4d97101ecb8ea1e822103b81fdb2d
# good: [764063eee7620ea9abb940068a7ad0e7f9efa1b6] cpufreq: pxa3: move clk register access to clk driver
git bisect good 764063eee7620ea9abb940068a7ad0e7f9efa1b6
# good: [5153474f0a4388b7ddb59add4be73bfb42b2007f] ARM: mmp: remove tavorevb board support
git bisect good 5153474f0a4388b7ddb59add4be73bfb42b2007f
# good: [2746f7c78b428c8b01b691a29a972c08101ae343] ARM: PXA: fix multi-cpu build of xsc3
git bisect good 2746f7c78b428c8b01b691a29a972c08101ae343
# good: [73d5106e9489464eac84362705e93bcf3b376123] ARM: pxa: remove support for MTD_XIP
git bisect good 73d5106e9489464eac84362705e93bcf3b376123
# first bad commit: [7643a9ca9f8e08f71e15f89dd74863635e981e03] ARM: pxa: convert to multiplatform

On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Tue, Apr 19, 2022 at 06:37:22PM +0200, Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > This revisits a series I sent a few years ago:
> >
> > https://lore.kernel.org/lkml/20191018154052.1276506-1-arnd@arndb.de/
> >
> > All the other ARMv5 conversions are under way now, with
> > OMAP1 being the only one still not in linux-next yet,
> > and PXA completing the set.
> >
> > Most of the patches are unchanged from before, furtunately
> > the PXA code is fairly stable. I addressed Robert's comments,
> > pulled in two patches from Dmitry, and added the last a the
> > final four patches to finish off the multiplatform conversion.
> >
> > I hope someone is left to test these on PXA: if this works,
> > I'd like to merge it for 5.19. A git tree with these is avaialable
> > for testing at
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/log/?h=pxa-multiplatform-5.18
> >
>
> Unfortunately that crashes for me when trying to boot from ide.
> Bisect points to the last patch of the series.

Thanks a lot for testing and the perfect bug report!

> [    1.403715] 8<--- cut here ---
> [    1.403848] Unable to handle kernel paging request at virtual address feeb000e
> [    1.404097] [feeb000e] *pgd=00000000

Ok, this is the PCI I/O space area, which starts at 0xfee00000,
clearly the way I/O space
gets mapped changed here. I don't yet see what happened, but it should
be straightforward
to find from here.

> [    1.416643]  pcmcia_init_one from pcmcia_device_probe+0xe4/0x2a0
> [    1.416882]  pcmcia_device_probe from really_probe+0xc8/0x3b4
> [    1.417070]  really_probe from __driver_probe_device+0x9c/0x214
> [    1.417255]  __driver_probe_device from driver_probe_device+0x38/0xe0
> [    1.417454]  driver_probe_device from __device_attach_driver+0xa4/0x11c
> [    1.417657]  __device_attach_driver from bus_for_each_drv+0x88/0xd8
> [    1.417864]  bus_for_each_drv from __device_attach+0xf4/0x194
> [    1.418047]  __device_attach from bus_probe_device+0x8c/0x94
> [    1.418224]  bus_probe_device from device_add+0x3d0/0x894
> [    1.418395]  device_add from pcmcia_device_add+0x2ec/0x3e0
> [    1.418568]  pcmcia_device_add from pcmcia_card_add+0xd4/0x1a0
> [    1.418756]  pcmcia_card_add from pcmcia_bus_add+0x44/0x4c
> [    1.418930]  pcmcia_bus_add from socket_insert+0x12c/0x150
> [    1.419103]  socket_insert from pccardd+0x398/0x44c
> [    1.419257]  pccardd from kthread+0xdc/0x114
> [    1.419400]  kthread from ret_from_fork+0x14/0x2c
> [    1.419569] Exception stack(0xc48a5fb0 to 0xc48a5ff8)
> [    1.419735] 5fa0:                                     00000000 00000000 00000000 00000000
> [    1.419979] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [    1.420222] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> [    1.420501] Code: 13570000 e1a06000 0a000043 e3a03002 (e5c03000)
> [    1.420874] ---[ end trace 0000000000000000 ]---
>
> ---
> # bad: [7643a9ca9f8e08f71e15f89dd74863635e981e03] ARM: pxa: convert to multiplatform
> # good: [3123109284176b1532874591f7c81f3837bbdc17] Linux 5.18-rc1
> git bisect start 'HEAD' 'v5.18-rc1'
> # good: [9b03d7f95bd4d97101ecb8ea1e822103b81fdb2d] ARM: pxa: mainstone-wm97xx: use gpio lookup table
> git bisect good 9b03d7f95bd4d97101ecb8ea1e822103b81fdb2d
> # good: [764063eee7620ea9abb940068a7ad0e7f9efa1b6] cpufreq: pxa3: move clk register access to clk driver
> git bisect good 764063eee7620ea9abb940068a7ad0e7f9efa1b6
> # good: [5153474f0a4388b7ddb59add4be73bfb42b2007f] ARM: mmp: remove tavorevb board support
> git bisect good 5153474f0a4388b7ddb59add4be73bfb42b2007f
> # good: [2746f7c78b428c8b01b691a29a972c08101ae343] ARM: PXA: fix multi-cpu build of xsc3
> git bisect good 2746f7c78b428c8b01b691a29a972c08101ae343
> # good: [73d5106e9489464eac84362705e93bcf3b376123] ARM: pxa: remove support for MTD_XIP
> git bisect good 73d5106e9489464eac84362705e93bcf3b376123
> # first bad commit: [7643a9ca9f8e08f71e15f89dd74863635e981e03] ARM: pxa: convert to multiplatform

I'll back out this patch for now while investigating further.

Which machine did you hit this on? Is this on hardware or in qemu?

       Arnd

On 4/22/22 12:16, Arnd Bergmann wrote:
> On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On Tue, Apr 19, 2022 at 06:37:22PM +0200, Arnd Bergmann wrote:
>>> From: Arnd Bergmann <arnd@arndb.de>
>>>
>>> This revisits a series I sent a few years ago:
>>>
>>> https://lore.kernel.org/lkml/20191018154052.1276506-1-arnd@arndb.de/
>>>
>>> All the other ARMv5 conversions are under way now, with
>>> OMAP1 being the only one still not in linux-next yet,
>>> and PXA completing the set.
>>>
>>> Most of the patches are unchanged from before, furtunately
>>> the PXA code is fairly stable. I addressed Robert's comments,
>>> pulled in two patches from Dmitry, and added the last a the
>>> final four patches to finish off the multiplatform conversion.
>>>
>>> I hope someone is left to test these on PXA: if this works,
>>> I'd like to merge it for 5.19. A git tree with these is avaialable
>>> for testing at
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/log/?h=pxa-multiplatform-5.18
>>>
>>
>> Unfortunately that crashes for me when trying to boot from ide.
>> Bisect points to the last patch of the series.
> 
> Thanks a lot for testing and the perfect bug report!
> 
>> [    1.403715] 8<--- cut here ---
>> [    1.403848] Unable to handle kernel paging request at virtual address feeb000e
>> [    1.404097] [feeb000e] *pgd=00000000
> 
> Ok, this is the PCI I/O space area, which starts at 0xfee00000,
> clearly the way I/O space
> gets mapped changed here. I don't yet see what happened, but it should
> be straightforward
> to find from here.
> 
>> [    1.416643]  pcmcia_init_one from pcmcia_device_probe+0xe4/0x2a0
>> [    1.416882]  pcmcia_device_probe from really_probe+0xc8/0x3b4
>> [    1.417070]  really_probe from __driver_probe_device+0x9c/0x214
>> [    1.417255]  __driver_probe_device from driver_probe_device+0x38/0xe0
>> [    1.417454]  driver_probe_device from __device_attach_driver+0xa4/0x11c
>> [    1.417657]  __device_attach_driver from bus_for_each_drv+0x88/0xd8
>> [    1.417864]  bus_for_each_drv from __device_attach+0xf4/0x194
>> [    1.418047]  __device_attach from bus_probe_device+0x8c/0x94
>> [    1.418224]  bus_probe_device from device_add+0x3d0/0x894
>> [    1.418395]  device_add from pcmcia_device_add+0x2ec/0x3e0
>> [    1.418568]  pcmcia_device_add from pcmcia_card_add+0xd4/0x1a0
>> [    1.418756]  pcmcia_card_add from pcmcia_bus_add+0x44/0x4c
>> [    1.418930]  pcmcia_bus_add from socket_insert+0x12c/0x150
>> [    1.419103]  socket_insert from pccardd+0x398/0x44c
>> [    1.419257]  pccardd from kthread+0xdc/0x114
>> [    1.419400]  kthread from ret_from_fork+0x14/0x2c
>> [    1.419569] Exception stack(0xc48a5fb0 to 0xc48a5ff8)
>> [    1.419735] 5fa0:                                     00000000 00000000 00000000 00000000
>> [    1.419979] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> [    1.420222] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
>> [    1.420501] Code: 13570000 e1a06000 0a000043 e3a03002 (e5c03000)
>> [    1.420874] ---[ end trace 0000000000000000 ]---
>>
>> ---
>> # bad: [7643a9ca9f8e08f71e15f89dd74863635e981e03] ARM: pxa: convert to multiplatform
>> # good: [3123109284176b1532874591f7c81f3837bbdc17] Linux 5.18-rc1
>> git bisect start 'HEAD' 'v5.18-rc1'
>> # good: [9b03d7f95bd4d97101ecb8ea1e822103b81fdb2d] ARM: pxa: mainstone-wm97xx: use gpio lookup table
>> git bisect good 9b03d7f95bd4d97101ecb8ea1e822103b81fdb2d
>> # good: [764063eee7620ea9abb940068a7ad0e7f9efa1b6] cpufreq: pxa3: move clk register access to clk driver
>> git bisect good 764063eee7620ea9abb940068a7ad0e7f9efa1b6
>> # good: [5153474f0a4388b7ddb59add4be73bfb42b2007f] ARM: mmp: remove tavorevb board support
>> git bisect good 5153474f0a4388b7ddb59add4be73bfb42b2007f
>> # good: [2746f7c78b428c8b01b691a29a972c08101ae343] ARM: PXA: fix multi-cpu build of xsc3
>> git bisect good 2746f7c78b428c8b01b691a29a972c08101ae343
>> # good: [73d5106e9489464eac84362705e93bcf3b376123] ARM: pxa: remove support for MTD_XIP
>> git bisect good 73d5106e9489464eac84362705e93bcf3b376123
>> # first bad commit: [7643a9ca9f8e08f71e15f89dd74863635e981e03] ARM: pxa: convert to multiplatform
> 
> I'll back out this patch for now while investigating further.
> 
> Which machine did you hit this on? Is this on hardware or in qemu?
> 
qemu, as always. borzoi, spitz, terrier, tosa, z2, and sx1 fail.
Also, I just noticed that the failure is not always the same.
z2 fails to boot from initrd, and sx1 fails to boot completely.
I'll do another round of bisects.

Guenter

>         Arnd

On Fri, Apr 22, 2022 at 10:55 PM Guenter Roeck <linux@roeck-us.net> wrote:
> On 4/22/22 12:16, Arnd Bergmann wrote:
> > On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > Which machine did you hit this on? Is this on hardware or in qemu?
> >
> qemu, as always. borzoi, spitz, terrier, tosa, z2, and sx1 fail.
> Also, I just noticed that the failure is not always the same.
> z2 fails to boot from initrd, and sx1 fails to boot completely.

That's a lot of machines failing, I hope at least we got the same bugs more
than once here.

For the I/O space, I found now that PXA was not using the standard
virtual I/O address yet, but instead used a NULL-based offset.

I'm not entirely happy with this patch, but this is an outline of what
I think we need to fix that: https://pastebin.com/3nVgQsEw
This one is probably incomplete, at least it breaks sa1100 for now,
and it adds a bogus CONFIG_PCI dependency. I'm also not sure
in what way the last patch in the series triggers it, rather than the
one that removed mach/io.h.

I had sx1 booting in qemu at least, with the omap1 multiplatform series only.
If you have a custom config for this one, make sure you get the right
DEBUG_LL address.

> I'll do another round of bisects.

Thanks!

       Arnd

On Sat, Apr 23, 2022 at 12:04:31AM +0200, Arnd Bergmann wrote:
> On Fri, Apr 22, 2022 at 10:55 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > On 4/22/22 12:16, Arnd Bergmann wrote:
> > > On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > Which machine did you hit this on? Is this on hardware or in qemu?
> > >
> > qemu, as always. borzoi, spitz, terrier, tosa, z2, and sx1 fail.
> > Also, I just noticed that the failure is not always the same.
> > z2 fails to boot from initrd, and sx1 fails to boot completely.
> 
> That's a lot of machines failing, I hope at least we got the same bugs more
> than once here.
> 
> For the I/O space, I found now that PXA was not using the standard
> virtual I/O address yet, but instead used a NULL-based offset.
> 
> I'm not entirely happy with this patch, but this is an outline of what
> I think we need to fix that: https://pastebin.com/3nVgQsEw
> This one is probably incomplete, at least it breaks sa1100 for now,
> and it adds a bogus CONFIG_PCI dependency. I'm also not sure
> in what way the last patch in the series triggers it, rather than the
> one that removed mach/io.h.
> 
> I had sx1 booting in qemu at least, with the omap1 multiplatform series only.
> If you have a custom config for this one, make sure you get the right
> DEBUG_LL address.
> 
> > I'll do another round of bisects.
> 

Here is the bisect for the sx1 boot failure.

Guenter

---
# bad: [e7d6987e09a328d4a949701db40ef63fbb970670] Add linux-next specific files for 20220422
# good: [b2d229d4ddb17db541098b83524d901257e93845] Linux 5.18-rc3
git bisect start 'HEAD' 'v5.18-rc3'
# bad: [479506a21bd2df998017a00f4fe0ea893039d9d0] Merge branch 'drm-next' of git://git.freedesktop.org/git/drm/drm.git
git bisect bad 479506a21bd2df998017a00f4fe0ea893039d9d0
# bad: [84fdc506ff63f3f8eb7feaac87821c39bf1dbdfd] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux.git
git bisect bad 84fdc506ff63f3f8eb7feaac87821c39bf1dbdfd
# bad: [0318e72d28be01b99056a7e66572423682eae2bb] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
git bisect bad 0318e72d28be01b99056a7e66572423682eae2bb
# good: [813d98e2e26d3f418d925263a82d72d1454b326e] Merge branch 'zstd-linus' of https://github.com/terrelln/linux.git
git bisect good 813d98e2e26d3f418d925263a82d72d1454b326e
# bad: [5e87f91cfe6e938eccb88a992687e2ac52eec2a7] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
git bisect bad 5e87f91cfe6e938eccb88a992687e2ac52eec2a7
# bad: [ac4b03d5ad6b887558eb94943f0f2834661dee45] Merge branch 'pxa-multiplatform-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc into arm/multiplatform-late
git bisect bad ac4b03d5ad6b887558eb94943f0f2834661dee45
# good: [6eab9bfd712f63c0977f2d38a45f321816030707] Merge branch 'omap1/multiplatform-prep' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc into arm/multiplatform
git bisect good 6eab9bfd712f63c0977f2d38a45f321816030707
# good: [ac571609a9fab9b94bbd8e634ba20e2ab672e32d] input: touchscreen: mainstone: sync with zylonite driver
git bisect good ac571609a9fab9b94bbd8e634ba20e2ab672e32d
# good: [77b9aeb6e3cd4de6b320d3a9be5d692594159f9e] ARM: pxa: remove unused mach/bitfield.h
git bisect good 77b9aeb6e3cd4de6b320d3a9be5d692594159f9e
# good: [7643a9ca9f8e08f71e15f89dd74863635e981e03] ARM: pxa: convert to multiplatform
git bisect good 7643a9ca9f8e08f71e15f89dd74863635e981e03
# good: [bdfb692acfa98c3e8135ab44bc8366636443590a] [MERGED] ASoC: ti: osk5912: Make it CCF clk API compatible
git bisect good bdfb692acfa98c3e8135ab44bc8366636443590a
# bad: [b59e8a5fd321fe44bdabd38908b4f899f933cf0f] [TO BE REBASED] ARM: omap1: enable multiplatform
git bisect bad b59e8a5fd321fe44bdabd38908b4f899f933cf0f
# good: [4c4467ac74299b14b8cf74406722af8090aa7766] [TO BE REBASED] ARM: OMAP1: clock: Convert to CCF
git bisect good 4c4467ac74299b14b8cf74406722af8090aa7766
# first bad commit: [b59e8a5fd321fe44bdabd38908b4f899f933cf0f] [TO BE REBASED] ARM: omap1: enable multiplatform

On Sat, Apr 23, 2022 at 1:41 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Sat, Apr 23, 2022 at 12:04:31AM +0200, Arnd Bergmann wrote:
> > On Fri, Apr 22, 2022 at 10:55 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > > On 4/22/22 12:16, Arnd Bergmann wrote:
> > > > On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > > >
> > > > Which machine did you hit this on? Is this on hardware or in qemu?
> > > >
> > > qemu, as always. borzoi, spitz, terrier, tosa, z2, and sx1 fail.
> > > Also, I just noticed that the failure is not always the same.
> > > z2 fails to boot from initrd, and sx1 fails to boot completely.
> >
> > That's a lot of machines failing, I hope at least we got the same bugs more
> > than once here.
> >
> > For the I/O space, I found now that PXA was not using the standard
> > virtual I/O address yet, but instead used a NULL-based offset.
> >
> > I'm not entirely happy with this patch, but this is an outline of what
> > I think we need to fix that: https://pastebin.com/3nVgQsEw
> > This one is probably incomplete, at least it breaks sa1100 for now,
> > and it adds a bogus CONFIG_PCI dependency. I'm also not sure
> > in what way the last patch in the series triggers it, rather than the
> > one that removed mach/io.h.
> >
> > I had sx1 booting in qemu at least, with the omap1 multiplatform series only.
> > If you have a custom config for this one, make sure you get the right
> > DEBUG_LL address.
> >
> > > I'll do another round of bisects.
> >
>
> Here is the bisect for the sx1 boot failure.

Odd, I can't reproduce this at all. Do you get any console output at
all for this?

Is this the plain omap1_defconfig, or something else?

One thing I keep having to apply myself is this snippet:

diff --git a/arch/arm/mm/proc-arm925.S b/arch/arm/mm/proc-arm925.S
index 0bfad62ea858..87c695703580 100644
--- a/arch/arm/mm/proc-arm925.S
+++ b/arch/arm/mm/proc-arm925.S
@@ -441,7 +441,6 @@ __arm925_setup:

 #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH
        mov     r0, #4                          @ disable write-back
on caches explicitly
-       mcr     p15, 7, r0, c15, c0, 0
 #endif

        adr     r5, arm925_crval

I don't remember what the story is behind this, but I can't actually manage
to boot omap1_defconfig on qemu with the instruction intact.

       Arnd

On 4/23/22 12:55, Arnd Bergmann wrote:
> On Sat, Apr 23, 2022 at 1:41 AM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On Sat, Apr 23, 2022 at 12:04:31AM +0200, Arnd Bergmann wrote:
>>> On Fri, Apr 22, 2022 at 10:55 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>>> On 4/22/22 12:16, Arnd Bergmann wrote:
>>>>> On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>>>>
>>>>> Which machine did you hit this on? Is this on hardware or in qemu?
>>>>>
>>>> qemu, as always. borzoi, spitz, terrier, tosa, z2, and sx1 fail.
>>>> Also, I just noticed that the failure is not always the same.
>>>> z2 fails to boot from initrd, and sx1 fails to boot completely.
>>>
>>> That's a lot of machines failing, I hope at least we got the same bugs more
>>> than once here.
>>>
>>> For the I/O space, I found now that PXA was not using the standard
>>> virtual I/O address yet, but instead used a NULL-based offset.
>>>
>>> I'm not entirely happy with this patch, but this is an outline of what
>>> I think we need to fix that: https://pastebin.com/3nVgQsEw
>>> This one is probably incomplete, at least it breaks sa1100 for now,
>>> and it adds a bogus CONFIG_PCI dependency. I'm also not sure
>>> in what way the last patch in the series triggers it, rather than the
>>> one that removed mach/io.h.
>>>
>>> I had sx1 booting in qemu at least, with the omap1 multiplatform series only.
>>> If you have a custom config for this one, make sure you get the right
>>> DEBUG_LL address.
>>>
>>>> I'll do another round of bisects.
>>>
>>
>> Here is the bisect for the sx1 boot failure.
> 
> Odd, I can't reproduce this at all. Do you get any console output at
> all for this?
> 
> Is this the plain omap1_defconfig, or something else?
> 

No, it is my own sx1 specific configuration.

https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/qemu_sx1_defconfig

I don't recall where I got it from but ...

> One thing I keep having to apply myself is this snippet:
> 
> diff --git a/arch/arm/mm/proc-arm925.S b/arch/arm/mm/proc-arm925.S
> index 0bfad62ea858..87c695703580 100644
> --- a/arch/arm/mm/proc-arm925.S
> +++ b/arch/arm/mm/proc-arm925.S
> @@ -441,7 +441,6 @@ __arm925_setup:
> 
>   #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH
>          mov     r0, #4                          @ disable write-back
> on caches explicitly
> -       mcr     p15, 7, r0, c15, c0, 0
>   #endif

it does not have CONFIG_CPU_DCACHE_WRITETHROUGH enabled.

Guenter

> 
>          adr     r5, arm925_crval
> 
> I don't remember what the story is behind this, but I can't actually manage
> to boot omap1_defconfig on qemu with the instruction intact.
> 
>         Arnd

On Sun, Apr 24, 2022 at 4:09 AM Guenter Roeck <linux@roeck-us.net> wrote:
> On 4/23/22 12:55, Arnd Bergmann wrote:
> > On Sat, Apr 23, 2022 at 1:41 AM Guenter Roeck <linux@roeck-us.net> wrote:
> >> On Sat, Apr 23, 2022 at 12:04:31AM +0200, Arnd Bergmann wrote:
> >
> > Odd, I can't reproduce this at all. Do you get any console output at
> > all for this?
> >
> > Is this the plain omap1_defconfig, or something else?
> >
>
> No, it is my own sx1 specific configuration.
>
> https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/qemu_sx1_defconfig
>
> I don't recall where I got it from but ...

Ok, that explains it, thanks!

I fixed all the defconfig files that come with the kernel, but for your own
ones you have to add

# CONFIG_ARCH_MULTI_V7 is not set

into the defconfig file, otherwise the multiplatform target defaults to
an ARMv7 instead of ARMv5 build. For an OMAP15xx as in the SX1,
you also need to enable CONFIG_ARCH_MULTI_V4T.

This is slightly unfortunate, but I don't see any way to avoid it, and the
modified defconfig will still work fine with older kernel trees.

> > One thing I keep having to apply myself is this snippet:
> >
> > diff --git a/arch/arm/mm/proc-arm925.S b/arch/arm/mm/proc-arm925.S
> > index 0bfad62ea858..87c695703580 100644
> > --- a/arch/arm/mm/proc-arm925.S
> > +++ b/arch/arm/mm/proc-arm925.S
> > @@ -441,7 +441,6 @@ __arm925_setup:
> >
> >   #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH
> >          mov     r0, #4                          @ disable write-back
> > on caches explicitly
> > -       mcr     p15, 7, r0, c15, c0, 0
> >   #endif
>
> it does not have CONFIG_CPU_DCACHE_WRITETHROUGH enabled.

Maybe it was disabled explicitly for the sx1_defconfig because of this
bug. I would think that this is required for actual sx1 hardware because the
option is default-enabled for ARM925T, and that CPU core is exclusively
used in OMAP15xx.

        Arnd

On 4/24/22 01:52, Arnd Bergmann wrote:
> On Sun, Apr 24, 2022 at 4:09 AM Guenter Roeck <linux@roeck-us.net> wrote:
>> On 4/23/22 12:55, Arnd Bergmann wrote:
>>> On Sat, Apr 23, 2022 at 1:41 AM Guenter Roeck <linux@roeck-us.net> wrote:
>>>> On Sat, Apr 23, 2022 at 12:04:31AM +0200, Arnd Bergmann wrote:
>>>
>>> Odd, I can't reproduce this at all. Do you get any console output at
>>> all for this?
>>>
>>> Is this the plain omap1_defconfig, or something else?
>>>
>>
>> No, it is my own sx1 specific configuration.
>>
>> https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/qemu_sx1_defconfig
>>
>> I don't recall where I got it from but ...
> 
> Ok, that explains it, thanks!
> 
> I fixed all the defconfig files that come with the kernel, but for your own
> ones you have to add
> 
> # CONFIG_ARCH_MULTI_V7 is not set
> 
> into the defconfig file, otherwise the multiplatform target defaults to
> an ARMv7 instead of ARMv5 build. For an OMAP15xx as in the SX1,
> you also need to enable CONFIG_ARCH_MULTI_V4T.
> 
> This is slightly unfortunate, but I don't see any way to avoid it, and the
> modified defconfig will still work fine with older kernel trees.
> 

Yes, that works. I changed it in my configuration.

>>> One thing I keep having to apply myself is this snippet:
>>>
>>> diff --git a/arch/arm/mm/proc-arm925.S b/arch/arm/mm/proc-arm925.S
>>> index 0bfad62ea858..87c695703580 100644
>>> --- a/arch/arm/mm/proc-arm925.S
>>> +++ b/arch/arm/mm/proc-arm925.S
>>> @@ -441,7 +441,6 @@ __arm925_setup:
>>>
>>>    #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH
>>>           mov     r0, #4                          @ disable write-back
>>> on caches explicitly
>>> -       mcr     p15, 7, r0, c15, c0, 0
>>>    #endif
>>
>> it does not have CONFIG_CPU_DCACHE_WRITETHROUGH enabled.
> 
> Maybe it was disabled explicitly for the sx1_defconfig because of this
> bug. I would think that this is required for actual sx1 hardware because the
> option is default-enabled for ARM925T, and that CPU core is exclusively
> used in OMAP15xx.
> 

That looks like a bug in qemu. ARM925T instruction support is limited to V4T
instructions. qemu doesn't have explicit 5T support. It is either V4T
or V5.

Guenter

On Sun, Apr 24, 2022 at 5:28 PM Guenter Roeck <linux@roeck-us.net> wrote:
> On 4/24/22 01:52, Arnd Bergmann wrote:
> > On Sun, Apr 24, 2022 at 4:09 AM Guenter Roeck <linux@roeck-us.net> wrote:
> > into the defconfig file, otherwise the multiplatform target defaults to
> > an ARMv7 instead of ARMv5 build. For an OMAP15xx as in the SX1,
> > you also need to enable CONFIG_ARCH_MULTI_V4T.
> >
> > This is slightly unfortunate, but I don't see any way to avoid it, and the
> > modified defconfig will still work fine with older kernel trees.
> >
>
> Yes, that works. I changed it in my configuration.

Ok, great!. I managed to boot the z2 machine with PCMCIA support
and it gets around the issue with my patch, correctly detecting the
CF card.

> >>> One thing I keep having to apply myself is this snippet:
> >>>
> >>> diff --git a/arch/arm/mm/proc-arm925.S b/arch/arm/mm/proc-arm925.S
> >>> index 0bfad62ea858..87c695703580 100644
> >>> --- a/arch/arm/mm/proc-arm925.S
> >>> +++ b/arch/arm/mm/proc-arm925.S
> >>> @@ -441,7 +441,6 @@ __arm925_setup:
> >>>
> >>>    #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH
> >>>           mov     r0, #4                          @ disable write-back
> >>> on caches explicitly
> >>> -       mcr     p15, 7, r0, c15, c0, 0
> >>>    #endif
> >>
> >> it does not have CONFIG_CPU_DCACHE_WRITETHROUGH enabled.
> >
> > Maybe it was disabled explicitly for the sx1_defconfig because of this
> > bug. I would think that this is required for actual sx1 hardware because the
> > option is default-enabled for ARM925T, and that CPU core is exclusively
> > used in OMAP15xx.
> >
>
> That looks like a bug in qemu. ARM925T instruction support is limited to V4T
> instructions. qemu doesn't have explicit 5T support. It is either V4T
> or V5.

I'm not entirely sure what instructions the CPU supports, but Linux
treats it as ARMv4T as well, and qemu supports some of the 925t
specific instructions as "ti925t" in target/arm/cpu_tcg.c, it just seems
it's missing some others.

      Arnd

On Sun, Apr 24, 2022 at 8:48 PM Arnd Bergmann <arnd@kernel.org> wrote:
> On Sun, Apr 24, 2022 at 5:28 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > On 4/24/22 01:52, Arnd Bergmann wrote:
> > > On Sun, Apr 24, 2022 at 4:09 AM Guenter Roeck <linux@roeck-us.net> wrote:
> > > into the defconfig file, otherwise the multiplatform target defaults to
> > > an ARMv7 instead of ARMv5 build. For an OMAP15xx as in the SX1,
> > > you also need to enable CONFIG_ARCH_MULTI_V4T.
> > >
> > > This is slightly unfortunate, but I don't see any way to avoid it, and the
> > > modified defconfig will still work fine with older kernel trees.
> > >
> >
> > Yes, that works. I changed it in my configuration.
>
> Ok, great!. I managed to boot the z2 machine with PCMCIA support
> and it gets around the issue with my patch, correctly detecting the
> CF card.

Hi Guenter,

I have now sent out a fix that I'm happy with, and applied it to the
pxa-multiplatform-5.18 branch of the soc tree as well as the
combined arm/multiplatform tree.

I have not merged this new version into the for-next branch
since I would like to see if there are any other regressions first.

Can you run your boot tests on the arm/multiplatform branch
and let me know if that fixes everything you found? If that
takes a lot of manual steps on your side, I'd just wait for the
build bots and merge it after all there are no new compile-time
issues.

       Arnd

On 4/28/22 06:44, Arnd Bergmann wrote:
> On Sun, Apr 24, 2022 at 8:48 PM Arnd Bergmann <arnd@kernel.org> wrote:
>> On Sun, Apr 24, 2022 at 5:28 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>> On 4/24/22 01:52, Arnd Bergmann wrote:
>>>> On Sun, Apr 24, 2022 at 4:09 AM Guenter Roeck <linux@roeck-us.net> wrote:
>>>> into the defconfig file, otherwise the multiplatform target defaults to
>>>> an ARMv7 instead of ARMv5 build. For an OMAP15xx as in the SX1,
>>>> you also need to enable CONFIG_ARCH_MULTI_V4T.
>>>>
>>>> This is slightly unfortunate, but I don't see any way to avoid it, and the
>>>> modified defconfig will still work fine with older kernel trees.
>>>>
>>>
>>> Yes, that works. I changed it in my configuration.
>>
>> Ok, great!. I managed to boot the z2 machine with PCMCIA support
>> and it gets around the issue with my patch, correctly detecting the
>> CF card.
> 
> Hi Guenter,
> 
> I have now sent out a fix that I'm happy with, and applied it to the
> pxa-multiplatform-5.18 branch of the soc tree as well as the
> combined arm/multiplatform tree.
> 
> I have not merged this new version into the for-next branch
> since I would like to see if there are any other regressions first.
> 
> Can you run your boot tests on the arm/multiplatform branch
> and let me know if that fixes everything you found? If that
> takes a lot of manual steps on your side, I'd just wait for the
> build bots and merge it after all there are no new compile-time
> issues.
> 

I tried the pxa-multiplatform-5.18 branch. Its failures match
those in v5.18-rc1.

Should I try soc/arm/multiplatform as well ?

Guenter

On 4/29/22 10:48, Guenter Roeck wrote:
> On 4/28/22 06:44, Arnd Bergmann wrote:
>> On Sun, Apr 24, 2022 at 8:48 PM Arnd Bergmann <arnd@kernel.org> wrote:
>>> On Sun, Apr 24, 2022 at 5:28 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>>> On 4/24/22 01:52, Arnd Bergmann wrote:
>>>>> On Sun, Apr 24, 2022 at 4:09 AM Guenter Roeck <linux@roeck-us.net> wrote:
>>>>> into the defconfig file, otherwise the multiplatform target defaults to
>>>>> an ARMv7 instead of ARMv5 build. For an OMAP15xx as in the SX1,
>>>>> you also need to enable CONFIG_ARCH_MULTI_V4T.
>>>>>
>>>>> This is slightly unfortunate, but I don't see any way to avoid it, and the
>>>>> modified defconfig will still work fine with older kernel trees.
>>>>>
>>>>
>>>> Yes, that works. I changed it in my configuration.
>>>
>>> Ok, great!. I managed to boot the z2 machine with PCMCIA support
>>> and it gets around the issue with my patch, correctly detecting the
>>> CF card.
>>
>> Hi Guenter,
>>
>> I have now sent out a fix that I'm happy with, and applied it to the
>> pxa-multiplatform-5.18 branch of the soc tree as well as the
>> combined arm/multiplatform tree.
>>
>> I have not merged this new version into the for-next branch
>> since I would like to see if there are any other regressions first.
>>
>> Can you run your boot tests on the arm/multiplatform branch
>> and let me know if that fixes everything you found? If that
>> takes a lot of manual steps on your side, I'd just wait for the
>> build bots and merge it after all there are no new compile-time
>> issues.
>>
> 
> I tried the pxa-multiplatform-5.18 branch. Its failures match
> those in v5.18-rc1.
> 

Uuh, wait, the build wasn't complete. There are still some
failures. I'll report later.

Guenter

On Fri, Apr 29, 2022 at 10:23 PM Guenter Roeck <linux@roeck-us.net> wrote:
> On 4/29/22 10:48, Guenter Roeck wrote:
> >
> > I tried the pxa-multiplatform-5.18 branch. Its failures match
> > those in v5.18-rc1.
> >
>
> Uuh, wait, the build wasn't complete. There are still some
> failures. I'll report later.

Sorry about the breakage, I got a few more reports about minor build errors
and warnings, the newly uploaded branches should address all of the ones
I got reports for.

        Arnd

On 4/29/22 14:46, Arnd Bergmann wrote:
> On Fri, Apr 29, 2022 at 10:23 PM Guenter Roeck <linux@roeck-us.net> wrote:
>> On 4/29/22 10:48, Guenter Roeck wrote:
>>>
>>> I tried the pxa-multiplatform-5.18 branch. Its failures match
>>> those in v5.18-rc1.
>>>
>>
>> Uuh, wait, the build wasn't complete. There are still some
>> failures. I'll report later.
> 
> Sorry about the breakage, I got a few more reports about minor build errors
> and warnings, the newly uploaded branches should address all of the ones
> I got reports for.
> 

Unless I am missing something the failures are the same as before. See
https://kerneltests.org/builders/qemu-arm-testing/builds/74/steps/qemubuildcommand/logs/stdio

This is with v5.18-rc1-49-ge8ab9a9a2745 which is the tip of
soc/pxa-multiplatform-5.18.

Should I check a different branch ?

Thanks,
Guenter

On Sat, Apr 30, 2022 at 1:09 AM Guenter Roeck <linux@roeck-us.net> wrote:
> On 4/29/22 14:46, Arnd Bergmann wrote:
> > On Fri, Apr 29, 2022 at 10:23 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >> On 4/29/22 10:48, Guenter Roeck wrote:
> >>>
> >>> I tried the pxa-multiplatform-5.18 branch. Its failures match
> >>> those in v5.18-rc1.
> >>>
> >>
> >> Uuh, wait, the build wasn't complete. There are still some
> >> failures. I'll report later.
> >
> > Sorry about the breakage, I got a few more reports about minor build errors
> > and warnings, the newly uploaded branches should address all of the ones
> > I got reports for.
> >
>
> Unless I am missing something the failures are the same as before. See
> https://kerneltests.org/builders/qemu-arm-testing/builds/74/steps/qemubuildcommand/logs/stdio
>
> This is with v5.18-rc1-49-ge8ab9a9a2745 which is the tip of
> soc/pxa-multiplatform-5.18.
>
> Should I check a different branch ?

I only addressed the pcmcia probe failure that you reported for the
final pxa patch, which
previously caused a NULL pointer reference here:

[    1.405319] PC is at pcmcia_init_one+0xf8/0x27c
[    1.405476] LR is at devres_add+0x40/0x6c
[    1.405611] pc : [<c04bdea0>]    lr : [<c044d808>]    psr: a0000113
[    1.405846] sp : c48a5d00  ip : c15f4220  fp : 60000113
[    1.406026] r10: 00000000  r9 : c48b000e  r8 : c48b0000
[    1.406195] r7 : feeb0000  r6 : feeb000e  r5 : c15ec090  r4 : c15ec020
[    1.406395] r3 : 00000002  r2 : 00000000  r1 : c15f4200  r0 : feeb000e

This now seems to work:

[    1.435846] pcmcia_socket pcmcia_socket1: pccard: PCMCIA card
inserted into slot 1
[    1.456350] pcmcia_socket pcmcia_socket0: pccard: PCMCIA card
inserted into slot 0
[    1.457489] pcmcia 0.0: pcmcia: registering new device pcmcia0.0 (IRQ: 217)
[    1.460275] pata_pcmcia: probe of 0.0 failed with error -12

So it sounds like there are additional bugs that I have to look at. I
probably won't
be able to do that in time for the merge window. The logs contain a number of
warnings, but I have no idea which ones of those are preexisting issue. I had
a look at

[    0.689982] pxa-dma pxa-dma.0: error -ENXIO: IRQ index 1 not found

and concluded that it must have done this for a long time. In my own qemu
instance, I see a crash from iWMMXt, but that works fine on your machine.
OTOH, your failed instances all look like they either time out or
failed to find a
rootfs. I tried passing an MMC device as root, and that works here.

         Arnd

On 4/30/22 01:04, Arnd Bergmann wrote:
> On Sat, Apr 30, 2022 at 1:09 AM Guenter Roeck <linux@roeck-us.net> wrote:
>> On 4/29/22 14:46, Arnd Bergmann wrote:
>>> On Fri, Apr 29, 2022 at 10:23 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>>> On 4/29/22 10:48, Guenter Roeck wrote:
>>>>>
>>>>> I tried the pxa-multiplatform-5.18 branch. Its failures match
>>>>> those in v5.18-rc1.
>>>>>
>>>>
>>>> Uuh, wait, the build wasn't complete. There are still some
>>>> failures. I'll report later.
>>>
>>> Sorry about the breakage, I got a few more reports about minor build errors
>>> and warnings, the newly uploaded branches should address all of the ones
>>> I got reports for.
>>>
>>
>> Unless I am missing something the failures are the same as before. See
>> https://kerneltests.org/builders/qemu-arm-testing/builds/74/steps/qemubuildcommand/logs/stdio
>>
>> This is with v5.18-rc1-49-ge8ab9a9a2745 which is the tip of
>> soc/pxa-multiplatform-5.18.
>>
>> Should I check a different branch ?
> 
> I only addressed the pcmcia probe failure that you reported for the
> final pxa patch, which
> previously caused a NULL pointer reference here:
> 
> [    1.405319] PC is at pcmcia_init_one+0xf8/0x27c
> [    1.405476] LR is at devres_add+0x40/0x6c
> [    1.405611] pc : [<c04bdea0>]    lr : [<c044d808>]    psr: a0000113
> [    1.405846] sp : c48a5d00  ip : c15f4220  fp : 60000113
> [    1.406026] r10: 00000000  r9 : c48b000e  r8 : c48b0000
> [    1.406195] r7 : feeb0000  r6 : feeb000e  r5 : c15ec090  r4 : c15ec020
> [    1.406395] r3 : 00000002  r2 : 00000000  r1 : c15f4200  r0 : feeb000e
> 
> This now seems to work:
> 
> [    1.435846] pcmcia_socket pcmcia_socket1: pccard: PCMCIA card
> inserted into slot 1
> [    1.456350] pcmcia_socket pcmcia_socket0: pccard: PCMCIA card
> inserted into slot 0
> [    1.457489] pcmcia 0.0: pcmcia: registering new device pcmcia0.0 (IRQ: 217)
> [    1.460275] pata_pcmcia: probe of 0.0 failed with error -12
> 
> So it sounds like there are additional bugs that I have to look at. I
> probably won't
> be able to do that in time for the merge window. The logs contain a number of
> warnings, but I have no idea which ones of those are preexisting issue. I had
> a look at
> 
> [    0.689982] pxa-dma pxa-dma.0: error -ENXIO: IRQ index 1 not found
> 
Yes, those messages are indeed old.

> and concluded that it must have done this for a long time. In my own qemu
> instance, I see a crash from iWMMXt, but that works fine on your machine.
> OTOH, your failed instances all look like they either time out or
> failed to find a
> rootfs. I tried passing an MMC device as root, and that works here.
> 

Booting from mmc works for me as well. Booting from pcmcia worked before,
so I assume that there must be some regression.

Guenter

On Sat, Apr 30, 2022 at 2:41 PM Guenter Roeck <linux@roeck-us.net> wrote:
> On 4/30/22 01:04, Arnd Bergmann wrote:
> > and concluded that it must have done this for a long time. In my own qemu
> > instance, I see a crash from iWMMXt, but that works fine on your machine.
> > OTOH, your failed instances all look like they either time out or
> > failed to find a
> > rootfs. I tried passing an MMC device as root, and that works here.
> >
>
> Booting from mmc works for me as well. Booting from pcmcia worked before,
> so I assume that there must be some regression.

Ok, got it, and managed to reproduce the hang now. My "ARM: pxa/sa1100: move
I/O space to PCI_IOBASE" patch managed to get it to the point of detecting
the pcmcia device instead of crashing, so I assumed it was enough when it
clearly was not. Before that patch, it still works, afterwards it hangs with
"pata_pcmcia: probe of 0.0 failed with error -12" as mentioned above. I'll
have another look.

       Arnd

On Sat, Apr 30, 2022 at 3:32 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Sat, Apr 30, 2022 at 2:41 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > On 4/30/22 01:04, Arnd Bergmann wrote:
> > > and concluded that it must have done this for a long time. In my own qemu
> > > instance, I see a crash from iWMMXt, but that works fine on your machine.
> > > OTOH, your failed instances all look like they either time out or
> > > failed to find a
> > > rootfs. I tried passing an MMC device as root, and that works here.
> > >
> >
> > Booting from mmc works for me as well. Booting from pcmcia worked before,
> > so I assume that there must be some regression.
>
> Ok, got it, and managed to reproduce the hang now. My "ARM: pxa/sa1100: move
> I/O space to PCI_IOBASE" patch managed to get it to the point of detecting
> the pcmcia device instead of crashing, so I assumed it was enough when it
> clearly was not. Before that patch, it still works, afterwards it hangs with
> "pata_pcmcia: probe of 0.0 failed with error -12" as mentioned above. I'll
> have another look.

Got it: as the PCMCIA bus on this machine is the only thing with an I/O space,
I assigned it port number range 0-0x1000, with an io_offset of 0, but this
was apparently unexpected and triggered this sanity check:

static int static_find_io(struct pcmcia_socket *s, unsigned int attr,
                        unsigned int *base, unsigned int num,
                        unsigned int align, struct resource **parent)
{
      if (!s->io_offset)
              return -EINVAL;
      ...
      return 0;
}

I moved the devices around now, giving zeus/viper I/O space an offset of
zero, and moving PCMCIA to offset 0x10000 and 0x11000 for the two slots,
which now works because the io_offset is nonzero. I've regenerated the
branches again, and confirmed the for-next branch still boots from pcmcia.

        Arnd

On 4/30/22 07:23, Arnd Bergmann wrote:
> On Sat, Apr 30, 2022 at 3:32 PM Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> On Sat, Apr 30, 2022 at 2:41 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>> On 4/30/22 01:04, Arnd Bergmann wrote:
>>>> and concluded that it must have done this for a long time. In my own qemu
>>>> instance, I see a crash from iWMMXt, but that works fine on your machine.
>>>> OTOH, your failed instances all look like they either time out or
>>>> failed to find a
>>>> rootfs. I tried passing an MMC device as root, and that works here.
>>>>
>>>
>>> Booting from mmc works for me as well. Booting from pcmcia worked before,
>>> so I assume that there must be some regression.
>>
>> Ok, got it, and managed to reproduce the hang now. My "ARM: pxa/sa1100: move
>> I/O space to PCI_IOBASE" patch managed to get it to the point of detecting
>> the pcmcia device instead of crashing, so I assumed it was enough when it
>> clearly was not. Before that patch, it still works, afterwards it hangs with
>> "pata_pcmcia: probe of 0.0 failed with error -12" as mentioned above. I'll
>> have another look.
> 
> Got it: as the PCMCIA bus on this machine is the only thing with an I/O space,
> I assigned it port number range 0-0x1000, with an io_offset of 0, but this
> was apparently unexpected and triggered this sanity check:
> 
> static int static_find_io(struct pcmcia_socket *s, unsigned int attr,
>                          unsigned int *base, unsigned int num,
>                          unsigned int align, struct resource **parent)
> {
>        if (!s->io_offset)
>                return -EINVAL;
>        ...
>        return 0;
> }
> 
> I moved the devices around now, giving zeus/viper I/O space an offset of
> zero, and moving PCMCIA to offset 0x10000 and 0x11000 for the two slots,
> which now works because the io_offset is nonzero. I've regenerated the
> branches again, and confirmed the for-next branch still boots from pcmcia.
> 


With v5.18-rc1-49-gcb813018b5c1, I still get:

[    0.797668] RAMDISK: Couldn't find valid RAM disk image starting at 0.
[    0.805262] /dev/root: Can't open blockdev
[    0.805487] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[    0.805674] Please append a correct "root=" boot option; here are the available partitions:

when trying to boot z2 from initrd.

The other problems are gone.

Guenter

On Mon, May 2, 2022 at 6:26 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> With v5.18-rc1-49-gcb813018b5c1, I still get:
>
> [    0.797668] RAMDISK: Couldn't find valid RAM disk image starting at 0.
> [    0.805262] /dev/root: Can't open blockdev
> [    0.805487] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
> [    0.805674] Please append a correct "root=" boot option; here are the available partitions:
>
> when trying to boot z2 from initrd.
>
> The other problems are gone.

Ok, progress!

What is your qemu command line? I see that z2 has no pcmcia device, so
I tried booting
from MMC, but this already fails with 5.18-rc1 without any of my
patches, giving me

[    0.697481] Creating 3 MTD partitions on "physmap-flash":
[    0.698161] 0x000000000000-0x000000040000 : "U-Boot Bootloader"
[    0.702815] 0x000000040000-0x000000060000 : "U-Boot Environment"
[    0.706541] 0x000000060000-0x000000800000 : "Flash"
[    0.718066] pxa2xx-mci pxa2xx-mci.0: incomplete constraints, dummy
supplies not allowed
[    0.718501] pxa2xx-mci pxa2xx-mci.0: incomplete constraints, dummy
supplies not allowed

Do  you have MMC or some other rootfs working without my patch series?

     Arnd

On 5/2/22 12:21, Arnd Bergmann wrote:
> On Mon, May 2, 2022 at 6:26 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> With v5.18-rc1-49-gcb813018b5c1, I still get:
>>
>> [    0.797668] RAMDISK: Couldn't find valid RAM disk image starting at 0.
>> [    0.805262] /dev/root: Can't open blockdev
>> [    0.805487] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
>> [    0.805674] Please append a correct "root=" boot option; here are the available partitions:
>>
>> when trying to boot z2 from initrd.
>>
>> The other problems are gone.
> 
> Ok, progress!
> 
> What is your qemu command line? I see that z2 has no pcmcia device, so
> I tried booting
> from MMC, but this already fails with 5.18-rc1 without any of my
> patches, giving me
> 
> [    0.697481] Creating 3 MTD partitions on "physmap-flash":
> [    0.698161] 0x000000000000-0x000000040000 : "U-Boot Bootloader"
> [    0.702815] 0x000000040000-0x000000060000 : "U-Boot Environment"
> [    0.706541] 0x000000060000-0x000000800000 : "Flash"
> [    0.718066] pxa2xx-mci pxa2xx-mci.0: incomplete constraints, dummy
> supplies not allowed
> [    0.718501] pxa2xx-mci pxa2xx-mci.0: incomplete constraints, dummy
> supplies not allowed
> 

To boot from initrd:

qemu-system-arm -M z2 -kernel \
      arch/arm/boot/zImage -no-reboot -initrd \
      rootfs-armv5.cpio --append \
      "panic=-1 slub_debug=FZPUA rdinit=/sbin/init console=ttyS0" -nographic \
      -monitor null -serial stdio

where rootfs-armv5.cpio is from my repository at github.com.

https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/rootfs-armv5.cpio.gz

> Do  you have MMC or some other rootfs working without my patch series?
> 

I can boot z2 from mmc and flash, but I have a number of configuration
flags enabled on top of pxa_defconfig. That also works with your latest patch
series. See
https://kerneltests.org/builders/qemu-arm-testing/builds/75/steps/qemubuildcommand/logs/stdio

     # Always enable ...
     enable_config "${defconfig}" CONFIG_DEVTMPFS CONFIG_DEVTMPFS_MOUNT CONFIG_BLK_DEV_INITRD
     # Options needed to be built into the kernel for device support
     # on pxa devices
     # MTD, squashfs
     enable_config_cond "${defconfig}" CONFIG_MTD_BLOCK CONFIG_MTD_PXA2XX CONFIG_SQUASHFS
     # MMC
     enable_config_cond "${defconfig}" CONFIG_MMC_BLOCK CONFIG_MMC_PXA
     # PCMCIA
     enable_config_cond "${defconfig}" CONFIG_ATA CONFIG_BLK_DEV_SD CONFIG_PCCARD
     enable_config_cond "${defconfig}" CONFIG_PCMCIA CONFIG_PATA_PCMCIA CONFIG_PCMCIA_PXA2XX
     # USB
     enable_config_cond "${defconfig}" CONFIG_USB CONFIG_USB_STORAGE CONFIG_USB_OHCI_HCD CONFIG_USB_OHCI_HCD_PXA27X

Hope this helps,
Guenter

On Mon, May 2, 2022 at 10:35 PM Guenter Roeck <linux@roeck-us.net> wrote:
> On 5/2/22 12:21, Arnd Bergmann wrote:
> >
>
> To boot from initrd:
>
> qemu-system-arm -M z2 -kernel \
>       arch/arm/boot/zImage -no-reboot -initrd \
>       rootfs-armv5.cpio --append \
>       "panic=-1 slub_debug=FZPUA rdinit=/sbin/init console=ttyS0" -nographic \
>       -monitor null -serial stdio
>
> where rootfs-armv5.cpio is from my repository at github.com.
>
> https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/rootfs-armv5.cpio.gz
>

Ok, that works here with any configuration, I don't see a regression.
Could this be a problem with the size increase? The machine only has
32MB of RAM, so it's possible that the multiplatform-enabled kernel
with DT support etc pushes it over the edge, especially with an initramfs.

My configuration is clearly a bit different from yours, so I tried giving it
a larger initramfs file, which randomly crashes elsewhere for me:

[    0.648659] pxa2xx-uart.0: ttyS0 at MMIO 0x40100000 (irq = 38,
base_baud = 928571) is a UART1
[    0.697984] kworker/u2:0 invoked oom-killer:
gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
[    0.698278] CPU: 0 PID: 7 Comm: kworker/u2:0 Not tainted
5.18.0-rc1-00109-gee927ad51300-dirty #52
[    0.698382] Hardware name: Zipit Z2
[    0.698520] Workqueue: events_unbound async_run_entry_fn
[    0.699063]  unwind_backtrace from show_stack+0x18/0x1c
[    0.699148]  show_stack from dump_header+0x68/0x254
[    0.699186]  dump_header from out_of_memory+0x474/0x4f0
[    0.699208]  out_of_memory from __alloc_pages+0xa0c/0xb84
[    0.699227]  __alloc_pages from shmem_getpage_gfp.constprop.0+0x270/0x9e0
[    0.699247]  shmem_getpage_gfp.constprop.0 from
generic_perform_write+0xd8/0x210
[    0.699268]  generic_perform_write from __generic_file_write_iter+0x130/0x198
[    0.699286]  __generic_file_write_iter from generic_file_write_iter+0x64/0xd0
[    0.699302]  generic_file_write_iter from __kernel_write+0x114/0x2b0
[    0.699321]  __kernel_write from kernel_write+0x68/0x194
[    0.699337]  kernel_write from xwrite+0x3c/0x78
[    0.699363]  xwrite from do_copy+0xc0/0x11c
[    0.699381]  do_copy from write_buffer+0x2c/0x44
[    0.699397]  write_buffer from flush_buffer+0x3c/0xa0
[    0.699413]  flush_buffer from __gunzip+0x2a4/0x364
[    0.699434]  __gunzip from gunzip+0x2c/0x34
[    0.699449]  gunzip from unpack_to_rootfs+0x19c/0x304
[    0.699465]  unpack_to_rootfs from do_populate_rootfs+0x6c/0x1dc
[    0.699483]  do_populate_rootfs from async_run_entry_fn+0x44/0x1a0
[    0.699502]  async_run_entry_fn from process_one_work+0x1e8/0x544
[    0.699520]  process_one_work from worker_thread+0x34/0x578
[    0.699579]  worker_thread from kthread+0xdc/0x114
[    0.699599]  kthread from ret_from_fork+0x14/0x2c
[    0.699651] Exception stack(0xc2821fb0 to 0xc2821ff8)
[    0.699711] 1fa0:                                     00000000
00000000 00000000 00000000
[    0.699731] 1fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[    0.699744] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    0.699801] Mem-Info:
[    0.699889] active_anon:90 inactive_anon:674 isolated_anon:0
[    0.699889]  active_file:0 inactive_file:0 isolated_file:0
[    0.699889]  unevictable:0 dirty:0 writeback:0
[    0.699889]  slab_reclaimable:0 slab_unreclaimable:1691
[    0.699889]  mapped:0 shmem:771 pagetables:0 bounce:0
[    0.699889]  kernel_misc_reclaimable:0
[    0.699889]  free:207 free_pcp:37 free_cma:0
[    0.699986] Node 0 active_anon:360kB inactive_anon:2696kB
active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:3084kB
writeback_tmp:0kB kernel_stack:192kB pagetables:0kB all_unreclaimable?
yes
[    0.700116] Normal free:828kB boost:1024kB min:1464kB low:1572kB
high:1680kB reserved_highatomic:0KB active_anon:360kB
inactive_anon:2696kB active_file:0kB inactive_file:0kB unevictable:0kB
writepending:0kB present:32768kB managed:12232kB mlocked:0kB
bounce:0kB free_pcp:148kB local_pcp:148kB free_cma:0kB
[    0.700177] lowmem_reserve[]: 0 0
[    0.700247] Normal: 3*4kB (UM) 2*8kB (UM) 2*16kB (M) 0*32kB 0*64kB
0*128kB 1*256kB (M) 1*512kB (M) 0*1024kB = 828kB

       Arnd

On 5/2/22 14:03, Arnd Bergmann wrote:
> On Mon, May 2, 2022 at 10:35 PM Guenter Roeck <linux@roeck-us.net> wrote:
>> On 5/2/22 12:21, Arnd Bergmann wrote:
>>>
>>
>> To boot from initrd:
>>
>> qemu-system-arm -M z2 -kernel \
>>        arch/arm/boot/zImage -no-reboot -initrd \
>>        rootfs-armv5.cpio --append \
>>        "panic=-1 slub_debug=FZPUA rdinit=/sbin/init console=ttyS0" -nographic \
>>        -monitor null -serial stdio
>>
>> where rootfs-armv5.cpio is from my repository at github.com.
>>
>> https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/rootfs-armv5.cpio.gz
>>
> 
> Ok, that works here with any configuration, I don't see a regression.
> Could this be a problem with the size increase? The machine only has
> 32MB of RAM, so it's possible that the multiplatform-enabled kernel
> with DT support etc pushes it over the edge, especially with an initramfs.
> 

qemu puts initrd in the middle of available memory. With the image size
being ~1MB larger than with v5.18-rc, this is too much, and the kernel
overwrites part of initrd. This causes it to be corrupted.

It looks like that would have happened eventually, your patch series just
made it happen now. The kernel is just getting too large to run on such small
systems. I worked around the problem in my version of qemu by loading initrd
at the end of the (small) RAM. With that, I no longer see the boot failure.

Guenter

On Tue, May 3, 2022 at 4:55 AM Guenter Roeck <linux@roeck-us.net> wrote:
> On 5/2/22 14:03, Arnd Bergmann wrote:
> > On Mon, May 2, 2022 at 10:35 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >> On 5/2/22 12:21, Arnd Bergmann wrote:
>
> qemu puts initrd in the middle of available memory. With the image size
> being ~1MB larger than with v5.18-rc, this is too much, and the kernel
> overwrites part of initrd. This causes it to be corrupted.
>
> It looks like that would have happened eventually, your patch series just
> made it happen now. The kernel is just getting too large to run on such small
> systems. I worked around the problem in my version of qemu by loading initrd
> at the end of the (small) RAM. With that, I no longer see the boot failure.

Ok, thanks for confirming. If it's just the image size that changed,
then I think
we can live with it. Having the kernel image grow by 1MB seems excessive
though, I'd like to understand better where that increase comes from.

Starting out from pxa_defconfig, I see a 40KB increase from the final patch
that moves to multiplatform support, which I think is fine.

If you have a z2 specific config, that would probably not enable CONFIG_OF,
which is always turned on for multiplatform, but again that only adds around
250KB in my builds (using gcc-11). This is more than I'd like it to be, but
still much less than 1MB.

        Arnd

On 5/3/22 00:17, Arnd Bergmann wrote:
> On Tue, May 3, 2022 at 4:55 AM Guenter Roeck <linux@roeck-us.net> wrote:
>> On 5/2/22 14:03, Arnd Bergmann wrote:
>>> On Mon, May 2, 2022 at 10:35 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>>> On 5/2/22 12:21, Arnd Bergmann wrote:
>>
>> qemu puts initrd in the middle of available memory. With the image size
>> being ~1MB larger than with v5.18-rc, this is too much, and the kernel
>> overwrites part of initrd. This causes it to be corrupted.
>>
>> It looks like that would have happened eventually, your patch series just
>> made it happen now. The kernel is just getting too large to run on such small
>> systems. I worked around the problem in my version of qemu by loading initrd
>> at the end of the (small) RAM. With that, I no longer see the boot failure.
> 
> Ok, thanks for confirming. If it's just the image size that changed,
> then I think
> we can live with it. Having the kernel image grow by 1MB seems excessive
> though, I'd like to understand better where that increase comes from.
> 
> Starting out from pxa_defconfig, I see a 40KB increase from the final patch
> that moves to multiplatform support, which I think is fine.
> 
> If you have a z2 specific config, that would probably not enable CONFIG_OF,
> which is always turned on for multiplatform, but again that only adds around
> 250KB in my builds (using gcc-11). This is more than I'd like it to be, but
> still much less than 1MB.
> 

Maybe it is a bit less; I only compared the size of "Image". Either case,
it is enough to cause the problem. I am not sure if it is worth the time
trying to track this down further.

Guenter

On Tue, May 3, 2022 at 4:04 PM Guenter Roeck <linux@roeck-us.net> wrote:
> On 5/3/22 00:17, Arnd Bergmann wrote:
>
> > If you have a z2 specific config, that would probably not enable CONFIG_OF,
> > which is always turned on for multiplatform, but again that only adds around
> > 250KB in my builds (using gcc-11). This is more than I'd like it to be, but
> > still much less than 1MB.
> >
>
> Maybe it is a bit less; I only compared the size of "Image". Either case,
> it is enough to cause the problem. I am not sure if it is worth the time
> trying to track this down further.

Sure, I'm not worried about the boot regression any more, as that is definitely
explained by the size growth. The only question is whether the patches make
the kernel grow more than it should. The 40+250KB I measured seem
within my expectations, so unless you have specific data showing much
more, I think we're good.

Thanks for all the help!

        Arnd

On 4/28/22 06:44, Arnd Bergmann wrote:
> On Sun, Apr 24, 2022 at 8:48 PM Arnd Bergmann <arnd@kernel.org> wrote:
>> On Sun, Apr 24, 2022 at 5:28 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>> On 4/24/22 01:52, Arnd Bergmann wrote:
>>>> On Sun, Apr 24, 2022 at 4:09 AM Guenter Roeck <linux@roeck-us.net> wrote:
>>>> into the defconfig file, otherwise the multiplatform target defaults to
>>>> an ARMv7 instead of ARMv5 build. For an OMAP15xx as in the SX1,
>>>> you also need to enable CONFIG_ARCH_MULTI_V4T.
>>>>
>>>> This is slightly unfortunate, but I don't see any way to avoid it, and the
>>>> modified defconfig will still work fine with older kernel trees.
>>>>
>>>
>>> Yes, that works. I changed it in my configuration.
>>
>> Ok, great!. I managed to boot the z2 machine with PCMCIA support
>> and it gets around the issue with my patch, correctly detecting the
>> CF card.
> 
> Hi Guenter,
> 
> I have now sent out a fix that I'm happy with, and applied it to the
> pxa-multiplatform-5.18 branch of the soc tree as well as the
> combined arm/multiplatform tree.
> 
> I have not merged this new version into the for-next branch
> since I would like to see if there are any other regressions first.
> 
> Can you run your boot tests on the arm/multiplatform branch
> and let me know if that fixes everything you found? If that
> takes a lot of manual steps on your side, I'd just wait for the
> build bots and merge it after all there are no new compile-time
> issues.
> 

-next is pretty badly broken right now due to a series of less than
perfect mm patches, so testing there won't do any good.

I'll see if I can dig up the multiplatform branch and push it into
my 'testing' branch.

Guenter

On Sat, Apr 23, 2022 at 12:04:31AM +0200, Arnd Bergmann wrote:
> On Fri, Apr 22, 2022 at 10:55 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > On 4/22/22 12:16, Arnd Bergmann wrote:
> > > On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > Which machine did you hit this on? Is this on hardware or in qemu?
> > >
> > qemu, as always. borzoi, spitz, terrier, tosa, z2, and sx1 fail.
> > Also, I just noticed that the failure is not always the same.
> > z2 fails to boot from initrd, and sx1 fails to boot completely.
> 
> That's a lot of machines failing, I hope at least we got the same bugs more
> than once here.
> 
> For the I/O space, I found now that PXA was not using the standard
> virtual I/O address yet, but instead used a NULL-based offset.
> 
> I'm not entirely happy with this patch, but this is an outline of what
> I think we need to fix that: https://pastebin.com/3nVgQsEw
> This one is probably incomplete, at least it breaks sa1100 for now,
> and it adds a bogus CONFIG_PCI dependency. I'm also not sure
> in what way the last patch in the series triggers it, rather than the
> one that removed mach/io.h.
> 
> I had sx1 booting in qemu at least, with the omap1 multiplatform series only.
> If you have a custom config for this one, make sure you get the right
> DEBUG_LL address.
> 
> > I'll do another round of bisects.
> 

So ... z2 bisect points to the same patch, but the error is different.
As mentioned, it does not recognize the initrd. Oddly enough, booting
from initrd works for the other platforms.

The sx1 boot failure seems to be unrelated to your patch series. It boots
fine if built from the tip of your branch, but fails to boot in -next.
That will require a bisect from -next.

Guenter

On Tue, Apr 19, 2022 at 6:37 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
>
> This revisits a series I sent a few years ago:
>
> https://lore.kernel.org/lkml/20191018154052.1276506-1-arnd@arndb.de/
>
> All the other ARMv5 conversions are under way now, with
> OMAP1 being the only one still not in linux-next yet,
> and PXA completing the set.
>
> Most of the patches are unchanged from before, furtunately
> the PXA code is fairly stable. I addressed Robert's comments,
> pulled in two patches from Dmitry, and added the last a the
> final four patches to finish off the multiplatform conversion.
>
> I hope someone is left to test these on PXA: if this works,
> I'd like to merge it for 5.19. A git tree with these is available
> for testing at
>
> https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/log/?h=pxa-multiplatform-5.18

I have updated the branch based on the feedback I got, and
done a preliminary merge into the for-next branch, so this work
should show up in linux-next. I expect to rebase this particular
branch before the merge window, to add further Acks or
fix regressions in place. (I don't do this for the other branches).

Let me know if there are any show-stoppers or patches that need
more work. I realize that this is a lot to review and that there is
limited reviewer bandwidth as most of the original developers
have moved on from PXA a long time ago.

       Arnd