[PATCH 0/2] powerpc: Remove support for ppc405/440 Xilinx platforms
Hi,
recently we wanted to update xilinx intc driver and we found that function which we wanted to remove is still wired by ancient Xilinx PowerPC platforms. Here is the thread about it. https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa2e8@xili...
I have been talking about it internally and there is no interest in these platforms and it is also orphan for quite a long time. None is really running/testing these platforms regularly that's why I think it makes sense to remove them also with drivers which are specific to this platform.
U-Boot support was removed in 2017 without anybody complain about it https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10...
Based on current ppc/next.
If anyone has any objection about it, please let me know.
Thanks, Michal
Michal Simek (2): sound: ac97: Remove sound driver for ancient platform powerpc: Remove Xilinx PPC405/PPC440 support
Documentation/devicetree/bindings/xilinx.txt | 143 -- Documentation/powerpc/bootwrapper.rst | 28 +- MAINTAINERS | 6 - arch/powerpc/Kconfig.debug | 2 +- arch/powerpc/boot/Makefile | 7 +- arch/powerpc/boot/dts/Makefile | 1 - arch/powerpc/boot/dts/virtex440-ml507.dts | 406 ------ arch/powerpc/boot/dts/virtex440-ml510.dts | 466 ------- arch/powerpc/boot/ops.h | 1 - arch/powerpc/boot/serial.c | 5 - arch/powerpc/boot/uartlite.c | 79 -- arch/powerpc/boot/virtex.c | 97 -- arch/powerpc/boot/virtex405-head.S | 31 - arch/powerpc/boot/wrapper | 8 - arch/powerpc/configs/40x/virtex_defconfig | 75 - arch/powerpc/configs/44x/virtex5_defconfig | 74 - arch/powerpc/configs/ppc40x_defconfig | 8 - arch/powerpc/configs/ppc44x_defconfig | 8 - arch/powerpc/include/asm/xilinx_intc.h | 16 - arch/powerpc/include/asm/xilinx_pci.h | 21 - arch/powerpc/kernel/cputable.c | 39 - arch/powerpc/platforms/40x/Kconfig | 31 - arch/powerpc/platforms/40x/Makefile | 1 - arch/powerpc/platforms/40x/virtex.c | 54 - arch/powerpc/platforms/44x/Kconfig | 37 - arch/powerpc/platforms/44x/Makefile | 2 - arch/powerpc/platforms/44x/virtex.c | 60 - arch/powerpc/platforms/44x/virtex_ml510.c | 30 - arch/powerpc/platforms/Kconfig | 4 - arch/powerpc/sysdev/Makefile | 2 - arch/powerpc/sysdev/xilinx_intc.c | 88 -- arch/powerpc/sysdev/xilinx_pci.c | 132 -- arch/powerpc/xmon/ppc-dis.c | 6 - arch/powerpc/xmon/ppc-opc.c | 23 - arch/powerpc/xmon/ppc.h | 5 - drivers/char/Kconfig | 2 +- drivers/video/fbdev/Kconfig | 2 +- sound/drivers/Kconfig | 12 - sound/drivers/Makefile | 2 - sound/drivers/ml403-ac97cr.c | 1298 ------------------ 40 files changed, 7 insertions(+), 3305 deletions(-) delete mode 100644 arch/powerpc/boot/dts/virtex440-ml507.dts delete mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts delete mode 100644 arch/powerpc/boot/uartlite.c delete mode 100644 arch/powerpc/boot/virtex.c delete mode 100644 arch/powerpc/boot/virtex405-head.S delete mode 100644 arch/powerpc/configs/40x/virtex_defconfig delete mode 100644 arch/powerpc/configs/44x/virtex5_defconfig delete mode 100644 arch/powerpc/include/asm/xilinx_intc.h delete mode 100644 arch/powerpc/include/asm/xilinx_pci.h delete mode 100644 arch/powerpc/platforms/40x/virtex.c delete mode 100644 arch/powerpc/platforms/44x/virtex.c delete mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c delete mode 100644 arch/powerpc/sysdev/xilinx_intc.c delete mode 100644 arch/powerpc/sysdev/xilinx_pci.c delete mode 100644 sound/drivers/ml403-ac97cr.c
Xilinx PowerPC platforms are no longer supported and none is really testing these platforms that's why remove them. If someone has any issue with it these patches can be reverted.
Signed-off-by: Michal Simek michal.simek@xilinx.com ---
sound/drivers/Kconfig | 12 - sound/drivers/Makefile | 2 - sound/drivers/ml403-ac97cr.c | 1298 ---------------------------------- 3 files changed, 1312 deletions(-) delete mode 100644 sound/drivers/ml403-ac97cr.c
diff --git a/sound/drivers/Kconfig b/sound/drivers/Kconfig index 577c8e03ec4d..7141f73cddd3 100644 --- a/sound/drivers/Kconfig +++ b/sound/drivers/Kconfig @@ -186,18 +186,6 @@ config SND_PORTMAN2X4 To compile this driver as a module, choose M here: the module will be called snd-portman2x4.
-config SND_ML403_AC97CR - tristate "Xilinx ML403 AC97 Controller Reference" - depends on XILINX_VIRTEX - select SND_AC97_CODEC - help - Say Y here to include support for the - opb_ac97_controller_ref_v1_00_a ip core found in Xilinx's ML403 - reference design. - - To compile this driver as a module, choose M here: the module - will be called snd-ml403_ac97cr. - config SND_AC97_POWER_SAVE bool "AC97 Power-Saving Mode" depends on SND_AC97_CODEC diff --git a/sound/drivers/Makefile b/sound/drivers/Makefile index 615558a281c8..c0fe4eccdaef 100644 --- a/sound/drivers/Makefile +++ b/sound/drivers/Makefile @@ -11,7 +11,6 @@ snd-mts64-objs := mts64.o snd-portman2x4-objs := portman2x4.o snd-serial-u16550-objs := serial-u16550.o snd-virmidi-objs := virmidi.o -snd-ml403-ac97cr-objs := ml403-ac97cr.o pcm-indirect2.o
# Toplevel Module Dependency obj-$(CONFIG_SND_DUMMY) += snd-dummy.o @@ -21,6 +20,5 @@ obj-$(CONFIG_SND_SERIAL_U16550) += snd-serial-u16550.o obj-$(CONFIG_SND_MTPAV) += snd-mtpav.o obj-$(CONFIG_SND_MTS64) += snd-mts64.o obj-$(CONFIG_SND_PORTMAN2X4) += snd-portman2x4.o -obj-$(CONFIG_SND_ML403_AC97CR) += snd-ml403-ac97cr.o
obj-$(CONFIG_SND) += opl3/ opl4/ mpu401/ vx/ pcsp/ diff --git a/sound/drivers/ml403-ac97cr.c b/sound/drivers/ml403-ac97cr.c deleted file mode 100644 index 0710707da8c1..000000000000 --- a/sound/drivers/ml403-ac97cr.c +++ /dev/null @@ -1,1298 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0-or-later -/* - * ALSA driver for Xilinx ML403 AC97 Controller Reference - * IP: opb_ac97_controller_ref_v1_00_a (EDK 8.1i) - * IP: opb_ac97_controller_ref_v1_00_a (EDK 9.1i) - * - * Copyright (c) by 2007 Joachim Foerster JOFT@gmx.de - */ - -/* Some notes / status of this driver: - * - * - Don't wonder about some strange implementations of things - especially the - * (heavy) shadowing of codec registers, with which I tried to reduce read - * accesses to a minimum, because after a variable amount of accesses, the AC97 - * controller doesn't raise the register access finished bit anymore ... - * - * - Playback support seems to be pretty stable - no issues here. - * - Capture support "works" now, too. Overruns don't happen any longer so often. - * But there might still be some ... - */ - -#include <linux/init.h> -#include <linux/module.h> - -#include <linux/platform_device.h> - -#include <linux/ioport.h> -#include <linux/slab.h> -#include <linux/io.h> -#include <linux/interrupt.h> - -/* HZ */ -#include <linux/param.h> -/* jiffies, time_*() */ -#include <linux/jiffies.h> -/* schedule_timeout*() */ -#include <linux/sched.h> -/* spin_lock*() */ -#include <linux/spinlock.h> -/* struct mutex, mutex_init(), mutex_*lock() */ -#include <linux/mutex.h> - -/* snd_printk(), snd_printd() */ -#include <sound/core.h> -#include <sound/pcm.h> -#include <sound/pcm_params.h> -#include <sound/initval.h> -#include <sound/ac97_codec.h> - -#include "pcm-indirect2.h" - - -#define SND_ML403_AC97CR_DRIVER "ml403-ac97cr" - -MODULE_AUTHOR("Joachim Foerster JOFT@gmx.de"); -MODULE_DESCRIPTION("Xilinx ML403 AC97 Controller Reference"); -MODULE_LICENSE("GPL"); -MODULE_SUPPORTED_DEVICE("{{Xilinx,ML403 AC97 Controller Reference}}"); - -static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX; -static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR; -static bool enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE; - -module_param_array(index, int, NULL, 0444); -MODULE_PARM_DESC(index, "Index value for ML403 AC97 Controller Reference."); -module_param_array(id, charp, NULL, 0444); -MODULE_PARM_DESC(id, "ID string for ML403 AC97 Controller Reference."); -module_param_array(enable, bool, NULL, 0444); -MODULE_PARM_DESC(enable, "Enable this ML403 AC97 Controller Reference."); - -/* Special feature options */ -/*#define CODEC_WRITE_CHECK_RAF*/ /* don't return after a write to a codec - * register, while RAF bit is not set - */ -/* Debug options for code which may be removed completely in a final version */ -#ifdef CONFIG_SND_DEBUG -/*#define CODEC_STAT*/ /* turn on some minimal "statistics" - * about codec register usage - */ -#define SND_PCM_INDIRECT2_STAT /* turn on some "statistics" about the - * process of copying bytes from the - * intermediate buffer to the hardware - * fifo and the other way round - */ -#endif - -/* Definition of a "level/facility dependent" printk(); may be removed - * completely in a final version - */ -#undef PDEBUG -#ifdef CONFIG_SND_DEBUG -/* "facilities" for PDEBUG */ -#define UNKNOWN (1<<0) -#define CODEC_SUCCESS (1<<1) -#define CODEC_FAKE (1<<2) -#define INIT_INFO (1<<3) -#define INIT_FAILURE (1<<4) -#define WORK_INFO (1<<5) -#define WORK_FAILURE (1<<6) - -#define PDEBUG_FACILITIES (UNKNOWN | INIT_FAILURE | WORK_FAILURE) - -#define PDEBUG(fac, fmt, args...) do { \ - if (fac & PDEBUG_FACILITIES) \ - snd_printd(KERN_DEBUG SND_ML403_AC97CR_DRIVER ": " \ - fmt, ##args); \ - } while (0) -#else -#define PDEBUG(fac, fmt, args...) /* nothing */ -#endif - - - -/* Defines for "waits"/timeouts (portions of HZ=250 on arch/ppc by default) */ -#define CODEC_TIMEOUT_ON_INIT 5 /* timeout for checking for codec - * readiness (after insmod) - */ -#ifndef CODEC_WRITE_CHECK_RAF -#define CODEC_WAIT_AFTER_WRITE 100 /* general, static wait after a write - * access to a codec register, may be - * 0 to completely remove wait - */ -#else -#define CODEC_TIMEOUT_AFTER_WRITE 5 /* timeout after a write access to a - * codec register, if RAF bit is used - */ -#endif -#define CODEC_TIMEOUT_AFTER_READ 5 /* timeout after a read access to a - * codec register (checking RAF bit) - */ - -/* Infrastructure for codec register shadowing */ -#define LM4550_REG_OK (1<<0) /* register exists */ -#define LM4550_REG_DONEREAD (1<<1) /* read register once, value should be - * the same currently in the register - */ -#define LM4550_REG_NOSAVE (1<<2) /* values written to this register will - * not be saved in the register - */ -#define LM4550_REG_NOSHADOW (1<<3) /* don't do register shadowing, use plain - * hardware access - */ -#define LM4550_REG_READONLY (1<<4) /* register is read only */ -#define LM4550_REG_FAKEPROBE (1<<5) /* fake write _and_ read actions during - * probe() correctly - */ -#define LM4550_REG_FAKEREAD (1<<6) /* fake read access, always return - * default value - */ -#define LM4550_REG_ALLFAKE (LM4550_REG_FAKEREAD | LM4550_REG_FAKEPROBE) - -struct lm4550_reg { - u16 value; - u16 flag; - u16 wmask; - u16 def; -}; - -struct lm4550_reg lm4550_regfile[64] = { - [AC97_RESET / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_NOSAVE \ - | LM4550_REG_FAKEREAD, - .def = 0x0D50}, - [AC97_MASTER / 2] = {.flag = LM4550_REG_OK - | LM4550_REG_FAKEPROBE, - .wmask = 0x9F1F, - .def = 0x8000}, - [AC97_HEADPHONE / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_FAKEPROBE, - .wmask = 0x9F1F, - .def = 0x8000}, - [AC97_MASTER_MONO / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_FAKEPROBE, - .wmask = 0x801F, - .def = 0x8000}, - [AC97_PC_BEEP / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_FAKEPROBE, - .wmask = 0x801E, - .def = 0x0}, - [AC97_PHONE / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_FAKEPROBE, - .wmask = 0x801F, - .def = 0x8008}, - [AC97_MIC / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_FAKEPROBE, - .wmask = 0x805F, - .def = 0x8008}, - [AC97_LINE / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_FAKEPROBE, - .wmask = 0x9F1F, - .def = 0x8808}, - [AC97_CD / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_FAKEPROBE, - .wmask = 0x9F1F, - .def = 0x8808}, - [AC97_VIDEO / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_FAKEPROBE, - .wmask = 0x9F1F, - .def = 0x8808}, - [AC97_AUX / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_FAKEPROBE, - .wmask = 0x9F1F, - .def = 0x8808}, - [AC97_PCM / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_FAKEPROBE, - .wmask = 0x9F1F, - .def = 0x8008}, - [AC97_REC_SEL / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_FAKEPROBE, - .wmask = 0x707, - .def = 0x0}, - [AC97_REC_GAIN / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_FAKEPROBE, - .wmask = 0x8F0F, - .def = 0x8000}, - [AC97_GENERAL_PURPOSE / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_FAKEPROBE, - .def = 0x0, - .wmask = 0xA380}, - [AC97_3D_CONTROL / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_FAKEREAD \ - | LM4550_REG_READONLY, - .def = 0x0101}, - [AC97_POWERDOWN / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_NOSHADOW \ - | LM4550_REG_NOSAVE, - .wmask = 0xFF00}, - /* may not write ones to - * REF/ANL/DAC/ADC bits - * FIXME: Is this ok? - */ - [AC97_EXTENDED_ID / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_FAKEREAD \ - | LM4550_REG_READONLY, - .def = 0x0201}, /* primary codec */ - [AC97_EXTENDED_STATUS / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_NOSHADOW \ - | LM4550_REG_NOSAVE, - .wmask = 0x1}, - [AC97_PCM_FRONT_DAC_RATE / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_FAKEPROBE, - .def = 0xBB80, - .wmask = 0xFFFF}, - [AC97_PCM_LR_ADC_RATE / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_FAKEPROBE, - .def = 0xBB80, - .wmask = 0xFFFF}, - [AC97_VENDOR_ID1 / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_READONLY \ - | LM4550_REG_FAKEREAD, - .def = 0x4E53}, - [AC97_VENDOR_ID2 / 2] = {.flag = LM4550_REG_OK \ - | LM4550_REG_READONLY \ - | LM4550_REG_FAKEREAD, - .def = 0x4350} -}; - -#define LM4550_RF_OK(reg) (lm4550_regfile[reg / 2].flag & LM4550_REG_OK) - -static void lm4550_regfile_init(void) -{ - int i; - for (i = 0; i < 64; i++) - if (lm4550_regfile[i].flag & LM4550_REG_FAKEPROBE) - lm4550_regfile[i].value = lm4550_regfile[i].def; -} - -static void lm4550_regfile_write_values_after_init(struct snd_ac97 *ac97) -{ - int i; - for (i = 0; i < 64; i++) - if ((lm4550_regfile[i].flag & LM4550_REG_FAKEPROBE) && - (lm4550_regfile[i].value != lm4550_regfile[i].def)) { - PDEBUG(CODEC_FAKE, "lm4550_regfile_write_values_after_" - "init(): reg=0x%x value=0x%x / %d is different " - "from def=0x%x / %d\n", - i, lm4550_regfile[i].value, - lm4550_regfile[i].value, lm4550_regfile[i].def, - lm4550_regfile[i].def); - snd_ac97_write(ac97, i * 2, lm4550_regfile[i].value); - lm4550_regfile[i].flag |= LM4550_REG_DONEREAD; - } -} - - -/* direct registers */ -#define CR_REG(ml403_ac97cr, x) ((ml403_ac97cr)->port + CR_REG_##x) - -#define CR_REG_PLAYFIFO 0x00 -#define CR_PLAYDATA(a) ((a) & 0xFFFF) - -#define CR_REG_RECFIFO 0x04 -#define CR_RECDATA(a) ((a) & 0xFFFF) - -#define CR_REG_STATUS 0x08 -#define CR_RECOVER (1<<7) -#define CR_PLAYUNDER (1<<6) -#define CR_CODECREADY (1<<5) -#define CR_RAF (1<<4) -#define CR_RECEMPTY (1<<3) -#define CR_RECFULL (1<<2) -#define CR_PLAYHALF (1<<1) -#define CR_PLAYFULL (1<<0) - -#define CR_REG_RESETFIFO 0x0C -#define CR_RECRESET (1<<1) -#define CR_PLAYRESET (1<<0) - -#define CR_REG_CODEC_ADDR 0x10 -/* UG082 says: - * #define CR_CODEC_ADDR(a) ((a) << 1) - * #define CR_CODEC_READ (1<<0) - * #define CR_CODEC_WRITE (0<<0) - */ -/* RefDesign example says: */ -#define CR_CODEC_ADDR(a) ((a) << 0) -#define CR_CODEC_READ (1<<7) -#define CR_CODEC_WRITE (0<<7) - -#define CR_REG_CODEC_DATAREAD 0x14 -#define CR_CODEC_DATAREAD(v) ((v) & 0xFFFF) - -#define CR_REG_CODEC_DATAWRITE 0x18 -#define CR_CODEC_DATAWRITE(v) ((v) & 0xFFFF) - -#define CR_FIFO_SIZE 32 - -struct snd_ml403_ac97cr { - /* lock for access to (controller) registers */ - spinlock_t reg_lock; - /* mutex for the whole sequence of accesses to (controller) registers - * which affect codec registers - */ - struct mutex cdc_mutex; - - int irq; /* for playback */ - int enable_irq; /* for playback */ - - int capture_irq; - int enable_capture_irq; - - struct resource *res_port; - void *port; - - struct snd_ac97 *ac97; - int ac97_fake; -#ifdef CODEC_STAT - int ac97_read; - int ac97_write; -#endif - - struct platform_device *pfdev; - struct snd_card *card; - struct snd_pcm *pcm; - struct snd_pcm_substream *playback_substream; - struct snd_pcm_substream *capture_substream; - - struct snd_pcm_indirect2 ind_rec; /* for playback */ - struct snd_pcm_indirect2 capture_ind2_rec; -}; - -static const struct snd_pcm_hardware snd_ml403_ac97cr_playback = { - .info = (SNDRV_PCM_INFO_MMAP | - SNDRV_PCM_INFO_INTERLEAVED | - SNDRV_PCM_INFO_MMAP_VALID), - .formats = SNDRV_PCM_FMTBIT_S16_BE, - .rates = (SNDRV_PCM_RATE_CONTINUOUS | - SNDRV_PCM_RATE_8000_48000), - .rate_min = 4000, - .rate_max = 48000, - .channels_min = 2, - .channels_max = 2, - .buffer_bytes_max = (128*1024), - .period_bytes_min = CR_FIFO_SIZE/2, - .period_bytes_max = (64*1024), - .periods_min = 2, - .periods_max = (128*1024)/(CR_FIFO_SIZE/2), - .fifo_size = 0, -}; - -static const struct snd_pcm_hardware snd_ml403_ac97cr_capture = { - .info = (SNDRV_PCM_INFO_MMAP | - SNDRV_PCM_INFO_INTERLEAVED | - SNDRV_PCM_INFO_MMAP_VALID), - .formats = SNDRV_PCM_FMTBIT_S16_BE, - .rates = (SNDRV_PCM_RATE_CONTINUOUS | - SNDRV_PCM_RATE_8000_48000), - .rate_min = 4000, - .rate_max = 48000, - .channels_min = 2, - .channels_max = 2, - .buffer_bytes_max = (128*1024), - .period_bytes_min = CR_FIFO_SIZE/2, - .period_bytes_max = (64*1024), - .periods_min = 2, - .periods_max = (128*1024)/(CR_FIFO_SIZE/2), - .fifo_size = 0, -}; - -static size_t -snd_ml403_ac97cr_playback_ind2_zero(struct snd_pcm_substream *substream, - struct snd_pcm_indirect2 *rec) -{ - struct snd_ml403_ac97cr *ml403_ac97cr; - int copied_words = 0; - u32 full = 0; - - ml403_ac97cr = snd_pcm_substream_chip(substream); - - spin_lock(&ml403_ac97cr->reg_lock); - while ((full = (in_be32(CR_REG(ml403_ac97cr, STATUS)) & - CR_PLAYFULL)) != CR_PLAYFULL) { - out_be32(CR_REG(ml403_ac97cr, PLAYFIFO), 0); - copied_words++; - } - rec->hw_ready = 0; - spin_unlock(&ml403_ac97cr->reg_lock); - - return (size_t) (copied_words * 2); -} - -static size_t -snd_ml403_ac97cr_playback_ind2_copy(struct snd_pcm_substream *substream, - struct snd_pcm_indirect2 *rec, - size_t bytes) -{ - struct snd_ml403_ac97cr *ml403_ac97cr; - u16 *src; - int copied_words = 0; - u32 full = 0; - - ml403_ac97cr = snd_pcm_substream_chip(substream); - src = (u16 *)(substream->runtime->dma_area + rec->sw_data); - - spin_lock(&ml403_ac97cr->reg_lock); - while (((full = (in_be32(CR_REG(ml403_ac97cr, STATUS)) & - CR_PLAYFULL)) != CR_PLAYFULL) && (bytes > 1)) { - out_be32(CR_REG(ml403_ac97cr, PLAYFIFO), - CR_PLAYDATA(src[copied_words])); - copied_words++; - bytes = bytes - 2; - } - if (full != CR_PLAYFULL) - rec->hw_ready = 1; - else - rec->hw_ready = 0; - spin_unlock(&ml403_ac97cr->reg_lock); - - return (size_t) (copied_words * 2); -} - -static size_t -snd_ml403_ac97cr_capture_ind2_null(struct snd_pcm_substream *substream, - struct snd_pcm_indirect2 *rec) -{ - struct snd_ml403_ac97cr *ml403_ac97cr; - int copied_words = 0; - u32 empty = 0; - - ml403_ac97cr = snd_pcm_substream_chip(substream); - - spin_lock(&ml403_ac97cr->reg_lock); - while ((empty = (in_be32(CR_REG(ml403_ac97cr, STATUS)) & - CR_RECEMPTY)) != CR_RECEMPTY) { - volatile u32 trash; - - trash = CR_RECDATA(in_be32(CR_REG(ml403_ac97cr, RECFIFO))); - /* Hmmmm, really necessary? Don't want call to in_be32() - * to be optimised away! - */ - trash++; - copied_words++; - } - rec->hw_ready = 0; - spin_unlock(&ml403_ac97cr->reg_lock); - - return (size_t) (copied_words * 2); -} - -static size_t -snd_ml403_ac97cr_capture_ind2_copy(struct snd_pcm_substream *substream, - struct snd_pcm_indirect2 *rec, size_t bytes) -{ - struct snd_ml403_ac97cr *ml403_ac97cr; - u16 *dst; - int copied_words = 0; - u32 empty = 0; - - ml403_ac97cr = snd_pcm_substream_chip(substream); - dst = (u16 *)(substream->runtime->dma_area + rec->sw_data); - - spin_lock(&ml403_ac97cr->reg_lock); - while (((empty = (in_be32(CR_REG(ml403_ac97cr, STATUS)) & - CR_RECEMPTY)) != CR_RECEMPTY) && (bytes > 1)) { - dst[copied_words] = CR_RECDATA(in_be32(CR_REG(ml403_ac97cr, - RECFIFO))); - copied_words++; - bytes = bytes - 2; - } - if (empty != CR_RECEMPTY) - rec->hw_ready = 1; - else - rec->hw_ready = 0; - spin_unlock(&ml403_ac97cr->reg_lock); - - return (size_t) (copied_words * 2); -} - -static snd_pcm_uframes_t -snd_ml403_ac97cr_pcm_pointer(struct snd_pcm_substream *substream) -{ - struct snd_ml403_ac97cr *ml403_ac97cr; - struct snd_pcm_indirect2 *ind2_rec = NULL; - - ml403_ac97cr = snd_pcm_substream_chip(substream); - - if (substream == ml403_ac97cr->playback_substream) - ind2_rec = &ml403_ac97cr->ind_rec; - if (substream == ml403_ac97cr->capture_substream) - ind2_rec = &ml403_ac97cr->capture_ind2_rec; - - if (ind2_rec != NULL) - return snd_pcm_indirect2_pointer(substream, ind2_rec); - return (snd_pcm_uframes_t) 0; -} - -static int -snd_ml403_ac97cr_pcm_playback_trigger(struct snd_pcm_substream *substream, - int cmd) -{ - struct snd_ml403_ac97cr *ml403_ac97cr; - int err = 0; - - ml403_ac97cr = snd_pcm_substream_chip(substream); - - switch (cmd) { - case SNDRV_PCM_TRIGGER_START: - PDEBUG(WORK_INFO, "trigger(playback): START\n"); - ml403_ac97cr->ind_rec.hw_ready = 1; - - /* clear play FIFO */ - out_be32(CR_REG(ml403_ac97cr, RESETFIFO), CR_PLAYRESET); - - /* enable play irq */ - ml403_ac97cr->enable_irq = 1; - enable_irq(ml403_ac97cr->irq); - break; - case SNDRV_PCM_TRIGGER_STOP: - PDEBUG(WORK_INFO, "trigger(playback): STOP\n"); - ml403_ac97cr->ind_rec.hw_ready = 0; -#ifdef SND_PCM_INDIRECT2_STAT - snd_pcm_indirect2_stat(substream, &ml403_ac97cr->ind_rec); -#endif - /* disable play irq */ - disable_irq_nosync(ml403_ac97cr->irq); - ml403_ac97cr->enable_irq = 0; - break; - default: - err = -EINVAL; - break; - } - PDEBUG(WORK_INFO, "trigger(playback): (done)\n"); - return err; -} - -static int -snd_ml403_ac97cr_pcm_capture_trigger(struct snd_pcm_substream *substream, - int cmd) -{ - struct snd_ml403_ac97cr *ml403_ac97cr; - int err = 0; - - ml403_ac97cr = snd_pcm_substream_chip(substream); - - switch (cmd) { - case SNDRV_PCM_TRIGGER_START: - PDEBUG(WORK_INFO, "trigger(capture): START\n"); - ml403_ac97cr->capture_ind2_rec.hw_ready = 0; - - /* clear record FIFO */ - out_be32(CR_REG(ml403_ac97cr, RESETFIFO), CR_RECRESET); - - /* enable record irq */ - ml403_ac97cr->enable_capture_irq = 1; - enable_irq(ml403_ac97cr->capture_irq); - break; - case SNDRV_PCM_TRIGGER_STOP: - PDEBUG(WORK_INFO, "trigger(capture): STOP\n"); - ml403_ac97cr->capture_ind2_rec.hw_ready = 0; -#ifdef SND_PCM_INDIRECT2_STAT - snd_pcm_indirect2_stat(substream, - &ml403_ac97cr->capture_ind2_rec); -#endif - /* disable capture irq */ - disable_irq_nosync(ml403_ac97cr->capture_irq); - ml403_ac97cr->enable_capture_irq = 0; - break; - default: - err = -EINVAL; - break; - } - PDEBUG(WORK_INFO, "trigger(capture): (done)\n"); - return err; -} - -static int -snd_ml403_ac97cr_pcm_playback_prepare(struct snd_pcm_substream *substream) -{ - struct snd_ml403_ac97cr *ml403_ac97cr; - struct snd_pcm_runtime *runtime; - - ml403_ac97cr = snd_pcm_substream_chip(substream); - runtime = substream->runtime; - - PDEBUG(WORK_INFO, - "prepare(): period_bytes=%d, minperiod_bytes=%d\n", - snd_pcm_lib_period_bytes(substream), CR_FIFO_SIZE / 2); - - /* set sampling rate */ - snd_ac97_set_rate(ml403_ac97cr->ac97, AC97_PCM_FRONT_DAC_RATE, - runtime->rate); - PDEBUG(WORK_INFO, "prepare(): rate=%d\n", runtime->rate); - - /* init struct for intermediate buffer */ - memset(&ml403_ac97cr->ind_rec, 0, - sizeof(struct snd_pcm_indirect2)); - ml403_ac97cr->ind_rec.hw_buffer_size = CR_FIFO_SIZE; - ml403_ac97cr->ind_rec.sw_buffer_size = - snd_pcm_lib_buffer_bytes(substream); - ml403_ac97cr->ind_rec.min_periods = -1; - ml403_ac97cr->ind_rec.min_multiple = - snd_pcm_lib_period_bytes(substream) / (CR_FIFO_SIZE / 2); - PDEBUG(WORK_INFO, "prepare(): hw_buffer_size=%d, " - "sw_buffer_size=%d, min_multiple=%d\n", - CR_FIFO_SIZE, ml403_ac97cr->ind_rec.sw_buffer_size, - ml403_ac97cr->ind_rec.min_multiple); - return 0; -} - -static int -snd_ml403_ac97cr_pcm_capture_prepare(struct snd_pcm_substream *substream) -{ - struct snd_ml403_ac97cr *ml403_ac97cr; - struct snd_pcm_runtime *runtime; - - ml403_ac97cr = snd_pcm_substream_chip(substream); - runtime = substream->runtime; - - PDEBUG(WORK_INFO, - "prepare(capture): period_bytes=%d, minperiod_bytes=%d\n", - snd_pcm_lib_period_bytes(substream), CR_FIFO_SIZE / 2); - - /* set sampling rate */ - snd_ac97_set_rate(ml403_ac97cr->ac97, AC97_PCM_LR_ADC_RATE, - runtime->rate); - PDEBUG(WORK_INFO, "prepare(capture): rate=%d\n", runtime->rate); - - /* init struct for intermediate buffer */ - memset(&ml403_ac97cr->capture_ind2_rec, 0, - sizeof(struct snd_pcm_indirect2)); - ml403_ac97cr->capture_ind2_rec.hw_buffer_size = CR_FIFO_SIZE; - ml403_ac97cr->capture_ind2_rec.sw_buffer_size = - snd_pcm_lib_buffer_bytes(substream); - ml403_ac97cr->capture_ind2_rec.min_multiple = - snd_pcm_lib_period_bytes(substream) / (CR_FIFO_SIZE / 2); - PDEBUG(WORK_INFO, "prepare(capture): hw_buffer_size=%d, " - "sw_buffer_size=%d, min_multiple=%d\n", CR_FIFO_SIZE, - ml403_ac97cr->capture_ind2_rec.sw_buffer_size, - ml403_ac97cr->capture_ind2_rec.min_multiple); - return 0; -} - -static int snd_ml403_ac97cr_playback_open(struct snd_pcm_substream *substream) -{ - struct snd_ml403_ac97cr *ml403_ac97cr; - struct snd_pcm_runtime *runtime; - - ml403_ac97cr = snd_pcm_substream_chip(substream); - runtime = substream->runtime; - - PDEBUG(WORK_INFO, "open(playback)\n"); - ml403_ac97cr->playback_substream = substream; - runtime->hw = snd_ml403_ac97cr_playback; - - snd_pcm_hw_constraint_step(runtime, 0, - SNDRV_PCM_HW_PARAM_PERIOD_BYTES, - CR_FIFO_SIZE / 2); - return 0; -} - -static int snd_ml403_ac97cr_capture_open(struct snd_pcm_substream *substream) -{ - struct snd_ml403_ac97cr *ml403_ac97cr; - struct snd_pcm_runtime *runtime; - - ml403_ac97cr = snd_pcm_substream_chip(substream); - runtime = substream->runtime; - - PDEBUG(WORK_INFO, "open(capture)\n"); - ml403_ac97cr->capture_substream = substream; - runtime->hw = snd_ml403_ac97cr_capture; - - snd_pcm_hw_constraint_step(runtime, 0, - SNDRV_PCM_HW_PARAM_PERIOD_BYTES, - CR_FIFO_SIZE / 2); - return 0; -} - -static int snd_ml403_ac97cr_playback_close(struct snd_pcm_substream *substream) -{ - struct snd_ml403_ac97cr *ml403_ac97cr; - - ml403_ac97cr = snd_pcm_substream_chip(substream); - - PDEBUG(WORK_INFO, "close(playback)\n"); - ml403_ac97cr->playback_substream = NULL; - return 0; -} - -static int snd_ml403_ac97cr_capture_close(struct snd_pcm_substream *substream) -{ - struct snd_ml403_ac97cr *ml403_ac97cr; - - ml403_ac97cr = snd_pcm_substream_chip(substream); - - PDEBUG(WORK_INFO, "close(capture)\n"); - ml403_ac97cr->capture_substream = NULL; - return 0; -} - -static const struct snd_pcm_ops snd_ml403_ac97cr_playback_ops = { - .open = snd_ml403_ac97cr_playback_open, - .close = snd_ml403_ac97cr_playback_close, - .prepare = snd_ml403_ac97cr_pcm_playback_prepare, - .trigger = snd_ml403_ac97cr_pcm_playback_trigger, - .pointer = snd_ml403_ac97cr_pcm_pointer, -}; - -static const struct snd_pcm_ops snd_ml403_ac97cr_capture_ops = { - .open = snd_ml403_ac97cr_capture_open, - .close = snd_ml403_ac97cr_capture_close, - .prepare = snd_ml403_ac97cr_pcm_capture_prepare, - .trigger = snd_ml403_ac97cr_pcm_capture_trigger, - .pointer = snd_ml403_ac97cr_pcm_pointer, -}; - -static irqreturn_t snd_ml403_ac97cr_irq(int irq, void *dev_id) -{ - struct snd_ml403_ac97cr *ml403_ac97cr; - struct platform_device *pfdev; - int cmp_irq; - - ml403_ac97cr = (struct snd_ml403_ac97cr *)dev_id; - if (ml403_ac97cr == NULL) - return IRQ_NONE; - - pfdev = ml403_ac97cr->pfdev; - - /* playback interrupt */ - cmp_irq = platform_get_irq(pfdev, 0); - if (irq == cmp_irq) { - if (ml403_ac97cr->enable_irq) - snd_pcm_indirect2_playback_interrupt( - ml403_ac97cr->playback_substream, - &ml403_ac97cr->ind_rec, - snd_ml403_ac97cr_playback_ind2_copy, - snd_ml403_ac97cr_playback_ind2_zero); - else - goto __disable_irq; - } else { - /* record interrupt */ - cmp_irq = platform_get_irq(pfdev, 1); - if (irq == cmp_irq) { - if (ml403_ac97cr->enable_capture_irq) - snd_pcm_indirect2_capture_interrupt( - ml403_ac97cr->capture_substream, - &ml403_ac97cr->capture_ind2_rec, - snd_ml403_ac97cr_capture_ind2_copy, - snd_ml403_ac97cr_capture_ind2_null); - else - goto __disable_irq; - } else - return IRQ_NONE; - } - return IRQ_HANDLED; - -__disable_irq: - PDEBUG(INIT_INFO, "irq(): irq %d is meant to be disabled! So, now try " - "to disable it _really_!\n", irq); - disable_irq_nosync(irq); - return IRQ_HANDLED; -} - -static unsigned short -snd_ml403_ac97cr_codec_read(struct snd_ac97 *ac97, unsigned short reg) -{ - struct snd_ml403_ac97cr *ml403_ac97cr = ac97->private_data; -#ifdef CODEC_STAT - u32 stat; - u32 rafaccess = 0; -#endif - unsigned long end_time; - u16 value = 0; - - if (!LM4550_RF_OK(reg)) { - snd_printk(KERN_WARNING SND_ML403_AC97CR_DRIVER ": " - "access to unknown/unused codec register 0x%x " - "ignored!\n", reg); - return 0; - } - /* check if we can fake/answer this access from our shadow register */ - if ((lm4550_regfile[reg / 2].flag & - (LM4550_REG_DONEREAD | LM4550_REG_ALLFAKE)) && - !(lm4550_regfile[reg / 2].flag & LM4550_REG_NOSHADOW)) { - if (lm4550_regfile[reg / 2].flag & LM4550_REG_FAKEREAD) { - PDEBUG(CODEC_FAKE, "codec_read(): faking read from " - "reg=0x%x, val=0x%x / %d\n", - reg, lm4550_regfile[reg / 2].def, - lm4550_regfile[reg / 2].def); - return lm4550_regfile[reg / 2].def; - } else if ((lm4550_regfile[reg / 2].flag & - LM4550_REG_FAKEPROBE) && - ml403_ac97cr->ac97_fake) { - PDEBUG(CODEC_FAKE, "codec_read(): faking read from " - "reg=0x%x, val=0x%x / %d (probe)\n", - reg, lm4550_regfile[reg / 2].value, - lm4550_regfile[reg / 2].value); - return lm4550_regfile[reg / 2].value; - } else { -#ifdef CODEC_STAT - PDEBUG(CODEC_FAKE, "codec_read(): read access " - "answered by shadow register 0x%x (value=0x%x " - "/ %d) (cw=%d cr=%d)\n", - reg, lm4550_regfile[reg / 2].value, - lm4550_regfile[reg / 2].value, - ml403_ac97cr->ac97_write, - ml403_ac97cr->ac97_read); -#else - PDEBUG(CODEC_FAKE, "codec_read(): read access " - "answered by shadow register 0x%x (value=0x%x " - "/ %d)\n", - reg, lm4550_regfile[reg / 2].value, - lm4550_regfile[reg / 2].value); -#endif - return lm4550_regfile[reg / 2].value; - } - } - /* if we are here, we _have_ to access the codec really, no faking */ - if (mutex_lock_interruptible(&ml403_ac97cr->cdc_mutex) != 0) - return 0; -#ifdef CODEC_STAT - ml403_ac97cr->ac97_read++; -#endif - spin_lock(&ml403_ac97cr->reg_lock); - out_be32(CR_REG(ml403_ac97cr, CODEC_ADDR), - CR_CODEC_ADDR(reg) | CR_CODEC_READ); - spin_unlock(&ml403_ac97cr->reg_lock); - end_time = jiffies + (HZ / CODEC_TIMEOUT_AFTER_READ); - do { - spin_lock(&ml403_ac97cr->reg_lock); -#ifdef CODEC_STAT - rafaccess++; - stat = in_be32(CR_REG(ml403_ac97cr, STATUS)); - if ((stat & CR_RAF) == CR_RAF) { - value = CR_CODEC_DATAREAD( - in_be32(CR_REG(ml403_ac97cr, CODEC_DATAREAD))); - PDEBUG(CODEC_SUCCESS, "codec_read(): (done) reg=0x%x, " - "value=0x%x / %d (STATUS=0x%x)\n", - reg, value, value, stat); -#else - if ((in_be32(CR_REG(ml403_ac97cr, STATUS)) & - CR_RAF) == CR_RAF) { - value = CR_CODEC_DATAREAD( - in_be32(CR_REG(ml403_ac97cr, CODEC_DATAREAD))); - PDEBUG(CODEC_SUCCESS, "codec_read(): (done) " - "reg=0x%x, value=0x%x / %d\n", - reg, value, value); -#endif - lm4550_regfile[reg / 2].value = value; - lm4550_regfile[reg / 2].flag |= LM4550_REG_DONEREAD; - spin_unlock(&ml403_ac97cr->reg_lock); - mutex_unlock(&ml403_ac97cr->cdc_mutex); - return value; - } - spin_unlock(&ml403_ac97cr->reg_lock); - schedule_timeout_uninterruptible(1); - } while (time_after(end_time, jiffies)); - /* read the DATAREAD register anyway, see comment below */ - spin_lock(&ml403_ac97cr->reg_lock); - value = - CR_CODEC_DATAREAD(in_be32(CR_REG(ml403_ac97cr, CODEC_DATAREAD))); - spin_unlock(&ml403_ac97cr->reg_lock); -#ifdef CODEC_STAT - snd_printk(KERN_WARNING SND_ML403_AC97CR_DRIVER ": " - "timeout while codec read! " - "(reg=0x%x, last STATUS=0x%x, DATAREAD=0x%x / %d, %d) " - "(cw=%d, cr=%d)\n", - reg, stat, value, value, rafaccess, - ml403_ac97cr->ac97_write, ml403_ac97cr->ac97_read); -#else - snd_printk(KERN_WARNING SND_ML403_AC97CR_DRIVER ": " - "timeout while codec read! " - "(reg=0x%x, DATAREAD=0x%x / %d)\n", - reg, value, value); -#endif - /* BUG: This is PURE speculation! But after _most_ read timeouts the - * value in the register is ok! - */ - lm4550_regfile[reg / 2].value = value; - lm4550_regfile[reg / 2].flag |= LM4550_REG_DONEREAD; - mutex_unlock(&ml403_ac97cr->cdc_mutex); - return value; -} - -static void -snd_ml403_ac97cr_codec_write(struct snd_ac97 *ac97, unsigned short reg, - unsigned short val) -{ - struct snd_ml403_ac97cr *ml403_ac97cr = ac97->private_data; - -#ifdef CODEC_STAT - u32 stat; - u32 rafaccess = 0; -#endif -#ifdef CODEC_WRITE_CHECK_RAF - unsigned long end_time; -#endif - - if (!LM4550_RF_OK(reg)) { - snd_printk(KERN_WARNING SND_ML403_AC97CR_DRIVER ": " - "access to unknown/unused codec register 0x%x " - "ignored!\n", reg); - return; - } - if (lm4550_regfile[reg / 2].flag & LM4550_REG_READONLY) { - snd_printk(KERN_WARNING SND_ML403_AC97CR_DRIVER ": " - "write access to read only codec register 0x%x " - "ignored!\n", reg); - return; - } - if ((val & lm4550_regfile[reg / 2].wmask) != val) { - snd_printk(KERN_WARNING SND_ML403_AC97CR_DRIVER ": " - "write access to codec register 0x%x " - "with bad value 0x%x / %d!\n", - reg, val, val); - val = val & lm4550_regfile[reg / 2].wmask; - } - if (((lm4550_regfile[reg / 2].flag & LM4550_REG_FAKEPROBE) && - ml403_ac97cr->ac97_fake) && - !(lm4550_regfile[reg / 2].flag & LM4550_REG_NOSHADOW)) { - PDEBUG(CODEC_FAKE, "codec_write(): faking write to reg=0x%x, " - "val=0x%x / %d\n", reg, val, val); - lm4550_regfile[reg / 2].value = (val & - lm4550_regfile[reg / 2].wmask); - return; - } - if (mutex_lock_interruptible(&ml403_ac97cr->cdc_mutex) != 0) - return; -#ifdef CODEC_STAT - ml403_ac97cr->ac97_write++; -#endif - spin_lock(&ml403_ac97cr->reg_lock); - out_be32(CR_REG(ml403_ac97cr, CODEC_DATAWRITE), - CR_CODEC_DATAWRITE(val)); - out_be32(CR_REG(ml403_ac97cr, CODEC_ADDR), - CR_CODEC_ADDR(reg) | CR_CODEC_WRITE); - spin_unlock(&ml403_ac97cr->reg_lock); -#ifdef CODEC_WRITE_CHECK_RAF - /* check CR_CODEC_RAF bit to see if write access to register is done; - * loop until bit is set or timeout happens - */ - end_time = jiffies + HZ / CODEC_TIMEOUT_AFTER_WRITE; - do { - spin_lock(&ml403_ac97cr->reg_lock); -#ifdef CODEC_STAT - rafaccess++; - stat = in_be32(CR_REG(ml403_ac97cr, STATUS)) - if ((stat & CR_RAF) == CR_RAF) { -#else - if ((in_be32(CR_REG(ml403_ac97cr, STATUS)) & - CR_RAF) == CR_RAF) { -#endif - PDEBUG(CODEC_SUCCESS, "codec_write(): (done) " - "reg=0x%x, value=%d / 0x%x\n", - reg, val, val); - if (!(lm4550_regfile[reg / 2].flag & - LM4550_REG_NOSHADOW) && - !(lm4550_regfile[reg / 2].flag & - LM4550_REG_NOSAVE)) - lm4550_regfile[reg / 2].value = val; - lm4550_regfile[reg / 2].flag |= LM4550_REG_DONEREAD; - spin_unlock(&ml403_ac97cr->reg_lock); - mutex_unlock(&ml403_ac97cr->cdc_mutex); - return; - } - spin_unlock(&ml403_ac97cr->reg_lock); - schedule_timeout_uninterruptible(1); - } while (time_after(end_time, jiffies)); -#ifdef CODEC_STAT - snd_printk(KERN_WARNING SND_ML403_AC97CR_DRIVER ": " - "timeout while codec write " - "(reg=0x%x, val=0x%x / %d, last STATUS=0x%x, %d) " - "(cw=%d, cr=%d)\n", - reg, val, val, stat, rafaccess, ml403_ac97cr->ac97_write, - ml403_ac97cr->ac97_read); -#else - snd_printk(KERN_WARNING SND_ML403_AC97CR_DRIVER ": " - "timeout while codec write (reg=0x%x, val=0x%x / %d)\n", - reg, val, val); -#endif -#else /* CODEC_WRITE_CHECK_RAF */ -#if CODEC_WAIT_AFTER_WRITE > 0 - /* officially, in AC97 spec there is no possibility for a AC97 - * controller to determine, if write access is done or not - so: How - * is Xilinx able to provide a RAF bit for write access? - * => very strange, thus just don't check RAF bit (compare with - * Xilinx's example app in EDK 8.1i) and wait - */ - schedule_timeout_uninterruptible(HZ / CODEC_WAIT_AFTER_WRITE); -#endif - PDEBUG(CODEC_SUCCESS, "codec_write(): (done) " - "reg=0x%x, value=%d / 0x%x (no RAF check)\n", - reg, val, val); -#endif - mutex_unlock(&ml403_ac97cr->cdc_mutex); - return; -} - -static int -snd_ml403_ac97cr_chip_init(struct snd_ml403_ac97cr *ml403_ac97cr) -{ - unsigned long end_time; - PDEBUG(INIT_INFO, "chip_init():\n"); - end_time = jiffies + HZ / CODEC_TIMEOUT_ON_INIT; - do { - if (in_be32(CR_REG(ml403_ac97cr, STATUS)) & CR_CODECREADY) { - /* clear both hardware FIFOs */ - out_be32(CR_REG(ml403_ac97cr, RESETFIFO), - CR_RECRESET | CR_PLAYRESET); - PDEBUG(INIT_INFO, "chip_init(): (done)\n"); - return 0; - } - schedule_timeout_uninterruptible(1); - } while (time_after(end_time, jiffies)); - snd_printk(KERN_ERR SND_ML403_AC97CR_DRIVER ": " - "timeout while waiting for codec, " - "not ready!\n"); - return -EBUSY; -} - -static int snd_ml403_ac97cr_free(struct snd_ml403_ac97cr *ml403_ac97cr) -{ - PDEBUG(INIT_INFO, "free():\n"); - /* irq release */ - if (ml403_ac97cr->irq >= 0) - free_irq(ml403_ac97cr->irq, ml403_ac97cr); - if (ml403_ac97cr->capture_irq >= 0) - free_irq(ml403_ac97cr->capture_irq, ml403_ac97cr); - /* give back "port" */ - iounmap(ml403_ac97cr->port); - kfree(ml403_ac97cr); - PDEBUG(INIT_INFO, "free(): (done)\n"); - return 0; -} - -static int snd_ml403_ac97cr_dev_free(struct snd_device *snddev) -{ - struct snd_ml403_ac97cr *ml403_ac97cr = snddev->device_data; - PDEBUG(INIT_INFO, "dev_free():\n"); - return snd_ml403_ac97cr_free(ml403_ac97cr); -} - -static int -snd_ml403_ac97cr_create(struct snd_card *card, struct platform_device *pfdev, - struct snd_ml403_ac97cr **rml403_ac97cr) -{ - struct snd_ml403_ac97cr *ml403_ac97cr; - int err; - static const struct snd_device_ops ops = { - .dev_free = snd_ml403_ac97cr_dev_free, - }; - struct resource *resource; - int irq; - - *rml403_ac97cr = NULL; - ml403_ac97cr = kzalloc(sizeof(*ml403_ac97cr), GFP_KERNEL); - if (ml403_ac97cr == NULL) - return -ENOMEM; - spin_lock_init(&ml403_ac97cr->reg_lock); - mutex_init(&ml403_ac97cr->cdc_mutex); - ml403_ac97cr->card = card; - ml403_ac97cr->pfdev = pfdev; - ml403_ac97cr->irq = -1; - ml403_ac97cr->enable_irq = 0; - ml403_ac97cr->capture_irq = -1; - ml403_ac97cr->enable_capture_irq = 0; - ml403_ac97cr->port = NULL; - ml403_ac97cr->res_port = NULL; - - PDEBUG(INIT_INFO, "Trying to reserve resources now ...\n"); - resource = platform_get_resource(pfdev, IORESOURCE_MEM, 0); - /* get "port" */ - ml403_ac97cr->port = ioremap(resource->start, - (resource->end) - - (resource->start) + 1); - if (ml403_ac97cr->port == NULL) { - snd_printk(KERN_ERR SND_ML403_AC97CR_DRIVER ": " - "unable to remap memory region (%pR)\n", - resource); - snd_ml403_ac97cr_free(ml403_ac97cr); - return -EBUSY; - } - snd_printk(KERN_INFO SND_ML403_AC97CR_DRIVER ": " - "remap controller memory region to " - "0x%x done\n", (unsigned int)ml403_ac97cr->port); - /* get irq */ - irq = platform_get_irq(pfdev, 0); - if (request_irq(irq, snd_ml403_ac97cr_irq, 0, - dev_name(&pfdev->dev), (void *)ml403_ac97cr)) { - snd_printk(KERN_ERR SND_ML403_AC97CR_DRIVER ": " - "unable to grab IRQ %d\n", - irq); - snd_ml403_ac97cr_free(ml403_ac97cr); - return -EBUSY; - } - ml403_ac97cr->irq = irq; - snd_printk(KERN_INFO SND_ML403_AC97CR_DRIVER ": " - "request (playback) irq %d done\n", - ml403_ac97cr->irq); - irq = platform_get_irq(pfdev, 1); - if (request_irq(irq, snd_ml403_ac97cr_irq, 0, - dev_name(&pfdev->dev), (void *)ml403_ac97cr)) { - snd_printk(KERN_ERR SND_ML403_AC97CR_DRIVER ": " - "unable to grab IRQ %d\n", - irq); - snd_ml403_ac97cr_free(ml403_ac97cr); - return -EBUSY; - } - ml403_ac97cr->capture_irq = irq; - snd_printk(KERN_INFO SND_ML403_AC97CR_DRIVER ": " - "request (capture) irq %d done\n", - ml403_ac97cr->capture_irq); - - err = snd_ml403_ac97cr_chip_init(ml403_ac97cr); - if (err < 0) { - snd_ml403_ac97cr_free(ml403_ac97cr); - return err; - } - - err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, ml403_ac97cr, &ops); - if (err < 0) { - PDEBUG(INIT_FAILURE, "probe(): snd_device_new() failed!\n"); - snd_ml403_ac97cr_free(ml403_ac97cr); - return err; - } - - *rml403_ac97cr = ml403_ac97cr; - return 0; -} - -static void snd_ml403_ac97cr_mixer_free(struct snd_ac97 *ac97) -{ - struct snd_ml403_ac97cr *ml403_ac97cr = ac97->private_data; - PDEBUG(INIT_INFO, "mixer_free():\n"); - ml403_ac97cr->ac97 = NULL; - PDEBUG(INIT_INFO, "mixer_free(): (done)\n"); -} - -static int -snd_ml403_ac97cr_mixer(struct snd_ml403_ac97cr *ml403_ac97cr) -{ - struct snd_ac97_bus *bus; - struct snd_ac97_template ac97; - int err; - static const struct snd_ac97_bus_ops ops = { - .write = snd_ml403_ac97cr_codec_write, - .read = snd_ml403_ac97cr_codec_read, - }; - PDEBUG(INIT_INFO, "mixer():\n"); - err = snd_ac97_bus(ml403_ac97cr->card, 0, &ops, NULL, &bus); - if (err < 0) - return err; - - memset(&ac97, 0, sizeof(ac97)); - ml403_ac97cr->ac97_fake = 1; - lm4550_regfile_init(); -#ifdef CODEC_STAT - ml403_ac97cr->ac97_read = 0; - ml403_ac97cr->ac97_write = 0; -#endif - ac97.private_data = ml403_ac97cr; - ac97.private_free = snd_ml403_ac97cr_mixer_free; - ac97.scaps = AC97_SCAP_AUDIO | AC97_SCAP_SKIP_MODEM | - AC97_SCAP_NO_SPDIF; - err = snd_ac97_mixer(bus, &ac97, &ml403_ac97cr->ac97); - ml403_ac97cr->ac97_fake = 0; - lm4550_regfile_write_values_after_init(ml403_ac97cr->ac97); - PDEBUG(INIT_INFO, "mixer(): (done) snd_ac97_mixer()=%d\n", err); - return err; -} - -static int -snd_ml403_ac97cr_pcm(struct snd_ml403_ac97cr *ml403_ac97cr, int device) -{ - struct snd_pcm *pcm; - int err; - - err = snd_pcm_new(ml403_ac97cr->card, "ML403AC97CR/1", device, 1, 1, - &pcm); - if (err < 0) - return err; - snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, - &snd_ml403_ac97cr_playback_ops); - snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, - &snd_ml403_ac97cr_capture_ops); - pcm->private_data = ml403_ac97cr; - pcm->info_flags = 0; - strcpy(pcm->name, "ML403AC97CR DAC/ADC"); - ml403_ac97cr->pcm = pcm; - - snd_pcm_set_managed_buffer_all(pcm, SNDRV_DMA_TYPE_CONTINUOUS, - NULL, - 64 * 1024, - 128 * 1024); - return 0; -} - -static int snd_ml403_ac97cr_probe(struct platform_device *pfdev) -{ - struct snd_card *card; - struct snd_ml403_ac97cr *ml403_ac97cr = NULL; - int err; - int dev = pfdev->id; - - if (dev >= SNDRV_CARDS) - return -ENODEV; - if (!enable[dev]) - return -ENOENT; - - err = snd_card_new(&pfdev->dev, index[dev], id[dev], THIS_MODULE, - 0, &card); - if (err < 0) - return err; - err = snd_ml403_ac97cr_create(card, pfdev, &ml403_ac97cr); - if (err < 0) { - PDEBUG(INIT_FAILURE, "probe(): create failed!\n"); - snd_card_free(card); - return err; - } - PDEBUG(INIT_INFO, "probe(): create done\n"); - card->private_data = ml403_ac97cr; - err = snd_ml403_ac97cr_mixer(ml403_ac97cr); - if (err < 0) { - snd_card_free(card); - return err; - } - PDEBUG(INIT_INFO, "probe(): mixer done\n"); - err = snd_ml403_ac97cr_pcm(ml403_ac97cr, 0); - if (err < 0) { - snd_card_free(card); - return err; - } - PDEBUG(INIT_INFO, "probe(): PCM done\n"); - strcpy(card->driver, SND_ML403_AC97CR_DRIVER); - strcpy(card->shortname, "ML403 AC97 Controller Reference"); - sprintf(card->longname, "%s %s at 0x%lx, irq %i & %i, device %i", - card->shortname, card->driver, - (unsigned long)ml403_ac97cr->port, ml403_ac97cr->irq, - ml403_ac97cr->capture_irq, dev + 1); - - err = snd_card_register(card); - if (err < 0) { - snd_card_free(card); - return err; - } - platform_set_drvdata(pfdev, card); - PDEBUG(INIT_INFO, "probe(): (done)\n"); - return 0; -} - -static int snd_ml403_ac97cr_remove(struct platform_device *pfdev) -{ - snd_card_free(platform_get_drvdata(pfdev)); - return 0; -} - -/* work with hotplug and coldplug */ -MODULE_ALIAS("platform:" SND_ML403_AC97CR_DRIVER); - -static struct platform_driver snd_ml403_ac97cr_driver = { - .probe = snd_ml403_ac97cr_probe, - .remove = snd_ml403_ac97cr_remove, - .driver = { - .name = SND_ML403_AC97CR_DRIVER, - }, -}; - -module_platform_driver(snd_ml403_ac97cr_driver);
On Fri, 27 Mar 2020 13:12:21 +0100, Michal Simek wrote:
Xilinx PowerPC platforms are no longer supported and none is really testing these platforms that's why remove them. If someone has any issue with it these patches can be reverted.
Signed-off-by: Michal Simek michal.simek@xilinx.com
sound/drivers/Kconfig | 12 - sound/drivers/Makefile | 2 - sound/drivers/ml403-ac97cr.c | 1298 ----------------------------------
I believe that sound/drivers/pcm-indirect2.[ch] can be removed altogether as it's used/linked only by this driver.
With that, Acked-by: Takashi Iwai tiwai@suse.de
thanks,
Takashi
On Fri, Mar 27, 2020 at 1:12 PM Michal Simek michal.simek@xilinx.com wrote:
recently we wanted to update xilinx intc driver and we found that function which we wanted to remove is still wired by ancient Xilinx PowerPC platforms. Here is the thread about it. https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa2e8@xili...
I have been talking about it internally and there is no interest in these platforms and it is also orphan for quite a long time. None is really running/testing these platforms regularly that's why I think it makes sense to remove them also with drivers which are specific to this platform.
U-Boot support was removed in 2017 without anybody complain about it https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10...
Based on current ppc/next.
If anyone has any objection about it, please let me know.
Acked-by: Arnd Bergmann arnd@arndb.de
This looks reasonable to me as well, in particular as the code only supports the two ppc44x virtex developer boards and no commercial products.
It does raise a follow-up question about ppc40x though: is it time to retire all of it? The other ppc405 machines appear to have seen even fewer updates after the OpenBlockS 600 got added in 2011, so it's possible nobody is using them any more with modern kernels.
I see that OpenWRT removed both ppc40x and ppc44x exactly a year ago after they had not been maintained for years.
However, 44x (in its ppc476 incarnation) is clearly still is used through the fsp2 platform, and can not be deprecated at least until that is known to have stopped getting kernel updates.
Arnd
On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
On Fri, Mar 27, 2020 at 1:12 PM Michal Simek michal.simek@xilinx.com wrote:
recently we wanted to update xilinx intc driver and we found that function which we wanted to remove is still wired by ancient Xilinx PowerPC platforms. Here is the thread about it. https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa2e8@xili...
I have been talking about it internally and there is no interest in these platforms and it is also orphan for quite a long time. None is really running/testing these platforms regularly that's why I think it makes sense to remove them also with drivers which are specific to this platform.
U-Boot support was removed in 2017 without anybody complain about it https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10...
Based on current ppc/next.
If anyone has any objection about it, please let me know.
Acked-by: Arnd Bergmann arnd@arndb.de
This looks reasonable to me as well, in particular as the code only supports the two ppc44x virtex developer boards and no commercial products.
It does raise a follow-up question about ppc40x though: is it time to retire all of it?
Who knows?
I have in possession nice WD My Book Live, based on this architecture, and I won't it gone from modern kernel support. OTOH I understand that amount of real users not too big.
Ah, and I have Amiga board, but that one is being used only for testing, so, I don't care much.
The other ppc405 machines appear to have seen even fewer updates after the OpenBlockS 600 got added in 2011, so it's possible nobody is using them any more with modern kernels.
I see that OpenWRT removed both ppc40x and ppc44x exactly a year ago after they had not been maintained for years.
However, 44x (in its ppc476 incarnation) is clearly still is used through the fsp2 platform, and can not be deprecated at least until that is known to have stopped getting kernel updates.
Arnd
On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
On Fri, Mar 27, 2020 at 1:12 PM Michal Simek michal.simek@xilinx.com wrote:
recently we wanted to update xilinx intc driver and we found that function which we wanted to remove is still wired by ancient Xilinx PowerPC platforms. Here is the thread about it. https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa2e8@xili...
I have been talking about it internally and there is no interest in these platforms and it is also orphan for quite a long time. None is really running/testing these platforms regularly that's why I think it makes sense to remove them also with drivers which are specific to this platform.
U-Boot support was removed in 2017 without anybody complain about it https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10...
Based on current ppc/next.
If anyone has any objection about it, please let me know.
Acked-by: Arnd Bergmann arnd@arndb.de
This looks reasonable to me as well, in particular as the code only supports the two ppc44x virtex developer boards and no commercial products.
It does raise a follow-up question about ppc40x though: is it time to retire all of it?
Who knows?
I have in possession nice WD My Book Live, based on this architecture, and I won't it gone from modern kernel support. OTOH I understand that amount of real users not too big.
+Cc: Christian Lamparter, whom I owe for that WD box.
Ah, and I have Amiga board, but that one is being used only for testing, so, I don't care much.
The other ppc405 machines appear to have seen even fewer updates after the OpenBlockS 600 got added in 2011, so it's possible nobody is using them any more with modern kernels.
I see that OpenWRT removed both ppc40x and ppc44x exactly a year ago after they had not been maintained for years.
However, 44x (in its ppc476 incarnation) is clearly still is used through the fsp2 platform, and can not be deprecated at least until that is known to have stopped getting kernel updates.
Arnd-- With Best Regards, Andy Shevchenko
On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
On Fri, Mar 27, 2020 at 1:12 PM Michal Simek michal.simek@xilinx.com wrote:
recently we wanted to update xilinx intc driver and we found that function which we wanted to remove is still wired by ancient Xilinx PowerPC platforms. Here is the thread about it. https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa2e8@xili...
I have been talking about it internally and there is no interest in these platforms and it is also orphan for quite a long time. None is really running/testing these platforms regularly that's why I think it makes sense to remove them also with drivers which are specific to this platform.
U-Boot support was removed in 2017 without anybody complain about it https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10...
Based on current ppc/next.
If anyone has any objection about it, please let me know.
Acked-by: Arnd Bergmann arnd@arndb.de
This looks reasonable to me as well, in particular as the code only supports the two ppc44x virtex developer boards and no commercial products.
It does raise a follow-up question about ppc40x though: is it time to retire all of it?
Who knows?
I have in possession nice WD My Book Live, based on this architecture, and I won't it gone from modern kernel support. OTOH I understand that amount of real users not too big.
+Cc: Christian Lamparter, whom I owe for that WD box.
According to https://openwrt.org/toh/wd/mybooklive, that one is based on APM82181/ppc464, so it is about several generations newer than what I asked about (ppc40x).
Ah, and I have Amiga board, but that one is being used only for testing, so, I don't care much.
I think there are a couple of ppc440 based Amiga boards, but again, not 405 to my knowledge.
Arnd
On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:
On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
On Fri, Mar 27, 2020 at 1:12 PM Michal Simek michal.simek@xilinx.com wrote:
...
It does raise a follow-up question about ppc40x though: is it time to retire all of it?
Who knows?
I have in possession nice WD My Book Live, based on this architecture, and I won't it gone from modern kernel support. OTOH I understand that amount of real users not too big.
+Cc: Christian Lamparter, whom I owe for that WD box.
According to https://openwrt.org/toh/wd/mybooklive, that one is based on APM82181/ppc464, so it is about several generations newer than what I asked about (ppc40x).
Ah, and I have Amiga board, but that one is being used only for testing, so, I don't care much.
I think there are a couple of ppc440 based Amiga boards, but again, not 405 to my knowledge.
Ah, you are right. No objections from ppc40x removal!
Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :
On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:
On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
On Fri, Mar 27, 2020 at 1:12 PM Michal Simek michal.simek@xilinx.com wrote:
...
It does raise a follow-up question about ppc40x though: is it time to retire all of it?
Who knows?
I have in possession nice WD My Book Live, based on this architecture, and I won't it gone from modern kernel support. OTOH I understand that amount of real users not too big.
+Cc: Christian Lamparter, whom I owe for that WD box.
According to https://openwrt.org/toh/wd/mybooklive, that one is based on APM82181/ppc464, so it is about several generations newer than what I asked about (ppc40x).
Ah, and I have Amiga board, but that one is being used only for testing, so, I don't care much.
I think there are a couple of ppc440 based Amiga boards, but again, not 405 to my knowledge.
Ah, you are right. No objections from ppc40x removal!
Removing 40x would help cleaning things a bit. For instance 40x is the last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x we can get rid of PTE_ATOMIC_UPDATES completely.
If no one objects, I can prepare a series to drop support for 40x completely.
Michael, any thought ?
Christophe
Christophe Leroy christophe.leroy@c-s.fr writes:
Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :
On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:
On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote:
On Fri, Mar 27, 2020 at 1:12 PM Michal Simek michal.simek@xilinx.com wrote:
...
It does raise a follow-up question about ppc40x though: is it time to retire all of it?
Who knows?
I have in possession nice WD My Book Live, based on this architecture, and I won't it gone from modern kernel support. OTOH I understand that amount of real users not too big.
+Cc: Christian Lamparter, whom I owe for that WD box.
According to https://openwrt.org/toh/wd/mybooklive, that one is based on APM82181/ppc464, so it is about several generations newer than what I asked about (ppc40x).
Ah, and I have Amiga board, but that one is being used only for testing, so, I don't care much.
I think there are a couple of ppc440 based Amiga boards, but again, not 405 to my knowledge.
Ah, you are right. No objections from ppc40x removal!
Removing 40x would help cleaning things a bit. For instance 40x is the last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x we can get rid of PTE_ATOMIC_UPDATES completely.
If no one objects, I can prepare a series to drop support for 40x completely.
Michael, any thought ?
I have no attachment to 40x, and I'd certainly be happy to have less code in the tree, we struggle to keep even the modern platforms well maintained.
At the same time I don't want to render anyone's hardware obsolete unnecessarily. But if there's really no one using 40x then we should remove it, it could well be broken already.
So I guess post a series to do the removal and we'll see if anyone speaks up.
cheers
Le 31/03/2020 à 07:30, Michael Ellerman a écrit :
Christophe Leroy christophe.leroy@c-s.fr writes:
Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :
On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:
On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote:
On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote: > On Fri, Mar 27, 2020 at 1:12 PM Michal Simek michal.simek@xilinx.com wrote:
...
> It does raise a follow-up question about ppc40x though: is it time to > retire all of it?
Who knows?
I have in possession nice WD My Book Live, based on this architecture, and I won't it gone from modern kernel support. OTOH I understand that amount of real users not too big.
+Cc: Christian Lamparter, whom I owe for that WD box.
According to https://openwrt.org/toh/wd/mybooklive, that one is based on APM82181/ppc464, so it is about several generations newer than what I asked about (ppc40x).
Ah, and I have Amiga board, but that one is being used only for testing, so, I don't care much.
I think there are a couple of ppc440 based Amiga boards, but again, not 405 to my knowledge.
Ah, you are right. No objections from ppc40x removal!
Removing 40x would help cleaning things a bit. For instance 40x is the last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x we can get rid of PTE_ATOMIC_UPDATES completely.
If no one objects, I can prepare a series to drop support for 40x completely.
Michael, any thought ?
I have no attachment to 40x, and I'd certainly be happy to have less code in the tree, we struggle to keep even the modern platforms well maintained.
At the same time I don't want to render anyone's hardware obsolete unnecessarily. But if there's really no one using 40x then we should remove it, it could well be broken already.
So I guess post a series to do the removal and we'll see if anyone speaks up.
Ok, series sent out, see https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757
While we are at it, can we also remove the 601 ? This one is also full of workarounds and diverges a bit from other 6xx.
I'm unable to find its end of life date, but it was on the market in 1994, so I guess it must be outdated by more than 10-15 yr old now ?
Christophe
On 31. 03. 20 8:56, Christophe Leroy wrote:
Le 31/03/2020 à 07:30, Michael Ellerman a écrit :
Christophe Leroy christophe.leroy@c-s.fr writes:
Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :
On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:
On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote: > On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote: >> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek >> michal.simek@xilinx.com wrote:
...
>> It does raise a follow-up question about ppc40x though: is it >> time to >> retire all of it? > > Who knows? > > I have in possession nice WD My Book Live, based on this > architecture, and I > won't it gone from modern kernel support. OTOH I understand that > amount of real > users not too big.
+Cc: Christian Lamparter, whom I owe for that WD box.
According to https://openwrt.org/toh/wd/mybooklive, that one is based on APM82181/ppc464, so it is about several generations newer than what I asked about (ppc40x).
> Ah, and I have Amiga board, but that one is being used only for > testing, so, > I don't care much.
I think there are a couple of ppc440 based Amiga boards, but again, not 405 to my knowledge.
Ah, you are right. No objections from ppc40x removal!
Removing 40x would help cleaning things a bit. For instance 40x is the last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x we can get rid of PTE_ATOMIC_UPDATES completely.
If no one objects, I can prepare a series to drop support for 40x completely.
Michael, any thought ?
I have no attachment to 40x, and I'd certainly be happy to have less code in the tree, we struggle to keep even the modern platforms well maintained.
At the same time I don't want to render anyone's hardware obsolete unnecessarily. But if there's really no one using 40x then we should remove it, it could well be broken already.
So I guess post a series to do the removal and we'll see if anyone speaks up.
Ok, series sent out, see https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757
ok. I see you have done it completely independently of my patchset. Would be better if you can base it on the top of my 2 patches because they are in conflict now and I need to also remove virtex 44x platform also with alsa driver.
Thanks, Michal
Le 31/03/2020 à 08:59, Michal Simek a écrit :
On 31. 03. 20 8:56, Christophe Leroy wrote:
Le 31/03/2020 à 07:30, Michael Ellerman a écrit :
Christophe Leroy christophe.leroy@c-s.fr writes:
Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :
On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote:
On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko andriy.shevchenko@linux.intel.com wrote: > On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote: >> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote: >>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek >>> michal.simek@xilinx.com wrote:
...
>>> It does raise a follow-up question about ppc40x though: is it >>> time to >>> retire all of it? >> >> Who knows? >> >> I have in possession nice WD My Book Live, based on this >> architecture, and I >> won't it gone from modern kernel support. OTOH I understand that >> amount of real >> users not too big. > > +Cc: Christian Lamparter, whom I owe for that WD box.
According to https://openwrt.org/toh/wd/mybooklive, that one is based on APM82181/ppc464, so it is about several generations newer than what I asked about (ppc40x).
>> Ah, and I have Amiga board, but that one is being used only for >> testing, so, >> I don't care much.
I think there are a couple of ppc440 based Amiga boards, but again, not 405 to my knowledge.
Ah, you are right. No objections from ppc40x removal!
Removing 40x would help cleaning things a bit. For instance 40x is the last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x we can get rid of PTE_ATOMIC_UPDATES completely.
If no one objects, I can prepare a series to drop support for 40x completely.
Michael, any thought ?
I have no attachment to 40x, and I'd certainly be happy to have less code in the tree, we struggle to keep even the modern platforms well maintained.
At the same time I don't want to render anyone's hardware obsolete unnecessarily. But if there's really no one using 40x then we should remove it, it could well be broken already.
So I guess post a series to do the removal and we'll see if anyone speaks up.
Ok, series sent out, see https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757
ok. I see you have done it completely independently of my patchset. Would be better if you can base it on the top of my 2 patches because they are in conflict now and I need to also remove virtex 44x platform also with alsa driver.
I can't see your first patch, only the second one shows up in the series, see https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757
Christophe
Le 31/03/2020 à 09:19, Christophe Leroy a écrit :
Le 31/03/2020 à 08:59, Michal Simek a écrit :
On 31. 03. 20 8:56, Christophe Leroy wrote:
Le 31/03/2020 à 07:30, Michael Ellerman a écrit :
Christophe Leroy christophe.leroy@c-s.fr writes:
Le 27/03/2020 à 15:14, Andy Shevchenko a écrit :
On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote: > On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko > andriy.shevchenko@linux.intel.com wrote: >> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote: >>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote: >>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek >>>> michal.simek@xilinx.com wrote: ...
>>>> It does raise a follow-up question about ppc40x though: is it >>>> time to >>>> retire all of it? >>> >>> Who knows? >>> >>> I have in possession nice WD My Book Live, based on this >>> architecture, and I >>> won't it gone from modern kernel support. OTOH I understand that >>> amount of real >>> users not too big. >> >> +Cc: Christian Lamparter, whom I owe for that WD box. > > According to https://openwrt.org/toh/wd/mybooklive, that one is > based on > APM82181/ppc464, so it is about several generations newer than > what I > asked about (ppc40x). > >>> Ah, and I have Amiga board, but that one is being used only for >>> testing, so, >>> I don't care much. > > I think there are a couple of ppc440 based Amiga boards, but again, > not 405 > to my knowledge.
Ah, you are right. No objections from ppc40x removal!
Removing 40x would help cleaning things a bit. For instance 40x is the last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x we can get rid of PTE_ATOMIC_UPDATES completely.
If no one objects, I can prepare a series to drop support for 40x completely.
Michael, any thought ?
I have no attachment to 40x, and I'd certainly be happy to have less code in the tree, we struggle to keep even the modern platforms well maintained.
At the same time I don't want to render anyone's hardware obsolete unnecessarily. But if there's really no one using 40x then we should remove it, it could well be broken already.
So I guess post a series to do the removal and we'll see if anyone speaks up.
Ok, series sent out, see https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757
ok. I see you have done it completely independently of my patchset. Would be better if you can base it on the top of my 2 patches because they are in conflict now and I need to also remove virtex 44x platform also with alsa driver.
I can't see your first patch, only the second one shows up in the series, see https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757
Ok, I found your first patch on another patchwork, it doesn't touch any file in arch/powerpc/
I sent a v2 series with your powerpc patch as patch 2/11
See https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167766
Christophe
On 31. 03. 20 11:49, Christophe Leroy wrote:
Le 31/03/2020 à 09:19, Christophe Leroy a écrit :
Le 31/03/2020 à 08:59, Michal Simek a écrit :
On 31. 03. 20 8:56, Christophe Leroy wrote:
Le 31/03/2020 à 07:30, Michael Ellerman a écrit :
Christophe Leroy christophe.leroy@c-s.fr writes:
Le 27/03/2020 à 15:14, Andy Shevchenko a écrit : > On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote: >> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko >> andriy.shevchenko@linux.intel.com wrote: >>> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote: >>>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote: >>>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek >>>>> michal.simek@xilinx.com wrote: > ... > >>>>> It does raise a follow-up question about ppc40x though: is it >>>>> time to >>>>> retire all of it? >>>> >>>> Who knows? >>>> >>>> I have in possession nice WD My Book Live, based on this >>>> architecture, and I >>>> won't it gone from modern kernel support. OTOH I understand that >>>> amount of real >>>> users not too big. >>> >>> +Cc: Christian Lamparter, whom I owe for that WD box. >> >> According to https://openwrt.org/toh/wd/mybooklive, that one is >> based on >> APM82181/ppc464, so it is about several generations newer than >> what I >> asked about (ppc40x). >> >>>> Ah, and I have Amiga board, but that one is being used only for >>>> testing, so, >>>> I don't care much. >> >> I think there are a couple of ppc440 based Amiga boards, but again, >> not 405 >> to my knowledge. > > Ah, you are right. No objections from ppc40x removal!
Removing 40x would help cleaning things a bit. For instance 40x is the last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x we can get rid of PTE_ATOMIC_UPDATES completely.
If no one objects, I can prepare a series to drop support for 40x completely.
Michael, any thought ?
I have no attachment to 40x, and I'd certainly be happy to have less code in the tree, we struggle to keep even the modern platforms well maintained.
At the same time I don't want to render anyone's hardware obsolete unnecessarily. But if there's really no one using 40x then we should remove it, it could well be broken already.
So I guess post a series to do the removal and we'll see if anyone speaks up.
Ok, series sent out, see https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757
ok. I see you have done it completely independently of my patchset. Would be better if you can base it on the top of my 2 patches because they are in conflict now and I need to also remove virtex 44x platform also with alsa driver.
I can't see your first patch, only the second one shows up in the series, see https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757
Ok, I found your first patch on another patchwork, it doesn't touch any file in arch/powerpc/
There was just driver dependency on symbol which is removed by 2/2. Let's see what you get from kbuild if any symbol is removed but still used in drivers folder.
I sent a v2 series with your powerpc patch as patch 2/11
See https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167766
Thanks, Michal
Le 31/03/2020 à 12:04, Michal Simek a écrit :
On 31. 03. 20 11:49, Christophe Leroy wrote:
Le 31/03/2020 à 09:19, Christophe Leroy a écrit :
Le 31/03/2020 à 08:59, Michal Simek a écrit :
On 31. 03. 20 8:56, Christophe Leroy wrote:
Le 31/03/2020 à 07:30, Michael Ellerman a écrit :
Christophe Leroy christophe.leroy@c-s.fr writes: > Le 27/03/2020 à 15:14, Andy Shevchenko a écrit : >> On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote: >>> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko >>> andriy.shevchenko@linux.intel.com wrote: >>>> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote: >>>>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote: >>>>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek >>>>>> michal.simek@xilinx.com wrote: >> ... >> >>>>>> It does raise a follow-up question about ppc40x though: is it >>>>>> time to >>>>>> retire all of it? >>>>> >>>>> Who knows? >>>>> >>>>> I have in possession nice WD My Book Live, based on this >>>>> architecture, and I >>>>> won't it gone from modern kernel support. OTOH I understand that >>>>> amount of real >>>>> users not too big. >>>> >>>> +Cc: Christian Lamparter, whom I owe for that WD box. >>> >>> According to https://openwrt.org/toh/wd/mybooklive, that one is >>> based on >>> APM82181/ppc464, so it is about several generations newer than >>> what I >>> asked about (ppc40x). >>> >>>>> Ah, and I have Amiga board, but that one is being used only for >>>>> testing, so, >>>>> I don't care much. >>> >>> I think there are a couple of ppc440 based Amiga boards, but again, >>> not 405 >>> to my knowledge. >> >> Ah, you are right. No objections from ppc40x removal! > > Removing 40x would help cleaning things a bit. For instance 40x is > the > last platform still having PTE_ATOMIC_UPDATES. So if we can remove > 40x > we can get rid of PTE_ATOMIC_UPDATES completely. > > If no one objects, I can prepare a series to drop support for 40x > completely. > > Michael, any thought ?
I have no attachment to 40x, and I'd certainly be happy to have less code in the tree, we struggle to keep even the modern platforms well maintained.
At the same time I don't want to render anyone's hardware obsolete unnecessarily. But if there's really no one using 40x then we should remove it, it could well be broken already.
So I guess post a series to do the removal and we'll see if anyone speaks up.
Ok, series sent out, see https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757
ok. I see you have done it completely independently of my patchset. Would be better if you can base it on the top of my 2 patches because they are in conflict now and I need to also remove virtex 44x platform also with alsa driver.
I can't see your first patch, only the second one shows up in the series, see https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757
Ok, I found your first patch on another patchwork, it doesn't touch any file in arch/powerpc/
There was just driver dependency on symbol which is removed by 2/2. Let's see what you get from kbuild if any symbol is removed but still used in drivers folder.
Nothing bad apparently, see build test at http://kisskb.ellerman.id.au/kisskb/head/a4890e3fb046950e9a62dc3eff5b3746955...
Christophe
On Tue, Mar 31, 2020 at 08:56:23AM +0200, Christophe Leroy wrote:
While we are at it, can we also remove the 601 ? This one is also full of workarounds and diverges a bit from other 6xx.
I'm unable to find its end of life date, but it was on the market in 1994, so I guess it must be outdated by more than 10-15 yr old now ?
There probably are still some people running Linux on 601 powermacs.
Segher
On Tue, Mar 31, 2020 at 7:51 PM Segher Boessenkool segher@kernel.crashing.org wrote:
On Tue, Mar 31, 2020 at 08:56:23AM +0200, Christophe Leroy wrote:
While we are at it, can we also remove the 601 ? This one is also full of workarounds and diverges a bit from other 6xx.
I'm unable to find its end of life date, but it was on the market in 1994, so I guess it must be outdated by more than 10-15 yr old now ?
There probably are still some people running Linux on 601 powermacs.
It could be marked as "BROKEN" for a year to find out for sure ;-)
Apparently there were only two or three models that are old enough to have a 601 and new enough to run Linux with PCI and OF: 7200/8200 and 7500. These were sold for less than 18 months around 1996, though one can still find them on eBay.
Arnd
On Wed, Apr 1, 2020 at 11:07 PM Arnd Bergmann arnd@arndb.de wrote:
On Tue, Mar 31, 2020 at 7:51 PM Segher Boessenkool segher@kernel.crashing.org wrote:
On Tue, Mar 31, 2020 at 08:56:23AM +0200, Christophe Leroy wrote:
While we are at it, can we also remove the 601 ? This one is also full of workarounds and diverges a bit from other 6xx.
I'm unable to find its end of life date, but it was on the market in 1994, so I guess it must be outdated by more than 10-15 yr old now ?
There probably are still some people running Linux on 601 powermacs.
It could be marked as "BROKEN" for a year to find out for sure ;-)
Apparently there were only two or three models that are old enough to have a 601 and new enough to run Linux with PCI and OF: 7200/8200 and 7500. These were sold for less than 18 months around 1996, though one can still find them on eBay.
A. Wilcox said on IRC regarding 601 support in Adélie Linux:
"right now we are primarily targeting G3, though 603 should be supported. 601/601e support is planned to be added for 2.0 (next year)."
Arnd
On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote:
I have no attachment to 40x, and I'd certainly be happy to have less code in the tree, we struggle to keep even the modern platforms well maintained.
At the same time I don't want to render anyone's hardware obsolete unnecessarily. But if there's really no one using 40x then we should remove it, it could well be broken already.
So I guess post a series to do the removal and we'll see if anyone speaks up.
We shouldn't remove 40x completely. Just remove the Xilinx 405 stuff.
Cheers, Ben.
Benjamin Herrenschmidt benh@kernel.crashing.org writes:
On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote:
I have no attachment to 40x, and I'd certainly be happy to have less code in the tree, we struggle to keep even the modern platforms well maintained.
At the same time I don't want to render anyone's hardware obsolete unnecessarily. But if there's really no one using 40x then we should remove it, it could well be broken already.
So I guess post a series to do the removal and we'll see if anyone speaks up.
We shouldn't remove 40x completely. Just remove the Xilinx 405 stuff.
Congratulations on becoming the 40x maintainer!
cheers
On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
Benjamin Herrenschmidt benh@kernel.crashing.org writes:
On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote:
I have no attachment to 40x, and I'd certainly be happy to have less code in the tree, we struggle to keep even the modern platforms well maintained.
At the same time I don't want to render anyone's hardware obsolete unnecessarily. But if there's really no one using 40x then we should remove it, it could well be broken already.
So I guess post a series to do the removal and we'll see if anyone speaks up.
We shouldn't remove 40x completely. Just remove the Xilinx 405 stuff.
Congratulations on becoming the 40x maintainer!
Didn't I give you my last 40x system ? :-) IBM still put 40x cores inside POWER chips no ?
Cheers, Ben.
Hi Ben,
On Wed, Apr 8, 2020 at 1:34 AM Benjamin Herrenschmidt benh@kernel.crashing.org wrote:
On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
Benjamin Herrenschmidt benh@kernel.crashing.org writes:
On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote:
I have no attachment to 40x, and I'd certainly be happy to have less code in the tree, we struggle to keep even the modern platforms well maintained.
At the same time I don't want to render anyone's hardware obsolete unnecessarily. But if there's really no one using 40x then we should remove it, it could well be broken already.
So I guess post a series to do the removal and we'll see if anyone speaks up.
We shouldn't remove 40x completely. Just remove the Xilinx 405 stuff.
Congratulations on becoming the 40x maintainer!
Didn't I give you my last 40x system ? :-) IBM still put 40x cores inside POWER chips no ?
Good to know!
Are they still big-endian, or have they been corrupted by the LE frenzy, too? ;)
Gr{oetje,eeting}s,
Geert
Le 08/04/2020 à 01:32, Benjamin Herrenschmidt a écrit :
On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
Benjamin Herrenschmidt benh@kernel.crashing.org writes:
On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote:
I have no attachment to 40x, and I'd certainly be happy to have less code in the tree, we struggle to keep even the modern platforms well maintained.
At the same time I don't want to render anyone's hardware obsolete unnecessarily. But if there's really no one using 40x then we should remove it, it could well be broken already.
So I guess post a series to do the removal and we'll see if anyone speaks up.
We shouldn't remove 40x completely. Just remove the Xilinx 405 stuff.
Congratulations on becoming the 40x maintainer!
Didn't I give you my last 40x system ? :-) IBM still put 40x cores inside POWER chips no ?
According to Wikipedia (https://en.wikipedia.org/wiki/PowerPC_400), 405 cores are used in modern equipments (how modern ?), however 403 has never reached the market.
Can we start removing 403 stuff ? That's not a lot, but still.
Does anybody knows anything about this ERRATUM 77 stuff ? Is that still an issue with all 405 cores or has this been fixed long time ago and can be removed ?
Christophe
Benjamin Herrenschmidt benh@kernel.crashing.org writes:
On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
Benjamin Herrenschmidt benh@kernel.crashing.org writes:
On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote:
I have no attachment to 40x, and I'd certainly be happy to have less code in the tree, we struggle to keep even the modern platforms well maintained.
At the same time I don't want to render anyone's hardware obsolete unnecessarily. But if there's really no one using 40x then we should remove it, it could well be broken already.
So I guess post a series to do the removal and we'll see if anyone speaks up.
We shouldn't remove 40x completely. Just remove the Xilinx 405 stuff.
Congratulations on becoming the 40x maintainer!
Didn't I give you my last 40x system ? :-)
Probably, but my desk is nearly as messy as yours so it's probably buried under some even more obscure hardware :P
IBM still put 40x cores inside POWER chips no ?
Oh yeah that's true. I guess most folks don't know that, or that they run RHEL on them.
cheers
+On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman mpe@ellerman.id.au wrote:
Benjamin Herrenschmidt benh@kernel.crashing.org writes:
On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
Benjamin Herrenschmidt benh@kernel.crashing.org writes:
IBM still put 40x cores inside POWER chips no ?
Oh yeah that's true. I guess most folks don't know that, or that they run RHEL on them.
Is there a reason for not having those dts files in mainline then? If nothing else, it would document what machines are still being used with future kernels.
Also, if that's the only 405 based product that is still relevant with a 5.7+ kernel, it may be useful to know at which point they move to a 476 core and stop updating kernels on the old ones.
Arnd
Arnd Bergmann arnd@arndb.de writes:
+On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman mpe@ellerman.id.au wrote:
Benjamin Herrenschmidt benh@kernel.crashing.org writes:
On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
Benjamin Herrenschmidt benh@kernel.crashing.org writes:
IBM still put 40x cores inside POWER chips no ?
Oh yeah that's true. I guess most folks don't know that, or that they run RHEL on them.
Is there a reason for not having those dts files in mainline then? If nothing else, it would document what machines are still being used with future kernels.
Sorry that part was a joke :D Those chips don't run Linux.
cheers
Le 21/05/2020 à 09:02, Michael Ellerman a écrit :
Arnd Bergmann arnd@arndb.de writes:
+On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman mpe@ellerman.id.au wrote:
Benjamin Herrenschmidt benh@kernel.crashing.org writes:
On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
Benjamin Herrenschmidt benh@kernel.crashing.org writes:
IBM still put 40x cores inside POWER chips no ?
Oh yeah that's true. I guess most folks don't know that, or that they run RHEL on them.
Is there a reason for not having those dts files in mainline then? If nothing else, it would document what machines are still being used with future kernels.
Sorry that part was a joke :D Those chips don't run Linux.
Nice to know :)
What's the plan then, do we still want to keep 40x in the kernel ?
If yes, is it ok to drop the oldies anyway as done in my series https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=172630 ?
(Note that this series will conflict with my series on hugepages on 8xx due to the PTE_ATOMIC_UPDATES stuff. I can rebase the 40x modernisation series on top of the 8xx hugepages series if it is worth it)
Christophe
Christophe Leroy christophe.leroy@csgroup.eu writes:
Le 21/05/2020 à 09:02, Michael Ellerman a écrit :
Arnd Bergmann arnd@arndb.de writes:
+On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman mpe@ellerman.id.au wrote:
Benjamin Herrenschmidt benh@kernel.crashing.org writes:
On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
Benjamin Herrenschmidt benh@kernel.crashing.org writes:
IBM still put 40x cores inside POWER chips no ?
Oh yeah that's true. I guess most folks don't know that, or that they run RHEL on them.
Is there a reason for not having those dts files in mainline then? If nothing else, it would document what machines are still being used with future kernels.
Sorry that part was a joke :D Those chips don't run Linux.
Nice to know :)
What's the plan then, do we still want to keep 40x in the kernel ?
I guess we keep it for now.
Perhaps we mark it BROKEN for a few releases and see if anyone complains?
If yes, is it ok to drop the oldies anyway as done in my series https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=172630 ?
Yeah let's do it. I would love to get rid of that horrible PPC405_ERR77() sprinkled all through our atomics.
(Note that this series will conflict with my series on hugepages on 8xx due to the PTE_ATOMIC_UPDATES stuff. I can rebase the 40x modernisation series on top of the 8xx hugepages series if it is worth it)
Yeah if you can rebase that would be great.
cheers
On 21. 05. 20 15:53, Michael Ellerman wrote:
Christophe Leroy christophe.leroy@csgroup.eu writes:
Le 21/05/2020 à 09:02, Michael Ellerman a écrit :
Arnd Bergmann arnd@arndb.de writes:
+On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman mpe@ellerman.id.au wrote:
Benjamin Herrenschmidt benh@kernel.crashing.org writes:
On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote: > Benjamin Herrenschmidt benh@kernel.crashing.org writes: IBM still put 40x cores inside POWER chips no ?
Oh yeah that's true. I guess most folks don't know that, or that they run RHEL on them.
Is there a reason for not having those dts files in mainline then? If nothing else, it would document what machines are still being used with future kernels.
Sorry that part was a joke :D Those chips don't run Linux.
Nice to know :)
What's the plan then, do we still want to keep 40x in the kernel ?
I guess we keep it for now.
Perhaps we mark it BROKEN for a few releases and see if anyone complains?
I would like to get at least that xilinx patch to the tree to unblock our changes on interrupt controller.
Thanks, Michal
participants (10)
-
Andy Shevchenko -
Arnd Bergmann -
Benjamin Herrenschmidt -
Christophe Leroy -
Christophe Leroy -
Geert Uytterhoeven -
Michael Ellerman -
Michal Simek -
Segher Boessenkool -
Takashi Iwai