Commit fc457203 authored by Arnd Bergmann's avatar Arnd Bergmann Committed by Lee Jones

mfd: Remove dm355evm_msp driver

The DaVinci DM355EVM platform is gone after the removal of all
unused board files, so the MTD device along with its sub-devices
can be removed as well.
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
Acked-by: default avatarBartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: default avatarLee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20221019152947.3857217-7-arnd@kernel.org
parent 118ee241
......@@ -662,17 +662,6 @@ config INPUT_DA9063_ONKEY
To compile this driver as a module, choose M here: the module
will be called da9063_onkey.
config INPUT_DM355EVM
tristate "TI DaVinci DM355 EVM Keypad and IR Remote"
depends on MFD_DM355EVM_MSP
select INPUT_SPARSEKMAP
help
Supports the pushbuttons and IR remote used with
the DM355 EVM board.
To compile this driver as a module, choose M here: the
module will be called dm355evm_keys.
config INPUT_WM831X_ON
tristate "WM831X ON pin"
depends on MFD_WM831X
......
......@@ -31,7 +31,6 @@ obj-$(CONFIG_INPUT_DA7280_HAPTICS) += da7280.o
obj-$(CONFIG_INPUT_DA9052_ONKEY) += da9052_onkey.o
obj-$(CONFIG_INPUT_DA9055_ONKEY) += da9055_onkey.o
obj-$(CONFIG_INPUT_DA9063_ONKEY) += da9063_onkey.o
obj-$(CONFIG_INPUT_DM355EVM) += dm355evm_keys.o
obj-$(CONFIG_INPUT_E3X0_BUTTON) += e3x0-button.o
obj-$(CONFIG_INPUT_DRV260X_HAPTICS) += drv260x.o
obj-$(CONFIG_INPUT_DRV2665_HAPTICS) += drv2665.o
......
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* dm355evm_keys.c - support buttons and IR remote on DM355 EVM board
*
* Copyright (c) 2008 by David Brownell
*/
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/input.h>
#include <linux/input/sparse-keymap.h>
#include <linux/platform_device.h>
#include <linux/interrupt.h>
#include <linux/mfd/dm355evm_msp.h>
#include <linux/module.h>
/*
* The MSP430 firmware on the DM355 EVM monitors on-board pushbuttons
* and an IR receptor used for the remote control. When any key is
* pressed, or its autorepeat kicks in, an event is sent. This driver
* read those events from the small (32 event) queue and reports them.
*
* Note that physically there can only be one of these devices.
*
* This driver was tested with firmware revision A4.
*/
struct dm355evm_keys {
struct input_dev *input;
struct device *dev;
};
/* These initial keycodes can be remapped */
static const struct key_entry dm355evm_keys[] = {
/*
* Pushbuttons on the EVM board ... note that the labels for these
* are SW10/SW11/etc on the PC board. The left/right orientation
* comes only from the firmware's documentation, and presumes the
* power connector is immediately in front of you and the IR sensor
* is to the right. (That is, rotate the board counter-clockwise
* by 90 degrees from the SW10/etc and "DM355 EVM" labels.)
*/
{ KE_KEY, 0x00d8, { KEY_OK } }, /* SW12 */
{ KE_KEY, 0x00b8, { KEY_UP } }, /* SW13 */
{ KE_KEY, 0x00e8, { KEY_DOWN } }, /* SW11 */
{ KE_KEY, 0x0078, { KEY_LEFT } }, /* SW14 */
{ KE_KEY, 0x00f0, { KEY_RIGHT } }, /* SW10 */
/*
* IR buttons ... codes assigned to match the universal remote
* provided with the EVM (Philips PM4S) using DVD code 0020.
*
* These event codes match firmware documentation, but other
* remote controls could easily send more RC5-encoded events.
* The PM4S manual was used in several cases to help select
* a keycode reflecting the intended usage.
*
* RC5 codes are 14 bits, with two start bits (0x3 prefix)
* and a toggle bit (masked out below).
*/
{ KE_KEY, 0x300c, { KEY_POWER } }, /* NOTE: docs omit this */
{ KE_KEY, 0x3000, { KEY_NUMERIC_0 } },
{ KE_KEY, 0x3001, { KEY_NUMERIC_1 } },
{ KE_KEY, 0x3002, { KEY_NUMERIC_2 } },
{ KE_KEY, 0x3003, { KEY_NUMERIC_3 } },
{ KE_KEY, 0x3004, { KEY_NUMERIC_4 } },
{ KE_KEY, 0x3005, { KEY_NUMERIC_5 } },
{ KE_KEY, 0x3006, { KEY_NUMERIC_6 } },
{ KE_KEY, 0x3007, { KEY_NUMERIC_7 } },
{ KE_KEY, 0x3008, { KEY_NUMERIC_8 } },
{ KE_KEY, 0x3009, { KEY_NUMERIC_9 } },
{ KE_KEY, 0x3022, { KEY_ENTER } },
{ KE_KEY, 0x30ec, { KEY_MODE } }, /* "tv/vcr/..." */
{ KE_KEY, 0x300f, { KEY_SELECT } }, /* "info" */
{ KE_KEY, 0x3020, { KEY_CHANNELUP } }, /* "up" */
{ KE_KEY, 0x302e, { KEY_MENU } }, /* "in/out" */
{ KE_KEY, 0x3011, { KEY_VOLUMEDOWN } }, /* "left" */
{ KE_KEY, 0x300d, { KEY_MUTE } }, /* "ok" */
{ KE_KEY, 0x3010, { KEY_VOLUMEUP } }, /* "right" */
{ KE_KEY, 0x301e, { KEY_SUBTITLE } }, /* "cc" */
{ KE_KEY, 0x3021, { KEY_CHANNELDOWN } },/* "down" */
{ KE_KEY, 0x3022, { KEY_PREVIOUS } },
{ KE_KEY, 0x3026, { KEY_SLEEP } },
{ KE_KEY, 0x3172, { KEY_REWIND } }, /* NOTE: docs wrongly say 0x30ca */
{ KE_KEY, 0x3175, { KEY_PLAY } },
{ KE_KEY, 0x3174, { KEY_FASTFORWARD } },
{ KE_KEY, 0x3177, { KEY_RECORD } },
{ KE_KEY, 0x3176, { KEY_STOP } },
{ KE_KEY, 0x3169, { KEY_PAUSE } },
};
/*
* Because we communicate with the MSP430 using I2C, and all I2C calls
* in Linux sleep, we use a threaded IRQ handler. The IRQ itself is
* active low, but we go through the GPIO controller so we can trigger
* on falling edges and not worry about enabling/disabling the IRQ in
* the keypress handling path.
*/
static irqreturn_t dm355evm_keys_irq(int irq, void *_keys)
{
static u16 last_event;
struct dm355evm_keys *keys = _keys;
const struct key_entry *ke;
unsigned int keycode;
int status;
u16 event;
/* For simplicity we ignore INPUT_COUNT and just read
* events until we get the "queue empty" indicator.
* Reading INPUT_LOW decrements the count.
*/
for (;;) {
status = dm355evm_msp_read(DM355EVM_MSP_INPUT_HIGH);
if (status < 0) {
dev_dbg(keys->dev, "input high err %d\n",
status);
break;
}
event = status << 8;
status = dm355evm_msp_read(DM355EVM_MSP_INPUT_LOW);
if (status < 0) {
dev_dbg(keys->dev, "input low err %d\n",
status);
break;
}
event |= status;
if (event == 0xdead)
break;
/* Press and release a button: two events, same code.
* Press and hold (autorepeat), then release: N events
* (N > 2), same code. For RC5 buttons the toggle bits
* distinguish (for example) "1-autorepeat" from "1 1";
* but PCB buttons don't support that bit.
*
* So we must synthesize release events. We do that by
* mapping events to a press/release event pair; then
* to avoid adding extra events, skip the second event
* of each pair.
*/
if (event == last_event) {
last_event = 0;
continue;
}
last_event = event;
/* ignore the RC5 toggle bit */
event &= ~0x0800;
/* find the key, or report it as unknown */
ke = sparse_keymap_entry_from_scancode(keys->input, event);
keycode = ke ? ke->keycode : KEY_UNKNOWN;
dev_dbg(keys->dev,
"input event 0x%04x--> keycode %d\n",
event, keycode);
/* report press + release */
input_report_key(keys->input, keycode, 1);
input_sync(keys->input);
input_report_key(keys->input, keycode, 0);
input_sync(keys->input);
}
return IRQ_HANDLED;
}
/*----------------------------------------------------------------------*/
static int dm355evm_keys_probe(struct platform_device *pdev)
{
struct dm355evm_keys *keys;
struct input_dev *input;
int irq;
int error;
keys = devm_kzalloc(&pdev->dev, sizeof (*keys), GFP_KERNEL);
if (!keys)
return -ENOMEM;
input = devm_input_allocate_device(&pdev->dev);
if (!input)
return -ENOMEM;
keys->dev = &pdev->dev;
keys->input = input;
input->name = "DM355 EVM Controls";
input->phys = "dm355evm/input0";
input->id.bustype = BUS_I2C;
input->id.product = 0x0355;
input->id.version = dm355evm_msp_read(DM355EVM_MSP_FIRMREV);
error = sparse_keymap_setup(input, dm355evm_keys, NULL);
if (error)
return error;
/* REVISIT: flush the event queue? */
/* set up "threaded IRQ handler" */
irq = platform_get_irq(pdev, 0);
if (irq < 0)
return irq;
error = devm_request_threaded_irq(&pdev->dev, irq,
NULL, dm355evm_keys_irq,
IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
dev_name(&pdev->dev), keys);
if (error)
return error;
/* register */
error = input_register_device(input);
if (error)
return error;
return 0;
}
/* REVISIT: add suspend/resume when DaVinci supports it. The IRQ should
* be able to wake up the system. When device_may_wakeup(&pdev->dev), call
* enable_irq_wake() on suspend, and disable_irq_wake() on resume.
*/
/*
* I2C is used to talk to the MSP430, but this platform device is
* exposed by an MFD driver that manages I2C communications.
*/
static struct platform_driver dm355evm_keys_driver = {
.probe = dm355evm_keys_probe,
.driver = {
.name = "dm355evm_keys",
},
};
module_platform_driver(dm355evm_keys_driver);
MODULE_LICENSE("GPL");
......@@ -1460,14 +1460,6 @@ config MFD_TI_AM335X_TSCADC
To compile this driver as a module, choose M here: the
module will be called ti_am335x_tscadc.
config MFD_DM355EVM_MSP
bool "TI DaVinci DM355 EVM microcontroller"
depends on I2C=y && MACH_DAVINCI_DM355_EVM
help
This driver supports the MSP430 microcontroller used on these
boards. MSP430 firmware manages resets and power sequencing,
inputs from buttons and the IR remote, LEDs, an RTC, and more.
config MFD_LP3943
tristate "TI/National Semiconductor LP3943 MFD Driver"
depends on I2C
......
......@@ -25,7 +25,6 @@ obj-$(CONFIG_MFD_TI_LP873X) += lp873x.o
obj-$(CONFIG_MFD_TI_LP87565) += lp87565.o
obj-$(CONFIG_MFD_DAVINCI_VOICECODEC) += davinci_voicecodec.o
obj-$(CONFIG_MFD_DM355EVM_MSP) += dm355evm_msp.o
obj-$(CONFIG_MFD_TI_AM335X_TSCADC) += ti_am335x_tscadc.o
obj-$(CONFIG_MFD_STA2X11) += sta2x11-mfd.o
......
This diff is collapsed.
......@@ -540,12 +540,6 @@ config RTC_DRV_BQ32K
This driver can also be built as a module. If so, the module
will be called rtc-bq32k.
config RTC_DRV_DM355EVM
tristate "TI DaVinci DM355 EVM RTC"
depends on MFD_DM355EVM_MSP
help
Supports the RTC firmware in the MSP430 on the DM355 EVM.
config RTC_DRV_TWL92330
bool "TI TWL92330/Menelaus"
depends on MENELAUS
......
......@@ -46,7 +46,6 @@ obj-$(CONFIG_RTC_DRV_DA9055) += rtc-da9055.o
obj-$(CONFIG_RTC_DRV_DA9063) += rtc-da9063.o
obj-$(CONFIG_RTC_DRV_DAVINCI) += rtc-davinci.o
obj-$(CONFIG_RTC_DRV_DIGICOLOR) += rtc-digicolor.o
obj-$(CONFIG_RTC_DRV_DM355EVM) += rtc-dm355evm.o
obj-$(CONFIG_RTC_DRV_DS1216) += rtc-ds1216.o
obj-$(CONFIG_RTC_DRV_DS1286) += rtc-ds1286.o
obj-$(CONFIG_RTC_DRV_DS1302) += rtc-ds1302.o
......
// SPDX-License-Identifier: GPL-2.0+
/*
* rtc-dm355evm.c - access battery-backed counter in MSP430 firmware
*
* Copyright (c) 2008 by David Brownell
*/
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/rtc.h>
#include <linux/platform_device.h>
#include <linux/mfd/dm355evm_msp.h>
#include <linux/module.h>
/*
* The MSP430 firmware on the DM355 EVM uses a watch crystal to feed
* a 1 Hz counter. When a backup battery is supplied, that makes a
* reasonable RTC for applications where alarms and non-NTP drift
* compensation aren't important.
*
* The only real glitch is the inability to read or write all four
* counter bytes atomically: the count may increment in the middle
* of an operation, causing trouble when the LSB rolls over.
*
* This driver was tested with firmware revision A4.
*/
union evm_time {
u8 bytes[4];
u32 value;
};
static int dm355evm_rtc_read_time(struct device *dev, struct rtc_time *tm)
{
union evm_time time;
int status;
int tries = 0;
do {
/*
* Read LSB(0) to MSB(3) bytes. Defend against the counter
* rolling over by re-reading until the value is stable,
* and assuming the four reads take at most a few seconds.
*/
status = dm355evm_msp_read(DM355EVM_MSP_RTC_0);
if (status < 0)
return status;
if (tries && time.bytes[0] == status)
break;
time.bytes[0] = status;
status = dm355evm_msp_read(DM355EVM_MSP_RTC_1);
if (status < 0)
return status;
if (tries && time.bytes[1] == status)
break;
time.bytes[1] = status;
status = dm355evm_msp_read(DM355EVM_MSP_RTC_2);
if (status < 0)
return status;
if (tries && time.bytes[2] == status)
break;
time.bytes[2] = status;
status = dm355evm_msp_read(DM355EVM_MSP_RTC_3);
if (status < 0)
return status;
if (tries && time.bytes[3] == status)
break;
time.bytes[3] = status;
} while (++tries < 5);
dev_dbg(dev, "read timestamp %08x\n", time.value);
rtc_time64_to_tm(le32_to_cpu(time.value), tm);
return 0;
}
static int dm355evm_rtc_set_time(struct device *dev, struct rtc_time *tm)
{
union evm_time time;
unsigned long value;
int status;
value = rtc_tm_to_time64(tm);
time.value = cpu_to_le32(value);
dev_dbg(dev, "write timestamp %08x\n", time.value);
/*
* REVISIT handle non-atomic writes ... maybe just retry until
* byte[1] sticks (no rollover)?
*/
status = dm355evm_msp_write(time.bytes[0], DM355EVM_MSP_RTC_0);
if (status < 0)
return status;
status = dm355evm_msp_write(time.bytes[1], DM355EVM_MSP_RTC_1);
if (status < 0)
return status;
status = dm355evm_msp_write(time.bytes[2], DM355EVM_MSP_RTC_2);
if (status < 0)
return status;
status = dm355evm_msp_write(time.bytes[3], DM355EVM_MSP_RTC_3);
if (status < 0)
return status;
return 0;
}
static const struct rtc_class_ops dm355evm_rtc_ops = {
.read_time = dm355evm_rtc_read_time,
.set_time = dm355evm_rtc_set_time,
};
/*----------------------------------------------------------------------*/
static int dm355evm_rtc_probe(struct platform_device *pdev)
{
struct rtc_device *rtc;
rtc = devm_rtc_allocate_device(&pdev->dev);
if (IS_ERR(rtc))
return PTR_ERR(rtc);
platform_set_drvdata(pdev, rtc);
rtc->ops = &dm355evm_rtc_ops;
rtc->range_max = U32_MAX;
return devm_rtc_register_device(rtc);
}
/*
* I2C is used to talk to the MSP430, but this platform device is
* exposed by an MFD driver that manages I2C communications.
*/
static struct platform_driver rtc_dm355evm_driver = {
.probe = dm355evm_rtc_probe,
.driver = {
.name = "rtc-dm355evm",
},
};
module_platform_driver(rtc_dm355evm_driver);
MODULE_LICENSE("GPL");
/*
* dm355evm_msp.h - support MSP430 microcontroller on DM355EVM board
*/
#ifndef __LINUX_I2C_DM355EVM_MSP
#define __LINUX_I2C_DM355EVM_MSP
/*
* Written against Spectrum's writeup for the A4 firmware revision,
* and tweaked to match source and rev D2 schematics by removing CPLD
* and NOR flash hooks (which were last appropriate in rev B boards).
*
* Note that the firmware supports a flavor of write posting ... to be
* sure a write completes, issue another read or write.
*/
/* utilities to access "registers" emulated by msp430 firmware */
extern int dm355evm_msp_write(u8 value, u8 reg);
extern int dm355evm_msp_read(u8 reg);
/* command/control registers */
#define DM355EVM_MSP_COMMAND 0x00
# define MSP_COMMAND_NULL 0
# define MSP_COMMAND_RESET_COLD 1
# define MSP_COMMAND_RESET_WARM 2
# define MSP_COMMAND_RESET_WARM_I 3
# define MSP_COMMAND_POWEROFF 4
# define MSP_COMMAND_IR_REINIT 5
#define DM355EVM_MSP_STATUS 0x01
# define MSP_STATUS_BAD_OFFSET BIT(0)
# define MSP_STATUS_BAD_COMMAND BIT(1)
# define MSP_STATUS_POWER_ERROR BIT(2)
# define MSP_STATUS_RXBUF_OVERRUN BIT(3)
#define DM355EVM_MSP_RESET 0x02 /* 0 bits == in reset */
# define MSP_RESET_DC5 BIT(0)
# define MSP_RESET_TVP5154 BIT(2)
# define MSP_RESET_IMAGER BIT(3)
# define MSP_RESET_ETHERNET BIT(4)
# define MSP_RESET_SYS BIT(5)
# define MSP_RESET_AIC33 BIT(7)
/* GPIO registers ... bit patterns mostly match the source MSP ports */
#define DM355EVM_MSP_LED 0x03 /* active low (MSP P4) */
#define DM355EVM_MSP_SWITCH1 0x04 /* (MSP P5, masked) */
# define MSP_SWITCH1_SW6_1 BIT(0)
# define MSP_SWITCH1_SW6_2 BIT(1)
# define MSP_SWITCH1_SW6_3 BIT(2)
# define MSP_SWITCH1_SW6_4 BIT(3)
# define MSP_SWITCH1_J1 BIT(4) /* NTSC/PAL */
# define MSP_SWITCH1_MSP_INT BIT(5) /* active low */
#define DM355EVM_MSP_SWITCH2 0x05 /* (MSP P6, masked) */
# define MSP_SWITCH2_SW10 BIT(3)
# define MSP_SWITCH2_SW11 BIT(4)
# define MSP_SWITCH2_SW12 BIT(5)
# define MSP_SWITCH2_SW13 BIT(6)
# define MSP_SWITCH2_SW14 BIT(7)
#define DM355EVM_MSP_SDMMC 0x06 /* (MSP P2, masked) */
# define MSP_SDMMC_0_WP BIT(1)
# define MSP_SDMMC_0_CD BIT(2) /* active low */
# define MSP_SDMMC_1_WP BIT(3)
# define MSP_SDMMC_1_CD BIT(4) /* active low */
#define DM355EVM_MSP_FIRMREV 0x07 /* not a GPIO (out of order) */
#define DM355EVM_MSP_VIDEO_IN 0x08 /* (MSP P3, masked) */
# define MSP_VIDEO_IMAGER BIT(7) /* low == tvp5146 */
/* power supply registers are currently omitted */
/* RTC registers */
#define DM355EVM_MSP_RTC_0 0x12 /* LSB */
#define DM355EVM_MSP_RTC_1 0x13
#define DM355EVM_MSP_RTC_2 0x14
#define DM355EVM_MSP_RTC_3 0x15 /* MSB */
/* input event queue registers; code == ((HIGH << 8) | LOW) */
#define DM355EVM_MSP_INPUT_COUNT 0x16 /* decrement by reading LOW */
#define DM355EVM_MSP_INPUT_HIGH 0x17
#define DM355EVM_MSP_INPUT_LOW 0x18
#endif /* __LINUX_I2C_DM355EVM_MSP */
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment