* [PATCH v6 1/6] [media] rc-main: assign driver type during allocation
From: Andi Shyti @ 2016-12-16 8:50 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Sean Young, Rob Herring, Mark Rutland,
Richard Purdie, Jacek Anaszewski, Heiner Kallweit
Cc: linux-media, devicetree, linux-leds, linux-kernel, Andi Shyti,
Andi Shyti
In-Reply-To: <20161216061218.5906-2-andi.shyti@samsung.com>
The driver type can be assigned immediately when an RC device
requests to the framework to allocate the device.
This is an 'enum rc_driver_type' data type and specifies whether
the device is a raw receiver or scancode receiver. The type will
be given as parameter to the rc_allocate_device device.
Change accordingly all the drivers calling rc_allocate_device()
so that the device type is specified during the rc device
allocation. Whenever the device type is not specified, it will be
set as RC_DRIVER_SCANCODE which was the default '0' value.
Suggested-by: Sean Young <sean@mess.org>
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Reviewed-by: Sean Young <sean@mess.org>
---
Hi,
Sorry for further spamming, but these drivers change so fast and
I'm taking too long to finalize this patch series.
This is the correct patch which fixes the compile error from the
kbuild test robot.
The whole patch series, anyway, is rebased on next-161216 and all
the files compile.
Thanks,
Andi
drivers/hid/hid-picolcd_cir.c | 3 +--
drivers/media/cec/cec-core.c | 3 +--
drivers/media/common/siano/smsir.c | 3 +--
drivers/media/i2c/ir-kbd-i2c.c | 2 +-
drivers/media/pci/bt8xx/bttv-input.c | 2 +-
drivers/media/pci/cx23885/cx23885-input.c | 11 +----------
drivers/media/pci/cx88/cx88-input.c | 3 +--
drivers/media/pci/dm1105/dm1105.c | 3 +--
drivers/media/pci/mantis/mantis_input.c | 2 +-
drivers/media/pci/saa7134/saa7134-input.c | 2 +-
drivers/media/pci/smipcie/smipcie-ir.c | 3 +--
drivers/media/pci/ttpci/budget-ci.c | 2 +-
drivers/media/rc/ati_remote.c | 3 +--
drivers/media/rc/ene_ir.c | 3 +--
drivers/media/rc/fintek-cir.c | 3 +--
drivers/media/rc/gpio-ir-recv.c | 3 +--
drivers/media/rc/igorplugusb.c | 3 +--
drivers/media/rc/iguanair.c | 3 +--
drivers/media/rc/img-ir/img-ir-hw.c | 2 +-
drivers/media/rc/img-ir/img-ir-raw.c | 3 +--
drivers/media/rc/imon.c | 3 +--
drivers/media/rc/ir-hix5hd2.c | 3 +--
drivers/media/rc/ite-cir.c | 3 +--
drivers/media/rc/mceusb.c | 3 +--
drivers/media/rc/meson-ir.c | 3 +--
drivers/media/rc/nuvoton-cir.c | 3 +--
drivers/media/rc/rc-loopback.c | 3 +--
drivers/media/rc/rc-main.c | 9 ++++++---
drivers/media/rc/redrat3.c | 3 +--
drivers/media/rc/serial_ir.c | 3 +--
drivers/media/rc/st_rc.c | 3 +--
drivers/media/rc/streamzap.c | 3 +--
drivers/media/rc/sunxi-cir.c | 3 +--
drivers/media/rc/ttusbir.c | 3 +--
drivers/media/rc/winbond-cir.c | 3 +--
drivers/media/usb/au0828/au0828-input.c | 3 +--
drivers/media/usb/cx231xx/cx231xx-input.c | 2 +-
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 3 +--
drivers/media/usb/dvb-usb/dvb-usb-remote.c | 3 +--
drivers/media/usb/em28xx/em28xx-input.c | 2 +-
drivers/media/usb/tm6000/tm6000-input.c | 3 +--
include/media/rc-core.h | 6 ++++--
42 files changed, 50 insertions(+), 85 deletions(-)
diff --git a/drivers/hid/hid-picolcd_cir.c b/drivers/hid/hid-picolcd_cir.c
index 9628651..38b0ea8 100644
--- a/drivers/hid/hid-picolcd_cir.c
+++ b/drivers/hid/hid-picolcd_cir.c
@@ -108,12 +108,11 @@ int picolcd_init_cir(struct picolcd_data *data, struct hid_report *report)
struct rc_dev *rdev;
int ret = 0;
- rdev = rc_allocate_device();
+ rdev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rdev)
return -ENOMEM;
rdev->priv = data;
- rdev->driver_type = RC_DRIVER_IR_RAW;
rdev->allowed_protocols = RC_BIT_ALL;
rdev->open = picolcd_cir_open;
rdev->close = picolcd_cir_close;
diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index aca3ab8..37217e2 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -239,7 +239,7 @@ struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops,
#if IS_REACHABLE(CONFIG_RC_CORE)
/* Prepare the RC input device */
- adap->rc = rc_allocate_device();
+ adap->rc = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!adap->rc) {
pr_err("cec-%s: failed to allocate memory for rc_dev\n",
name);
@@ -259,7 +259,6 @@ struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops,
adap->rc->input_id.vendor = 0;
adap->rc->input_id.product = 0;
adap->rc->input_id.version = 1;
- adap->rc->driver_type = RC_DRIVER_SCANCODE;
adap->rc->driver_name = CEC_NAME;
adap->rc->allowed_protocols = RC_BIT_CEC;
adap->rc->priv = adap;
diff --git a/drivers/media/common/siano/smsir.c b/drivers/media/common/siano/smsir.c
index 41f2a39..ee30c7b 100644
--- a/drivers/media/common/siano/smsir.c
+++ b/drivers/media/common/siano/smsir.c
@@ -58,7 +58,7 @@ int sms_ir_init(struct smscore_device_t *coredev)
struct rc_dev *dev;
pr_debug("Allocating rc device\n");
- dev = rc_allocate_device();
+ dev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!dev)
return -ENOMEM;
@@ -86,7 +86,6 @@ int sms_ir_init(struct smscore_device_t *coredev)
#endif
dev->priv = coredev;
- dev->driver_type = RC_DRIVER_IR_RAW;
dev->allowed_protocols = RC_BIT_ALL;
dev->map_name = sms_get_board(board_id)->rc_codes;
dev->driver_name = MODULE_NAME;
diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c
index cede397..5ad5167 100644
--- a/drivers/media/i2c/ir-kbd-i2c.c
+++ b/drivers/media/i2c/ir-kbd-i2c.c
@@ -428,7 +428,7 @@ static int ir_probe(struct i2c_client *client, const struct i2c_device_id *id)
* If platform_data doesn't specify rc_dev, initialize it
* internally
*/
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!rc)
return -ENOMEM;
}
diff --git a/drivers/media/pci/bt8xx/bttv-input.c b/drivers/media/pci/bt8xx/bttv-input.c
index 4da720e..76daec7 100644
--- a/drivers/media/pci/bt8xx/bttv-input.c
+++ b/drivers/media/pci/bt8xx/bttv-input.c
@@ -424,7 +424,7 @@ int bttv_input_init(struct bttv *btv)
return -ENODEV;
ir = kzalloc(sizeof(*ir),GFP_KERNEL);
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!ir || !rc)
goto err_out_free;
diff --git a/drivers/media/pci/cx23885/cx23885-input.c b/drivers/media/pci/cx23885/cx23885-input.c
index 1f092fe..c743317 100644
--- a/drivers/media/pci/cx23885/cx23885-input.c
+++ b/drivers/media/pci/cx23885/cx23885-input.c
@@ -267,7 +267,6 @@ int cx23885_input_init(struct cx23885_dev *dev)
struct cx23885_kernel_ir *kernel_ir;
struct rc_dev *rc;
char *rc_map;
- enum rc_driver_type driver_type;
u64 allowed_protos;
int ret;
@@ -285,28 +284,24 @@ int cx23885_input_init(struct cx23885_dev *dev)
case CX23885_BOARD_HAUPPAUGE_HVR1290:
case CX23885_BOARD_HAUPPAUGE_HVR1250:
/* Integrated CX2388[58] IR controller */
- driver_type = RC_DRIVER_IR_RAW;
allowed_protos = RC_BIT_ALL;
/* The grey Hauppauge RC-5 remote */
rc_map = RC_MAP_HAUPPAUGE;
break;
case CX23885_BOARD_TERRATEC_CINERGY_T_PCIE_DUAL:
/* Integrated CX23885 IR controller */
- driver_type = RC_DRIVER_IR_RAW;
allowed_protos = RC_BIT_ALL;
/* The grey Terratec remote with orange buttons */
rc_map = RC_MAP_NEC_TERRATEC_CINERGY_XS;
break;
case CX23885_BOARD_TEVII_S470:
/* Integrated CX23885 IR controller */
- driver_type = RC_DRIVER_IR_RAW;
allowed_protos = RC_BIT_ALL;
/* A guess at the remote */
rc_map = RC_MAP_TEVII_NEC;
break;
case CX23885_BOARD_MYGICA_X8507:
/* Integrated CX23885 IR controller */
- driver_type = RC_DRIVER_IR_RAW;
allowed_protos = RC_BIT_ALL;
/* A guess at the remote */
rc_map = RC_MAP_TOTAL_MEDIA_IN_HAND_02;
@@ -314,7 +309,6 @@ int cx23885_input_init(struct cx23885_dev *dev)
case CX23885_BOARD_TBS_6980:
case CX23885_BOARD_TBS_6981:
/* Integrated CX23885 IR controller */
- driver_type = RC_DRIVER_IR_RAW;
allowed_protos = RC_BIT_ALL;
/* A guess at the remote */
rc_map = RC_MAP_TBS_NEC;
@@ -326,13 +320,11 @@ int cx23885_input_init(struct cx23885_dev *dev)
case CX23885_BOARD_DVBSKY_S952:
case CX23885_BOARD_DVBSKY_T982:
/* Integrated CX23885 IR controller */
- driver_type = RC_DRIVER_IR_RAW;
allowed_protos = RC_BIT_ALL;
rc_map = RC_MAP_DVBSKY;
break;
case CX23885_BOARD_TT_CT2_4500_CI:
/* Integrated CX23885 IR controller */
- driver_type = RC_DRIVER_IR_RAW;
allowed_protos = RC_BIT_ALL;
rc_map = RC_MAP_TT_1500;
break;
@@ -352,7 +344,7 @@ int cx23885_input_init(struct cx23885_dev *dev)
pci_name(dev->pci));
/* input device */
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rc) {
ret = -ENOMEM;
goto err_out_free;
@@ -371,7 +363,6 @@ int cx23885_input_init(struct cx23885_dev *dev)
rc->input_id.product = dev->pci->device;
}
rc->dev.parent = &dev->pci->dev;
- rc->driver_type = driver_type;
rc->allowed_protocols = allowed_protos;
rc->priv = kernel_ir;
rc->open = cx23885_input_ir_open;
diff --git a/drivers/media/pci/cx88/cx88-input.c b/drivers/media/pci/cx88/cx88-input.c
index dcfea35..6e9f366e 100644
--- a/drivers/media/pci/cx88/cx88-input.c
+++ b/drivers/media/pci/cx88/cx88-input.c
@@ -276,7 +276,7 @@ int cx88_ir_init(struct cx88_core *core, struct pci_dev *pci)
*/
ir = kzalloc(sizeof(*ir), GFP_KERNEL);
- dev = rc_allocate_device();
+ dev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!ir || !dev)
goto err_out_free;
@@ -486,7 +486,6 @@ int cx88_ir_init(struct cx88_core *core, struct pci_dev *pci)
dev->scancode_mask = hardware_mask;
if (ir->sampling) {
- dev->driver_type = RC_DRIVER_IR_RAW;
dev->timeout = 10 * 1000 * 1000; /* 10 ms */
} else {
dev->driver_type = RC_DRIVER_SCANCODE;
diff --git a/drivers/media/pci/dm1105/dm1105.c b/drivers/media/pci/dm1105/dm1105.c
index a589aa7..76e07c7 100644
--- a/drivers/media/pci/dm1105/dm1105.c
+++ b/drivers/media/pci/dm1105/dm1105.c
@@ -743,7 +743,7 @@ static int dm1105_ir_init(struct dm1105_dev *dm1105)
struct rc_dev *dev;
int err = -ENOMEM;
- dev = rc_allocate_device();
+ dev = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!dev)
return -ENOMEM;
@@ -752,7 +752,6 @@ static int dm1105_ir_init(struct dm1105_dev *dm1105)
dev->driver_name = MODULE_NAME;
dev->map_name = RC_MAP_DM1105_NEC;
- dev->driver_type = RC_DRIVER_SCANCODE;
dev->input_name = "DVB on-card IR receiver";
dev->input_phys = dm1105->ir.input_phys;
dev->input_id.bustype = BUS_PCI;
diff --git a/drivers/media/pci/mantis/mantis_input.c b/drivers/media/pci/mantis/mantis_input.c
index 7f7f1d4..50d10cb 100644
--- a/drivers/media/pci/mantis/mantis_input.c
+++ b/drivers/media/pci/mantis/mantis_input.c
@@ -39,7 +39,7 @@ int mantis_input_init(struct mantis_pci *mantis)
struct rc_dev *dev;
int err;
- dev = rc_allocate_device();
+ dev = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!dev) {
dprintk(MANTIS_ERROR, 1, "Remote device allocation failed");
err = -ENOMEM;
diff --git a/drivers/media/pci/saa7134/saa7134-input.c b/drivers/media/pci/saa7134/saa7134-input.c
index 823b75e..509caa86 100644
--- a/drivers/media/pci/saa7134/saa7134-input.c
+++ b/drivers/media/pci/saa7134/saa7134-input.c
@@ -846,7 +846,7 @@ int saa7134_input_init1(struct saa7134_dev *dev)
}
ir = kzalloc(sizeof(*ir), GFP_KERNEL);
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!ir || !rc) {
err = -ENOMEM;
goto err_out_free;
diff --git a/drivers/media/pci/smipcie/smipcie-ir.c b/drivers/media/pci/smipcie/smipcie-ir.c
index 826c7c7..d2730c3 100644
--- a/drivers/media/pci/smipcie/smipcie-ir.c
+++ b/drivers/media/pci/smipcie/smipcie-ir.c
@@ -183,7 +183,7 @@ int smi_ir_init(struct smi_dev *dev)
struct rc_dev *rc_dev;
struct smi_rc *ir = &dev->ir;
- rc_dev = rc_allocate_device();
+ rc_dev = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!rc_dev)
return -ENOMEM;
@@ -202,7 +202,6 @@ int smi_ir_init(struct smi_dev *dev)
rc_dev->input_id.product = dev->pci_dev->subsystem_device;
rc_dev->dev.parent = &dev->pci_dev->dev;
- rc_dev->driver_type = RC_DRIVER_SCANCODE;
rc_dev->map_name = dev->info->rc_map;
ir->rc_dev = rc_dev;
diff --git a/drivers/media/pci/ttpci/budget-ci.c b/drivers/media/pci/ttpci/budget-ci.c
index 20ad93b..0c0b733 100644
--- a/drivers/media/pci/ttpci/budget-ci.c
+++ b/drivers/media/pci/ttpci/budget-ci.c
@@ -177,7 +177,7 @@ static int msp430_ir_init(struct budget_ci *budget_ci)
struct rc_dev *dev;
int error;
- dev = rc_allocate_device();
+ dev = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!dev) {
printk(KERN_ERR "budget_ci: IR interface initialisation failed\n");
return -ENOMEM;
diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
index 0884b7d..7d0ee3d 100644
--- a/drivers/media/rc/ati_remote.c
+++ b/drivers/media/rc/ati_remote.c
@@ -764,7 +764,6 @@ static void ati_remote_rc_init(struct ati_remote *ati_remote)
struct rc_dev *rdev = ati_remote->rdev;
rdev->priv = ati_remote;
- rdev->driver_type = RC_DRIVER_SCANCODE;
rdev->allowed_protocols = RC_BIT_OTHER;
rdev->driver_name = "ati_remote";
@@ -851,7 +850,7 @@ static int ati_remote_probe(struct usb_interface *interface,
}
ati_remote = kzalloc(sizeof (struct ati_remote), GFP_KERNEL);
- rc_dev = rc_allocate_device();
+ rc_dev = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!ati_remote || !rc_dev)
goto exit_free_dev_rdev;
diff --git a/drivers/media/rc/ene_ir.c b/drivers/media/rc/ene_ir.c
index bd5512e..3b7275f 100644
--- a/drivers/media/rc/ene_ir.c
+++ b/drivers/media/rc/ene_ir.c
@@ -1012,7 +1012,7 @@ static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *id)
/* allocate memory */
dev = kzalloc(sizeof(struct ene_device), GFP_KERNEL);
- rdev = rc_allocate_device();
+ rdev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!dev || !rdev)
goto exit_free_dev_rdev;
@@ -1058,7 +1058,6 @@ static int ene_probe(struct pnp_dev *pnp_dev, const struct pnp_device_id *id)
if (!dev->hw_learning_and_tx_capable)
learning_mode_force = false;
- rdev->driver_type = RC_DRIVER_IR_RAW;
rdev->allowed_protocols = RC_BIT_ALL;
rdev->priv = dev;
rdev->open = ene_open;
diff --git a/drivers/media/rc/fintek-cir.c b/drivers/media/rc/fintek-cir.c
index ecab69e..df125c2 100644
--- a/drivers/media/rc/fintek-cir.c
+++ b/drivers/media/rc/fintek-cir.c
@@ -492,7 +492,7 @@ static int fintek_probe(struct pnp_dev *pdev, const struct pnp_device_id *dev_id
return ret;
/* input device for IR remote (and tx) */
- rdev = rc_allocate_device();
+ rdev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rdev)
goto exit_free_dev_rdev;
@@ -534,7 +534,6 @@ static int fintek_probe(struct pnp_dev *pdev, const struct pnp_device_id *dev_id
/* Set up the rc device */
rdev->priv = fintek;
- rdev->driver_type = RC_DRIVER_IR_RAW;
rdev->allowed_protocols = RC_BIT_ALL;
rdev->open = fintek_open;
rdev->close = fintek_close;
diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c
index 5b63b1f..d5d2152 100644
--- a/drivers/media/rc/gpio-ir-recv.c
+++ b/drivers/media/rc/gpio-ir-recv.c
@@ -143,14 +143,13 @@ static int gpio_ir_recv_probe(struct platform_device *pdev)
if (!gpio_dev)
return -ENOMEM;
- rcdev = rc_allocate_device();
+ rcdev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rcdev) {
rc = -ENOMEM;
goto err_allocate_device;
}
rcdev->priv = gpio_dev;
- rcdev->driver_type = RC_DRIVER_IR_RAW;
rcdev->input_name = GPIO_IR_DEVICE_NAME;
rcdev->input_phys = GPIO_IR_DEVICE_NAME "/input0";
rcdev->input_id.bustype = BUS_HOST;
diff --git a/drivers/media/rc/igorplugusb.c b/drivers/media/rc/igorplugusb.c
index 5cf983b..d770a62 100644
--- a/drivers/media/rc/igorplugusb.c
+++ b/drivers/media/rc/igorplugusb.c
@@ -190,7 +190,7 @@ static int igorplugusb_probe(struct usb_interface *intf,
usb_make_path(udev, ir->phys, sizeof(ir->phys));
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rc)
goto fail;
@@ -198,7 +198,6 @@ static int igorplugusb_probe(struct usb_interface *intf,
rc->input_phys = ir->phys;
usb_to_input_id(udev, &rc->input_id);
rc->dev.parent = &intf->dev;
- rc->driver_type = RC_DRIVER_IR_RAW;
/*
* This device can only store 36 pulses + spaces, which is not enough
* for the NEC protocol and many others.
diff --git a/drivers/media/rc/iguanair.c b/drivers/media/rc/iguanair.c
index 5f63454..4cd1e6b 100644
--- a/drivers/media/rc/iguanair.c
+++ b/drivers/media/rc/iguanair.c
@@ -431,7 +431,7 @@ static int iguanair_probe(struct usb_interface *intf,
struct usb_host_interface *idesc;
ir = kzalloc(sizeof(*ir), GFP_KERNEL);
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!ir || !rc) {
ret = -ENOMEM;
goto out;
@@ -494,7 +494,6 @@ static int iguanair_probe(struct usb_interface *intf,
rc->input_phys = ir->phys;
usb_to_input_id(ir->udev, &rc->input_id);
rc->dev.parent = &intf->dev;
- rc->driver_type = RC_DRIVER_IR_RAW;
rc->allowed_protocols = RC_BIT_ALL;
rc->priv = ir;
rc->open = iguanair_open;
diff --git a/drivers/media/rc/img-ir/img-ir-hw.c b/drivers/media/rc/img-ir/img-ir-hw.c
index 7bb71bc..c87ae03 100644
--- a/drivers/media/rc/img-ir/img-ir-hw.c
+++ b/drivers/media/rc/img-ir/img-ir-hw.c
@@ -1071,7 +1071,7 @@ int img_ir_probe_hw(struct img_ir_priv *priv)
}
/* Allocate hardware decoder */
- hw->rdev = rdev = rc_allocate_device();
+ hw->rdev = rdev = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!rdev) {
dev_err(priv->dev, "cannot allocate input device\n");
error = -ENOMEM;
diff --git a/drivers/media/rc/img-ir/img-ir-raw.c b/drivers/media/rc/img-ir/img-ir-raw.c
index 33f37ed..8d2f8e2 100644
--- a/drivers/media/rc/img-ir/img-ir-raw.c
+++ b/drivers/media/rc/img-ir/img-ir-raw.c
@@ -110,7 +110,7 @@ int img_ir_probe_raw(struct img_ir_priv *priv)
setup_timer(&raw->timer, img_ir_echo_timer, (unsigned long)priv);
/* Allocate raw decoder */
- raw->rdev = rdev = rc_allocate_device();
+ raw->rdev = rdev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rdev) {
dev_err(priv->dev, "cannot allocate raw input device\n");
return -ENOMEM;
@@ -118,7 +118,6 @@ int img_ir_probe_raw(struct img_ir_priv *priv)
rdev->priv = priv;
rdev->map_name = RC_MAP_EMPTY;
rdev->input_name = "IMG Infrared Decoder Raw";
- rdev->driver_type = RC_DRIVER_IR_RAW;
/* Register raw decoder */
error = rc_register_device(rdev);
diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 0785a24..4234ae6 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -1939,7 +1939,7 @@ static struct rc_dev *imon_init_rdev(struct imon_context *ictx)
const unsigned char fp_packet[] = { 0x40, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x88 };
- rdev = rc_allocate_device();
+ rdev = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!rdev) {
dev_err(ictx->dev, "remote control dev allocation failed\n");
goto out;
@@ -1957,7 +1957,6 @@ static struct rc_dev *imon_init_rdev(struct imon_context *ictx)
rdev->dev.parent = ictx->dev;
rdev->priv = ictx;
- rdev->driver_type = RC_DRIVER_SCANCODE;
rdev->allowed_protocols = RC_BIT_OTHER | RC_BIT_RC6_MCE; /* iMON PAD or MCE */
rdev->change_protocol = imon_ir_change_protocol;
rdev->driver_name = MOD_NAME;
diff --git a/drivers/media/rc/ir-hix5hd2.c b/drivers/media/rc/ir-hix5hd2.c
index d26907e..dc3b959 100644
--- a/drivers/media/rc/ir-hix5hd2.c
+++ b/drivers/media/rc/ir-hix5hd2.c
@@ -229,7 +229,7 @@ static int hix5hd2_ir_probe(struct platform_device *pdev)
return priv->irq;
}
- rdev = rc_allocate_device();
+ rdev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rdev)
return -ENOMEM;
@@ -242,7 +242,6 @@ static int hix5hd2_ir_probe(struct platform_device *pdev)
clk_prepare_enable(priv->clock);
priv->rate = clk_get_rate(priv->clock);
- rdev->driver_type = RC_DRIVER_IR_RAW;
rdev->allowed_protocols = RC_BIT_ALL;
rdev->priv = priv;
rdev->open = hix5hd2_ir_open;
diff --git a/drivers/media/rc/ite-cir.c b/drivers/media/rc/ite-cir.c
index 367b28b..92ed356 100644
--- a/drivers/media/rc/ite-cir.c
+++ b/drivers/media/rc/ite-cir.c
@@ -1470,7 +1470,7 @@ static int ite_probe(struct pnp_dev *pdev, const struct pnp_device_id
return ret;
/* input device for IR remote (and tx) */
- rdev = rc_allocate_device();
+ rdev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rdev)
goto exit_free_dev_rdev;
itdev->rdev = rdev;
@@ -1561,7 +1561,6 @@ static int ite_probe(struct pnp_dev *pdev, const struct pnp_device_id
/* set up ir-core props */
rdev->priv = itdev;
- rdev->driver_type = RC_DRIVER_IR_RAW;
rdev->allowed_protocols = RC_BIT_ALL;
rdev->open = ite_open;
rdev->close = ite_close;
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 9bf6917..ebcc82d 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -1181,7 +1181,7 @@ static struct rc_dev *mceusb_init_rc_dev(struct mceusb_dev *ir)
struct rc_dev *rc;
int ret;
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rc) {
dev_err(dev, "remote dev allocation failed");
goto out;
@@ -1201,7 +1201,6 @@ static struct rc_dev *mceusb_init_rc_dev(struct mceusb_dev *ir)
usb_to_input_id(ir->usbdev, &rc->input_id);
rc->dev.parent = dev;
rc->priv = ir;
- rc->driver_type = RC_DRIVER_IR_RAW;
rc->allowed_protocols = RC_BIT_ALL;
rc->timeout = MS_TO_NS(100);
if (!ir->flags.no_tx) {
diff --git a/drivers/media/rc/meson-ir.c b/drivers/media/rc/meson-ir.c
index 7eb3f4f..8947dc6 100644
--- a/drivers/media/rc/meson-ir.c
+++ b/drivers/media/rc/meson-ir.c
@@ -131,7 +131,7 @@ static int meson_ir_probe(struct platform_device *pdev)
return ir->irq;
}
- ir->rc = rc_allocate_device();
+ ir->rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!ir->rc) {
dev_err(dev, "failed to allocate rc device\n");
return -ENOMEM;
@@ -144,7 +144,6 @@ static int meson_ir_probe(struct platform_device *pdev)
map_name = of_get_property(node, "linux,rc-map-name", NULL);
ir->rc->map_name = map_name ? map_name : RC_MAP_EMPTY;
ir->rc->dev.parent = dev;
- ir->rc->driver_type = RC_DRIVER_IR_RAW;
ir->rc->allowed_protocols = RC_BIT_ALL;
ir->rc->rx_resolution = US_TO_NS(MESON_TRATE);
ir->rc->timeout = MS_TO_NS(200);
diff --git a/drivers/media/rc/nuvoton-cir.c b/drivers/media/rc/nuvoton-cir.c
index 4b78c89..d4cc880 100644
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -998,7 +998,7 @@ static int nvt_probe(struct pnp_dev *pdev, const struct pnp_device_id *dev_id)
return -ENOMEM;
/* input device for IR remote (and tx) */
- nvt->rdev = devm_rc_allocate_device(&pdev->dev);
+ nvt->rdev = devm_rc_allocate_device(&pdev->dev, RC_DRIVER_IR_RAW);
if (!nvt->rdev)
return -ENOMEM;
rdev = nvt->rdev;
@@ -1061,7 +1061,6 @@ static int nvt_probe(struct pnp_dev *pdev, const struct pnp_device_id *dev_id)
/* Set up the rc device */
rdev->priv = nvt;
- rdev->driver_type = RC_DRIVER_IR_RAW;
rdev->allowed_protocols = RC_BIT_ALL;
rdev->open = nvt_open;
rdev->close = nvt_close;
diff --git a/drivers/media/rc/rc-loopback.c b/drivers/media/rc/rc-loopback.c
index 63dace8..36192ac 100644
--- a/drivers/media/rc/rc-loopback.c
+++ b/drivers/media/rc/rc-loopback.c
@@ -181,7 +181,7 @@ static int __init loop_init(void)
struct rc_dev *rc;
int ret;
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rc) {
printk(KERN_ERR DRIVER_NAME ": rc_dev allocation failed\n");
return -ENOMEM;
@@ -194,7 +194,6 @@ static int __init loop_init(void)
rc->driver_name = DRIVER_NAME;
rc->map_name = RC_MAP_EMPTY;
rc->priv = &loopdev;
- rc->driver_type = RC_DRIVER_IR_RAW;
rc->allowed_protocols = RC_BIT_ALL;
rc->timeout = 100 * 1000 * 1000; /* 100 ms */
rc->min_timeout = 1;
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index dedaf38..a6bbceb 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1357,7 +1357,7 @@ static struct device_type rc_dev_type = {
.uevent = rc_dev_uevent,
};
-struct rc_dev *rc_allocate_device(void)
+struct rc_dev *rc_allocate_device(enum rc_driver_type type)
{
struct rc_dev *dev;
@@ -1384,6 +1384,8 @@ struct rc_dev *rc_allocate_device(void)
dev->dev.class = &rc_class;
device_initialize(&dev->dev);
+ dev->driver_type = type;
+
__module_get(THIS_MODULE);
return dev;
}
@@ -1410,7 +1412,8 @@ static void devm_rc_alloc_release(struct device *dev, void *res)
rc_free_device(*(struct rc_dev **)res);
}
-struct rc_dev *devm_rc_allocate_device(struct device *dev)
+struct rc_dev *devm_rc_allocate_device(struct device *dev,
+ enum rc_driver_type type)
{
struct rc_dev **dr, *rc;
@@ -1418,7 +1421,7 @@ struct rc_dev *devm_rc_allocate_device(struct device *dev)
if (!dr)
return NULL;
- rc = rc_allocate_device();
+ rc = rc_allocate_device(type);
if (!rc) {
devres_free(dr);
return NULL;
diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c
index 2784f5d..2b6f828 100644
--- a/drivers/media/rc/redrat3.c
+++ b/drivers/media/rc/redrat3.c
@@ -945,7 +945,7 @@ static struct rc_dev *redrat3_init_rc_dev(struct redrat3_dev *rr3)
int ret;
u16 prod = le16_to_cpu(rr3->udev->descriptor.idProduct);
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rc)
return NULL;
@@ -960,7 +960,6 @@ static struct rc_dev *redrat3_init_rc_dev(struct redrat3_dev *rr3)
usb_to_input_id(rr3->udev, &rc->input_id);
rc->dev.parent = dev;
rc->priv = rr3;
- rc->driver_type = RC_DRIVER_IR_RAW;
rc->allowed_protocols = RC_BIT_ALL;
rc->min_timeout = MS_TO_NS(RR3_RX_MIN_TIMEOUT);
rc->max_timeout = MS_TO_NS(RR3_RX_MAX_TIMEOUT);
diff --git a/drivers/media/rc/serial_ir.c b/drivers/media/rc/serial_ir.c
index 436bd58..640acc6 100644
--- a/drivers/media/rc/serial_ir.c
+++ b/drivers/media/rc/serial_ir.c
@@ -738,7 +738,7 @@ static int __init serial_ir_init_module(void)
if (result)
return result;
- rcdev = devm_rc_allocate_device(&serial_ir.pdev->dev);
+ rcdev = devm_rc_allocate_device(&serial_ir.pdev->dev, RC_DRIVER_IR_RAW);
if (!rcdev) {
result = -ENOMEM;
goto serial_cleanup;
@@ -777,7 +777,6 @@ static int __init serial_ir_init_module(void)
rcdev->open = serial_ir_open;
rcdev->close = serial_ir_close;
rcdev->dev.parent = &serial_ir.pdev->dev;
- rcdev->driver_type = RC_DRIVER_IR_RAW;
rcdev->allowed_protocols = RC_BIT_ALL;
rcdev->driver_name = KBUILD_MODNAME;
rcdev->map_name = RC_MAP_RC6_MCE;
diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
index 1fa0c9d..e6f6735 100644
--- a/drivers/media/rc/st_rc.c
+++ b/drivers/media/rc/st_rc.c
@@ -235,7 +235,7 @@ static int st_rc_probe(struct platform_device *pdev)
if (!rc_dev)
return -ENOMEM;
- rdev = rc_allocate_device();
+ rdev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rdev)
return -ENOMEM;
@@ -290,7 +290,6 @@ static int st_rc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, rc_dev);
st_rc_hardware_init(rc_dev);
- rdev->driver_type = RC_DRIVER_IR_RAW;
rdev->allowed_protocols = RC_BIT_ALL;
/* rx sampling rate is 10Mhz */
rdev->rx_resolution = 100;
diff --git a/drivers/media/rc/streamzap.c b/drivers/media/rc/streamzap.c
index 53f9b0a..f434e45 100644
--- a/drivers/media/rc/streamzap.c
+++ b/drivers/media/rc/streamzap.c
@@ -291,7 +291,7 @@ static struct rc_dev *streamzap_init_rc_dev(struct streamzap_ir *sz)
struct device *dev = sz->dev;
int ret;
- rdev = rc_allocate_device();
+ rdev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rdev) {
dev_err(dev, "remote dev allocation failed\n");
goto out;
@@ -308,7 +308,6 @@ static struct rc_dev *streamzap_init_rc_dev(struct streamzap_ir *sz)
usb_to_input_id(sz->usbdev, &rdev->input_id);
rdev->dev.parent = dev;
rdev->priv = sz;
- rdev->driver_type = RC_DRIVER_IR_RAW;
rdev->allowed_protocols = RC_BIT_ALL;
rdev->driver_name = DRIVER_NAME;
rdev->map_name = RC_MAP_STREAMZAP;
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index eaadc08..5451f3d 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -212,7 +212,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
goto exit_clkdisable_clk;
}
- ir->rc = rc_allocate_device();
+ ir->rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!ir->rc) {
dev_err(dev, "failed to allocate device\n");
ret = -ENOMEM;
@@ -229,7 +229,6 @@ static int sunxi_ir_probe(struct platform_device *pdev)
ir->map_name = of_get_property(dn, "linux,rc-map-name", NULL);
ir->rc->map_name = ir->map_name ?: RC_MAP_EMPTY;
ir->rc->dev.parent = dev;
- ir->rc->driver_type = RC_DRIVER_IR_RAW;
ir->rc->allowed_protocols = RC_BIT_ALL;
ir->rc->rx_resolution = SUNXI_IR_SAMPLE;
ir->rc->timeout = MS_TO_NS(SUNXI_IR_TIMEOUT);
diff --git a/drivers/media/rc/ttusbir.c b/drivers/media/rc/ttusbir.c
index bc214e2..6ff2cef 100644
--- a/drivers/media/rc/ttusbir.c
+++ b/drivers/media/rc/ttusbir.c
@@ -205,7 +205,7 @@ static int ttusbir_probe(struct usb_interface *intf,
int altsetting = -1;
tt = kzalloc(sizeof(*tt), GFP_KERNEL);
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!tt || !rc) {
ret = -ENOMEM;
goto out;
@@ -317,7 +317,6 @@ static int ttusbir_probe(struct usb_interface *intf,
rc->input_phys = tt->phys;
usb_to_input_id(tt->udev, &rc->input_id);
rc->dev.parent = &intf->dev;
- rc->driver_type = RC_DRIVER_IR_RAW;
rc->allowed_protocols = RC_BIT_ALL;
rc->priv = tt;
rc->driver_name = DRIVER_NAME;
diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
index 78491ed..bc95d22 100644
--- a/drivers/media/rc/winbond-cir.c
+++ b/drivers/media/rc/winbond-cir.c
@@ -1059,13 +1059,12 @@ wbcir_probe(struct pnp_dev *device, const struct pnp_device_id *dev_id)
if (err)
goto exit_free_data;
- data->dev = rc_allocate_device();
+ data->dev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!data->dev) {
err = -ENOMEM;
goto exit_unregister_led;
}
- data->dev->driver_type = RC_DRIVER_IR_RAW;
data->dev->driver_name = DRVNAME;
data->dev->input_name = WBCIR_NAME;
data->dev->input_phys = "wbcir/cir0";
diff --git a/drivers/media/usb/au0828/au0828-input.c b/drivers/media/usb/au0828/au0828-input.c
index 1e66e78..9ec919c 100644
--- a/drivers/media/usb/au0828/au0828-input.c
+++ b/drivers/media/usb/au0828/au0828-input.c
@@ -298,7 +298,7 @@ int au0828_rc_register(struct au0828_dev *dev)
return -ENODEV;
ir = kzalloc(sizeof(*ir), GFP_KERNEL);
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!ir || !rc)
goto error;
@@ -343,7 +343,6 @@ int au0828_rc_register(struct au0828_dev *dev)
rc->input_id.product = le16_to_cpu(dev->usbdev->descriptor.idProduct);
rc->dev.parent = &dev->usbdev->dev;
rc->driver_name = "au0828-input";
- rc->driver_type = RC_DRIVER_IR_RAW;
rc->allowed_protocols = RC_BIT_NEC | RC_BIT_NECX | RC_BIT_NEC32 |
RC_BIT_RC5;
diff --git a/drivers/media/usb/cx231xx/cx231xx-input.c b/drivers/media/usb/cx231xx/cx231xx-input.c
index 15d8d1b..6e80f3c 100644
--- a/drivers/media/usb/cx231xx/cx231xx-input.c
+++ b/drivers/media/usb/cx231xx/cx231xx-input.c
@@ -72,7 +72,7 @@ int cx231xx_ir_init(struct cx231xx *dev)
memset(&info, 0, sizeof(struct i2c_board_info));
memset(&dev->init_data, 0, sizeof(dev->init_data));
- dev->init_data.rc_dev = rc_allocate_device();
+ dev->init_data.rc_dev = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!dev->init_data.rc_dev)
return -ENOMEM;
diff --git a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
index a8e6624..298c91a 100644
--- a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
+++ b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
@@ -147,7 +147,7 @@ static int dvb_usbv2_remote_init(struct dvb_usb_device *d)
if (!d->rc.map_name)
return 0;
- dev = rc_allocate_device();
+ dev = rc_allocate_device(d->rc.driver_type);
if (!dev) {
ret = -ENOMEM;
goto err;
@@ -162,7 +162,6 @@ static int dvb_usbv2_remote_init(struct dvb_usb_device *d)
/* TODO: likely RC-core should took const char * */
dev->driver_name = (char *) d->props->driver_name;
dev->map_name = d->rc.map_name;
- dev->driver_type = d->rc.driver_type;
dev->allowed_protocols = d->rc.allowed_protos;
dev->change_protocol = d->rc.change_protocol;
dev->priv = d;
diff --git a/drivers/media/usb/dvb-usb/dvb-usb-remote.c b/drivers/media/usb/dvb-usb/dvb-usb-remote.c
index c259f9e..059ded5 100644
--- a/drivers/media/usb/dvb-usb/dvb-usb-remote.c
+++ b/drivers/media/usb/dvb-usb/dvb-usb-remote.c
@@ -265,7 +265,7 @@ static int rc_core_dvb_usb_remote_init(struct dvb_usb_device *d)
int err, rc_interval;
struct rc_dev *dev;
- dev = rc_allocate_device();
+ dev = rc_allocate_device(d->props.rc.core.driver_type);
if (!dev)
return -ENOMEM;
@@ -273,7 +273,6 @@ static int rc_core_dvb_usb_remote_init(struct dvb_usb_device *d)
dev->map_name = d->props.rc.core.rc_codes;
dev->change_protocol = d->props.rc.core.change_protocol;
dev->allowed_protocols = d->props.rc.core.allowed_protos;
- dev->driver_type = d->props.rc.core.driver_type;
usb_to_input_id(d->udev, &dev->input_id);
dev->input_name = "IR-receiver inside an USB DVB receiver";
dev->input_phys = d->rc_phys;
diff --git a/drivers/media/usb/em28xx/em28xx-input.c b/drivers/media/usb/em28xx/em28xx-input.c
index 782ce09..aa24bba 100644
--- a/drivers/media/usb/em28xx/em28xx-input.c
+++ b/drivers/media/usb/em28xx/em28xx-input.c
@@ -719,7 +719,7 @@ static int em28xx_ir_init(struct em28xx *dev)
ir = kzalloc(sizeof(*ir), GFP_KERNEL);
if (!ir)
return -ENOMEM;
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!rc)
goto error;
diff --git a/drivers/media/usb/tm6000/tm6000-input.c b/drivers/media/usb/tm6000/tm6000-input.c
index 26b2ebb..377a69b 100644
--- a/drivers/media/usb/tm6000/tm6000-input.c
+++ b/drivers/media/usb/tm6000/tm6000-input.c
@@ -429,7 +429,7 @@ int tm6000_ir_init(struct tm6000_core *dev)
return 0;
ir = kzalloc(sizeof(*ir), GFP_ATOMIC);
- rc = rc_allocate_device();
+ rc = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!ir || !rc)
goto out;
@@ -456,7 +456,6 @@ int tm6000_ir_init(struct tm6000_core *dev)
ir->polling = 50;
INIT_DELAYED_WORK(&ir->work, tm6000_ir_handle_key);
}
- rc->driver_type = RC_DRIVER_SCANCODE;
snprintf(ir->name, sizeof(ir->name), "tm5600/60x0 IR (%s)",
dev->name);
diff --git a/include/media/rc-core.h b/include/media/rc-core.h
index 55281b9..ba92c86 100644
--- a/include/media/rc-core.h
+++ b/include/media/rc-core.h
@@ -200,17 +200,19 @@ struct rc_dev {
/**
* rc_allocate_device - Allocates a RC device
*
+ * @rc_driver_type: specifies the type of the RC output to be allocated
* returns a pointer to struct rc_dev.
*/
-struct rc_dev *rc_allocate_device(void);
+struct rc_dev *rc_allocate_device(enum rc_driver_type);
/**
* devm_rc_allocate_device - Managed RC device allocation
*
* @dev: pointer to struct device
+ * @rc_driver_type: specifies the type of the RC output to be allocated
* returns a pointer to struct rc_dev.
*/
-struct rc_dev *devm_rc_allocate_device(struct device *dev);
+struct rc_dev *devm_rc_allocate_device(struct device *dev, enum rc_driver_type);
/**
* rc_free_device - Frees a RC device
--
2.10.2
^ permalink raw reply related
* Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Markus Reichl @ 2016-12-16 9:08 UTC (permalink / raw)
To: Krzysztof Kozlowski, Doug Anderson
Cc: Bartlomiej Zolnierkiewicz, Javier Martinez Canillas, Arjun K V,
Kukjin Kim, Rob Herring, Mark Rutland, Russell King,
Andreas Faerber, Thomas Abraham, Ben Gamari, linux-samsung-soc,
linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Alim
In-Reply-To: <20161216073720.GA3489@kozik-lap>
Am 16.12.2016 um 08:37 schrieb Krzysztof Kozlowski:
> On Thu, Dec 15, 2016 at 04:52:58PM -0800, Doug Anderson wrote:
>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>> (unfortunately Inderpal's email is no longer working). ]
>>>
>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>> IOW if the problem exists it is already present in the mainline
>>> kernel.
>>
>> Interesting. In the ChromeOS tree I see significantly higher voltages
>> needed... Note that one might naively look at
>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#178>.
>>
>> 1362500, /* L0 2100 */
>> 1312500, /* L1 2000 */
>>
>> ..but, amazingly enough those voltages aren't used at all. Surprise!
>>
>> I believe that the above numbers are actually not used and the ASV
>> numbers are used instead. See
>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/include/mach/asv-exynos542x.h#452>
>>
>> { 2100000,
>> 1350000, 1350000, 1350000, 1350000, 1350000,
>> 1337500, 1325000, 1312500, 1300000, 1287500,
>> 1275000, 1262500, 1250000, 1237500 },
>>
>> I believe that interpretation there is: some bins of the CPU can run
>> at 2.1 GHz just fine at 1.25 V but others need up to 1.35V.
>
> That is definitely the case. One could just look at vendors ASV table
> (for 1.9 GHz):
> { 1900000, 1300000, 1287500, 1262500, 1237500, 1225000, 1212500,
> 1200000, 1187500, 1175000, 1162500, 1150000,
> 1137500, 1125000, 1112500, 1112500},
>
> The theoretical difference is up to 1.875V! From my experiments I saw
> BIN1 chips which should be the same... but some working on 1.2V, some on
> 1.225V (@1.9 GHz). I didn't see any requiring higher voltages but that
> does not mean that there aren't such...
>
>> ...so if you're running at 2.1 GHz at 1.25V then perhaps you're just
>> running on a CPU from a nice bin?
I've been running the proposed frequency/voltage combinations without any
stability problems on my XU4, XU3 and even XU3-lite ( I did not delete the
nodes on XU3-lite dts) with make -j8 kernel and ssvb-cpuburn.
The chips are poorly cooled, especially the XU4 and quickly step down.
>
> Would be nice to see a dump of PKG_ID and AUX_INFO chipid registers
> along with name of tested board. Because the "Tested on XU3" is not
> sufficient.
If you point me to how to read these values out, I will publish them.
>
> Best regards,
> Krzysztof
--
Markus Reichl
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: power: supply: bq24735: reverse the polarity of ac-detect
From: Jon Hunter @ 2016-12-16 9:09 UTC (permalink / raw)
To: Peter Rosin, linux-kernel
Cc: Sebastian Reichel, Rob Herring, Mark Rutland, linux-pm,
devicetree, linux-tegra
In-Reply-To: <1481804479-8711-1-git-send-email-peda@axentia.se>
On 15/12/16 12:21, Peter Rosin wrote:
> The ACOK pin on the bq24735 is active-high, of course meaning that when
> AC is OK the pin is high. However, all Tegra dts files have incorrectly
> specified active-high even though the signal is inverted on the Tegra
> boards. This has worked since the Linux driver has also inverted the
> meaning of the GPIO. Fix this situation by simply specifying in the
> bindings what everybody else agrees on; that the ti,ac-detect-gpios is
> active on AC adapter absence.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
>
> Hi!
>
> This patch is the result of this discussion:
> http://marc.info/?t=148152531800002
>
> I don't like how it changes the one thing that is seems correct, but
> what to do?
>
> Cheers,
> Peter
>
> Documentation/devicetree/bindings/power/supply/ti,bq24735.txt | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt b/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt
> index 3bf55757ceec..43d56c49455b 100644
> --- a/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt
> +++ b/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt
> @@ -8,8 +8,9 @@ Optional properties :
> - interrupts : Specify the interrupt to be used to trigger when the AC
> adapter is either plugged in or removed.
> - ti,ac-detect-gpios : This GPIO is optionally used to read the AC adapter
> - presence. This is a Host GPIO that is configured as an input and
> - connected to the bq24735.
> + status. This is a Host GPIO that is configured as an input and
> + connected to the bq24735, typically the ACOK pin (note: the GPIO should
> + be active on AC adapter absence).
> - ti,charge-current : Used to control and set the charging current. This value
> must be between 128mA and 8.128A with a 64mA step resolution. The POR value
> is 0x0000h. This number is in mA (e.g. 8192), see spec for more information
I don't think you need the 'typically' above, and I may have added ...
"the GPIO must be active on AC adapter absence despite the ACOK being
active-high on AC presence to be compatible with legacy boards".
... but otherwise ...
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH v4] dt-bindings: power: supply: bq24735: reverse the polarity of ac-detect
From: Peter Rosin @ 2016-12-16 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Sebastian Reichel, Rob Herring, Mark Rutland,
Jon Hunter, Stephen Warren, linux-pm, devicetree
The ACOK pin on the bq24735 is active-high, of course meaning that when
AC is OK the pin is high. However, all Tegra dts files have incorrectly
specified active-high even though the signal is inverted on the Tegra
boards. This has worked since the Linux driver has also inverted the
meaning of the GPIO. Fix this situation by simply specifying in the
bindings what everybody else agrees on; that the ti,ac-detect-gpios is
active on AC adapter absence.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
Documentation/devicetree/bindings/power/supply/ti,bq24735.txt | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
Hi!
v3 -> v4 changes:
- improve the bindings text in the spirit of remarks from Jon Hunter
(There were no v1 nor v2, I made a mistake and started from v3 this time.)
This patch is the result of this discussion:
http://marc.info/?t=148152531800002
I don't like how it changes the one thing that is seems correct, but
what to do?
Cheers,
peda
diff --git a/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt b/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt
index 3bf55757ceec..c95e16e2dc56 100644
--- a/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt
+++ b/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt
@@ -8,8 +8,10 @@ Optional properties :
- interrupts : Specify the interrupt to be used to trigger when the AC
adapter is either plugged in or removed.
- ti,ac-detect-gpios : This GPIO is optionally used to read the AC adapter
- presence. This is a Host GPIO that is configured as an input and
- connected to the bq24735.
+ status. This is a Host GPIO that is configured as an input and connected
+ to the ACOK pin on the bq24735. Note: for backwards compatibility reasons,
+ the GPIO must be active on AC adapter absence despite ACOK being active
+ (high) on AC adapter presence.
- ti,charge-current : Used to control and set the charging current. This value
must be between 128mA and 8.128A with a 64mA step resolution. The POR value
is 0x0000h. This number is in mA (e.g. 8192), see spec for more information
--
2.1.4
^ permalink raw reply related
* [PATCH v4] i2c: designware: Cleaning and comment style fixes.
From: Luis Oliveira @ 2016-12-16 9:54 UTC (permalink / raw)
To: wsa, robh+dt, mark.rutland, jarkko.nikula, andriy.shevchenko,
mika.westerberg, linux-i2c, devicetree, linux-kernel
Cc: Luis.Oliveira, Ramiro.Oliveira, Joao.Pinto, CARLOS.PALMINHA
The purpose of this commit is to fix some comments and styling issues in the
existing code due to the need of reuse this code. What is being made here is:
- Sorted the headers files
- Corrected some comments style
- Reverse tree in the variables declaration
- Add/remove empty lines and tabs where needed
- Fix of a misspelled word
The value of this, besides the rules of coding style, is because I
will use this code after and it will make my future patch a lot bigger and
complicated to review. The work here won't bring any additional work to
backported fixes because is just style and reordering.
Signed-off-by: Luis Oliveira <lolivei@synopsys.com>
---
Changes V3->V4: (Peter Rosin)
- Remove the unnecessary TAB as suggested
drivers/i2c/busses/i2c-designware-core.c | 36 ++++++++++++++---------------
drivers/i2c/busses/i2c-designware-platdrv.c | 27 +++++++++++-----------
2 files changed, 32 insertions(+), 31 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-core.c b/drivers/i2c/busses/i2c-designware-core.c
index 6d81c56184d3..9d724a6a7ec8 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -21,17 +21,17 @@
* ----------------------------------------------------------------------------
*
*/
+#include <linux/delay.h>
#include <linux/export.h>
#include <linux/errno.h>
#include <linux/err.h>
#include <linux/i2c.h>
#include <linux/interrupt.h>
#include <linux/io.h>
-#include <linux/pm_runtime.h>
-#include <linux/delay.h>
#include <linux/module.h>
-#include "i2c-designware-core.h"
+#include <linux/pm_runtime.h>
+#include "i2c-designware-core.h"
/*
* Registers offset
*/
@@ -98,7 +98,7 @@
#define DW_IC_ERR_TX_ABRT 0x1
-#define DW_IC_TAR_10BITADDR_MASTER BIT(12)
+#define DW_IC_TAR_10BITADDR_MASTER BIT(12)
#define DW_IC_COMP_PARAM_1_SPEED_MODE_HIGH (BIT(2) | BIT(3))
#define DW_IC_COMP_PARAM_1_SPEED_MODE_MASK GENMASK(3, 2)
@@ -113,10 +113,10 @@
#define TIMEOUT 20 /* ms */
/*
- * hardware abort codes from the DW_IC_TX_ABRT_SOURCE register
+ * Hardware abort codes from the DW_IC_TX_ABRT_SOURCE register
*
- * only expected abort codes are listed here
- * refer to the datasheet for the full list
+ * Only expected abort codes are listed here,
+ * refer to the datasheet for the full list.
*/
#define ABRT_7B_ADDR_NOACK 0
#define ABRT_10ADDR1_NOACK 1
@@ -338,14 +338,14 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
reg = dw_readl(dev, DW_IC_COMP_TYPE);
if (reg == ___constant_swab32(DW_IC_COMP_TYPE_VALUE)) {
- /* Configure register endianess access */
+ /* Configure register endianness access */
dev->accessor_flags |= ACCESS_SWAP;
} else if (reg == (DW_IC_COMP_TYPE_VALUE & 0x0000ffff)) {
/* Configure register access mode 16bit */
dev->accessor_flags |= ACCESS_16BIT;
} else if (reg != DW_IC_COMP_TYPE_VALUE) {
- dev_err(dev->dev, "Unknown Synopsys component type: "
- "0x%08x\n", reg);
+ dev_err(dev->dev,
+ "Unknown Synopsys component type: 0x%08x\n", reg);
i2c_dw_release_lock(dev);
return -ENODEV;
}
@@ -355,7 +355,7 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
/* Disable the adapter */
__i2c_dw_enable_and_wait(dev, false);
- /* set standard and fast speed deviders for high/low periods */
+ /* Set standard and fast speed deviders for high/low periods */
sda_falling_time = dev->sda_falling_time ?: 300; /* ns */
scl_falling_time = dev->scl_falling_time ?: 300; /* ns */
@@ -444,7 +444,7 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
dw_writel(dev, dev->tx_fifo_depth / 2, DW_IC_TX_TL);
dw_writel(dev, 0, DW_IC_RX_TL);
- /* configure the i2c master */
+ /* Configure the I2C master */
dw_writel(dev, dev->master_cfg , DW_IC_CON);
i2c_dw_release_lock(dev);
@@ -480,7 +480,7 @@ static void i2c_dw_xfer_init(struct dw_i2c_dev *dev)
/* Disable the adapter */
__i2c_dw_enable_and_wait(dev, false);
- /* if the slave address is ten bit address, enable 10BITADDR */
+ /* If the slave address is ten bit address, enable 10BITADDR */
if (dev->dynamic_tar_update_enabled) {
/*
* If I2C_DYNAMIC_TAR_UPDATE is set, the 10-bit addressing
@@ -505,7 +505,7 @@ static void i2c_dw_xfer_init(struct dw_i2c_dev *dev)
*/
dw_writel(dev, msgs[dev->msg_write_idx].addr | ic_tar, DW_IC_TAR);
- /* enforce disabled interrupts (due to HW issues) */
+ /* Enforce disabled interrupts (due to HW issues) */
i2c_dw_disable_int(dev);
/* Enable the adapter */
@@ -539,7 +539,7 @@ i2c_dw_xfer_msg(struct dw_i2c_dev *dev)
u32 flags = msgs[dev->msg_write_idx].flags;
/*
- * if target address has changed, we need to
+ * If target address has changed, we need to
* reprogram the target address in the i2c
* adapter when we are done with this transfer
*/
@@ -601,7 +601,7 @@ i2c_dw_xfer_msg(struct dw_i2c_dev *dev)
if (msgs[dev->msg_write_idx].flags & I2C_M_RD) {
- /* avoid rx buffer overrun */
+ /* Avoid rx buffer overrun */
if (dev->rx_outstanding >= dev->rx_fifo_depth)
break;
@@ -905,7 +905,7 @@ static irqreturn_t i2c_dw_isr(int this_irq, void *dev_id)
/*
* Anytime TX_ABRT is set, the contents of the tx/rx
- * buffers are flushed. Make sure to skip them.
+ * buffers are flushed. Make sure to skip them.
*/
dw_writel(dev, 0, DW_IC_INTR_MASK);
goto tx_aborted;
@@ -927,7 +927,7 @@ static irqreturn_t i2c_dw_isr(int this_irq, void *dev_id)
if ((stat & (DW_IC_INTR_TX_ABRT | DW_IC_INTR_STOP_DET)) || dev->msg_err)
complete(&dev->cmd_complete);
else if (unlikely(dev->accessor_flags & ACCESS_INTR_MASK)) {
- /* workaround to trigger pending interrupt */
+ /* Workaround to trigger pending interrupt */
stat = dw_readl(dev, DW_IC_INTR_MASK);
i2c_dw_disable_int(dev);
dw_writel(dev, stat, DW_IC_INTR_MASK);
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 08153ea4d848..886e39753fc2 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -21,26 +21,27 @@
* ----------------------------------------------------------------------------
*
*/
-#include <linux/kernel.h>
-#include <linux/module.h>
+#include <linux/acpi.h>
+#include <linux/clk-provider.h>
+#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/dmi.h>
-#include <linux/i2c.h>
-#include <linux/clk.h>
-#include <linux/clk-provider.h>
-#include <linux/errno.h>
-#include <linux/sched.h>
#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/i2c.h>
#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
#include <linux/of.h>
+#include <linux/platform_data/i2c-designware.h>
#include <linux/platform_device.h>
#include <linux/pm.h>
#include <linux/pm_runtime.h>
#include <linux/property.h>
-#include <linux/io.h>
+#include <linux/sched.h>
#include <linux/slab.h>
-#include <linux/acpi.h>
-#include <linux/platform_data/i2c-designware.h>
+
#include "i2c-designware-core.h"
static u32 i2c_dw_get_clk_rate_khz(struct dw_i2c_dev *dev)
@@ -153,11 +154,11 @@ static int i2c_dw_plat_prepare_clk(struct dw_i2c_dev *i_dev, bool prepare)
static int dw_i2c_plat_probe(struct platform_device *pdev)
{
struct dw_i2c_platform_data *pdata = dev_get_platdata(&pdev->dev);
- struct dw_i2c_dev *dev;
struct i2c_adapter *adap;
+ struct dw_i2c_dev *dev;
+ u32 acpi_speed, ht = 0;
struct resource *mem;
int irq, r;
- u32 acpi_speed, ht = 0;
irq = platform_get_irq(pdev, 0);
if (irq < 0)
@@ -354,7 +355,7 @@ static const struct dev_pm_ops dw_i2c_dev_pm_ops = {
#define DW_I2C_DEV_PMOPS NULL
#endif
-/* work with hotplug and coldplug */
+/* Work with hotplug and coldplug */
MODULE_ALIAS("platform:i2c_designware");
static struct platform_driver dw_i2c_driver = {
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v4] i2c: designware: Cleaning and comment style fixes.
From: Jarkko Nikula @ 2016-12-16 10:48 UTC (permalink / raw)
To: Luis Oliveira, wsa-z923LK4zBo2bacvFa/9K2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA,
mika.westerberg-VuQAYsv1563Yd54FQh9/CA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w,
Joao.Pinto-HKixBCOQz3hWk0Htik3J/w,
CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <928f25ad1fb39ec458758070d100852f7e47f1bb.1481881774.git.lolivei-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On 12/16/2016 11:54 AM, Luis Oliveira wrote:
> The purpose of this commit is to fix some comments and styling issues in the
> existing code due to the need of reuse this code. What is being made here is:
>
./scripts/checkpatch.pl complains about this. Following in ~/.vimrc will
help if vim is your editor for git commit:
autocmd Filetype gitcommit set textwidth=72
Although not that big issue.
Acked-by: Jarkko Nikula <jarkko.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4] dt-bindings: power: supply: bq24735: reverse the polarity of ac-detect
From: Jon Hunter @ 2016-12-16 10:55 UTC (permalink / raw)
To: Peter Rosin, linux-kernel
Cc: Sebastian Reichel, Rob Herring, Mark Rutland, Stephen Warren,
linux-pm, devicetree
In-Reply-To: <1481881440-13464-1-git-send-email-peda@axentia.se>
On 16/12/16 09:44, Peter Rosin wrote:
> The ACOK pin on the bq24735 is active-high, of course meaning that when
> AC is OK the pin is high. However, all Tegra dts files have incorrectly
> specified active-high even though the signal is inverted on the Tegra
> boards. This has worked since the Linux driver has also inverted the
> meaning of the GPIO. Fix this situation by simply specifying in the
> bindings what everybody else agrees on; that the ti,ac-detect-gpios is
> active on AC adapter absence.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> Documentation/devicetree/bindings/power/supply/ti,bq24735.txt | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> Hi!
>
> v3 -> v4 changes:
> - improve the bindings text in the spirit of remarks from Jon Hunter
>
> (There were no v1 nor v2, I made a mistake and started from v3 this time.)
>
> This patch is the result of this discussion:
> http://marc.info/?t=148152531800002
>
> I don't like how it changes the one thing that is seems correct, but
> what to do?
>
> Cheers,
> peda
>
> diff --git a/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt b/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt
> index 3bf55757ceec..c95e16e2dc56 100644
> --- a/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt
> +++ b/Documentation/devicetree/bindings/power/supply/ti,bq24735.txt
> @@ -8,8 +8,10 @@ Optional properties :
> - interrupts : Specify the interrupt to be used to trigger when the AC
> adapter is either plugged in or removed.
> - ti,ac-detect-gpios : This GPIO is optionally used to read the AC adapter
> - presence. This is a Host GPIO that is configured as an input and
> - connected to the bq24735.
> + status. This is a Host GPIO that is configured as an input and connected
> + to the ACOK pin on the bq24735. Note: for backwards compatibility reasons,
> + the GPIO must be active on AC adapter absence despite ACOK being active
> + (high) on AC adapter presence.
> - ti,charge-current : Used to control and set the charging current. This value
> must be between 128mA and 8.128A with a 64mA step resolution. The POR value
> is 0x0000h. This number is in mA (e.g. 8192), see spec for more information
Thanks.
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v7 1/2] mtd: nand: add tango NFC dt bindings doc
From: Marc Gonzalez @ 2016-12-16 10:56 UTC (permalink / raw)
To: Arnd Bergmann, Boris Brezillon
Cc: Mark Rutland, DT, Mason, Richard Weinberger, Rob Herring,
linux-mtd, Sebastian Frias
In-Reply-To: <1978954.SRtJpfOGp1@wuerfel>
On 07/11/2016 10:18, Arnd Bergmann wrote:
> On Tuesday, October 25, 2016 3:15:50 PM CET Marc Gonzalez wrote:
>> Add the tango NAND Flash Controller dt bindings documentation.
>>
>> Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
>> ---
>> Documentation/devicetree/bindings/mtd/tango-nand.txt | 38 ++++++++++++++++++++++++++++++
>> 1 file changed, 38 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/tango-nand.txt b/Documentation/devicetree/bindings/mtd/tango-nand.txt
>> new file mode 100644
>> index 000000000000..3cbf95d6595a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mtd/tango-nand.txt
>> @@ -0,0 +1,38 @@
>> +Sigma Designs Tango4 NAND Flash Controller (NFC)
>> +
>> +Required properties:
>> +
>> +- compatible: "sigma,smp8758-nand"
>> +- reg: address/size of nfc_reg, nfc_mem, and pbus_reg
>> +- dmas: reference to the DMA channel used by the controller
>> +- dma-names: "nfc_sbox"
>
> Drop the "nfc_" prefix here, it seems redundant.
I took a closer look at Documentation/devicetree/bindings and
arch/arm/boot/dts and it seems the overwhelming nomenclature
is "rx", "tx" (with variants around these two).
Should I just use "rxtx" for my driver?
>> +- clocks: reference to the system clock
>> +- #address-cells: <1>
>> +- #size-cells: <0>
>> +
>> +Children nodes represent the available NAND chips.
>> +See Documentation/devicetree/bindings/mtd/nand.txt for generic bindings.
>> +
>> +Example:
>> +
>> + nand: nand@2c000 {
>> + compatible = "sigma,smp8758-nand";
>> + reg = <0x2c000 0x30 0x2d000 0x800 0x20000 0x1000>;
>
> It would be nicer to write this as
>
> reg = <0x2c000 0x30>, <0x2d000 0x800>, <0x20000 0x1000>;
>
> which is identical in binary format.
This is indeed a marked improvement. Boris, if I fix these two nits,
can I submit a single patch, or do you want them split?
Regards.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v5 2/2] mmc: sdhci-cadence: add Cadence SD4HC support
From: Ulf Hansson @ 2016-12-16 11:07 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Rob Herring, linux-mmc, Adrian Hunter, Douglas Anderson,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Al Cooper,
Linux Kernel Mailing List, Stefan Wahren, Andrei Pistirica,
Wolfram Sang, Mark Rutland, Simon Horman
In-Reply-To: <CAK7LNASaKpGyE_qpQGyqxeVRSkqwj6Rm4WKNq2Zs4Woj4MY01A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[...]
>>
>> I think a better approach is to use the new sdhci-caps* bindings to
>> mask those caps that can't be trusted. And then use the generic mmc
>> bindings for speed modes instead.
>>
>> That should be a safer approach, right!?
>
> Right.
>
> But, if I know the caps register bits 63-32 are all zero,
> I need not explicitly specify sdhci-caps-mask, right?
Maybe not. I don't have a strong opinion here, so l am fine with
whatever you choose.
Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] mmc: sdhci-cadence: add Socionext UniPhier specific compatible string
From: Ulf Hansson @ 2016-12-16 11:09 UTC (permalink / raw)
To: Masahiro Yamada, Rob Herring
Cc: linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Adrian Hunter,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Mark Rutland
In-Reply-To: <1481681446-29832-1-git-send-email-yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
On 14 December 2016 at 03:10, Masahiro Yamada
<yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org> wrote:
> Add a Socionext SoC specific compatible (suggested by Rob Herring).
>
> No SoC specific data are associated with the compatible strings for
> now, but other SoC vendors may use this IP and want to differentiate
> IP variants in the future.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
This looks good to me. I intend to apply this as fix, although
deferring to first get an ack from Rob - to make sure we get it right
this time. :-)
Kind regards
Uffe
> ---
>
> Changes in v2:
> - Add "uniphier" to the compatible to make it more SoC-specific
>
> Documentation/devicetree/bindings/mmc/sdhci-cadence.txt | 6 ++++--
> drivers/mmc/host/sdhci-cadence.c | 1 +
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
> index 750374f..c0f37cb 100644
> --- a/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
> +++ b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
> @@ -1,7 +1,9 @@
> * Cadence SD/SDIO/eMMC Host Controller
>
> Required properties:
> -- compatible: should be "cdns,sd4hc".
> +- compatible: should be one of the following:
> + "cdns,sd4hc" - default of the IP
> + "socionext,uniphier-sd4hc" - for Socionext UniPhier SoCs
> - reg: offset and length of the register set for the device.
> - interrupts: a single interrupt specifier.
> - clocks: phandle to the input clock.
> @@ -19,7 +21,7 @@ if supported. See mmc.txt for details.
>
> Example:
> emmc: sdhci@5a000000 {
> - compatible = "cdns,sd4hc";
> + compatible = "socionext,uniphier-sd4hc", "cdns,sd4hc";
> reg = <0x5a000000 0x400>;
> interrupts = <0 78 4>;
> clocks = <&clk 4>;
> diff --git a/drivers/mmc/host/sdhci-cadence.c b/drivers/mmc/host/sdhci-cadence.c
> index 1501cfd..4b0ecb9 100644
> --- a/drivers/mmc/host/sdhci-cadence.c
> +++ b/drivers/mmc/host/sdhci-cadence.c
> @@ -262,6 +262,7 @@ static int sdhci_cdns_probe(struct platform_device *pdev)
> }
>
> static const struct of_device_id sdhci_cdns_match[] = {
> + { .compatible = "socionext,uniphier-sd4hc" },
> { .compatible = "cdns,sd4hc" },
> { /* sentinel */ }
> };
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Docs: dt: Be explicit and consistent in reference to IOMMU specifiers
From: Mark Rutland @ 2016-12-16 11:33 UTC (permalink / raw)
To: Stuart Yoder
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, will.deacon-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <1481847373-2602-1-git-send-email-stuart.yoder-3arQi8VN3Tc@public.gmane.org>
Hi Stuart,
On Thu, Dec 15, 2016 at 06:16:13PM -0600, Stuart Yoder wrote:
> The generic IOMMU binding says that the meaning of an 'IOMMU specifier'
> is defined by the binding of a specific SMMU. The ARM SMMU binding
> never explicitly uses the term 'specifier' at all. Update implicit
> references to use the explicit term.
>
> In the iommu-map binding change references to iommu-specifier to
> "IOMMU specifier" so we are 100% consistent everywhere with terminology
> and capitalization.
Elsewhere, we always use lower case "xxx-specifier" or "xxx specifier",
e.g. Documentation/devicetree/bindings/gpio/gpio.txt defines
"gpio-specifier", ePAPR defines "interrupt specifier".
Given we're morstly consistent on "iommu-specifier" today, could we
please jsut update the ARM SMMU binding to match that? If we're going to
fix the dash mismatch, that's a more general, cross-binding thing.
Thanks,
Mark.
> Signed-off-by: Stuart Yoder <stuart.yoder-3arQi8VN3Tc@public.gmane.org>
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu.txt | 10 +++++-----
> Documentation/devicetree/bindings/pci/pci-iommu.txt | 6 +++---
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index e862d148..6cdf32d 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -36,15 +36,15 @@ conditions.
> combined interrupt, it must be listed multiple times.
>
> - #iommu-cells : See Documentation/devicetree/bindings/iommu/iommu.txt
> - for details. With a value of 1, each "iommus" entry
> + for details. With a value of 1, each IOMMU specifier
> represents a distinct stream ID emitted by that device
> into the relevant SMMU.
>
> SMMUs with stream matching support and complex masters
> - may use a value of 2, where the second cell represents
> - an SMR mask to combine with the ID in the first cell.
> - Care must be taken to ensure the set of matched IDs
> - does not result in conflicts.
> + may use a value of 2, where the second cell of the
> + IOMMU specifier represents an SMR mask to combine with
> + the ID in the first cell. Care must be taken to ensure
> + the set of matched IDs does not result in conflicts.
>
> ** System MMU optional properties:
>
> diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.txt b/Documentation/devicetree/bindings/pci/pci-iommu.txt
> index 56c8296..0def586 100644
> --- a/Documentation/devicetree/bindings/pci/pci-iommu.txt
> +++ b/Documentation/devicetree/bindings/pci/pci-iommu.txt
> @@ -32,17 +32,17 @@ PCI root complex
> Optional properties
> -------------------
>
> -- iommu-map: Maps a Requester ID to an IOMMU and associated iommu-specifier
> +- iommu-map: Maps a Requester ID to an IOMMU and associated IOMMU specifier
> data.
>
> The property is an arbitrary number of tuples of
> (rid-base,iommu,iommu-base,length).
>
> Any RID r in the interval [rid-base, rid-base + length) is associated with
> - the listed IOMMU, with the iommu-specifier (r - rid-base + iommu-base).
> + the listed IOMMU, with the IOMMU specifier (r - rid-base + iommu-base).
>
> - iommu-map-mask: A mask to be applied to each Requester ID prior to being
> - mapped to an iommu-specifier per the iommu-map property.
> + mapped to an IOMMU specifier per the iommu-map property.
>
>
> Example (1)
> --
> 1.9.0
>
^ permalink raw reply
* Re: RFC: extend iommu-map binding to support #iommu-cells > 1
From: Robin Murphy @ 2016-12-16 11:34 UTC (permalink / raw)
To: Stuart Yoder, Mark Rutland,
will.deacon-5wv7dgnIgG8@public.gmane.org
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
In-Reply-To: <VI1PR0401MB2638DE2D30F8423F6F8C7A6E8D9C0-9IDQY6o3qQjcXZ0H4ZLnAo3W/0Ik+aLCnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
On 16/12/16 02:36, Stuart Yoder wrote:
> For context, please see the thread:
> https://www.spinics.net/lists/arm-kernel/msg539066.html
>
> The existing iommu-map binding did not account for the situation where
> #iommu-cells == 2, as permitted in the ARM SMMU binding. The 2nd cell
> of the IOMMU specifier being the SMR mask. The existing binding defines
> the mapping as:
> Any RID r in the interval [rid-base, rid-base + length) is associated with
> the listed IOMMU, with the iommu-specifier (r - rid-base + iommu-base).
>
> ...and that does not work if iommu-base is 2 cells, the second being the
> SMR mask.
>
> While this can be worked around by always having length=1, it seems we
> can get this cleaned up by updating the binding definition for iommu-map.
>
> See patch below. Thoughts?
I really don't think defining a generic binding to have a magic
non-standard meaning for one specific use-case is the right way to go.
Give me a moment to spin the patch I reckon you actually want...
Robin.
>
> Thanks,
> Stuart
>
> -------------------------------------------------------------------------
>
> diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.txt b/Documentation/devicetree/bindings/pci/pci-iommu.txt
> index 56c8296..e81b461 100644
> --- a/Documentation/devicetree/bindings/pci/pci-iommu.txt
> +++ b/Documentation/devicetree/bindings/pci/pci-iommu.txt
> @@ -38,8 +38,20 @@ Optional properties
> The property is an arbitrary number of tuples of
> (rid-base,iommu,iommu-base,length).
>
> - Any RID r in the interval [rid-base, rid-base + length) is associated with
> - the listed IOMMU, with the iommu-specifier (r - rid-base + iommu-base).
> + If the associated IOMMU has an #iommu-cells value of 1, any RID r in the
> + interval [rid-base, rid-base + length) is associated with the listed IOMMU,
> + with the iommu-specifier (r - rid-base + iommu-base).
> +
> + ARM SMMU Note:
> + The ARM SMMU binding permits an #iommu-cells value of 2 and in this
> + case defines an IOMMU specifier to be: (stream-id,smr-mask)
> +
> + In an iommu-map this means the iommu-base consists of 2 cells:
> + (rid-base,iommu,[stream-id,smr-mask],length).
> +
> + In this case the RID to IOMMU specifier mapping is defined to be:
> + any RID r in the interval [rid-base, rid-base + length) is associated
> + with the listed IOMMU, with the iommu-specifier (r - rid-base + stream-id).
>
> - iommu-map-mask: A mask to be applied to each Requester ID prior to being
> mapped to an iommu-specifier per the iommu-map property.
>
>
>
> _______________________________________________
> iommu mailing list
> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>
^ permalink raw reply
* Re: RFC: extend iommu-map binding to support #iommu-cells > 1
From: Mark Rutland @ 2016-12-16 11:39 UTC (permalink / raw)
To: Stuart Yoder
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
In-Reply-To: <VI1PR0401MB2638DE2D30F8423F6F8C7A6E8D9C0-9IDQY6o3qQjcXZ0H4ZLnAo3W/0Ik+aLCnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
On Fri, Dec 16, 2016 at 02:36:57AM +0000, Stuart Yoder wrote:
> For context, please see the thread:
> https://www.spinics.net/lists/arm-kernel/msg539066.html
>
> The existing iommu-map binding did not account for the situation where
> #iommu-cells == 2, as permitted in the ARM SMMU binding. The 2nd cell
> of the IOMMU specifier being the SMR mask. The existing binding defines
> the mapping as:
> Any RID r in the interval [rid-base, rid-base + length) is associated with
> the listed IOMMU, with the iommu-specifier (r - rid-base + iommu-base).
>
> ...and that does not work if iommu-base is 2 cells, the second being the
> SMR mask.
>
> While this can be worked around by always having length=1, it seems we
> can get this cleaned up by updating the binding definition for iommu-map.
To reiterate, I'm very much not keen on the pci-iommu binding having
knowledge of the decomposition of iommu-specifiers from other bindings.
As mentioned previously, there's an intended interpretation [1] that we
need to fix up the pci-iommu binding with. With that, I don't think it's
even necessary to bodge iommu-cells = <1> AFAICT.
I'm sorry that the patch I suggested never materialized; let me figure
out the wording now...
Thanks,
Mark.
[1] https://www.spinics.net/lists/arm-kernel/msg539357.html
>
> See patch below. Thoughts?
>
> Thanks,
> Stuart
>
> -------------------------------------------------------------------------
>
> diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.txt b/Documentation/devicetree/bindings/pci/pci-iommu.txt
> index 56c8296..e81b461 100644
> --- a/Documentation/devicetree/bindings/pci/pci-iommu.txt
> +++ b/Documentation/devicetree/bindings/pci/pci-iommu.txt
> @@ -38,8 +38,20 @@ Optional properties
> The property is an arbitrary number of tuples of
> (rid-base,iommu,iommu-base,length).
>
> - Any RID r in the interval [rid-base, rid-base + length) is associated with
> - the listed IOMMU, with the iommu-specifier (r - rid-base + iommu-base).
> + If the associated IOMMU has an #iommu-cells value of 1, any RID r in the
> + interval [rid-base, rid-base + length) is associated with the listed IOMMU,
> + with the iommu-specifier (r - rid-base + iommu-base).
> +
> + ARM SMMU Note:
> + The ARM SMMU binding permits an #iommu-cells value of 2 and in this
> + case defines an IOMMU specifier to be: (stream-id,smr-mask)
> +
> + In an iommu-map this means the iommu-base consists of 2 cells:
> + (rid-base,iommu,[stream-id,smr-mask],length).
> +
> + In this case the RID to IOMMU specifier mapping is defined to be:
> + any RID r in the interval [rid-base, rid-base + length) is associated
> + with the listed IOMMU, with the iommu-specifier (r - rid-base + stream-id).
>
> - iommu-map-mask: A mask to be applied to each Requester ID prior to being
> mapped to an iommu-specifier per the iommu-map property.
>
>
>
^ permalink raw reply
* Re: [PATCH v5 3/6] [media] rc-core: add support for IR raw transmitters
From: kbuild test robot @ 2016-12-16 11:41 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, Mauro Carvalho Chehab, Sean Young,
Rob Herring, Mark Rutland, Richard Purdie, Jacek Anaszewski,
Heiner Kallweit, linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andi Shyti, Andi Shyti
In-Reply-To: <20161216061218.5906-4-andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4574 bytes --]
Hi Andi,
[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on next-20161216]
[cannot apply to v4.9]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Andi-Shyti/Add-support-for-IR-transmitters/20161216-144204
base: git://linuxtv.org/media_tree.git master
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
make[3]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule.
include/linux/init.h:1: warning: no structured comments found
include/linux/workqueue.h:392: warning: No description found for parameter '...'
include/linux/workqueue.h:392: warning: Excess function parameter 'args' description in 'alloc_workqueue'
include/linux/workqueue.h:413: warning: No description found for parameter '...'
include/linux/workqueue.h:413: warning: Excess function parameter 'args' description in 'alloc_ordered_workqueue'
include/linux/kthread.h:26: warning: No description found for parameter '...'
kernel/sys.c:1: warning: no structured comments found
drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
include/linux/fence-array.h:61: warning: No description found for parameter 'fence'
include/sound/core.h:324: warning: No description found for parameter '...'
include/sound/core.h:335: warning: No description found for parameter '...'
include/sound/core.h:388: warning: No description found for parameter '...'
drivers/media/dvb-core/dvb_frontend.h:677: warning: No description found for parameter 'refcount'
include/media/media-entity.h:1054: warning: No description found for parameter '...'
>> include/media/rc-core.h:39: warning: bad line: driver requires pulse/space data sequence.
include/net/mac80211.h:3207: ERROR: Unexpected indentation.
include/net/mac80211.h:3210: WARNING: Block quote ends without a blank line; unexpected unindent.
include/net/mac80211.h:3212: ERROR: Unexpected indentation.
include/net/mac80211.h:3213: WARNING: Block quote ends without a blank line; unexpected unindent.
include/net/mac80211.h:1772: ERROR: Unexpected indentation.
include/net/mac80211.h:1776: WARNING: Block quote ends without a blank line; unexpected unindent.
kernel/sched/fair.c:7259: WARNING: Inline emphasis start-string without end-string.
kernel/time/timer.c:1240: ERROR: Unexpected indentation.
kernel/time/timer.c:1242: ERROR: Unexpected indentation.
kernel/time/timer.c:1243: WARNING: Block quote ends without a blank line; unexpected unindent.
include/linux/wait.h:121: WARNING: Block quote ends without a blank line; unexpected unindent.
include/linux/wait.h:124: ERROR: Unexpected indentation.
include/linux/wait.h:126: WARNING: Block quote ends without a blank line; unexpected unindent.
kernel/time/hrtimer.c:1021: WARNING: Block quote ends without a blank line; unexpected unindent.
kernel/signal.c:317: WARNING: Inline literal start-string without end-string.
drivers/base/firmware_class.c:1348: WARNING: Bullet list ends without a blank line; unexpected unindent.
drivers/message/fusion/mptbase.c:5054: WARNING: Definition list ends without a blank line; unexpected unindent.
drivers/tty/serial/serial_core.c:1893: WARNING: Definition list ends without a blank line; unexpected unindent.
include/linux/spi/spi.h:369: ERROR: Unexpected indentation.
WARNING: dvipng command 'dvipng' cannot be run (needed for math display), check the imgmath_dvipng setting
vim +39 include/media/rc-core.h
23 #include <media/rc-map.h>
24
25 extern int rc_core_debug;
26 #define IR_dprintk(level, fmt, ...) \
27 do { \
28 if (rc_core_debug >= level) \
29 printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__); \
30 } while (0)
31
32 /**
33 * enum rc_driver_type - type of the RC output
34 *
35 * @RC_DRIVER_SCANCODE: Driver or hardware generates a scancode
36 * @RC_DRIVER_IR_RAW: Driver or hardware generates pulse/space sequences.
37 * It needs a Infra-Red pulse/space decoder
38 * @RC_DRIVER_IR_RAW_TX: Device transmitter only,
> 39 driver requires pulse/space data sequence.
40 */
41 enum rc_driver_type {
42 RC_DRIVER_SCANCODE = 0,
43 RC_DRIVER_IR_RAW,
44 RC_DRIVER_IR_RAW_TX,
45 };
46
47 /**
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 6425 bytes --]
^ permalink raw reply
* Re: [PATCH v5 2/6] [media] rc-main: split setup and unregister functions
From: Sean Young @ 2016-12-16 12:10 UTC (permalink / raw)
To: Andi Shyti
Cc: Mauro Carvalho Chehab, Rob Herring, Mark Rutland, Richard Purdie,
Jacek Anaszewski, Heiner Kallweit, linux-media, devicetree,
linux-leds, linux-kernel, Andi Shyti
In-Reply-To: <20161216061218.5906-3-andi.shyti@samsung.com>
Hi Andi,
Sorry to add to your woes, but there are some checkpatch warnings and
errors. Please can you correct these. One is below.
Thanks
Sean
On Fri, Dec 16, 2016 at 03:12:14PM +0900, Andi Shyti wrote:
> Move the input device allocation, map and protocol handling to
> different functions.
>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> Reviewed-by: Sean Young <sean@mess.org>
> ---
> drivers/media/rc/rc-main.c | 143 +++++++++++++++++++++++++--------------------
> 1 file changed, 81 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
> index a6bbceb..7cc700d 100644
> --- a/drivers/media/rc/rc-main.c
> +++ b/drivers/media/rc/rc-main.c
> @@ -1436,16 +1436,12 @@ struct rc_dev *devm_rc_allocate_device(struct device *dev,
> }
> EXPORT_SYMBOL_GPL(devm_rc_allocate_device);
>
> -int rc_register_device(struct rc_dev *dev)
> +static int rc_setup_rx_device(struct rc_dev *dev)
> {
> - static bool raw_init = false; /* raw decoders loaded? */
> - struct rc_map *rc_map;
> - const char *path;
> - int attr = 0;
> - int minor;
> int rc;
> + struct rc_map *rc_map;
>
> - if (!dev || !dev->map_name)
> + if (!dev->map_name)
> return -EINVAL;
>
> rc_map = rc_map_get(dev->map_name);
> @@ -1454,6 +1450,19 @@ int rc_register_device(struct rc_dev *dev)
> if (!rc_map || !rc_map->scan || rc_map->size == 0)
> return -EINVAL;
>
> + rc = ir_setkeytable(dev, rc_map);
> + if (rc)
> + return rc;
> +
> + if (dev->change_protocol) {
> + u64 rc_type = (1ll << rc_map->rc_type);
> +
> + rc = dev->change_protocol(dev, &rc_type);
> + if (rc < 0)
> + goto out_table;
> + dev->enabled_protocols = rc_type;
> + }
> +
> set_bit(EV_KEY, dev->input_dev->evbit);
> set_bit(EV_REP, dev->input_dev->evbit);
> set_bit(EV_MSC, dev->input_dev->evbit);
> @@ -1463,6 +1472,61 @@ int rc_register_device(struct rc_dev *dev)
> if (dev->close)
> dev->input_dev->close = ir_close;
>
> + /*
> + * Default delay of 250ms is too short for some protocols, especially
> + * since the timeout is currently set to 250ms. Increase it to 500ms,
> + * to avoid wrong repetition of the keycodes. Note that this must be
> + * set after the call to input_register_device().
> + */
> + dev->input_dev->rep[REP_DELAY] = 500;
> +
> + /*
> + * As a repeat event on protocols like RC-5 and NEC take as long as
> + * 110/114ms, using 33ms as a repeat period is not the right thing
> + * to do.
> + */
> + dev->input_dev->rep[REP_PERIOD] = 125;
> +
> + dev->input_dev->dev.parent = &dev->dev;
> + memcpy(&dev->input_dev->id, &dev->input_id, sizeof(dev->input_id));
> + dev->input_dev->phys = dev->input_phys;
> + dev->input_dev->name = dev->input_name;
> +
> + /* rc_open will be called here */
> + rc = input_register_device(dev->input_dev);
> + if (rc)
> + goto out_table;
> +
> + return 0;
> +
> +out_table:
> + ir_free_table(&dev->rc_map);
> +
> + return rc;
> +}
> +
> +static void rc_free_rx_device(struct rc_dev *dev)
> +{
> + if (!dev)
> + return;
> +
> + ir_free_table(&dev->rc_map);
> +
> + input_unregister_device(dev->input_dev);
> + dev->input_dev = NULL;
> +}
> +
> +int rc_register_device(struct rc_dev *dev)
> +{
> + static bool raw_init = false; /* raw decoders loaded? */
ERROR: do not initialise statics to false
#110: FILE: drivers/media/rc/rc-main.c:1741:
+ static bool raw_init = false; /* raw decoders loaded? */
> + const char *path;
> + int attr = 0;
> + int minor;
> + int rc;
> +
> + if (!dev)
> + return -EINVAL;
> +
> minor = ida_simple_get(&rc_ida, 0, RC_DEV_MAX, GFP_KERNEL);
> if (minor < 0)
> return minor;
> @@ -1486,39 +1550,15 @@ int rc_register_device(struct rc_dev *dev)
> if (rc)
> goto out_unlock;
>
> - rc = ir_setkeytable(dev, rc_map);
> - if (rc)
> - goto out_dev;
> -
> - dev->input_dev->dev.parent = &dev->dev;
> - memcpy(&dev->input_dev->id, &dev->input_id, sizeof(dev->input_id));
> - dev->input_dev->phys = dev->input_phys;
> - dev->input_dev->name = dev->input_name;
> -
> - rc = input_register_device(dev->input_dev);
> - if (rc)
> - goto out_table;
> -
> - /*
> - * Default delay of 250ms is too short for some protocols, especially
> - * since the timeout is currently set to 250ms. Increase it to 500ms,
> - * to avoid wrong repetition of the keycodes. Note that this must be
> - * set after the call to input_register_device().
> - */
> - dev->input_dev->rep[REP_DELAY] = 500;
> -
> - /*
> - * As a repeat event on protocols like RC-5 and NEC take as long as
> - * 110/114ms, using 33ms as a repeat period is not the right thing
> - * to do.
> - */
> - dev->input_dev->rep[REP_PERIOD] = 125;
> -
> path = kobject_get_path(&dev->dev.kobj, GFP_KERNEL);
> dev_info(&dev->dev, "%s as %s\n",
> dev->input_name ?: "Unspecified device", path ?: "N/A");
> kfree(path);
>
> + rc = rc_setup_rx_device(dev);
> + if (rc)
> + goto out_dev;
> +
> if (dev->driver_type == RC_DRIVER_IR_RAW) {
> if (!raw_init) {
> request_module_nowait("ir-lirc-codec");
> @@ -1526,36 +1566,20 @@ int rc_register_device(struct rc_dev *dev)
> }
> rc = ir_raw_event_register(dev);
> if (rc < 0)
> - goto out_input;
> - }
> -
> - if (dev->change_protocol) {
> - u64 rc_type = (1ll << rc_map->rc_type);
> - rc = dev->change_protocol(dev, &rc_type);
> - if (rc < 0)
> - goto out_raw;
> - dev->enabled_protocols = rc_type;
> + goto out_rx;
> }
>
> /* Allow the RC sysfs nodes to be accessible */
> atomic_set(&dev->initialized, 1);
>
> - IR_dprintk(1, "Registered rc%u (driver: %s, remote: %s, mode %s)\n",
> + IR_dprintk(1, "Registered rc%u (driver: %s)\n",
> dev->minor,
> - dev->driver_name ? dev->driver_name : "unknown",
> - rc_map->name ? rc_map->name : "unknown",
> - dev->driver_type == RC_DRIVER_IR_RAW ? "raw" : "cooked");
> + dev->driver_name ? dev->driver_name : "unknown");
>
> return 0;
>
> -out_raw:
> - if (dev->driver_type == RC_DRIVER_IR_RAW)
> - ir_raw_event_unregister(dev);
> -out_input:
> - input_unregister_device(dev->input_dev);
> - dev->input_dev = NULL;
> -out_table:
> - ir_free_table(&dev->rc_map);
> +out_rx:
> + rc_free_rx_device(dev);
> out_dev:
> device_del(&dev->dev);
> out_unlock:
> @@ -1601,12 +1625,7 @@ void rc_unregister_device(struct rc_dev *dev)
> if (dev->driver_type == RC_DRIVER_IR_RAW)
> ir_raw_event_unregister(dev);
>
> - /* Freeing the table should also call the stop callback */
> - ir_free_table(&dev->rc_map);
> - IR_dprintk(1, "Freed keycode table\n");
> -
> - input_unregister_device(dev->input_dev);
> - dev->input_dev = NULL;
> + rc_free_rx_device(dev);
>
> device_del(&dev->dev);
>
> --
> 2.10.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: sun8i-q8-common: enable bluetooth on SDIO Wi-Fi
From: Maxime Ripard @ 2016-12-16 12:47 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Hans de Goede, Chen-Yu Tsai, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20161213233658.atGuNCNY@smtp1h.mail.yandex.net>
[-- Attachment #1.1: Type: text/plain, Size: 2945 bytes --]
On Fri, Dec 09, 2016 at 07:49:00PM +0800, Icenowy Zheng wrote:
>
> 2016年12月9日 下午4:07于 Maxime Ripard <maxime.ripard@free-electrons.com>写道：
> >
> > On Tue, Dec 06, 2016 at 04:08:38PM +0800, Icenowy Zheng wrote:
> > > Some SDIO Wi-Fi chips (such as RTL8703AS) have a UART bluetooth, which
> > > has a dedicated enable pin (PL8 in the reference design).
> > >
> > > Enable the pin in the same way as the WLAN enable pins.
> > >
> > > Tested on an A33 Q8 tablet with RTL8703AS.
> > >
> > > Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> > > ---
> > >
> > > This patch should be coupled with the uart1 node patch I send before:
> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/471997.html
> > >
> > > For RTL8703AS, the rtl8723bs bluetooth code is used, which can be retrieve from:
> > > https://github.com/lwfinger/rtl8723bs_bt
> > >
> > > arch/arm/boot/dts/sun8i-q8-common.dtsi | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/boot/dts/sun8i-q8-common.dtsi b/arch/arm/boot/dts/sun8i-q8-common.dtsi
> > > index c676940..4aeb5bb 100644
> > > --- a/arch/arm/boot/dts/sun8i-q8-common.dtsi
> > > +++ b/arch/arm/boot/dts/sun8i-q8-common.dtsi
> > > @@ -88,7 +88,7 @@
> > >
> > > &r_pio {
> > > wifi_pwrseq_pin_q8: wifi_pwrseq_pin@0 {
> > > - pins = "PL6", "PL7", "PL11";
> > > + pins = "PL6", "PL7", "PL8", "PL11";
> > > function = "gpio_in";
> > > bias-pull-up;
> > > };
> >
> > There's several things wrong here. The first one is that you rely
> > solely on the pinctrl state to maintain a reset line. This is very
> > fragile (especially since the GPIO pinctrl state are likely to go away
> > at some point), but it also means that if your driver wants to recover
> > from that situation at some point, it won't work.
> >
> > The other one is that the bluetooth and wifi chips are two devices in
> > linux, and you assign that pin to the wrong device (wifi).
> >
> > rfkill-gpio is made just for that, so please use it.
>
> The GPIO is not for the radio, but for the full Bluetooth part.
I know.
> If it's set to 0, then the bluetooth part will reset, and the
> hciattach will fail.
Both rfkill-gpio and rfkill-regulator will shutdown when called
(either by poking the reset pin or shutting down the regulator), so
that definitely seems like an expected behavior to put the device in
reset.
> The BSP uses this as a rfkill, and the result is that the bluetooth
> on/off switch do not work properly.
Then rfkill needs fixing, but working around it by hoping that the
core will probe an entirely different device, and enforcing a default
that the rest of the kernel might or might not change is both fragile
and wrong.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC PATCH] iommu/arm-smmu: Add global SMR masking property
From: Robin Murphy @ 2016-12-16 13:19 UTC (permalink / raw)
To: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: will.deacon-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
stuart.yoder-3arQi8VN3Tc
The current SMR masking support using a 2-cell iommu-specifier is
primarily intended to handle individual masters with large and/or
complex Stream ID assignments; it quickly gets a bit clunky in other SMR
use-cases where we just want to consistently mask out the same part of
every Stream ID (e.g. for MMU-500 configurations where the appended TBU
number gets in the way unnecessarily). Let's add a new property to allow
a single global mask value to better fit the latter situation.
CC: Stuart Yoder <stuart.yoder-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
---
Compile-tested only...
Documentation/devicetree/bindings/iommu/arm,smmu.txt | 8 ++++++++
drivers/iommu/arm-smmu.c | 4 +++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
index e862d1485205..98f5cbe5fdb4 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -60,6 +60,14 @@ conditions.
aliases of secure registers have to be used during
SMMU configuration.
+- stream-match-mask : Specifies a fixed SMR mask value to combine with
+ the Stream ID value from every iommu-specifier. This
+ may be used instead of an "#iommu-cells" value of 2
+ when there is no need for per-master SMR masks, but
+ it is still desired to mask some portion of every
+ Stream ID (e.g. for certain MMU-500 configurations
+ given globally unique external IDs).
+
** Deprecated properties:
- mmu-masters (deprecated in favour of the generic "iommus" binding) :
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 8f7281444551..f1abcb7dde36 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1534,13 +1534,15 @@ static int arm_smmu_domain_set_attr(struct iommu_domain *domain,
static int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
{
- u32 fwid = 0;
+ u32 mask, fwid = 0;
if (args->args_count > 0)
fwid |= (u16)args->args[0];
if (args->args_count > 1)
fwid |= (u16)args->args[1] << SMR_MASK_SHIFT;
+ else if (!of_property_read_u32(args->np, "stream-match-mask", &mask))
+ fwid |= (u16)mask << SMR_MASK_SHIFT;
return iommu_fwspec_add_ids(dev, &fwid, 1);
}
--
2.10.2.dirty
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v7 1/2] mtd: nand: add tango NFC dt bindings doc
From: Marc Gonzalez @ 2016-12-16 13:26 UTC (permalink / raw)
To: Arnd Bergmann, Boris Brezillon
Cc: Mark Rutland, DT, Mans Rullgard, Mason, Richard Weinberger,
Mark Brown, Rob Herring, linux-mtd, Sebastian Frias
In-Reply-To: <d3cbfda6-23bf-4ad1-b1ce-c179b765272f@sigmadesigns.com>
On 16/12/2016 11:56, Marc Gonzalez wrote:
> On 07/11/2016 10:18, Arnd Bergmann wrote:
>> On Tuesday, October 25, 2016 3:15:50 PM CET Marc Gonzalez wrote:
>>> Add the tango NAND Flash Controller dt bindings documentation.
>>>
>>> Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
>>> ---
>>> Documentation/devicetree/bindings/mtd/tango-nand.txt | 38 ++++++++++++++++++++++++++++++
>>> 1 file changed, 38 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mtd/tango-nand.txt b/Documentation/devicetree/bindings/mtd/tango-nand.txt
>>> new file mode 100644
>>> index 000000000000..3cbf95d6595a
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/mtd/tango-nand.txt
>>> @@ -0,0 +1,38 @@
>>> +Sigma Designs Tango4 NAND Flash Controller (NFC)
>>> +
>>> +Required properties:
>>> +
>>> +- compatible: "sigma,smp8758-nand"
>>> +- reg: address/size of nfc_reg, nfc_mem, and pbus_reg
>>> +- dmas: reference to the DMA channel used by the controller
>>> +- dma-names: "nfc_sbox"
>>
>> Drop the "nfc_" prefix here, it seems redundant.
>
> I took a closer look at Documentation/devicetree/bindings and
> arch/arm/boot/dts and it seems the overwhelming nomenclature
> is "rx", "tx" (with variants around these two).
>
> Should I just use "rxtx" for my driver?
On IRC, Arnd wrote:
"The string for dma-names is not important, it just needs to be documented
in the binding. If you have hardware specifications, use the name that is
next to the wire for the dma-request line. "dma-names" is only required so
you can connect a single dmarq to multiple dma engines (most chips only
connect each rq to one dmaengine though)."
In my system, peripheral devices are connected to DMA channels via
a multiplexer called the "host switch box". The documentation calls
the ports FOO_SBOX and SBOX_FOO.
For MLC NAND Flash controller 0, the ports are mlc_flash0_sbox
and sbox_mlc_flash0.
Additionally, the DMA driver handles both directions, so the DT only
defines a single duplex channel.
I originally used "nfc_sbox" (nfc = NAND Flash controller) to stick to
the HW naming, but I am willing to change it to "rxtx" if that's what
Boris prefers, (or just "sbox", but Mans pointed out that this was too
specific, and future HW might do away with the switch box).
I'm open to comments.
Regards.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v7 1/2] mtd: nand: add tango NFC dt bindings doc
From: Mark Rutland @ 2016-12-16 13:33 UTC (permalink / raw)
To: Marc Gonzalez
Cc: Arnd Bergmann, Boris Brezillon, linux-mtd, Richard Weinberger, DT,
Rob Herring, Mason, Sebastian Frias, Mans Rullgard, Mark Brown
In-Reply-To: <ee9efd0a-59f5-8c21-0cad-40ca30e3a3e7-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org>
On Fri, Dec 16, 2016 at 02:26:33PM +0100, Marc Gonzalez wrote:
> On 16/12/2016 11:56, Marc Gonzalez wrote:
> > Should I just use "rxtx" for my driver?
>
> On IRC, Arnd wrote:
>
> "The string for dma-names is not important, it just needs to be documented
> in the binding. If you have hardware specifications, use the name that is
> next to the wire for the dma-request line. "dma-names" is only required so
> you can connect a single dmarq to multiple dma engines (most chips only
> connect each rq to one dmaengine though)."
>
> In my system, peripheral devices are connected to DMA channels via
> a multiplexer called the "host switch box". The documentation calls
> the ports FOO_SBOX and SBOX_FOO.
>
> For MLC NAND Flash controller 0, the ports are mlc_flash0_sbox
> and sbox_mlc_flash0.
>
> Additionally, the DMA driver handles both directions, so the DT only
> defines a single duplex channel.
>
> I originally used "nfc_sbox" (nfc = NAND Flash controller) to stick to
> the HW naming, but I am willing to change it to "rxtx" if that's what
> Boris prefers, (or just "sbox", but Mans pointed out that this was too
> specific, and future HW might do away with the switch box).
"rxtx" is the best option, if you need a name at all.
The name is relative to the device instance, so "nfc_" is unnecessary;
we know the node is an NFC controller. The sbox is part of the SoC
wiring rather than being part of the NFC controller, so the "sbox" part
also shouldn't be part of the name.
Likewise for the NAND flash controller. There, the "0" instance number
also shouldn't have been there -- the name is relative to the instance,
and two instances should use the same names. Too late now, I guess. :(
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH] Docs: dt: Be explicit and consistent in reference to IOMMU specifiers
From: Stuart Yoder @ 2016-12-16 14:08 UTC (permalink / raw)
To: Mark Rutland
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
In-Reply-To: <20161216113317.GB20265@leverpostej>
> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland-5wv7dgnIgG8@public.gmane.org]
> Sent: Friday, December 16, 2016 5:33 AM
> To: Stuart Yoder <stuart.yoder-3arQi8VN3Tc@public.gmane.org>
> Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org;
> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; will.deacon-5wv7dgnIgG8@public.gmane.org
> Subject: Re: [PATCH] Docs: dt: Be explicit and consistent in reference to IOMMU specifiers
>
> Hi Stuart,
>
> On Thu, Dec 15, 2016 at 06:16:13PM -0600, Stuart Yoder wrote:
> > The generic IOMMU binding says that the meaning of an 'IOMMU specifier'
> > is defined by the binding of a specific SMMU. The ARM SMMU binding
> > never explicitly uses the term 'specifier' at all. Update implicit
> > references to use the explicit term.
> >
> > In the iommu-map binding change references to iommu-specifier to
> > "IOMMU specifier" so we are 100% consistent everywhere with terminology
> > and capitalization.
>
> Elsewhere, we always use lower case "xxx-specifier" or "xxx specifier",
> e.g. Documentation/devicetree/bindings/gpio/gpio.txt defines
> "gpio-specifier", ePAPR defines "interrupt specifier".
>
> Given we're morstly consistent on "iommu-specifier" today,could we
> please jsut update the ARM SMMU binding to match that? If we're going to
> fix the dash mismatch, that's a more general, cross-binding thing.
The notable place where we don't use "iommu-specifier" in in the generic
IOMMU binding itself where we use "IOMMU specifier". You're suggesting
using "iommu-specifier" everywhere including the generic binding? Sounds
fine to me. It's a nit but would like to see it consistent everywhere.
Thanks,
Stuart
^ permalink raw reply
* [PATCH] Documentation: dt: Explicitly mark Samsung Exynos SoC bindings as unstable
From: Marek Szyprowski @ 2016-12-16 14:14 UTC (permalink / raw)
To: linux-samsung-soc, devicetree, linux-arm-kernel
Cc: Mark Rutland, Chanwoo Choi, Bartlomiej Zolnierkiewicz,
Seung-Woo Kim, Krzysztof Kozlowski, Inki Dae,
Javier Martinez Canillas, Rob Herring, Kukjin Kim,
Sylwester Nawrocki, Marek Szyprowski
Samsung Exynos SoCs and boards related bindings evolved since the initial
introduction, but initially the bindings were minimal and a bit incomplete
(they never described all the hardware modules available in the SoCs).
Since then some significant (not fully compatible) changes have been
already committed a few times (like gpio replaced by pinctrl, display ddc,
mfc reserved memory, some core clocks added to various hardware modules,
added more required nodes).
On the other side there are no boards which have device tree embedded in
the bootloader. Device tree blob is always compiled from the kernel tree
and updated together with the kernel image.
Thus to avoid further adding a bunch of workarounds for old/missing
bindings and allow to make cleanup of the existing code and device tree
files, lets mark Samsung Exynos SoC platform bindings as unstable. This
means that bindings can may change at any time and users should use the
dtb file compiled from the same kernel source tree as the kernel image.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
Documentation/devicetree/bindings/arm/samsung/exynos.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/samsung/exynos.txt
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos.txt b/Documentation/devicetree/bindings/arm/samsung/exynos.txt
new file mode 100644
index 000000000000..0c606f4c6e85
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos.txt
@@ -0,0 +1,12 @@
+Samsung Exynos SoC Family Device Tree Bindings
+---------------------------------------------------------------
+
+Work in progress statement:
+
+Device tree files and bindings applying to Samsung Exynos SoCs and boards are
+considered "unstable". Any Samsung Exynos device tree binding may change at any
+time. Be sure to use a device tree binary and a kernel image generated from the
+same source tree.
+
+Please refer to Documentation/devicetree/bindings/ABI.txt for a definition of a
+stable binding/ABI.
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v5 2/6] [media] rc-main: split setup and unregister functions
From: Sean Young @ 2016-12-16 14:16 UTC (permalink / raw)
To: Andi Shyti
Cc: Mauro Carvalho Chehab, Rob Herring, Mark Rutland, Richard Purdie,
Jacek Anaszewski, Heiner Kallweit, linux-media, devicetree,
linux-leds, linux-kernel, Andi Shyti
In-Reply-To: <20161216121026.GA31618@gofer.mess.org>
Hi Andi,
On Fri, Dec 16, 2016 at 12:10:26PM +0000, Sean Young wrote:
> Sorry to add to your woes, but there are some checkpatch warnings and
> errors. Please can you correct these. One is below.
Actually, the changes are pretty minor, I can fix them up before sending
them to Mauro. Sorry for bothering you.
Sean
^ permalink raw reply
* Re: [PATCH] Documentation: dt: Explicitly mark Samsung Exynos SoC bindings as unstable
From: Javier Martinez Canillas @ 2016-12-16 14:18 UTC (permalink / raw)
To: Marek Szyprowski, linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Rob Herring, Mark Rutland, Krzysztof Kozlowski,
Bartlomiej Zolnierkiewicz, Kukjin Kim, Inki Dae, Seung-Woo Kim,
Chanwoo Choi, Sylwester Nawrocki
In-Reply-To: <1481897676-13578-1-git-send-email-m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Hello Marek,
On 12/16/2016 11:14 AM, Marek Szyprowski wrote:
> Samsung Exynos SoCs and boards related bindings evolved since the initial
> introduction, but initially the bindings were minimal and a bit incomplete
> (they never described all the hardware modules available in the SoCs).
> Since then some significant (not fully compatible) changes have been
> already committed a few times (like gpio replaced by pinctrl, display ddc,
> mfc reserved memory, some core clocks added to various hardware modules,
> added more required nodes).
>
> On the other side there are no boards which have device tree embedded in
> the bootloader. Device tree blob is always compiled from the kernel tree
> and updated together with the kernel image.
>
> Thus to avoid further adding a bunch of workarounds for old/missing
> bindings and allow to make cleanup of the existing code and device tree
> files, lets mark Samsung Exynos SoC platform bindings as unstable. This
> means that bindings can may change at any time and users should use the
> dtb file compiled from the same kernel source tree as the kernel image.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
I completely agree with you on this.
Reviewed-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: RFC: extend iommu-map binding to support #iommu-cells > 1
From: Stuart Yoder @ 2016-12-16 14:21 UTC (permalink / raw)
To: Mark Rutland
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
In-Reply-To: <20161216113914.GC20265@leverpostej>
> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland-5wv7dgnIgG8@public.gmane.org]
> Sent: Friday, December 16, 2016 5:39 AM
> To: Stuart Yoder <stuart.yoder-3arQi8VN3Tc@public.gmane.org>
> Cc: robin.murphy-5wv7dgnIgG8@public.gmane.org; will.deacon-5wv7dgnIgG8@public.gmane.org; robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; Bharat Bhushan
> <bharat.bhushan-3arQi8VN3Tc@public.gmane.org>; Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>; Diana Madalina Craciun
> <diana.craciun-3arQi8VN3Tc@public.gmane.org>; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> Subject: Re: RFC: extend iommu-map binding to support #iommu-cells > 1
>
> On Fri, Dec 16, 2016 at 02:36:57AM +0000, Stuart Yoder wrote:
> > For context, please see the thread:
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spinics.net%2Flists%2Farm-
> kernel%2Fmsg539066.html&data=01%7C01%7Cstuart.yoder%40nxp.com%7C0464e12bddfd42e0f0a508d425a847cb%7C686ea
> 1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=KnzeOlbts271GwD1cpx2FLMsKnxw%2FOdiGVTp6%2BKFrbM%3D&reserved=0
> >
> > The existing iommu-map binding did not account for the situation where
> > #iommu-cells == 2, as permitted in the ARM SMMU binding. The 2nd cell
> > of the IOMMU specifier being the SMR mask. The existing binding defines
> > the mapping as:
> > Any RID r in the interval [rid-base, rid-base + length) is associated with
> > the listed IOMMU, with the iommu-specifier (r - rid-base + iommu-base).
> >
> > ...and that does not work if iommu-base is 2 cells, the second being the
> > SMR mask.
> >
> > While this can be worked around by always having length=1, it seems we
> > can get this cleaned up by updating the binding definition for iommu-map.
>
> To reiterate, I'm very much not keen on the pci-iommu binding having
> knowledge of the decomposition of iommu-specifiers from other bindings.
With the current definition of iommu-map we already have baked in an
assumption that an iommu-specifier is a value that can be incremented
by 1 to get to the next sequential specifier. So the binding already
has "knowledge" that applies in most, but not all cases.
The generic iommu binding also defines a case where #iommu-cells=4
for some IOMMUs.
Since the ARM SMMU is a special case, perhaps the intepretation
of an iommu-specifier in the context of iommu-map should be moved
into the SMMU binding.
> As mentioned previously, there's an intended interpretation [1] that we
> need to fix up the pci-iommu binding with. With that, I don't think it's
> even necessary to bodge iommu-cells = <1> AFAICT.
You had said in the previous thread:
> I had intended that the offset was added to the final cell of the
> iommu-specifier (i.e. that the iommu-specifier was treated as a large
> number).
> You can handle this case by adding additional entries in the map table,
> with a single entry length.
I understand that, and it works, but I don't see why the definition has
to be that the offset is added to the "final cell". Why can't it be
an iommu specific definition that makes sense for a given IOMMU?
Stuart
^ permalink raw reply
* Re: [PATCH] Documentation: dt: Explicitly mark Samsung Exynos SoC bindings as unstable
From: Bartlomiej Zolnierkiewicz @ 2016-12-16 14:27 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-samsung-soc, devicetree, linux-arm-kernel, Rob Herring,
Mark Rutland, Krzysztof Kozlowski, Javier Martinez Canillas,
Kukjin Kim, Inki Dae, Seung-Woo Kim, Chanwoo Choi,
Sylwester Nawrocki
In-Reply-To: <1481897676-13578-1-git-send-email-m.szyprowski@samsung.com>
Hi,
On Friday, December 16, 2016 03:14:36 PM Marek Szyprowski wrote:
> Samsung Exynos SoCs and boards related bindings evolved since the initial
> introduction, but initially the bindings were minimal and a bit incomplete
> (they never described all the hardware modules available in the SoCs).
> Since then some significant (not fully compatible) changes have been
> already committed a few times (like gpio replaced by pinctrl, display ddc,
> mfc reserved memory, some core clocks added to various hardware modules,
> added more required nodes).
>
> On the other side there are no boards which have device tree embedded in
> the bootloader. Device tree blob is always compiled from the kernel tree
> and updated together with the kernel image.
>
> Thus to avoid further adding a bunch of workarounds for old/missing
> bindings and allow to make cleanup of the existing code and device tree
> files, lets mark Samsung Exynos SoC platform bindings as unstable. This
> means that bindings can may change at any time and users should use the
> dtb file compiled from the same kernel source tree as the kernel image.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
This change is long overdue..
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> ---
> Documentation/devicetree/bindings/arm/samsung/exynos.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/samsung/exynos.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos.txt b/Documentation/devicetree/bindings/arm/samsung/exynos.txt
> new file mode 100644
> index 000000000000..0c606f4c6e85
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos.txt
> @@ -0,0 +1,12 @@
> +Samsung Exynos SoC Family Device Tree Bindings
> +---------------------------------------------------------------
> +
> +Work in progress statement:
> +
> +Device tree files and bindings applying to Samsung Exynos SoCs and boards are
> +considered "unstable". Any Samsung Exynos device tree binding may change at any
> +time. Be sure to use a device tree binary and a kernel image generated from the
> +same source tree.
> +
> +Please refer to Documentation/devicetree/bindings/ABI.txt for a definition of a
> +stable binding/ABI.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox