Skip to contentSkip to conversation

rtc: enable adjustment of clock offset

PATCH In review Joshua Clayton 7 participants 58 messages Jan 4, 2016 – Feb 23, 2016 1 message not in the archive

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

v2 cover rtc: enable adjustment of clock offset

Alexandre,
this is the second version of apatch set to be able to adjust the clock on a pcf2123, but with a big addition. I am also proposing a couple of new rtc api functions and a new sysfs file.

Patches 1-5 are very much v2 patches that address All of the concerns you had with v1. It is my hope to get them merged without too much more trouble.

Patches 6-8 are attemping to add a new function to the rtc class to adjust the clock rate. I hope I am going about this the right way, But here goes.

A number of rtc devices, such as the NXP pcf2123 include a facility to adjust the clock in order to compensate for temperature or a crystal, capacitor, etc, that results in the rtc clock not running at exactly 32.768 kHz.

This patchset adds kernel and sysfs hooks to access that ability.

One datasheet suggests it might be adjusted based on input from a temperature sensor. I could also potentially see it being set as part of ntp calibration.

Data sheets I have seen refer to this as a clock offset, and measure it in parts per million (ppm), however they often reference ppm to 2 digits of precision, which makes integer ppm less than ideal. I use parts per billion, which more than covers the precision needed and works nicely within 32 bits

The name "offset" came from the pcf-2123 datasheet and is used by at least some other data sheets. I would be happy to use a different term if someone else comes up with something more concise.

Changes since v1:
- Use the BIT() macro for all register bits
- Remove unneeded range checks from read/write functions
- Merge patch 3 (replace magic numbers with defines) into patch 2
- Add a proper commit message to patch 5, now patch 4
- Fix a function alignment bug.
- Move OSC_HAS_STOPPED check into pcf2123_rtc_read_time, and get rid of pcf2123_time_valid()
- Drop patches refactoring pcf2123 sysfs.
- Add rtc interface and rtc sysfs file for clock offset

Joshua Clayton (8):
rtc-pcf2123: define registers and bit macros
rtc-pcf2123: clean up reads from the chip
rtc-pcf2123: clean up writes to the rtc chip
rtc-pcf2123: refactor chip reset into a function
rtc-pcf2123: avoid resetting the clock if possible
rtc: Add functions to set and read clock offset
rtc: implement a sysfs interface for clock offset
rtc-pcf2123: implement read_offset and set_offset

 drivers/rtc/interface.c   |  57 ++++++++++
 drivers/rtc/rtc-pcf2123.c | 271 +++++++++++++++++++++++++++++++++-------------
 drivers/rtc/rtc-sysfs.c   |  29 +++++
 include/linux/rtc.h       |   4 +
 4 files changed, 284 insertions(+), 77 deletions(-)
Signature · 12 lines
2.5.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#1 lore raw

PATCH v2 1/8 rtc-pcf2123: define registers and bit macros

Add defines for all 16 registers in the pcf2123. Add defines for useful bits from several registers I've tried to document all the registers, and as best as possible, all the special bits they employ

Use BIT() wherever possible in the bit definitions

---
 drivers/rtc/rtc-pcf2123.c | 50 ++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 47 insertions(+), 3 deletions(-)
drivers/rtc/rtc-pcf2123.c +47 -3
index ea8a31c..be3ec83 100644
@@ -48,6 +48,7 @@
 
 #define DRV_VERSION "0.6"
 
+/* REGISTERS */
 #define PCF2123_REG_CTRL1	(0x00)	/* Control Register 1 */
 #define PCF2123_REG_CTRL2	(0x01)	/* Control Register 2 */
 #define PCF2123_REG_SC		(0x02)	/* datetime */
@@ -57,10 +58,53 @@
 #define PCF2123_REG_DW		(0x06)
 #define PCF2123_REG_MO		(0x07)
 #define PCF2123_REG_YR		(0x08)
+#define PCF2123_REG_ALRM_MN	(0x09)	/* Alarm Registers */
+#define PCF2123_REG_ALRM_HR	(0x0a)
+#define PCF2123_REG_ALRM_DM	(0x0b)
+#define PCF2123_REG_ALRM_DW	(0x0c)
+#define PCF2123_REG_OFFSET	(0x0d)	/* Clock Rate Offset Register */
+#define PCF2123_REG_TMR_CLKOUT	(0x0e)	/* Timer Registers */
+#define PCF2123_REG_CTDWN_TMR	(0x0f)
+
+/* PCF2123_REG_CTRL1 BITS */
+#define CTRL1_CLEAR		(0)	/* Clear */
+#define CTRL1_CORR_INT		BIT(1)	/* Correction irq enable */
+#define CTRL1_12_HOUR		BIT(2)	/* 12 hour time */
+#define CTRL1_SW_RESET	(BIT(3) | BIT(4) | BIT(6))	/* Software reset */
+#define CTRL1_STOP		BIT(5)	/* Stop the clock */
+#define CTRL1_EXT_TEST		BIT(7)	/* External clock test mode */
+
+/* PCF2123_REG_CTRL2 BITS */
+#define CTRL2_TIE		BIT(0)	/* Countdown timer irq enable */
+#define CTRL2_AIE		BIT(1)	/* Alarm irq enable */
+#define CTRL2_TF		BIT(2)	/* Countdown timer flag */
+#define CTRL2_AF		BIT(3)	/* Alarm flag */
+#define CTRL2_TI_TP		BIT(4)	/* Irq pin generates pulse */
+#define CTRL2_MSF		BIT(5)	/* Minute or second irq flag */
+#define CTRL2_SI		BIT(6)	/* Second irq enable */
+#define CTRL2_MI		BIT(7)	/* Minute irq enable */
+
+/* PCF2123_REG_SC BITS */
+#define OSC_HAS_STOPPED		BIT(7)	/* Clock has been stopped */
+
+/* PCF2123_REG_ALRM_XX BITS */
+#define ALRM_ENABLE		BIT(7)	/* MN, HR, DM, or DW alarm enable */
+
+/* PCF2123_REG_TMR_CLKOUT BITS */
+#define CD_TMR_4096KHZ		(0)	/* 4096 KHz countdown timer */
+#define CD_TMR_64HZ		(1)	/* 64 Hz countdown timer */
+#define CD_TMR_1HZ		(2)	/* 1 Hz countdown timer */
+#define CD_TMR_60th_HZ		(3)	/* 60th Hz countdown timer */
+#define CD_TMR_TE		BIT(3)	/* Countdown timer enable */
+
+/* PCF2123_REG_OFFSET BITS */
+#define OFFSET_SIGN_BIT		BIT(6)	/* 2's complement sign bit */
+#define OFFSET_COARSE		BIT(7)	/* Coarse mode offset */
+
+/* READ/WRITE ADDRESS BITS */
+#define PCF2123_WRITE		BIT(4)
+#define PCF2123_READ		(BIT(4) | BIT(7))
 
-#define PCF2123_SUBADDR		(1 << 4)
-#define PCF2123_WRITE		((0 << 7) | PCF2123_SUBADDR)
-#define PCF2123_READ		((1 << 7) | PCF2123_SUBADDR)
 
 static struct spi_driver pcf2123_driver;
 
Signature · 12 lines
2.5.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#2 lore raw

PATCH v2 2/8 rtc-pcf2123: clean up reads from the chip

In reply to Joshua Clayton

Put read operations into a function.
This improves modularity and readability.

---
 drivers/rtc/rtc-pcf2123.c | 36 +++++++++++++++++++-----------------
 1 file changed, 19 insertions(+), 17 deletions(-)
drivers/rtc/rtc-pcf2123.c +19 -17
index be3ec83..4c4b3fc 100644
@@ -128,12 +128,23 @@ static inline void pcf2123_delay_trec(void)
 	ndelay(30);
 }
 
+static int pcf2123_read(struct device *dev, u8 reg, u8 *rxbuf, size_t size)
+{
+	struct spi_device *spi = to_spi_device(dev);
+	int ret;
+
+	reg |= PCF2123_READ;
+	ret = spi_write_then_read(spi, &reg, 1, rxbuf, size);
+	pcf2123_delay_trec();
+
+	return ret;
+}
+
 static ssize_t pcf2123_show(struct device *dev, struct device_attribute *attr,
 			    char *buffer)
 {
-	struct spi_device *spi = to_spi_device(dev);
 	struct pcf2123_sysfs_reg *r;
-	u8 txbuf[1], rxbuf[1];
+	u8 rxbuf[1];
 	unsigned long reg;
 	int ret;
 
@@ -143,11 +154,10 @@ static ssize_t pcf2123_show(struct device *dev, struct device_attribute *attr,
 	if (ret)
 		return ret;
 
-	txbuf[0] = PCF2123_READ | reg;
-	ret = spi_write_then_read(spi, txbuf, 1, rxbuf, 1);
+	ret = pcf2123_read(dev, reg, rxbuf, 1);
 	if (ret < 0)
 		return -EIO;
-	pcf2123_delay_trec();
+
 	return sprintf(buffer, "0x%x\n", rxbuf[0]);
 }
 
@@ -182,16 +192,12 @@ static ssize_t pcf2123_store(struct device *dev, struct device_attribute *attr,
 
 static int pcf2123_rtc_read_time(struct device *dev, struct rtc_time *tm)
 {
-	struct spi_device *spi = to_spi_device(dev);
-	u8 txbuf[1], rxbuf[7];
+	u8 rxbuf[7];
 	int ret;
 
-	txbuf[0] = PCF2123_READ | PCF2123_REG_SC;
-	ret = spi_write_then_read(spi, txbuf, sizeof(txbuf),
-			rxbuf, sizeof(rxbuf));
+	ret = pcf2123_read(dev, PCF2123_REG_SC, rxbuf, sizeof(rxbuf));
 	if (ret < 0)
 		return ret;
-	pcf2123_delay_trec();
 
 	tm->tm_sec = bcd2bin(rxbuf[0] & 0x7F);
 	tm->tm_min = bcd2bin(rxbuf[1] & 0x7F);
@@ -297,16 +303,12 @@ static int pcf2123_probe(struct spi_device *spi)
 	pcf2123_delay_trec();
 
 	/* See if the counter was actually stopped */
-	txbuf[0] = PCF2123_READ | PCF2123_REG_CTRL1;
-	dev_dbg(&spi->dev, "checking for presence of RTC (0x%02X)\n",
-			txbuf[0]);
-	ret = spi_write_then_read(spi, txbuf, 1 * sizeof(u8),
-					rxbuf, 2 * sizeof(u8));
+	dev_dbg(&spi->dev, "checking for presence of RTC\n");
+	ret = pcf2123_read(&spi->dev, PCF2123_REG_CTRL1, rxbuf, sizeof(rxbuf));
 	dev_dbg(&spi->dev, "received data from RTC (0x%02X 0x%02X)\n",
 			rxbuf[0], rxbuf[1]);
 	if (ret < 0)
 		goto kfree_exit;
-	pcf2123_delay_trec();
 
 	if (!(rxbuf[0] & 0x20)) {
 		dev_err(&spi->dev, "chip not found\n");
Signature · 12 lines
2.5.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#3 lore raw

PATCH v2 3/8 rtc-pcf2123: clean up writes to the rtc chip

In reply to Joshua Clayton

Add new functions pcf2123_write(), and pcf2123_write_reg(). Use named defines for the values being written.

This improves modularity and readability, and reduces lines of code.

---
 drivers/rtc/rtc-pcf2123.c | 67 ++++++++++++++++++++++-------------------------
 1 file changed, 32 insertions(+), 35 deletions(-)
drivers/rtc/rtc-pcf2123.c +32 -35
index 4c4b3fc..0f2ce45 100644
@@ -140,6 +140,27 @@ static int pcf2123_read(struct device *dev, u8 reg, u8 *rxbuf, size_t size)
 	return ret;
 }
 
+static int pcf2123_write(struct device *dev, u8 *txbuf, size_t size)
+{
+	struct spi_device *spi = to_spi_device(dev);
+	int ret;
+
+	txbuf[0] |= PCF2123_WRITE;
+	ret = spi_write(spi, txbuf, size);
+	pcf2123_delay_trec();
+
+	return ret;
+}
+
+static int pcf2123_write_reg(struct device *dev, u8 reg, u8 val)
+{
+	u8 txbuf[2];
+
+	txbuf[0] = reg;
+	txbuf[1] = val;
+	return pcf2123_write(dev, txbuf, sizeof(txbuf));
+}
+
 static ssize_t pcf2123_show(struct device *dev, struct device_attribute *attr,
 			    char *buffer)
 {
@@ -163,9 +184,7 @@ static ssize_t pcf2123_show(struct device *dev, struct device_attribute *attr,
 
 static ssize_t pcf2123_store(struct device *dev, struct device_attribute *attr,
 			     const char *buffer, size_t count) {
-	struct spi_device *spi = to_spi_device(dev);
 	struct pcf2123_sysfs_reg *r;
-	u8 txbuf[2];
 	unsigned long reg;
 	unsigned long val;
 
@@ -181,12 +200,9 @@ static ssize_t pcf2123_store(struct device *dev, struct device_attribute *attr,
 	if (ret)
 		return ret;
 
-	txbuf[0] = PCF2123_WRITE | reg;
-	txbuf[1] = val;
-	ret = spi_write(spi, txbuf, sizeof(txbuf));
+	pcf2123_write_reg(dev, reg, val);
 	if (ret < 0)
 		return -EIO;
-	pcf2123_delay_trec();
 	return count;
 }
 
@@ -220,7 +236,6 @@ static int pcf2123_rtc_read_time(struct device *dev, struct rtc_time *tm)
 
 static int pcf2123_rtc_set_time(struct device *dev, struct rtc_time *tm)
 {
-	struct spi_device *spi = to_spi_device(dev);
 	u8 txbuf[8];
 	int ret;
 
@@ -231,15 +246,12 @@ static int pcf2123_rtc_set_time(struct device *dev, struct rtc_time *tm)
 			tm->tm_mday, tm->tm_mon, tm->tm_year, tm->tm_wday);
 
 	/* Stop the counter first */
-	txbuf[0] = PCF2123_WRITE | PCF2123_REG_CTRL1;
-	txbuf[1] = 0x20;
-	ret = spi_write(spi, txbuf, 2);
+	ret = pcf2123_write_reg(dev, PCF2123_REG_CTRL1, CTRL1_STOP);
 	if (ret < 0)
 		return ret;
-	pcf2123_delay_trec();
 
 	/* Set the new time */
-	txbuf[0] = PCF2123_WRITE | PCF2123_REG_SC;
+	txbuf[0] = PCF2123_REG_SC;
 	txbuf[1] = bin2bcd(tm->tm_sec & 0x7F);
 	txbuf[2] = bin2bcd(tm->tm_min & 0x7F);
 	txbuf[3] = bin2bcd(tm->tm_hour & 0x3F);
@@ -248,18 +260,14 @@ static int pcf2123_rtc_set_time(struct device *dev, struct rtc_time *tm)
 	txbuf[6] = bin2bcd((tm->tm_mon + 1) & 0x1F); /* rtc mn 1-12 */
 	txbuf[7] = bin2bcd(tm->tm_year < 100 ? tm->tm_year : tm->tm_year - 100);
 
-	ret = spi_write(spi, txbuf, sizeof(txbuf));
+	ret = pcf2123_write(dev, txbuf, sizeof(txbuf));
 	if (ret < 0)
 		return ret;
-	pcf2123_delay_trec();
 
 	/* Start the counter */
-	txbuf[0] = PCF2123_WRITE | PCF2123_REG_CTRL1;
-	txbuf[1] = 0x00;
-	ret = spi_write(spi, txbuf, 2);
+	ret = pcf2123_write_reg(dev, PCF2123_REG_CTRL1, CTRL1_CLEAR);
 	if (ret < 0)
 		return ret;
-	pcf2123_delay_trec();
 
 	return 0;
 }
@@ -273,7 +281,7 @@ static int pcf2123_probe(struct spi_device *spi)
 {
 	struct rtc_device *rtc;
 	struct pcf2123_plat_data *pdata;
-	u8 txbuf[2], rxbuf[2];
+	u8  rxbuf[2];
 	int ret, i;
 
 	pdata = devm_kzalloc(&spi->dev, sizeof(struct pcf2123_plat_data),
@@ -283,24 +291,16 @@ static int pcf2123_probe(struct spi_device *spi)
 	spi->dev.platform_data = pdata;
 
 	/* Send a software reset command */
-	txbuf[0] = PCF2123_WRITE | PCF2123_REG_CTRL1;
-	txbuf[1] = 0x58;
-	dev_dbg(&spi->dev, "resetting RTC (0x%02X 0x%02X)\n",
-			txbuf[0], txbuf[1]);
-	ret = spi_write(spi, txbuf, 2 * sizeof(u8));
+	dev_dbg(&spi->dev, "resetting RTC\n");
+	ret = pcf2123_write_reg(&spi->dev, PCF2123_REG_CTRL1, CTRL1_SW_RESET);
 	if (ret < 0)
 		goto kfree_exit;
-	pcf2123_delay_trec();
 
 	/* Stop the counter */
-	txbuf[0] = PCF2123_WRITE | PCF2123_REG_CTRL1;
-	txbuf[1] = 0x20;
-	dev_dbg(&spi->dev, "stopping RTC (0x%02X 0x%02X)\n",
-			txbuf[0], txbuf[1]);
-	ret = spi_write(spi, txbuf, 2 * sizeof(u8));
+	dev_dbg(&spi->dev, "stopping RTC\n");
+	ret = pcf2123_write_reg(&spi->dev, PCF2123_REG_CTRL1, CTRL1_STOP);
 	if (ret < 0)
 		goto kfree_exit;
-	pcf2123_delay_trec();
 
 	/* See if the counter was actually stopped */
 	dev_dbg(&spi->dev, "checking for presence of RTC\n");
@@ -321,12 +321,9 @@ static int pcf2123_probe(struct spi_device *spi)
 			(spi->max_speed_hz + 500) / 1000);
 
 	/* Start the counter */
-	txbuf[0] = PCF2123_WRITE | PCF2123_REG_CTRL1;
-	txbuf[1] = 0x00;
-	ret = spi_write(spi, txbuf, sizeof(txbuf));
+	ret = pcf2123_write_reg(&spi->dev, PCF2123_REG_CTRL1, CTRL1_CLEAR);
 	if (ret < 0)
 		goto kfree_exit;
-	pcf2123_delay_trec();
 
 	/* Finalize the initialization */
 	rtc = devm_rtc_device_register(&spi->dev, pcf2123_driver.driver.name,
Signature · 12 lines
2.5.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#4 lore raw

PATCH v2 4/8 rtc-pcf2123: refactor chip reset into a function

In reply to Joshua Clayton

Refactor chip reset items into its own function, isolating it from the rest of the device probe.
Subsequent commits will avoid calling this code.

---
 drivers/rtc/rtc-pcf2123.c | 64 ++++++++++++++++++++++++++---------------------
 1 file changed, 36 insertions(+), 28 deletions(-)
drivers/rtc/rtc-pcf2123.c +36 -28
index 0f2ce45..2d886d4 100644
@@ -272,6 +272,40 @@ static int pcf2123_rtc_set_time(struct device *dev, struct rtc_time *tm)
 	return 0;
 }
 
+static int pcf2123_reset(struct device *dev)
+{
+	int ret;
+	u8  rxbuf[2];
+
+	ret = pcf2123_write_reg(dev, PCF2123_REG_CTRL1, CTRL1_SW_RESET);
+	if (ret < 0)
+		return ret;
+
+	/* Stop the counter */
+	dev_dbg(dev, "stopping RTC\n");
+	ret = pcf2123_write_reg(dev, PCF2123_REG_CTRL1, CTRL1_STOP);
+	if (ret < 0)
+		return ret;
+
+	/* See if the counter was actually stopped */
+	dev_dbg(dev, "checking for presence of RTC\n");
+	ret = pcf2123_read(dev, PCF2123_REG_CTRL1, rxbuf, sizeof(rxbuf));
+	if (ret < 0)
+		return ret;
+
+	dev_dbg(dev, "received data from RTC (0x%02X 0x%02X)\n",
+		rxbuf[0], rxbuf[1]);
+	if (!(rxbuf[0] & CTRL1_STOP))
+		return -ENODEV;
+
+	/* Start the counter */
+	ret = pcf2123_write_reg(dev, PCF2123_REG_CTRL1, CTRL1_CLEAR);
+	if (ret < 0)
+		return ret;
+
+	return 0;
+}
+
 static const struct rtc_class_ops pcf2123_rtc_ops = {
 	.read_time	= pcf2123_rtc_read_time,
 	.set_time	= pcf2123_rtc_set_time,
@@ -281,7 +315,6 @@ static int pcf2123_probe(struct spi_device *spi)
 {
 	struct rtc_device *rtc;
 	struct pcf2123_plat_data *pdata;
-	u8  rxbuf[2];
 	int ret, i;
 
 	pdata = devm_kzalloc(&spi->dev, sizeof(struct pcf2123_plat_data),
@@ -290,29 +323,9 @@ static int pcf2123_probe(struct spi_device *spi)
 		return -ENOMEM;
 	spi->dev.platform_data = pdata;
 
-	/* Send a software reset command */
-	dev_dbg(&spi->dev, "resetting RTC\n");
-	ret = pcf2123_write_reg(&spi->dev, PCF2123_REG_CTRL1, CTRL1_SW_RESET);
-	if (ret < 0)
-		goto kfree_exit;
-
-	/* Stop the counter */
-	dev_dbg(&spi->dev, "stopping RTC\n");
-	ret = pcf2123_write_reg(&spi->dev, PCF2123_REG_CTRL1, CTRL1_STOP);
-	if (ret < 0)
-		goto kfree_exit;
-
-	/* See if the counter was actually stopped */
-	dev_dbg(&spi->dev, "checking for presence of RTC\n");
-	ret = pcf2123_read(&spi->dev, PCF2123_REG_CTRL1, rxbuf, sizeof(rxbuf));
-	dev_dbg(&spi->dev, "received data from RTC (0x%02X 0x%02X)\n",
-			rxbuf[0], rxbuf[1]);
-	if (ret < 0)
-		goto kfree_exit;
-
-	if (!(rxbuf[0] & 0x20)) {
+	ret = pcf2123_reset(&spi->dev);
+	if (ret < 0) {
 		dev_err(&spi->dev, "chip not found\n");
-		ret = -ENODEV;
 		goto kfree_exit;
 	}
 
@@ -320,11 +333,6 @@ static int pcf2123_probe(struct spi_device *spi)
 	dev_info(&spi->dev, "spiclk %u KHz.\n",
 			(spi->max_speed_hz + 500) / 1000);
 
-	/* Start the counter */
-	ret = pcf2123_write_reg(&spi->dev, PCF2123_REG_CTRL1, CTRL1_CLEAR);
-	if (ret < 0)
-		goto kfree_exit;
-
 	/* Finalize the initialization */
 	rtc = devm_rtc_device_register(&spi->dev, pcf2123_driver.driver.name,
 			&pcf2123_rtc_ops, THIS_MODULE);
Signature · 12 lines
2.5.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#5 lore raw

PATCH v2 5/8 rtc-pcf2123: avoid resetting the clock if possible

In reply to Joshua Clayton

pcf2123 data sheet recommends a software reset when the chip is first powered on. This change avoids resetting the chip every time the driver is loaded, which has some negative effects.

There are several registers including a clock rate adjustment that really should survive a reload of the driver (or reboot).

In addition, stopping and restarting the clock to verify the chip is there is not a good thing once the time is set.

According to the data sheet, the seconds register has a 1 in the high bit when the voltage has gotten low. We check for this condition, as well as whether the time retrieved from the chip is valid. We reset the rtc only if the time is not reliable and valid. This is sufficient for checking for the presence of the chip, as either all zeros or all 0xff will result in an invalid time/date

---
 drivers/rtc/rtc-pcf2123.c | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)
drivers/rtc/rtc-pcf2123.c +12 -3
index 2d886d4..d9a44ad 100644
@@ -215,6 +215,11 @@ static int pcf2123_rtc_read_time(struct device *dev, struct rtc_time *tm)
 	if (ret < 0)
 		return ret;
 
+	if (rxbuf[0] & OSC_HAS_STOPPED) {
+		dev_info(dev, "clock was stopped. Time is not valid\n");
+		return -EINVAL;
+	}
+
 	tm->tm_sec = bcd2bin(rxbuf[0] & 0x7F);
 	tm->tm_min = bcd2bin(rxbuf[1] & 0x7F);
 	tm->tm_hour = bcd2bin(rxbuf[2] & 0x3F); /* rtc hr 0-23 */
@@ -314,6 +319,7 @@ static const struct rtc_class_ops pcf2123_rtc_ops = {
 static int pcf2123_probe(struct spi_device *spi)
 {
 	struct rtc_device *rtc;
+	struct rtc_time tm;
 	struct pcf2123_plat_data *pdata;
 	int ret, i;
 
@@ -323,10 +329,13 @@ static int pcf2123_probe(struct spi_device *spi)
 		return -ENOMEM;
 	spi->dev.platform_data = pdata;
 
-	ret = pcf2123_reset(&spi->dev);
+	ret = pcf2123_rtc_read_time(&spi->dev, &tm);
 	if (ret < 0) {
-		dev_err(&spi->dev, "chip not found\n");
-		goto kfree_exit;
+		ret = pcf2123_reset(&spi->dev);
+		if (ret < 0) {
+			dev_err(&spi->dev, "chip not found\n");
+			goto kfree_exit;
+		}
 	}
 
 	dev_info(&spi->dev, "chip found, driver version " DRV_VERSION "\n");
Signature · 12 lines
2.5.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#6 lore raw

PATCH v2 6/8 rtc: Add functions to set and read clock offset

In reply to Joshua Clayton

A number of rtc devices, such as the NXP pcf2123 include a facility to adjust the clock in order to compensate for temperature or a crystal, capacitor, etc, that results in the rtc clock not running at exactly 32.768 kHz.

Data sheets I have seen refer to this as a clock offset, and measure it in parts per million (ppm), however they often reference ppm to 2 digits of precision, which makes integer ppm less than ideal.

We use parts per billion, which more than covers the precision needed and works nicely within 32 bits

---
 drivers/rtc/interface.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/rtc.h     |  4 ++++
 2 files changed, 61 insertions(+)
drivers/rtc/interface.c +57 -0
index 5836751..57cd928 100644
@@ -939,4 +939,61 @@ void rtc_timer_cancel(struct rtc_device *rtc, struct rtc_timer *timer)
 	mutex_unlock(&rtc->ops_lock);
 }
 
+/**
+ * rtc_read_offset - Read the amount of rtc offset in parts per billion
+ * @ rtc: rtc device to be used
+ * @ offset: the offset in parts per billion
+ *
+ * see below for details.
+ *
+ * Kernel interface to read rtc clock offset
+ * Returns 0 on success, or a negative number on error.
+ * If the rtc offset is not setable (or not implemented), return 0 and put
+ * 0 in the offset value;
+ */
+int rtc_read_offset(struct rtc_device *rtc, long *offset)
+{
+	int ret = 0;
+
+	if (!rtc->ops)
+		return -ENODEV;
+
+	if (!rtc->ops->set_offset) {
+		offset = 0;
+		return 0;
+	}
+
+	mutex_lock(&rtc->ops_lock);
+	ret = rtc->ops->read_offset(rtc->dev.parent, offset);
+	mutex_unlock(&rtc->ops_lock);
+	return ret;
+}
 
+/**
+ * rtc_set_offset - Adjusts the duration of the average second
+ * @ rtc: rtc device to be used
+ * @ offset: the offset in parts per billion
+ *
+ * Some rtc's allow an adjustment to the average duration of a second
+ * to compensate for differences in the actual clock rate due to temperature,
+ * the crystal, capacitor, etc.
+ *
+ * Kernel interface to adjust an rtc clock offset.
+ * Return 0 on success, or a negative number on error.
+ * If the rtc offset is not setable (or not implemented), return -EINVAL
+ */
+int rtc_set_offset(struct rtc_device *rtc, long offset)
+{
+	int ret = 0;
+
+	if (!rtc->ops)
+		return -ENODEV;
+
+	if (!rtc->ops->set_offset)
+		return -EINVAL;
+
+	mutex_lock(&rtc->ops_lock);
+	ret = rtc->ops->set_offset(rtc->dev.parent, offset);
+	mutex_unlock(&rtc->ops_lock);
+	return ret;
+}
include/linux/rtc.h +4 -0
index 3359f04..b693ada 100644
@@ -89,6 +89,8 @@ struct rtc_class_ops {
 	int (*set_mmss)(struct device *, unsigned long secs);
 	int (*read_callback)(struct device *, int data);
 	int (*alarm_irq_enable)(struct device *, unsigned int enabled);
+	int (*read_offset)(struct device *, long *offset);
+	int (*set_offset)(struct device *, long offset);
 };
 
 #define RTC_DEVICE_NAME_SIZE 20
@@ -208,6 +210,8 @@ void rtc_timer_init(struct rtc_timer *timer, void (*f)(void *p), void *data);
 int rtc_timer_start(struct rtc_device *rtc, struct rtc_timer *timer,
 		    ktime_t expires, ktime_t period);
 void rtc_timer_cancel(struct rtc_device *rtc, struct rtc_timer *timer);
+int rtc_read_offset(struct rtc_device *rtc, long *offset);
+int rtc_set_offset(struct rtc_device *rtc, long offset);
 void rtc_timer_do_work(struct work_struct *work);
 
 static inline bool is_leap_year(unsigned int year)
Signature · 12 lines
2.5.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#7 lore raw

PATCH v2 7/8 rtc: implement a sysfs interface for clock offset

In reply to Joshua Clayton

The file is called "offset", and may be set and read in decimal. For rtcs that do not have read_offset or set_offset implemented, read always returns zero and write will return -EINVAL.

---
 drivers/rtc/interface.c |  2 +-
 drivers/rtc/rtc-sysfs.c | 29 +++++++++++++++++++++++++++++
 2 files changed, 30 insertions(+), 1 deletion(-)
drivers/rtc/interface.c +1 -1
index 57cd928..c064eb9 100644
@@ -959,7 +959,7 @@ int rtc_read_offset(struct rtc_device *rtc, long *offset)
 		return -ENODEV;
 
 	if (!rtc->ops->set_offset) {
-		offset = 0;
+		*offset = 0;
 		return 0;
 	}
 
drivers/rtc/rtc-sysfs.c +29 -0
index 7273855..622a0dc 100644
@@ -211,6 +211,34 @@ wakealarm_store(struct device *dev, struct device_attribute *attr,
 }
 static DEVICE_ATTR_RW(wakealarm);
 
+static ssize_t
+offset_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	ssize_t retval;
+	long offset;
+
+	retval = rtc_read_offset(to_rtc_device(dev), &offset);
+	if (retval == 0)
+		retval = sprintf(buf, "%ld\n", offset);
+
+	return retval;
+}
+
+static ssize_t
+offset_store(struct device *dev, struct device_attribute *attr,
+		const char *buf, size_t n)
+{
+	ssize_t retval;
+	long offset;
+
+	retval = kstrtol(buf, 10, &offset);
+	if (retval == 0)
+		retval = rtc_set_offset(to_rtc_device(dev), offset);
+
+	return (retval < 0) ? retval : n;
+}
+static DEVICE_ATTR_RW(offset);
+
 static struct attribute *rtc_attrs[] = {
 	&dev_attr_name.attr,
 	&dev_attr_date.attr,
@@ -219,6 +247,7 @@ static struct attribute *rtc_attrs[] = {
 	&dev_attr_max_user_freq.attr,
 	&dev_attr_hctosys.attr,
 	&dev_attr_wakealarm.attr,
+	&dev_attr_offset.attr,
 	NULL,
 };
 
Signature · 12 lines
2.5.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#8 lore raw

Re: [PATCH v2 7/8] rtc: implement a sysfs interface for clock offset

Hi,

Quoted 4 lines · Joshua Clayton

The file is called "offset", and may be set and read in decimal. For rtcs that do not have read_offset or set_offset implemented, read always returns zero and write will return -EINVAL.

Can you expand rtc_attr_is_visible() instead of having the offset file always present?

Also, you need to expand Documentation/rtc.txt, section SYSFS INTERFACE.

I'm fine with having parts per billion as the unit and I hope we won't ever need anything more precise :)

Quoted 67 lines
---
 drivers/rtc/interface.c |  2 +-
 drivers/rtc/rtc-sysfs.c | 29 +++++++++++++++++++++++++++++
 2 files changed, 30 insertions(+), 1 deletion(-)
drivers/rtc/interface.c +1 -1
index 57cd928..c064eb9 100644
@@ -959,7 +959,7 @@ int rtc_read_offset(struct rtc_device *rtc, long *offset)
 		return -ENODEV;
 
 	if (!rtc->ops->set_offset) {
-		offset = 0;
+		*offset = 0;
 		return 0;
 	}
 
drivers/rtc/rtc-sysfs.c +29 -0
index 7273855..622a0dc 100644
@@ -211,6 +211,34 @@ wakealarm_store(struct device *dev, struct device_attribute *attr,
 }
 static DEVICE_ATTR_RW(wakealarm);
 
+static ssize_t
+offset_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	ssize_t retval;
+	long offset;
+
+	retval = rtc_read_offset(to_rtc_device(dev), &offset);
+	if (retval == 0)
+		retval = sprintf(buf, "%ld\n", offset);
+
+	return retval;
+}
+
+static ssize_t
+offset_store(struct device *dev, struct device_attribute *attr,
+		const char *buf, size_t n)
+{
+	ssize_t retval;
+	long offset;
+
+	retval = kstrtol(buf, 10, &offset);
+	if (retval == 0)
+		retval = rtc_set_offset(to_rtc_device(dev), offset);
+
+	return (retval < 0) ? retval : n;
+}
+static DEVICE_ATTR_RW(offset);
+
 static struct attribute *rtc_attrs[] = {
 	&dev_attr_name.attr,
 	&dev_attr_date.attr,
@@ -219,6 +247,7 @@ static struct attribute *rtc_attrs[] = {
 	&dev_attr_max_user_freq.attr,
 	&dev_attr_hctosys.attr,
 	&dev_attr_wakealarm.attr,
+	&dev_attr_offset.attr,
 	NULL,
 };
 
Signature · 14 lines
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#9 lore raw

Re: [PATCH v2 7/8] rtc: implement a sysfs interface for clock offset

Quoted 9 lines · On Sun, 31 Jan 2016 12:41:15 +0100 Alexandre Belloni…

Hi,

Quoted 4 lines · Joshua Clayton

The file is called "offset", and may be set and read in decimal. For rtcs that do not have read_offset or set_offset implemented, read always returns zero and write will return -EINVAL.

Can you expand rtc_attr_is_visible() instead of having the offset file always present?

Yes, Absolutely.
I wanted to do something like this, but didn't know is_visible existed... and no wonder. Its in attribute_group

Quoted 4 lines

Also, you need to expand Documentation/rtc.txt, section SYSFS INTERFACE.

OK. Will do.

Quoted 3 lines

I'm fine with having parts per billion as the unit and I hope we won't ever need anything more precise :)

It is orders of magnitude more than needed at present ...and no will ever need more than 640k of memory... right?

Signature · 9 lines
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#10 lore raw

Re: [PATCH v2 7/8] rtc: implement a sysfs interface for clock offset

Quoted 4 lines · Joshua Clayton
Quoted 3 lines

I'm fine with having parts per billion as the unit and I hope we won't ever need anything more precise :)

It is orders of magnitude more than needed at present

Yeah, until we get an RTC with an offset precision that has 4 decimals in ppm.

Quoted 1 line

...and no will ever need more than 640k of memory... right?

Right :)

Signature · 14 lines
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#11 lore raw

PATCH v3 1/3 rtc: Add functions to set and read rtc offset

A number of rtc devices, such as the NXP pcf2123 include a facility to adjust the clock in order to compensate for temperature or a crystal, capacitor, etc, that results in the rtc clock not running at exactly 32.768 kHz.

Data sheets I have seen refer to this as a clock offset, and measure it in parts per million, however they often reference ppm to 2 digits of precision, which makes integer ppm less than ideal.

We use parts per billion, which more than covers the precision needed and works nicely within 32 bits

---
Changes since v2:
- patches 1 - 5 from v2 were merged, so 6, 7 , and 8 become 1, 2, 3
- Added documentation of the sysfs interface in Documenbtation/rtc.txt
- Added code so that the offset attrbute does not appear on rtcs that do not support it.

 drivers/rtc/interface.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/rtc.h     |  4 ++++
 2 files changed, 61 insertions(+)
drivers/rtc/interface.c +57 -0
index 5836751..c064eb9 100644
@@ -939,4 +939,61 @@ void rtc_timer_cancel(struct rtc_device *rtc, struct rtc_timer *timer)
 	mutex_unlock(&rtc->ops_lock);
 }
 
+/**
+ * rtc_read_offset - Read the amount of rtc offset in parts per billion
+ * @ rtc: rtc device to be used
+ * @ offset: the offset in parts per billion
+ *
+ * see below for details.
+ *
+ * Kernel interface to read rtc clock offset
+ * Returns 0 on success, or a negative number on error.
+ * If the rtc offset is not setable (or not implemented), return 0 and put
+ * 0 in the offset value;
+ */
+int rtc_read_offset(struct rtc_device *rtc, long *offset)
+{
+	int ret = 0;
+
+	if (!rtc->ops)
+		return -ENODEV;
+
+	if (!rtc->ops->set_offset) {
+		*offset = 0;
+		return 0;
+	}
+
+	mutex_lock(&rtc->ops_lock);
+	ret = rtc->ops->read_offset(rtc->dev.parent, offset);
+	mutex_unlock(&rtc->ops_lock);
+	return ret;
+}
 
+/**
+ * rtc_set_offset - Adjusts the duration of the average second
+ * @ rtc: rtc device to be used
+ * @ offset: the offset in parts per billion
+ *
+ * Some rtc's allow an adjustment to the average duration of a second
+ * to compensate for differences in the actual clock rate due to temperature,
+ * the crystal, capacitor, etc.
+ *
+ * Kernel interface to adjust an rtc clock offset.
+ * Return 0 on success, or a negative number on error.
+ * If the rtc offset is not setable (or not implemented), return -EINVAL
+ */
+int rtc_set_offset(struct rtc_device *rtc, long offset)
+{
+	int ret = 0;
+
+	if (!rtc->ops)
+		return -ENODEV;
+
+	if (!rtc->ops->set_offset)
+		return -EINVAL;
+
+	mutex_lock(&rtc->ops_lock);
+	ret = rtc->ops->set_offset(rtc->dev.parent, offset);
+	mutex_unlock(&rtc->ops_lock);
+	return ret;
+}
include/linux/rtc.h +4 -0
index 3359f04..b693ada 100644
@@ -89,6 +89,8 @@ struct rtc_class_ops {
 	int (*set_mmss)(struct device *, unsigned long secs);
 	int (*read_callback)(struct device *, int data);
 	int (*alarm_irq_enable)(struct device *, unsigned int enabled);
+	int (*read_offset)(struct device *, long *offset);
+	int (*set_offset)(struct device *, long offset);
 };
 
 #define RTC_DEVICE_NAME_SIZE 20
@@ -208,6 +210,8 @@ void rtc_timer_init(struct rtc_timer *timer, void (*f)(void *p), void *data);
 int rtc_timer_start(struct rtc_device *rtc, struct rtc_timer *timer,
 		    ktime_t expires, ktime_t period);
 void rtc_timer_cancel(struct rtc_device *rtc, struct rtc_timer *timer);
+int rtc_read_offset(struct rtc_device *rtc, long *offset);
+int rtc_set_offset(struct rtc_device *rtc, long offset);
 void rtc_timer_do_work(struct work_struct *work);
 
 static inline bool is_leap_year(unsigned int year)
Signature · 12 lines
2.5.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#12 lore raw

PATCH v3 2/3 rtc: implement a sysfs interface for clock offset

clock offset may be set and read in decimal parts per billion attribute is /sys/class/rtc/rtcN/offset
The attribute is only visible for rtcs that have set_offset implemented.

---
 Documentation/rtc.txt   |  6 ++++++
 drivers/rtc/rtc-sysfs.c | 35 ++++++++++++++++++++++++++++++++++-
 2 files changed, 40 insertions(+), 1 deletion(-)
Documentation/rtc.txt +6 -0
index 8446f1e..ddc3660 100644
@@ -157,6 +157,12 @@ wakealarm:	 The time at which the clock will generate a system wakeup
 		 the epoch by default, or if there's a leading +, seconds in the
 		 future, or if there is a leading +=, seconds ahead of the current
 		 alarm.
+offset:		 The amount which the rtc clock has been adjusted in firmware.
+		 Visible only if the driver supports clock offset adjustment.
+		 The unit is parts per billion, i.e. The number of clock ticks
+		 which are added to or removed from the rtc's base clock per
+		 billion ticks. A positive value makes a day pass more slowly,
+		 longer, and a negative value makes a day pass more quickly.
 
 IOCTL INTERFACE
 ---------------
drivers/rtc/rtc-sysfs.c +34 -1
index 463e286..f8d7f8d 100644
@@ -218,6 +218,34 @@ wakealarm_store(struct device *dev, struct device_attribute *attr,
 }
 static DEVICE_ATTR_RW(wakealarm);
 
+static ssize_t
+offset_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	ssize_t retval;
+	long offset;
+
+	retval = rtc_read_offset(to_rtc_device(dev), &offset);
+	if (retval == 0)
+		retval = sprintf(buf, "%ld\n", offset);
+
+	return retval;
+}
+
+static ssize_t
+offset_store(struct device *dev, struct device_attribute *attr,
+		const char *buf, size_t n)
+{
+	ssize_t retval;
+	long offset;
+
+	retval = kstrtol(buf, 10, &offset);
+	if (retval == 0)
+		retval = rtc_set_offset(to_rtc_device(dev), offset);
+
+	return (retval < 0) ? retval : n;
+}
+static DEVICE_ATTR_RW(offset);
+
 static struct attribute *rtc_attrs[] = {
 	&dev_attr_name.attr,
 	&dev_attr_date.attr,
@@ -226,6 +254,7 @@ static struct attribute *rtc_attrs[] = {
 	&dev_attr_max_user_freq.attr,
 	&dev_attr_hctosys.attr,
 	&dev_attr_wakealarm.attr,
+	&dev_attr_offset.attr,
 	NULL,
 };
 
@@ -249,9 +278,13 @@ static umode_t rtc_attr_is_visible(struct kobject *kobj,
 	struct rtc_device *rtc = to_rtc_device(dev);
 	umode_t mode = attr->mode;
 
-	if (attr == &dev_attr_wakealarm.attr)
+	if (attr == &dev_attr_wakealarm.attr) {
 		if (!rtc_does_wakealarm(rtc))
 			mode = 0;
+	} else if (attr == &dev_attr_offset.attr) {
+		if (!rtc->ops->set_offset)
+			mode = 0;
+	}
 
 	return mode;
 }
Signature · 12 lines
2.5.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#13 lore raw

Re: [PATCH v3 2/3] rtc: implement a sysfs interface for clock offset

A really small nitpick below

Quoted 41 lines · Joshua Clayton

clock offset may be set and read in decimal parts per billion attribute is /sys/class/rtc/rtcN/offset
The attribute is only visible for rtcs that have set_offset implemented.

---
 Documentation/rtc.txt   |  6 ++++++
 drivers/rtc/rtc-sysfs.c | 35 ++++++++++++++++++++++++++++++++++-
 2 files changed, 40 insertions(+), 1 deletion(-)
Documentation/rtc.txt +6 -0
index 8446f1e..ddc3660 100644
@@ -157,6 +157,12 @@ wakealarm:	 The time at which the clock will generate a system wakeup
 		 the epoch by default, or if there's a leading +, seconds in the
 		 future, or if there is a leading +=, seconds ahead of the current
 		 alarm.
+offset:		 The amount which the rtc clock has been adjusted in firmware.
+		 Visible only if the driver supports clock offset adjustment.
+		 The unit is parts per billion, i.e. The number of clock ticks
+		 which are added to or removed from the rtc's base clock per
+		 billion ticks. A positive value makes a day pass more slowly,
+		 longer, and a negative value makes a day pass more quickly.
 
 IOCTL INTERFACE
 ---------------
drivers/rtc/rtc-sysfs.c +6 -0
index 463e286..f8d7f8d 100644
@@ -218,6 +218,34 @@ wakealarm_store(struct device *dev, struct device_attribute *attr,
 }
 static DEVICE_ATTR_RW(wakealarm);
 
+static ssize_t
+offset_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	ssize_t retval;
+	long offset;
+

drivers/rtc/rtc-sysfs.c wakealarm_store(struct device *dev, struct device_attribute *attr, · line 236

Quoted 10 lines
drivers/rtc/rtc-sysfs.c +10 -0
+	retval = rtc_read_offset(to_rtc_device(dev), &offset);
+	if (retval == 0)
+		retval = sprintf(buf, "%ld\n", offset);
+
+	return retval;
+}
+
+static ssize_t
+offset_store(struct device *dev, struct device_attribute *attr,
+		const char *buf, size_t n)

This is not properly aligned.

Quoted 41 lines
drivers/rtc/rtc-sysfs.c +18 -1
+{
+	ssize_t retval;
+	long offset;
+
+	retval = kstrtol(buf, 10, &offset);
+	if (retval == 0)
+		retval = rtc_set_offset(to_rtc_device(dev), offset);
+
+	return (retval < 0) ? retval : n;
+}
+static DEVICE_ATTR_RW(offset);
+
 static struct attribute *rtc_attrs[] = {
 	&dev_attr_name.attr,
 	&dev_attr_date.attr,
@@ -226,6 +254,7 @@ static struct attribute *rtc_attrs[] = {
 	&dev_attr_max_user_freq.attr,
 	&dev_attr_hctosys.attr,
 	&dev_attr_wakealarm.attr,
+	&dev_attr_offset.attr,
 	NULL,
 };
 
@@ -249,9 +278,13 @@ static umode_t rtc_attr_is_visible(struct kobject *kobj,
 	struct rtc_device *rtc = to_rtc_device(dev);
 	umode_t mode = attr->mode;
 
-	if (attr == &dev_attr_wakealarm.attr)
+	if (attr == &dev_attr_wakealarm.attr) {
 		if (!rtc_does_wakealarm(rtc))
 			mode = 0;
+	} else if (attr == &dev_attr_offset.attr) {
+		if (!rtc->ops->set_offset)
+			mode = 0;
+	}
 
 	return mode;
 }
Signature · 1 line
2.5.0
Signature · 14 lines
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#14 lore raw

PATCH v3 3/3 rtc-pcf2123: implement read_offset and set_offset

In reply to Joshua Clayton

pcf2123 has an offset register, which can be used to make minor adjustments to the clock rate to compensate for temperature or a crystal that is not exactly right.

---
 drivers/rtc/rtc-pcf2123.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 57 insertions(+)
drivers/rtc/rtc-pcf2123.c +57 -0
index d9a44ad..da27738 100644
@@ -100,6 +100,7 @@
 /* PCF2123_REG_OFFSET BITS */
 #define OFFSET_SIGN_BIT		BIT(6)	/* 2's complement sign bit */
 #define OFFSET_COARSE		BIT(7)	/* Coarse mode offset */
+#define OFFSET_STEP		(2170)	/* Offset step in parts per billion */
 
 /* READ/WRITE ADDRESS BITS */
 #define PCF2123_WRITE		BIT(4)
@@ -206,6 +207,59 @@ static ssize_t pcf2123_store(struct device *dev, struct device_attribute *attr,
 	return count;
 }
 
+static int pcf2123_read_offset(struct device *dev, long *offset)
+{
+	int ret;
+	s8 reg;
+
+	ret = pcf2123_read(dev, PCF2123_REG_OFFSET, &reg, 1);
+	if (ret < 0)
+		return ret;
+
+	if (reg & OFFSET_COARSE)
+		reg <<= 1; /* multiply by 2 and sign extend */
+	else
+		reg |= (reg & OFFSET_SIGN_BIT) << 1; /* sign extend only */
+
+	*offset = ((long)reg) * OFFSET_STEP;
+
+	return 0;
+}
+
+/*
+ * The offset register is a 7 bit signed value with a coarse bit in bit 7.
+ * The main difference between the two is normal offset adjusts the first
+ * second of n minutes every other hour, with 61, 62 and 63 being shoved
+ * into the 60th minute.
+ * The coarse adjustment does the same, but every hour.
+ * the two overlap, with every even normal offset value corresponding
+ * to a coarse offset. Based on this algorithm, it seems that despite the
+ * name, coarse offset is a better fit for overlapping values.
+ */
+static int pcf2123_set_offset(struct device *dev, long offset)
+{
+	s8 reg;
+
+	if (offset > OFFSET_STEP * 127)
+		reg = 127;
+	else if (offset < OFFSET_STEP * -128)
+		reg = -128;
+	else
+		reg = (s8)((offset + (OFFSET_STEP >> 1)) / OFFSET_STEP);
+
+	/* choose fine offset only for odd values in the normal range */
+	if (reg & 1 && reg <= 63 && reg >= -64) {
+		/* Normal offset. Clear the coarse bit */
+		reg &= ~OFFSET_COARSE;
+	} else {
+		/* Coarse offset. Divide by 2 and set the coarse bit */
+		reg >>= 1;
+		reg |= OFFSET_COARSE;
+	}
+
+	return pcf2123_write_reg(dev, PCF2123_REG_OFFSET, reg);
+}
+
 static int pcf2123_rtc_read_time(struct device *dev, struct rtc_time *tm)
 {
 	u8 rxbuf[7];
@@ -314,6 +368,9 @@ static int pcf2123_reset(struct device *dev)
 static const struct rtc_class_ops pcf2123_rtc_ops = {
 	.read_time	= pcf2123_rtc_read_time,
 	.set_time	= pcf2123_rtc_set_time,
+	.read_offset	= pcf2123_read_offset,
+	.set_offset	= pcf2123_set_offset,
+
 };
 
 static int pcf2123_probe(struct spi_device *spi)
Signature · 12 lines
2.5.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#15 lore raw

Re: [PATCH v3 1/3] rtc: Add functions to set and read rtc offset

In reply to Joshua Clayton

Hi,

Quoted 22 lines · Joshua Clayton
drivers/rtc/interface.c +14 -0
index 5836751..c064eb9 100644
@@ -939,4 +939,61 @@ void rtc_timer_cancel(struct rtc_device *rtc, struct rtc_timer *timer)
 	mutex_unlock(&rtc->ops_lock);
 }
 
+/**
+ * rtc_read_offset - Read the amount of rtc offset in parts per billion
+ * @ rtc: rtc device to be used
+ * @ offset: the offset in parts per billion
+ *
+ * see below for details.
+ *
+ * Kernel interface to read rtc clock offset
+ * Returns 0 on success, or a negative number on error.
+ * If the rtc offset is not setable (or not implemented), return 0 and put
+ * 0 in the offset value;
+ */
+int rtc_read_offset(struct rtc_device *rtc, long *offset)
+{

drivers/rtc/interface.c void rtc_timer_cancel(struct rtc_device *rtc, struct rtc_timer *timer) · line 965

Quoted 10 lines
drivers/rtc/interface.c +10 -0
+	int ret = 0;
+
+	if (!rtc->ops)
+		return -ENODEV;
+
+	if (!rtc->ops->set_offset) {
+		*offset = 0;
+		return 0;
+	}
+

I should have been clearer but this is not necessary anymore since the sysfs interface will not always be present but you
should probably test rtc->ops->read_offset instead.

Quoted 59 lines
drivers/rtc/interface.c +33 -0
+	mutex_lock(&rtc->ops_lock);
+	ret = rtc->ops->read_offset(rtc->dev.parent, offset);
+	mutex_unlock(&rtc->ops_lock);
+	return ret;
+}
 
+/**
+ * rtc_set_offset - Adjusts the duration of the average second
+ * @ rtc: rtc device to be used
+ * @ offset: the offset in parts per billion
+ *
+ * Some rtc's allow an adjustment to the average duration of a second
+ * to compensate for differences in the actual clock rate due to temperature,
+ * the crystal, capacitor, etc.
+ *
+ * Kernel interface to adjust an rtc clock offset.
+ * Return 0 on success, or a negative number on error.
+ * If the rtc offset is not setable (or not implemented), return -EINVAL
+ */
+int rtc_set_offset(struct rtc_device *rtc, long offset)
+{
+	int ret = 0;
+
+	if (!rtc->ops)
+		return -ENODEV;
+
+	if (!rtc->ops->set_offset)
+		return -EINVAL;
+
+	mutex_lock(&rtc->ops_lock);
+	ret = rtc->ops->set_offset(rtc->dev.parent, offset);
+	mutex_unlock(&rtc->ops_lock);
+	return ret;
+}
include/linux/rtc.h +4 -0
index 3359f04..b693ada 100644
@@ -89,6 +89,8 @@ struct rtc_class_ops {
 	int (*set_mmss)(struct device *, unsigned long secs);
 	int (*read_callback)(struct device *, int data);
 	int (*alarm_irq_enable)(struct device *, unsigned int enabled);
+	int (*read_offset)(struct device *, long *offset);
+	int (*set_offset)(struct device *, long offset);
 };
 
 #define RTC_DEVICE_NAME_SIZE 20
@@ -208,6 +210,8 @@ void rtc_timer_init(struct rtc_timer *timer, void (*f)(void *p), void *data);
 int rtc_timer_start(struct rtc_device *rtc, struct rtc_timer *timer,
 		    ktime_t expires, ktime_t period);
 void rtc_timer_cancel(struct rtc_device *rtc, struct rtc_timer *timer);
+int rtc_read_offset(struct rtc_device *rtc, long *offset);
+int rtc_set_offset(struct rtc_device *rtc, long offset);
 void rtc_timer_do_work(struct work_struct *work);
 
 static inline bool is_leap_year(unsigned int year)
Signature · 1 line
2.5.0
Signature · 14 lines
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#16 lore raw

Re: [PATCH v3 1/3] rtc: Add functions to set and read rtc offset

Quoted 33 lines · On Thu, 4 Feb 2016 23:07:54 +0100 Alexandre Belloni…

Hi,

Quoted 30 lines · Joshua Clayton
drivers/rtc/interface.c +2 -0
index 5836751..c064eb9 100644
@@ -939,4 +939,61 @@ void rtc_timer_cancel(struct rtc_device *rtc,
 struct rtc_timer *timer) mutex_unlock(&rtc->ops_lock);
 }
 
+/**
+ * rtc_read_offset - Read the amount of rtc offset in parts per

billion
+ * @ rtc: rtc device to be used
+ * @ offset: the offset in parts per billion
+ *
+ * see below for details.
+ *
+ * Kernel interface to read rtc clock offset
+ * Returns 0 on success, or a negative number on error.
+ * If the rtc offset is not setable (or not implemented), return 0 and put
+ * 0 in the offset value;
+ */

drivers/rtc/interface.c +8 -0
+int rtc_read_offset(struct rtc_device *rtc, long *offset)
+{
+	int ret = 0;
+
+	if (!rtc->ops)
+		return -ENODEV;
+
+	if (!rtc->ops->set_offset) {
Quoted 9 lines

drivers/rtc/interface.c void rtc_timer_cancel(struct rtc_device *rtc, struct rtc_timer *timer) · line 965

Quoted 4 lines
drivers/rtc/interface.c +4 -0
+		*offset = 0;
+		return 0;
+	}
+

I should have been clearer but this is not necessary anymore since the sysfs interface will not always be present but you
should probably test rtc->ops->read_offset instead.

I left it because the kernel API is still there even if the sysfs file is not...
but yeah, you are right. I'll fix the check, and the formatting in the other patch.

Quoted 64 lines
Quoted 63 lines
drivers/rtc/interface.c +11 -0
+	mutex_lock(&rtc->ops_lock);
+	ret = rtc->ops->read_offset(rtc->dev.parent, offset);
+	mutex_unlock(&rtc->ops_lock);
+	return ret;
+}
 
+/**
+ * rtc_set_offset - Adjusts the duration of the average second
+ * @ rtc: rtc device to be used
+ * @ offset: the offset in parts per billion
+ *
+ * Some rtc's allow an adjustment to the average duration of a

second
+ * to compensate for differences in the actual clock rate due to temperature,
+ * the crystal, capacitor, etc.
+ *
+ * Kernel interface to adjust an rtc clock offset.
+ * Return 0 on success, or a negative number on error.
+ * If the rtc offset is not setable (or not implemented), return

drivers/rtc/interface.c +16 -1
-EINVAL
+ */
+int rtc_set_offset(struct rtc_device *rtc, long offset)
+{
+	int ret = 0;
+
+	if (!rtc->ops)
+		return -ENODEV;
+
+	if (!rtc->ops->set_offset)
+		return -EINVAL;
+
+	mutex_lock(&rtc->ops_lock);
+	ret = rtc->ops->set_offset(rtc->dev.parent, offset);
+	mutex_unlock(&rtc->ops_lock);
+	return ret;
+}
include/linux/rtc.h +2 -0
index 3359f04..b693ada 100644
@@ -89,6 +89,8 @@ struct rtc_class_ops {
 	int (*set_mmss)(struct device *, unsigned long secs);
 	int (*read_callback)(struct device *, int data);
 	int (*alarm_irq_enable)(struct device *, unsigned int
 enabled);
+	int (*read_offset)(struct device *, long *offset);
+	int (*set_offset)(struct device *, long offset);
 };
 

#define RTC_DEVICE_NAME_SIZE 20

include/linux/rtc.h +0 -0
@@ -208,6 +210,8 @@ void rtc_timer_init(struct rtc_timer *timer,

void (*f)(void *p), void *data); int rtc_timer_start(struct rtc_device *rtc, struct rtc_timer *timer, ktime_t expires, ktime_t period); void rtc_timer_cancel(struct rtc_device *rtc, struct rtc_timer *timer); +int rtc_read_offset(struct rtc_device *rtc, long *offset); +int rtc_set_offset(struct rtc_device *rtc, long offset); void rtc_timer_do_work(struct work_struct *work);

static inline bool is_leap_year(unsigned int year)

Signature · 1 line
2.5.0
Signature · 9 lines
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#17 lore raw

Re: [PATCH v3 1/3] rtc: Add functions to set and read rtc offset

Quoted 17 lines · Joshua Clayton
Quoted 8 lines
Quoted 8 lines
drivers/rtc/interface.c +8 -0
+int rtc_read_offset(struct rtc_device *rtc, long *offset)
+{
+	int ret = 0;
+
+	if (!rtc->ops)
+		return -ENODEV;
+
+	if (!rtc->ops->set_offset) {
Quoted 9 lines

drivers/rtc/interface.c void rtc_timer_cancel(struct rtc_device *rtc, struct rtc_timer *timer) · line 965

Quoted 4 lines
drivers/rtc/interface.c +4 -0
+		*offset = 0;
+		return 0;
+	}
+

I should have been clearer but this is not necessary anymore since the sysfs interface will not always be present but you
should probably test rtc->ops->read_offset instead.

Quoted 5 lines

I left it because the kernel API is still there even if the sysfs file is not...
but yeah, you are right. I'll fix the check, and the formatting in the other patch.

Yeah but from inside the kernel, I feel that it is more useful to know that the value doesn't exist instead of having 0.

Signature · 14 lines
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#18 lore raw

PATCH v4 1/3 rtc: Add functions to set and read rtc offset

A number of rtc devices, such as the NXP pcf2123 include a facility to adjust the clock in order to compensate for temperature or a crystal, capacitor, etc, that results in the rtc clock not running at exactly 32.768 kHz.

Data sheets I have seen refer to this as a clock offset, and measure it in parts per million, however they often reference ppm to 2 digits of precision, which makes integer ppm less than ideal.

We use parts per billion, which more than covers the precision needed and works nicely within 32 bits

---
 drivers/rtc/interface.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/rtc.h     |  4 ++++
 2 files changed, 58 insertions(+)
drivers/rtc/interface.c +54 -0
index 5836751..9ef5f6f 100644
@@ -939,4 +939,58 @@ void rtc_timer_cancel(struct rtc_device *rtc, struct rtc_timer *timer)
 	mutex_unlock(&rtc->ops_lock);
 }
 
+/**
+ * rtc_read_offset - Read the amount of rtc offset in parts per billion
+ * @ rtc: rtc device to be used
+ * @ offset: the offset in parts per billion
+ *
+ * see below for details.
+ *
+ * Kernel interface to read rtc clock offset
+ * Returns 0 on success, or a negative number on error.
+ * If read_offset() is not implemented for the rtc, return -EINVAL
+ */
+int rtc_read_offset(struct rtc_device *rtc, long *offset)
+{
+	int ret;
+
+	if (!rtc->ops)
+		return -ENODEV;
+
+	if (!rtc->ops->read_offset)
+		return -EINVAL;
+
+	mutex_lock(&rtc->ops_lock);
+	ret = rtc->ops->read_offset(rtc->dev.parent, offset);
+	mutex_unlock(&rtc->ops_lock);
+	return ret;
+}
 
+/**
+ * rtc_set_offset - Adjusts the duration of the average second
+ * @ rtc: rtc device to be used
+ * @ offset: the offset in parts per billion
+ *
+ * Some rtc's allow an adjustment to the average duration of a second
+ * to compensate for differences in the actual clock rate due to temperature,
+ * the crystal, capacitor, etc.
+ *
+ * Kernel interface to adjust an rtc clock offset.
+ * Return 0 on success, or a negative number on error.
+ * If the rtc offset is not setable (or not implemented), return -EINVAL
+ */
+int rtc_set_offset(struct rtc_device *rtc, long offset)
+{
+	int ret;
+
+	if (!rtc->ops)
+		return -ENODEV;
+
+	if (!rtc->ops->set_offset)
+		return -EINVAL;
+
+	mutex_lock(&rtc->ops_lock);
+	ret = rtc->ops->set_offset(rtc->dev.parent, offset);
+	mutex_unlock(&rtc->ops_lock);
+	return ret;
+}
include/linux/rtc.h +4 -0
index 3359f04..b693ada 100644
@@ -89,6 +89,8 @@ struct rtc_class_ops {
 	int (*set_mmss)(struct device *, unsigned long secs);
 	int (*read_callback)(struct device *, int data);
 	int (*alarm_irq_enable)(struct device *, unsigned int enabled);
+	int (*read_offset)(struct device *, long *offset);
+	int (*set_offset)(struct device *, long offset);
 };
 
 #define RTC_DEVICE_NAME_SIZE 20
@@ -208,6 +210,8 @@ void rtc_timer_init(struct rtc_timer *timer, void (*f)(void *p), void *data);
 int rtc_timer_start(struct rtc_device *rtc, struct rtc_timer *timer,
 		    ktime_t expires, ktime_t period);
 void rtc_timer_cancel(struct rtc_device *rtc, struct rtc_timer *timer);
+int rtc_read_offset(struct rtc_device *rtc, long *offset);
+int rtc_set_offset(struct rtc_device *rtc, long offset);
 void rtc_timer_do_work(struct work_struct *work);
 
 static inline bool is_leap_year(unsigned int year)
Signature · 12 lines
2.5.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#19 lore raw

PATCH v4 2/3 rtc: implement a sysfs interface for clock offset

clock offset may be set and read in decimal parts per billion attribute is /sys/class/rtc/rtcN/offset
The attribute is only visible for rtcs that have set_offset implemented.

---
 Documentation/rtc.txt   |  6 ++++++
 drivers/rtc/rtc-sysfs.c | 35 ++++++++++++++++++++++++++++++++++-
 2 files changed, 40 insertions(+), 1 deletion(-)
Documentation/rtc.txt +6 -0
index 8446f1e..ddc3660 100644
@@ -157,6 +157,12 @@ wakealarm:	 The time at which the clock will generate a system wakeup
 		 the epoch by default, or if there's a leading +, seconds in the
 		 future, or if there is a leading +=, seconds ahead of the current
 		 alarm.
+offset:		 The amount which the rtc clock has been adjusted in firmware.
+		 Visible only if the driver supports clock offset adjustment.
+		 The unit is parts per billion, i.e. The number of clock ticks
+		 which are added to or removed from the rtc's base clock per
+		 billion ticks. A positive value makes a day pass more slowly,
+		 longer, and a negative value makes a day pass more quickly.
 
 IOCTL INTERFACE
 ---------------
drivers/rtc/rtc-sysfs.c +34 -1
index 463e286..63b9fb1 100644
@@ -218,6 +218,34 @@ wakealarm_store(struct device *dev, struct device_attribute *attr,
 }
 static DEVICE_ATTR_RW(wakealarm);
 
+static ssize_t
+offset_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	ssize_t retval;
+	long offset;
+
+	retval = rtc_read_offset(to_rtc_device(dev), &offset);
+	if (retval == 0)
+		retval = sprintf(buf, "%ld\n", offset);
+
+	return retval;
+}
+
+static ssize_t
+offset_store(struct device *dev, struct device_attribute *attr,
+	     const char *buf, size_t n)
+{
+	ssize_t retval;
+	long offset;
+
+	retval = kstrtol(buf, 10, &offset);
+	if (retval == 0)
+		retval = rtc_set_offset(to_rtc_device(dev), offset);
+
+	return (retval < 0) ? retval : n;
+}
+static DEVICE_ATTR_RW(offset);
+
 static struct attribute *rtc_attrs[] = {
 	&dev_attr_name.attr,
 	&dev_attr_date.attr,
@@ -226,6 +254,7 @@ static struct attribute *rtc_attrs[] = {
 	&dev_attr_max_user_freq.attr,
 	&dev_attr_hctosys.attr,
 	&dev_attr_wakealarm.attr,
+	&dev_attr_offset.attr,
 	NULL,
 };
 
@@ -249,9 +278,13 @@ static umode_t rtc_attr_is_visible(struct kobject *kobj,
 	struct rtc_device *rtc = to_rtc_device(dev);
 	umode_t mode = attr->mode;
 
-	if (attr == &dev_attr_wakealarm.attr)
+	if (attr == &dev_attr_wakealarm.attr) {
 		if (!rtc_does_wakealarm(rtc))
 			mode = 0;
+	} else if (attr == &dev_attr_offset.attr) {
+		if (!rtc->ops->set_offset)
+			mode = 0;
+	}
 
 	return mode;
 }
Signature · 12 lines
2.5.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#20 lore raw

PATCH v4 3/3 rtc-pcf2123: implement read_offset and set_offset

In reply to Joshua Clayton

pcf2123 has an offset register, which can be used to make minor adjustments to the clock rate to compensate for temperature or a crystal that is not exactly right.

---
 drivers/rtc/rtc-pcf2123.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 57 insertions(+)
drivers/rtc/rtc-pcf2123.c +57 -0
index d9a44ad..da27738 100644
@@ -100,6 +100,7 @@
 /* PCF2123_REG_OFFSET BITS */
 #define OFFSET_SIGN_BIT		BIT(6)	/* 2's complement sign bit */
 #define OFFSET_COARSE		BIT(7)	/* Coarse mode offset */
+#define OFFSET_STEP		(2170)	/* Offset step in parts per billion */
 
 /* READ/WRITE ADDRESS BITS */
 #define PCF2123_WRITE		BIT(4)
@@ -206,6 +207,59 @@ static ssize_t pcf2123_store(struct device *dev, struct device_attribute *attr,
 	return count;
 }
 
+static int pcf2123_read_offset(struct device *dev, long *offset)
+{
+	int ret;
+	s8 reg;
+
+	ret = pcf2123_read(dev, PCF2123_REG_OFFSET, &reg, 1);
+	if (ret < 0)
+		return ret;
+
+	if (reg & OFFSET_COARSE)
+		reg <<= 1; /* multiply by 2 and sign extend */
+	else
+		reg |= (reg & OFFSET_SIGN_BIT) << 1; /* sign extend only */
+
+	*offset = ((long)reg) * OFFSET_STEP;
+
+	return 0;
+}
+
+/*
+ * The offset register is a 7 bit signed value with a coarse bit in bit 7.
+ * The main difference between the two is normal offset adjusts the first
+ * second of n minutes every other hour, with 61, 62 and 63 being shoved
+ * into the 60th minute.
+ * The coarse adjustment does the same, but every hour.
+ * the two overlap, with every even normal offset value corresponding
+ * to a coarse offset. Based on this algorithm, it seems that despite the
+ * name, coarse offset is a better fit for overlapping values.
+ */
+static int pcf2123_set_offset(struct device *dev, long offset)
+{
+	s8 reg;
+
+	if (offset > OFFSET_STEP * 127)
+		reg = 127;
+	else if (offset < OFFSET_STEP * -128)
+		reg = -128;
+	else
+		reg = (s8)((offset + (OFFSET_STEP >> 1)) / OFFSET_STEP);
+
+	/* choose fine offset only for odd values in the normal range */
+	if (reg & 1 && reg <= 63 && reg >= -64) {
+		/* Normal offset. Clear the coarse bit */
+		reg &= ~OFFSET_COARSE;
+	} else {
+		/* Coarse offset. Divide by 2 and set the coarse bit */
+		reg >>= 1;
+		reg |= OFFSET_COARSE;
+	}
+
+	return pcf2123_write_reg(dev, PCF2123_REG_OFFSET, reg);
+}
+
 static int pcf2123_rtc_read_time(struct device *dev, struct rtc_time *tm)
 {
 	u8 rxbuf[7];
@@ -314,6 +368,9 @@ static int pcf2123_reset(struct device *dev)
 static const struct rtc_class_ops pcf2123_rtc_ops = {
 	.read_time	= pcf2123_rtc_read_time,
 	.set_time	= pcf2123_rtc_set_time,
+	.read_offset	= pcf2123_read_offset,
+	.set_offset	= pcf2123_set_offset,
+
 };
 
 static int pcf2123_probe(struct spi_device *spi)
Signature · 12 lines
2.5.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#21 lore raw

Re: [PATCH v4 1/3] rtc: Add functions to set and read rtc offset

In reply to Joshua Clayton

On Fri, 5 Feb 2016 12:41:11 -0800
Joshua Clayton <[email protected]> wrote:

Alexandre,
in case you didn't see, I made the change you requested. The rtc_read_offset function checks for a read_offset function and returns -EINVAL if not there, instead of an offset of 0. I just didn't put together a cover letter this time around.

Quoted 106 lines

A number of rtc devices, such as the NXP pcf2123 include a facility to adjust the clock in order to compensate for temperature or a crystal, capacitor, etc, that results in the rtc clock not running at exactly 32.768 kHz.

Data sheets I have seen refer to this as a clock offset, and measure it in parts per million, however they often reference ppm to 2 digits of precision, which makes integer ppm less than ideal.

We use parts per billion, which more than covers the precision needed and works nicely within 32 bits

---
 drivers/rtc/interface.c | 54

+++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/rtc.h | 4 ++++ 2 files changed, 58 insertions(+)

drivers/rtc/interface.c +0 -0
index 5836751..9ef5f6f 100644
@@ -939,4 +939,58 @@ void

rtc_t4e40602412d61b7ef4162621a1a15be32126baeeimer_cancel(struct rtc_device *rtc, struct rtc_timer *timer) mutex_unlock(&rtc->ops_lock); }
+/**
+ * rtc_read_offset - Read the amount of rtc offset in parts per billion
+ * @ rtc: rtc device to be used
+ * @ offset: the offset in parts per billion
+ *
+ * see below for details.
+ *
+ * Kernel interface to read rtc clock offset
+ * Returns 0 on success, or a negative number on error.
+ * If read_offset() is not implemented for the rtc, return -EINVAL
+ */

drivers/rtc/interface.c +22 -0
+int rtc_read_offset(struct rtc_device *rtc, long *offset)
+{
+	int ret;
+
+	if (!rtc->ops)
+		return -ENODEV;
+
+	if (!rtc->ops->read_offset)
+		return -EINVAL;
+
+	mutex_lock(&rtc->ops_lock);
+	ret = rtc->ops->read_offset(rtc->dev.parent, offset);
+	mutex_unlock(&rtc->ops_lock);
+	return ret;
+}
 
+/**
+ * rtc_set_offset - Adjusts the duration of the average second
+ * @ rtc: rtc device to be used
+ * @ offset: the offset in parts per billion
+ *
+ * Some rtc's allow an adjustment to the average duration of a second
+ * to compensate for differences in the actual clock rate due to

temperature,
+ * the crystal, capacitor, etc.
+ *
+ * Kernel interface to adjust an rtc clock offset.
+ * Return 0 on success, or a negative number on error.
+ * If the rtc offset is not setable (or not implemented), return

drivers/rtc/interface.c +16 -1
-EINVAL
+ */
+int rtc_set_offset(struct rtc_device *rtc, long offset)
+{
+	int ret;
+
+	if (!rtc->ops)
+		return -ENODEV;
+
+	if (!rtc->ops->set_offset)
+		return -EINVAL;
+
+	mutex_lock(&rtc->ops_lock);
+	ret = rtc->ops->set_offset(rtc->dev.parent, offset);
+	mutex_unlock(&rtc->ops_lock);
+	return ret;
+}
include/linux/rtc.h +2 -0
index 3359f04..b693ada 100644
@@ -89,6 +89,8 @@ struct rtc_class_ops {
 	int (*set_mmss)(struct device *, unsigned long secs);
 	int (*read_callback)(struct device *, int data);
 	int (*alarm_irq_enable)(struct device *, unsigned int
 enabled);
+	int (*read_offset)(struct device *, long *offset);
+	int (*set_offset)(struct device *, long offset);
 };
 

#define RTC_DEVICE_NAME_SIZE 20

include/linux/rtc.h +0 -0
@@ -208,6 +210,8 @@ void rtc_timer_init(struct rtc_timer *timer, void

(*f)(void *p), void *data); int rtc_timer_start(struct rtc_device *rtc, struct rtc_timer *timer, ktime_t expires, ktime_t period);
void rtc_timer_cancel(struct rtc_device *rtc, struct rtc_timer
*timer); +int rtc_read_offset(struct rtc_device *rtc, long *offset); +int rtc_set_offset(struct rtc_device *rtc, long offset);
void rtc_timer_do_work(struct work_struct *work);

Quoted 1 line

static inline bool is_leap_year(unsigned int year)

Thanks,

Joshua

Signature · 9 lines
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#22 lore raw

Re: [PATCH v4 1/3] rtc: Add functions to set and read rtc offset

Hi,

Quoted 9 lines · Joshua Clayton

On Fri, 5 Feb 2016 12:41:11 -0800
Joshua Clayton <[email protected]> wrote:

Alexandre,
in case you didn't see, I made the change you requested. The rtc_read_offset function checks for a read_offset function and returns -EINVAL if not there, instead of an offset of 0. I just didn't put together a cover letter this time around.

Sure, I was planning to review them tonight anyway.

All applied, thanks!

Signature · 14 lines
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#23 lore raw

PATCH v2 8/8 rtc-pcf2123: implement read_offset and set_offset

In reply to Joshua Clayton

pcf2123 has an offset register, which can be used to make minor adjustments to the clock rate to compensate for temperature or a crystal that is not exactly right.

Expose the offset register to sysfs

---
 drivers/rtc/rtc-pcf2123.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 57 insertions(+)
drivers/rtc/rtc-pcf2123.c +57 -0
index d9a44ad..da27738 100644
@@ -100,6 +100,7 @@
 /* PCF2123_REG_OFFSET BITS */
 #define OFFSET_SIGN_BIT		BIT(6)	/* 2's complement sign bit */
 #define OFFSET_COARSE		BIT(7)	/* Coarse mode offset */
+#define OFFSET_STEP		(2170)	/* Offset step in parts per billion */
 
 /* READ/WRITE ADDRESS BITS */
 #define PCF2123_WRITE		BIT(4)
@@ -206,6 +207,59 @@ static ssize_t pcf2123_store(struct device *dev, struct device_attribute *attr,
 	return count;
 }
 
+static int pcf2123_read_offset(struct device *dev, long *offset)
+{
+	int ret;
+	s8 reg;
+
+	ret = pcf2123_read(dev, PCF2123_REG_OFFSET, &reg, 1);
+	if (ret < 0)
+		return ret;
+
+	if (reg & OFFSET_COARSE)
+		reg <<= 1; /* multiply by 2 and sign extend */
+	else
+		reg |= (reg & OFFSET_SIGN_BIT) << 1; /* sign extend only */
+
+	*offset = ((long)reg) * OFFSET_STEP;
+
+	return 0;
+}
+
+/*
+ * The offset register is a 7 bit signed value with a coarse bit in bit 7.
+ * The main difference between the two is normal offset adjusts the first
+ * second of n minutes every other hour, with 61, 62 and 63 being shoved
+ * into the 60th minute.
+ * The coarse adjustment does the same, but every hour.
+ * the two overlap, with every even normal offset value corresponding
+ * to a coarse offset. Based on this algorithm, it seems that despite the
+ * name, coarse offset is a better fit for overlapping values.
+ */
+static int pcf2123_set_offset(struct device *dev, long offset)
+{
+	s8 reg;
+
+	if (offset > OFFSET_STEP * 127)
+		reg = 127;
+	else if (offset < OFFSET_STEP * -128)
+		reg = -128;
+	else
+		reg = (s8)((offset + (OFFSET_STEP >> 1)) / OFFSET_STEP);
+
+	/* choose fine offset only for odd values in the normal range */
+	if (reg & 1 && reg <= 63 && reg >= -64) {
+		/* Normal offset. Clear the coarse bit */
+		reg &= ~OFFSET_COARSE;
+	} else {
+		/* Coarse offset. Divide by 2 and set the coarse bit */
+		reg >>= 1;
+		reg |= OFFSET_COARSE;
+	}
+
+	return pcf2123_write_reg(dev, PCF2123_REG_OFFSET, reg);
+}
+
 static int pcf2123_rtc_read_time(struct device *dev, struct rtc_time *tm)
 {
 	u8 rxbuf[7];
@@ -314,6 +368,9 @@ static int pcf2123_reset(struct device *dev)
 static const struct rtc_class_ops pcf2123_rtc_ops = {
 	.read_time	= pcf2123_rtc_read_time,
 	.set_time	= pcf2123_rtc_set_time,
+	.read_offset	= pcf2123_read_offset,
+	.set_offset	= pcf2123_set_offset,
+
 };
 
 static int pcf2123_probe(struct spi_device *spi)
Signature · 12 lines
2.5.0

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#24 lore raw
In reply to Joshua Clayton

Ping?

Quoted 9 lines · Joshua Clayton

Alexandre,
this is the second version of apatch set to be able to adjust the clock on a pcf2123, but with a big addition. I am also proposing a couple of new rtc api functions and a new sysfs file.

Patches 1-5 are very much v2 patches that address All of the concerns you had with v1. It is my hope to get them merged without too much more trouble.

The rtc _needs_ patches 1-5 in order to use the clock offset adjustment at all (current upstream code resets it to zero during device probe, so it doesn't survive a reboot)
Should I split out patches 1-5 to make them easier to review?

Quoted 4 lines

Patches 6-8 are attemping to add a new function to the rtc class to adjust the clock rate. I hope I am going about this the right way, But here goes.

I am hoping to have some discussion about 6, 7 and 8. Particularly whether parts per billion is the right unit (I think it is) and whether "offset" is the best name for the attribute (not as sure).

Quoted 42 lines

A number of rtc devices, such as the NXP pcf2123 include a facility to adjust the clock in order to compensate for temperature or a crystal, capacitor, etc, that results in the rtc clock not running at exactly 32.768 kHz.

This patchset adds kernel and sysfs hooks to access that ability.

One datasheet suggests it might be adjusted based on input from a temperature sensor. I could also potentially see it being set as part of ntp calibration.

Data sheets I have seen refer to this as a clock offset, and measure it in parts per million (ppm), however they often reference ppm to 2 digits of precision, which makes integer ppm less than ideal. I use parts per billion, which more than covers the precision needed and works nicely within 32 bits

The name "offset" came from the pcf-2123 datasheet and is used by at least some other data sheets. I would be happy to use a different term if someone else comes up with something more concise.

Changes since v1:
- Use the BIT() macro for all register bits
- Remove unneeded range checks from read/write functions
- Merge patch 3 (replace magic numbers with defines) into patch 2
- Add a proper commit message to patch 5, now patch 4
- Fix a function alignment bug.
- Move OSC_HAS_STOPPED check into pcf2123_rtc_read_time, and get rid of pcf2123_time_valid()
- Drop patches refactoring pcf2123 sysfs.
- Add rtc interface and rtc sysfs file for clock offset

Joshua Clayton (8):
rtc-pcf2123: define registers and bit macros
rtc-pcf2123: clean up reads from the chip
rtc-pcf2123: clean up writes to the rtc chip
rtc-pcf2123: refactor chip reset into a function
rtc-pcf2123: avoid resetting the clock if possible
rtc: Add functions to set and read clock offset
rtc: implement a sysfs interface for clock offset
rtc-pcf2123: implement read_offset and set_offset

Quoted 7 lines
 drivers/rtc/interface.c   |  57 ++++++++++
 drivers/rtc/rtc-pcf2123.c | 271 +++++++++++++++++++++++++++++++++-------------
 drivers/rtc/rtc-sysfs.c   |  29 +++++
 include/linux/rtc.h       |   4 +
 4 files changed, 284 insertions(+), 77 deletions(-)

Thanks again,
Joshua Clayton

Signature · 9 lines
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#25 lore raw
Quoted 8 lines · Joshua Clayton

Ping?

Quoted 5 lines · Joshua Clayton

Alexandre,
this is the second version of apatch set to be able to adjust the clock on a pcf2123, but with a big addition. I am also proposing a couple of new rtc api functions and a new sysfs file.

Quoted 9 lines
Quoted 4 lines

Patches 1-5 are very much v2 patches that address All of the concerns you had with v1. It is my hope to get them merged without too much more trouble.

The rtc _needs_ patches 1-5 in order to use the clock offset adjustment at all (current upstream code resets it to zero during device probe, so it doesn't survive a reboot)
Should I split out patches 1-5 to make them easier to review?

The merge widows just closed so I've started to collect a few patches since monday. This is a big series and I didn't have time to review everything yet.

Quoted 8 lines
Quoted 4 lines

Patches 6-8 are attemping to add a new function to the rtc class to adjust the clock rate. I hope I am going about this the right way, But here goes.

I am hoping to have some discussion about 6, 7 and 8. Particularly whether parts per billion is the right unit (I think it is) and whether "offset" is the best name for the attribute (not as sure).

Yeah, My plan was to take 1 to 5 and leave out 6-8 for discussion, I'm not yet sure what the correct api should look like.

Quoted 51 lines
Quoted 42 lines

A number of rtc devices, such as the NXP pcf2123 include a facility to adjust the clock in order to compensate for temperature or a crystal, capacitor, etc, that results in the rtc clock not running at exactly 32.768 kHz.

This patchset adds kernel and sysfs hooks to access that ability.

One datasheet suggests it might be adjusted based on input from a temperature sensor. I could also potentially see it being set as part of ntp calibration.

Data sheets I have seen refer to this as a clock offset, and measure it in parts per million (ppm), however they often reference ppm to 2 digits of precision, which makes integer ppm less than ideal. I use parts per billion, which more than covers the precision needed and works nicely within 32 bits

The name "offset" came from the pcf-2123 datasheet and is used by at least some other data sheets. I would be happy to use a different term if someone else comes up with something more concise.

Changes since v1:
- Use the BIT() macro for all register bits
- Remove unneeded range checks from read/write functions
- Merge patch 3 (replace magic numbers with defines) into patch 2
- Add a proper commit message to patch 5, now patch 4
- Fix a function alignment bug.
- Move OSC_HAS_STOPPED check into pcf2123_rtc_read_time, and get rid of pcf2123_time_valid()
- Drop patches refactoring pcf2123 sysfs.
- Add rtc interface and rtc sysfs file for clock offset

Joshua Clayton (8):
rtc-pcf2123: define registers and bit macros
rtc-pcf2123: clean up reads from the chip
rtc-pcf2123: clean up writes to the rtc chip
rtc-pcf2123: refactor chip reset into a function
rtc-pcf2123: avoid resetting the clock if possible
rtc: Add functions to set and read clock offset
rtc: implement a sysfs interface for clock offset
rtc-pcf2123: implement read_offset and set_offset

Quoted 7 lines
 drivers/rtc/interface.c   |  57 ++++++++++
 drivers/rtc/rtc-pcf2123.c | 271 +++++++++++++++++++++++++++++++++-------------
 drivers/rtc/rtc-sysfs.c   |  29 +++++
 include/linux/rtc.h       |   4 +
 4 files changed, 284 insertions(+), 77 deletions(-)

Thanks again,
Joshua Clayton

Signature · 14 lines
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
#26 lore raw

Hi,

Quoted 19 lines · Alexandre Belloni
Quoted 8 lines · Joshua Clayton

Ping?

Quoted 5 lines · Joshua Clayton

Alexandre,
this is the second version of apatch set to be able to adjust the clock on a pcf2123, but with a big addition. I am also proposing a couple of new rtc api functions and a new sysfs file.

Quoted 9 lines
Quoted 4 lines

Patches 1-5 are very much v2 patches that address All of the concerns you had with v1. It is my hope to get them merged without too much more trouble.

The rtc _needs_ patches 1-5 in order to use the clock offset adjustment at all (current upstream code resets it to zero during device probe, so it doesn't survive a reboot)
Should I split out patches 1-5 to make them easier to review?

Quoted 4 lines

The merge widows just closed so I've started to collect a few patches since monday. This is a big series and I didn't have time to review everything yet.

Patches 1-5 are applied and pushed to rtc-next.

Signature · 14 lines
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.

A message that is not in the archive (sent off-list or not yet received): 0000-cover-letter.patch

#28 lore raw

PATCH v6 1/8 eal: pci: add api to rd/wr pci bar region

Introducing below api for pci bar region rd/wr.
Api's are:
- rte_eal_pci_read_bar
- rte_eal_pci_write_bar

---
v5-->v6:
- update api infor in rte_eal_version.map file
suggested by david manchand.

 lib/librte_eal/bsdapp/eal/eal_pci.c             |   19 ++++++++++++
 lib/librte_eal/bsdapp/eal/rte_eal_version.map   |    3 ++
 lib/librte_eal/common/include/rte_pci.h         |   38 +++++++++++++++++++++++
 lib/librte_eal/linuxapp/eal/eal_pci.c           |   34 ++++++++++++++++++++
 lib/librte_eal/linuxapp/eal/eal_pci_init.h      |    6 ++++
 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c      |   28 +++++++++++++++++
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |    3 ++
 7 files changed, 131 insertions(+)
lib/librte_eal/bsdapp/eal/eal_pci.c +19 -0
index 95c32c1..2e535ea 100644
@@ -479,6 +479,25 @@ int rte_eal_pci_write_config(const struct rte_pci_device *dev,
 	return -1;
 }
 
+int rte_eal_pci_read_bar(const struct rte_pci_device *device __rte_unused,
+			 void *buf __rte_unused, size_t len __rte_unused,
+			 off_t offset __rte_unused,
+			 int bar_idx __rte_unused)
+
+{
+	/* NA */
+	return 1;
+}
+
+int rte_eal_pci_write_bar(const struct rte_pci_device *device __rte_unused,
+			  const void *buf __rte_unused, size_t len __rte_unused,
+			  off_t offset __rte_unused,
+			  int bar_idx __rte_unused)
+{
+	/* NA */
+	return 1;
+}
+
 /* Init the PCI EAL subsystem */
 int
 rte_eal_pci_init(void)
lib/librte_eal/bsdapp/eal/rte_eal_version.map +3 -0
index 1b28170..7c7dcf0 100644
@@ -141,4 +141,7 @@ DPDK_2.3 {
 
 	rte_eal_pci_map_device;
 	rte_eal_pci_unmap_device;
+	rte_eal_pci_read_bar;
+	rte_eal_pci_write_bar;
+
 } DPDK_2.2;
lib/librte_eal/common/include/rte_pci.h +38 -0
index 2224109..0c667ff 100644
@@ -471,6 +471,44 @@ int rte_eal_pci_read_config(const struct rte_pci_device *device,
 			    void *buf, size_t len, off_t offset);
 
 /**
+ * Read PCI bar space.
+ *
+ * @param device
+ *   A pointer to a rte_pci_device structure describing the device
+ *   to use
+ * @param buf
+ *   A data buffer where the bytes should be read into
+ * @param len
+ *   The length of the data buffer.
+ * @param offset
+ *   The offset into PCI bar space
+ * @param bar_idx
+ *   The pci bar index (valid range is 0..5)
+ */
+int rte_eal_pci_read_bar(const struct rte_pci_device *device,
+			 void *buf, size_t len, off_t offset, int bar_idx);
+
+/**
+ * Write PCI bar space.
+ *
+ * @param device
+ *   A pointer to a rte_pci_device structure describing the device
+ *   to use
+ * @param buf
+ *   A data buffer containing the bytes should be written
+ * @param len
+ *   The length of the data buffer.
+ * @param offset
+ *   The offset into PCI config space
+ * @param bar_idx
+ *   The pci bar index (valid range is 0..5)
+*/
+int rte_eal_pci_write_bar(const struct rte_pci_device *device,
+			  const void *buf, size_t len, off_t offset,
+			  int bar_idx);
+
+
+/**
  * Write PCI config space.
  *
  * @param device
lib/librte_eal/linuxapp/eal/eal_pci.c +34 -0
index db947da..eb503f0 100644
@@ -621,6 +621,40 @@ int rte_eal_pci_write_config(const struct rte_pci_device *device,
 	}
 }
 
+int rte_eal_pci_read_bar(const struct rte_pci_device *device,
+			 void *buf, size_t len, off_t offset,
+			 int bar_idx)
+
+{
+	const struct rte_intr_handle *intr_handle = &device->intr_handle;
+
+	switch (device->kdrv) {
+	case RTE_KDRV_VFIO:
+		return pci_vfio_read_bar(intr_handle, buf, len,
+					 offset, bar_idx);
+	default:
+		RTE_LOG(ERR, EAL, "write bar not supported by driver\n");
+		return -1;
+	}
+}
+
+int rte_eal_pci_write_bar(const struct rte_pci_device *device,
+			  const void *buf, size_t len, off_t offset,
+			  int bar_idx)
+{
+
+	const struct rte_intr_handle *intr_handle = &device->intr_handle;
+
+	switch (device->kdrv) {
+	case RTE_KDRV_VFIO:
+		return pci_vfio_write_bar(intr_handle, buf, len,
+					  offset, bar_idx);
+	default:
+		RTE_LOG(ERR, EAL, "write bar not supported by driver\n");
+		return -1;
+	}
+}
+
 /* Init the PCI EAL subsystem */
 int
 rte_eal_pci_init(void)
lib/librte_eal/linuxapp/eal/eal_pci_init.h +6 -0
index a17c708..3bc592b 100644
@@ -68,6 +68,12 @@ int pci_vfio_read_config(const struct rte_intr_handle *intr_handle,
 int pci_vfio_write_config(const struct rte_intr_handle *intr_handle,
 			  const void *buf, size_t len, off_t offs);
 
+int pci_vfio_read_bar(const struct rte_intr_handle *intr_handle,
+		      void *buf, size_t len, off_t offs, int bar_idx);
+
+int pci_vfio_write_bar(const struct rte_intr_handle *intr_handle,
+		       const void *buf, size_t len, off_t offs, int bar_idx);
+
 /* map VFIO resource prototype */
 int pci_vfio_map_resource(struct rte_pci_device *dev);
 int pci_vfio_get_group_fd(int iommu_group_fd);
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c +28 -0
index a6c7e16..34c4558 100644
@@ -156,6 +156,34 @@ pci_vfio_write_config(const struct rte_intr_handle *intr_handle,
 	       VFIO_GET_REGION_ADDR(VFIO_PCI_CONFIG_REGION_INDEX) + offs);
 }
 
+int
+pci_vfio_read_bar(const struct rte_intr_handle *intr_handle,
+		  void *buf, size_t len, off_t offs, int bar_idx)
+{
+	if (bar_idx < VFIO_PCI_BAR0_REGION_INDEX
+	   || bar_idx > VFIO_PCI_BAR5_REGION_INDEX) {
+		RTE_LOG(ERR, EAL, "invalid bar_idx!\n");
+		return -1;
+	}
+
+	return pread64(intr_handle->vfio_dev_fd, buf, len,
+		       VFIO_GET_REGION_ADDR(bar_idx) + offs);
+}
+
+int
+pci_vfio_write_bar(const struct rte_intr_handle *intr_handle,
+		   const void *buf, size_t len, off_t offs, int bar_idx)
+{
+	if (bar_idx < VFIO_PCI_BAR0_REGION_INDEX
+	   || bar_idx > VFIO_PCI_BAR5_REGION_INDEX) {
+		RTE_LOG(ERR, EAL, "invalid bar_idx!\n");
+		return -1;
+	}
+
+	return pwrite64(intr_handle->vfio_dev_fd, buf, len,
+			VFIO_GET_REGION_ADDR(bar_idx) + offs);
+}
+
 /* get PCI BAR number where MSI-X interrupts are */
 static int
 pci_vfio_get_msix_bar(int fd, int *msix_bar, uint32_t *msix_table_offset,
lib/librte_eal/linuxapp/eal/rte_eal_version.map +3 -0
index b9937c4..371b6c1 100644
@@ -144,4 +144,7 @@ DPDK_2.3 {
 
 	rte_eal_pci_map_device;
 	rte_eal_pci_unmap_device;
+	rte_eal_pci_read_bar;
+	rte_eal_pci_write_bar;
+
 } DPDK_2.2;
Signature · 1 line
1.7.9.5
#29 lore raw

PATCH v6 2/8 linuxapp/vfio: ignore mapping for ioport region

vfio_pci_mmap() try to map all pci bars. ioport region are not mapped in vfio/kernel so ignore mmaping for ioport.

---
 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c +20 -0
index 34c4558..b704ffd 100644
@@ -687,6 +687,7 @@ pci_vfio_map_resource(struct rte_pci_device *dev)
 	struct pci_map *maps;
 	uint32_t msix_table_offset = 0;
 	uint32_t msix_table_size = 0;
+	uint32_t ioport_bar;
 
 	dev->intr_handle.fd = -1;
 	dev->intr_handle.type = RTE_INTR_HANDLE_UNKNOWN;
@@ -881,6 +882,25 @@ pci_vfio_map_resource(struct rte_pci_device *dev)
 			return -1;
 		}
 
+		/* chk for io port region */
+		ret = pread64(vfio_dev_fd, &ioport_bar, sizeof(ioport_bar),
+			      VFIO_GET_REGION_ADDR(VFIO_PCI_CONFIG_REGION_INDEX)
+			      + PCI_BASE_ADDRESS_0 + i*4);
+
+		if (ret != sizeof(ioport_bar)) {
+			RTE_LOG(ERR, EAL,
+				"Cannot read command (%x) from config space!\n",
+				PCI_BASE_ADDRESS_0 + i*4);
+			return -1;
+		}
+
+		if (ioport_bar & PCI_BASE_ADDRESS_SPACE_IO) {
+			RTE_LOG(INFO, EAL,
+				"Ignore mapping IO port bar(%d) addr: %x\n",
+				 i, ioport_bar);
+			continue;
+		}
+
 		/* skip non-mmapable BARs */
 		if ((reg.flags & VFIO_REGION_INFO_FLAG_MMAP) == 0)
 			continue;
Signature · 1 line
1.7.9.5
#30 lore raw

PATCH v6 3/8 eal/linux: never check iopl for arm

In reply to Santosh Shukla

iopl() syscall not supported in linux-arm/arm64 so always return 0 value.

---
 lib/librte_eal/linuxapp/eal/eal.c |    2 ++
 1 file changed, 2 insertions(+)
lib/librte_eal/linuxapp/eal/eal.c +2 -0
index 635ec36..a2a3485 100644
@@ -715,6 +715,8 @@ rte_eal_iopl_init(void)
 	if (iopl(3) != 0)
 		return -1;
 	return 0;
+#elif defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
+	return 0; /* iopl syscall not supported for ARM/ARM64 */
 #else
 	return -1;
 #endif
Signature · 1 line
1.7.9.5
#31 lore raw

PATCH v6 4/8 virtio: Introduce config RTE_VIRTIO_INC_VECTOR

In reply to Santosh Shukla

- virtio_recv_pkts_vec and other virtio vector friend apis are written for sse/avx instructions. For arm64 in particular, virtio vector implementation does not exist(todo).

So virtio pmd driver wont build for targets like i686, arm64. By making RTE_VIRTIO_INC_VECTOR=n, Driver can build for non-sse/avx targets and will work in non-vectored virtio mode.

Disabling RTE_VIRTIO_INC_VECTOR config for :

- i686 arch as i686 target config says:
config/defconfig_i686-native-linuxapp-gcc says "Vectorized PMD is not supported on 32-bit".

- armv7/v8 arch.

---
v4--> v5:
- squashed v4's RTE_VIRTIO_INC_VECTOR patches into one patch.
- Added ifdefs RTE_xx_xx_INC_VECTOR across _simple_rx_tx flag occurance in code.

 config/common_linuxapp                     |    1 +
 config/defconfig_arm-armv7a-linuxapp-gcc   |    4 +++-
 config/defconfig_arm64-armv8a-linuxapp-gcc |    4 +++-
 config/defconfig_i686-native-linuxapp-gcc  |    1 +
 config/defconfig_i686-native-linuxapp-icc  |    1 +
 drivers/net/virtio/Makefile                |    2 +-
 drivers/net/virtio/virtio_rxtx.c           |   16 +++++++++++++++-
 drivers/net/virtio/virtio_rxtx.h           |    2 ++
 8 files changed, 27 insertions(+), 4 deletions(-)
config/common_linuxapp +1 -0
index 74bc515..8677697 100644
@@ -274,6 +274,7 @@ CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_RX=n
 CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX=n
 CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DRIVER=n
 CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_DUMP=n
+CONFIG_RTE_VIRTIO_INC_VECTOR=y
 
 #
 # Compile burst-oriented VMXNET3 PMD driver
config/defconfig_arm-armv7a-linuxapp-gcc +3 -1
index cbebd64..9f852ce 100644
@@ -43,6 +43,9 @@ CONFIG_RTE_FORCE_INTRINSICS=y
 CONFIG_RTE_TOOLCHAIN="gcc"
 CONFIG_RTE_TOOLCHAIN_GCC=y
 
+# Disable VIRTIO VECTOR support
+CONFIG_RTE_VIRTIO_INC_VECTOR=n
+
 # ARM doesn't have support for vmware TSC map
 CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=n
 
@@ -70,7 +73,6 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n
 CONFIG_RTE_LIBRTE_IXGBE_PMD=n
 CONFIG_RTE_LIBRTE_MLX4_PMD=n
 CONFIG_RTE_LIBRTE_MPIPE_PMD=n
-CONFIG_RTE_LIBRTE_VIRTIO_PMD=n
 CONFIG_RTE_LIBRTE_VMXNET3_PMD=n
 CONFIG_RTE_LIBRTE_PMD_XENVIRT=n
 CONFIG_RTE_LIBRTE_PMD_BNX2X=n
config/defconfig_arm64-armv8a-linuxapp-gcc +3 -1
index 504f3ed..1a638b3 100644
@@ -45,8 +45,10 @@ CONFIG_RTE_TOOLCHAIN_GCC=y
 
 CONFIG_RTE_CACHE_LINE_SIZE=64
 
+# Disable VIRTIO VECTOR support
+CONFIG_RTE_VIRTIO_INC_VECTOR=n
+
 CONFIG_RTE_IXGBE_INC_VECTOR=n
-CONFIG_RTE_LIBRTE_VIRTIO_PMD=n
 CONFIG_RTE_LIBRTE_IVSHMEM=n
 CONFIG_RTE_LIBRTE_FM10K_PMD=n
 CONFIG_RTE_LIBRTE_I40E_PMD=n
config/defconfig_i686-native-linuxapp-gcc +1 -0
index a90de9b..a4b1c49 100644
@@ -49,3 +49,4 @@ CONFIG_RTE_LIBRTE_KNI=n
 # Vectorized PMD is not supported on 32-bit
 #
 CONFIG_RTE_IXGBE_INC_VECTOR=n
+CONFIG_RTE_VIRTIO_INC_VECTOR=n
config/defconfig_i686-native-linuxapp-icc +1 -0
index c021321..f8eb6ad 100644
@@ -49,3 +49,4 @@ CONFIG_RTE_LIBRTE_KNI=n
 # Vectorized PMD is not supported on 32-bit
 #
 CONFIG_RTE_IXGBE_INC_VECTOR=n
+CONFIG_RTE_VIRTIO_INC_VECTOR=n
drivers/net/virtio/Makefile +1 -1
index 43835ba..25a842d 100644
@@ -50,7 +50,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtqueue.c
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_pci.c
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx.c
 SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_ethdev.c
-SRCS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio_rxtx_simple.c
+SRCS-$(CONFIG_RTE_VIRTIO_INC_VECTOR) += virtio_rxtx_simple.c
 
 # this lib depends upon:
 DEPDIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += lib/librte_eal lib/librte_ether
drivers/net/virtio/virtio_rxtx.c +15 -1
index 41a1366..d8169d1 100644
@@ -67,7 +67,9 @@
 #define VIRTIO_SIMPLE_FLAGS ((uint32_t)ETH_TXQ_FLAGS_NOMULTSEGS | \
 	ETH_TXQ_FLAGS_NOOFFLOADS)
 
+#ifdef RTE_VIRTIO_INC_VECTOR
 static int use_simple_rxtx;
+#endif
 
 static void
 vq_ring_free_chain(struct virtqueue *vq, uint16_t desc_idx)
@@ -307,12 +309,13 @@ virtio_dev_vring_start(struct virtqueue *vq, int queue_type)
 		nbufs = 0;
 		error = ENOSPC;
 
+#ifdef RTE_VIRTIO_INC_VECTOR
 		if (use_simple_rxtx)
 			for (i = 0; i < vq->vq_nentries; i++) {
 				vq->vq_ring.avail->ring[i] = i;
 				vq->vq_ring.desc[i].flags = VRING_DESC_F_WRITE;
 			}
-
+#endif
 		memset(&vq->fake_mbuf, 0, sizeof(vq->fake_mbuf));
 		for (i = 0; i < RTE_PMD_VIRTIO_RX_MAX_BURST; i++)
 			vq->sw_ring[vq->vq_nentries + i] = &vq->fake_mbuf;
@@ -325,9 +328,11 @@ virtio_dev_vring_start(struct virtqueue *vq, int queue_type)
 			/******************************************
 			*         Enqueue allocated buffers        *
 			*******************************************/
+#ifdef RTE_VIRTIO_INC_VECTOR
 			if (use_simple_rxtx)
 				error = virtqueue_enqueue_recv_refill_simple(vq, m);
 			else
+#endif
 				error = virtqueue_enqueue_recv_refill(vq, m);
 			if (error) {
 				rte_pktmbuf_free(m);
@@ -340,6 +345,7 @@ virtio_dev_vring_start(struct virtqueue *vq, int queue_type)
 
 		PMD_INIT_LOG(DEBUG, "Allocated %d bufs", nbufs);
 	} else if (queue_type == VTNET_TQ) {
+#ifdef RTE_VIRTIO_INC_VECTOR
 		if (use_simple_rxtx) {
 			int mid_idx  = vq->vq_nentries >> 1;
 			for (i = 0; i < mid_idx; i++) {
@@ -357,6 +363,7 @@ virtio_dev_vring_start(struct virtqueue *vq, int queue_type)
 			for (i = mid_idx; i < vq->vq_nentries; i++)
 				vq->vq_ring.avail->ring[i] = i;
 		}
+#endif
 	}
 }
 
@@ -423,7 +430,9 @@ virtio_dev_rx_queue_setup(struct rte_eth_dev *dev,
 
 	dev->data->rx_queues[queue_idx] = vq;
 
+#ifdef RTE_VIRTIO_INC_VECTOR
 	virtio_rxq_vec_setup(vq);
+#endif
 
 	return 0;
 }
@@ -449,7 +458,10 @@ virtio_dev_tx_queue_setup(struct rte_eth_dev *dev,
 			const struct rte_eth_txconf *tx_conf)
 {
 	uint8_t vtpci_queue_idx = 2 * queue_idx + VTNET_SQ_TQ_QUEUE_IDX;
+
+#ifdef RTE_VIRTIO_INC_VECTOR
 	struct virtio_hw *hw = dev->data->dev_private;
+#endif
 	struct virtqueue *vq;
 	uint16_t tx_free_thresh;
 	int ret;
@@ -462,6 +474,7 @@ virtio_dev_tx_queue_setup(struct rte_eth_dev *dev,
 		return -EINVAL;
 	}
 
+#ifdef RTE_VIRTIO_INC_VECTOR
 	/* Use simple rx/tx func if single segment and no offloads */
 	if ((tx_conf->txq_flags & VIRTIO_SIMPLE_FLAGS) == VIRTIO_SIMPLE_FLAGS &&
 	     !vtpci_with_feature(hw, VIRTIO_NET_F_MRG_RXBUF)) {
@@ -470,6 +483,7 @@ virtio_dev_tx_queue_setup(struct rte_eth_dev *dev,
 		dev->rx_pkt_burst = virtio_recv_pkts_vec;
 		use_simple_rxtx = 1;
 	}
+#endif
 
 	ret = virtio_dev_queue_setup(dev, VTNET_TQ, queue_idx, vtpci_queue_idx,
 			nb_desc, socket_id, &vq);
drivers/net/virtio/virtio_rxtx.h +2 -0
index 831e492..9be1378 100644
@@ -33,7 +33,9 @@
 
 #define RTE_PMD_VIRTIO_RX_MAX_BURST 64
 
+#ifdef RTE_VIRTIO_INC_VECTOR
 int virtio_rxq_vec_setup(struct virtqueue *rxq);
 
 int virtqueue_enqueue_recv_refill_simple(struct virtqueue *vq,
 	struct rte_mbuf *m);
+#endif
Signature · 1 line
1.7.9.5
#32 lore raw

PATCH v6 5/8 virtio: move io header and api from virtio_pci.h

In reply to Santosh Shukla

Moving io api and header file i.e. sys/io.h to separate file virtio_io.h

---
v5-->v6:
- included new file virtio_io.h, has in/out api and sys/io.h.

 drivers/net/virtio/virtio_io.h  |  114 +++++++++++++++++++++++++++++++++++++++
 drivers/net/virtio/virtio_pci.c |    1 +
 drivers/net/virtio/virtio_pci.h |   30 -----------
 3 files changed, 115 insertions(+), 30 deletions(-)
 create mode 100644 drivers/net/virtio/virtio_io.h
drivers/net/virtio/virtio_io.h new file +114 -0
new file mode 100644
index 0000000..bfa1341
@@ -0,0 +1,114 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2016 Cavium Networks. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ *     notice, this list of conditions and the following disclaimer in
+ *     the documentation and/or other materials provided with the
+ *     distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ *    THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *    "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *    LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *    A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *    OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *    SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *    LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *    DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *    THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *    (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *    OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ */
+#ifndef _VIRTIO_IO_H_
+#define _VIRTIO_IO_H_
+
+#include <rte_common.h>
+#include "virtio_logs.h"
+
+#if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
+
+#ifdef __FreeBSD__
+#include <sys/types.h>
+#include <machine/cpufunc.h>
+
+static inline void
+outb_p(unsigned char data, unsigned int port)
+{
+
+	outb(port, (u_char)data);
+}
+
+static inline void
+outw_p(unsigned short data, unsigned int port)
+{
+	outw(port, (u_short)data);
+}
+
+static inline void
+outl_p(unsigned int data, unsigned int port)
+{
+	outl(port, (u_int)data);
+}
+
+#else
+#include <sys/io.h>
+#endif
+
+#else /* ! X86 */
+
+static inline uint8_t
+inb(unsigned long addr __rte_unused)
+{
+	PMD_INIT_LOG(ERR, "inb() not supported for this RTE_ARCH\n");
+	return 0;
+}
+
+static inline uint16_t
+inw(unsigned long addr __rte_unused)
+{
+	PMD_INIT_LOG(ERR, "inw() not supported for this RTE_ARCH\n");
+	return 0;
+}
+
+static inline uint32_t
+inl(unsigned long addr __rte_unused)
+{
+	PMD_INIT_LOG(ERR, "in() not supported for this RTE_ARCH\n");
+	return 0;
+}
+
+static inline void
+outb_p(unsigned char data __rte_unused, unsigned int port __rte_unused)
+{
+	PMD_INIT_LOG(ERR, "outb_p() not supported for this RTE_ARCH\n");
+	return;
+}
+
+static inline void
+outw_p(unsigned short data __rte_unused, unsigned int port __rte_unused)
+{
+	PMD_INIT_LOG(ERR, "outw_p() not supported for this RTE_ARCH\n");
+	return;
+}
+
+static inline void
+outl_p(unsigned int data __rte_unused, unsigned int port __rte_unused)
+{
+	PMD_INIT_LOG(ERR, "outl_p() not supported for this RTE_ARCH\n");
+	return;
+}
+
+#endif /* X86 */
+#endif /* _VIRTIO_IO_H_ */
drivers/net/virtio/virtio_pci.c +1 -0
index a9f179f..064f234 100644
@@ -37,6 +37,7 @@
  #include <fcntl.h>
 #endif
 
+#include "virtio_io.h"
 #include "virtio_pci.h"
 #include "virtio_logs.h"
 #include "virtqueue.h"
drivers/net/virtio/virtio_pci.h +0 -30
index 99572a0..2fe5835 100644
@@ -35,14 +35,6 @@
 #define _VIRTIO_PCI_H_
 
 #include <stdint.h>
-
-#ifdef __FreeBSD__
-#include <sys/types.h>
-#include <machine/cpufunc.h>
-#else
-#include <sys/io.h>
-#endif
-
 #include <rte_ethdev.h>
 
 struct virtqueue;
@@ -296,28 +288,6 @@ struct virtio_net_config {
 /* The alignment to use between consumer and producer parts of vring. */
 #define VIRTIO_PCI_VRING_ALIGN 4096
 
-#ifdef __FreeBSD__
-
-static inline void
-outb_p(unsigned char data, unsigned int port)
-{
-
-	outb(port, (u_char)data);
-}
-
-static inline void
-outw_p(unsigned short data, unsigned int port)
-{
-	outw(port, (u_short)data);
-}
-
-static inline void
-outl_p(unsigned int data, unsigned int port)
-{
-	outl(port, (u_int)data);
-}
-#endif
-
 static inline int
 vtpci_with_feature(struct virtio_hw *hw, uint64_t bit)
 {
Signature · 1 line
1.7.9.5
#33 lore raw

PATCH v6 6/8 virtio: add vfio api to rd/wr ioport space

In reply to Santosh Shukla

For vfio case - Use pread/pwrite api to access virtio ioport space.

---
v5-->v6:
- renamed inport_in/out to vfio_in/out
- Renamed file from virtio_vfio_rw.h to virtio_vfio_io.h

 drivers/net/virtio/virtio_vfio_io.h |  104 +++++++++++++++++++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 drivers/net/virtio/virtio_vfio_io.h
drivers/net/virtio/virtio_vfio_io.h new file +104 -0
new file mode 100644
index 0000000..218d4ed
@@ -0,0 +1,104 @@
+/*
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2016 Cavium Networks. All rights reserved.
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ *     notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ *     notice, this list of conditions and the following disclaimer in
+ *     the documentation and/or other materials provided with the
+ *     distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ *     contributors may be used to endorse or promote products derived
+ *     from this software without specific prior written permission.
+ *
+ *    THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *    "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *    LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *    A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *    OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *    SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *    LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *    DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *    THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *    (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *    OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ */
+#ifndef _VIRTIO_VFIO_IO_H_
+#define _VIRTIO_VFIO_IO_H_
+
+#include "virtio_logs.h"
+#if defined(RTE_EAL_VFIO) && defined(RTE_LIBRTE_EAL_LINUXAPP)
+
+#include <stdint.h>
+#include <rte_pci.h>
+
+/* vfio rd/rw virtio apis */
+static inline void
+vfio_inb(const struct rte_pci_device *pci_dev, uint8_t reg, uint8_t *val)
+{
+	if (rte_eal_pci_read_bar(pci_dev, val, sizeof(uint8_t), reg, 0) <= 0) {
+		PMD_DRV_LOG(ERR, "Can't read from PCI bar space");
+		return;
+	}
+}
+
+static inline void
+vfio_inw(const struct rte_pci_device *pci_dev, uint16_t reg, uint16_t *val)
+{
+	if (rte_eal_pci_read_bar(pci_dev, val, sizeof(uint16_t), reg, 0) <= 0) {
+		PMD_DRV_LOG(ERR, "Can't read from PCI bar space");
+		return;
+	}
+}
+
+static inline void
+vfio_inl(const struct rte_pci_device *pci_dev, uint32_t reg, uint32_t *val)
+{
+	if (rte_eal_pci_read_bar(pci_dev, val, sizeof(uint32_t), reg, 0) <= 0) {
+		PMD_DRV_LOG(ERR, "Can't read from PCI bar space");
+		return;
+	}
+}
+
+static inline void
+vfio_outb_p(const struct rte_pci_device *pci_dev, uint8_t reg, uint8_t val)
+{
+	if (rte_eal_pci_write_bar(pci_dev, &val, sizeof(uint8_t),
+				  reg, 0) <= 0) {
+		PMD_DRV_LOG(ERR, "Can't write to PCI bar space");
+		return;
+	}
+}
+
+
+static inline void
+vfio_outw_p(const struct rte_pci_device *pci_dev, uint16_t reg, uint16_t val)
+{
+	if (rte_eal_pci_write_bar(pci_dev, &val, sizeof(uint16_t),
+				  reg, 0) <= 0) {
+		PMD_DRV_LOG(ERR, "Can't write to PCI bar space");
+		return;
+	}
+}
+
+
+static inline void
+vfio_outl_p(const struct rte_pci_device *pci_dev, uint32_t reg, uint32_t val)
+{
+	if (rte_eal_pci_write_bar(pci_dev, &val, sizeof(uint32_t),
+				  reg, 0) <= 0) {
+		PMD_DRV_LOG(ERR, "Can't write to PCI bar space");
+		return;
+	}
+}
+
+#endif /* RTE_EAL_VFIO && RTE_XX_EAL_LINUXAPP */
+#endif /* _VIRTIO_VFIO_RW_H_ */
Signature · 1 line
1.7.9.5
#34 lore raw

Re: [PATCH v6 6/8] virtio: add vfio api to rd/wr ioport space

Quoted 20 lines · Santosh Shukla

For vfio case - Use pread/pwrite api to access virtio ioport space.

---
v5-->v6:
- renamed inport_in/out to vfio_in/out
- Renamed file from virtio_vfio_rw.h to virtio_vfio_io.h

 drivers/net/virtio/virtio_vfio_io.h |  104 +++++++++++++++++++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 drivers/net/virtio/virtio_vfio_io.h
drivers/net/virtio/virtio_vfio_io.h new file +0 -0
new file mode 100644
index 0000000..218d4ed

...

drivers/net/virtio/virtio_vfio_io.h line 5

Quoted 6 lines
drivers/net/virtio/virtio_vfio_io.h new file +5 -0
@@ -0,0 +1,104 @@
+#ifndef _VIRTIO_VFIO_IO_H_
+#define _VIRTIO_VFIO_IO_H_
+
+#include "virtio_logs.h"
+#if defined(RTE_EAL_VFIO) && defined(RTE_LIBRTE_EAL_LINUXAPP)

Won't it cause build failure if above "#if ..." is false, as virtio_read/write_reg_x() reference them unconditionally?

BTW, why above check is needed? We have rte_eal_pci_read/write_bar() implementation with both VFIO and BSD, don't we?

drivers/net/virtio/virtio_vfio_io.h line 104

Quoted 1 line
drivers/net/virtio/virtio_vfio_io.h new file +1 -0
+#endif /* _VIRTIO_VFIO_RW_H_ */
                         ^^^^

You forgot to do rename here.

BTW, I didn't follow the noIOMMU discussion; how did it end? Do we still need that? Is this patch a full story to enable virtio on ARM?

	--yliu
#35 lore raw

Re: [PATCH v6 6/8] virtio: add vfio api to rd/wr ioport space

Quoted 22 lines · Yuanhan Liu
Quoted 20 lines · Santosh Shukla

For vfio case - Use pread/pwrite api to access virtio ioport space.

---
v5-->v6:
- renamed inport_in/out to vfio_in/out
- Renamed file from virtio_vfio_rw.h to virtio_vfio_io.h

 drivers/net/virtio/virtio_vfio_io.h |  104 +++++++++++++++++++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 drivers/net/virtio/virtio_vfio_io.h
drivers/net/virtio/virtio_vfio_io.h new file +0 -0
new file mode 100644
index 0000000..218d4ed

...

Quoted 7 lines

drivers/net/virtio/virtio_vfio_io.h line 5

Quoted 6 lines
drivers/net/virtio/virtio_vfio_io.h new file +5 -0
@@ -0,0 +1,104 @@
+#ifndef _VIRTIO_VFIO_IO_H_
+#define _VIRTIO_VFIO_IO_H_
+
+#include "virtio_logs.h"
+#if defined(RTE_EAL_VFIO) && defined(RTE_LIBRTE_EAL_LINUXAPP)

Yes, Now that we have pci_eal_read/write_bar() dummy implementation for freebsd so we don't need both checks. I overlooked it, sending v7 for this patch now. Thanks.

Quoted 11 lines

Won't it cause build failure if above "#if ..." is false, as virtio_read/write_reg_x() reference them unconditionally?

BTW, why above check is needed? We have rte_eal_pci_read/write_bar() implementation with both VFIO and BSD, don't we?

drivers/net/virtio/virtio_vfio_io.h line 104

Quoted 1 line
drivers/net/virtio/virtio_vfio_io.h new file +1 -0
+#endif /* _VIRTIO_VFIO_RW_H_ */
                         ^^^^

You forgot to do rename here.

My bad (:-

Quoted 4 lines

BTW, I didn't follow the noIOMMU discussion; how did it end? Do we still need that? Is this patch a full story to enable virtio on ARM?

Ok, We agreed that explicit __noiommu suffix not required, atleast for rte_xx_drv struct{}, as because sooner than later we'll have virtio working for both flavours ie... iommu/noiommu. My only worry was parsing for _noiommu and default vfio case, as because noiomu needed user to preset "enable_noiommu_" param for vfio driver to do mode switch. But we wont need that parsing as because if param is not set then binding won't happen, which Thomas rightly pointed out, therefore I choose to drop resource parsing for virtio-for-vfio case, now virtio driver to check only drv->kdrv == RTE_KDRV_VFIO so to make sure interface attached to vfio or not.

But perhaps when we have both flavours working for virtio, then we should at least prompt a INFO message on console that virtio pmd driver attached to default vfio or noIOMMU.

So we don't need explicit _noIOMMU.

Yes this patch is to enable non-x86 arch to use virtio pmd driver (virtio 0.95 spec). After this patch merges-in, I am planning to
- replace sys/io.h entirely
- Add raw_read/raw_writel() api for arm/arm64 {Already proposed similar implementation in v2} so that they could use virtio 1.0spec mapped memory, for both UIO/VFIO mode.

#36 lore raw

Re: [PATCH v6 6/8] virtio: add vfio api to rd/wr ioport space

Quoted 15 lines · Santosh Shukla
Quoted 4 lines

BTW, I didn't follow the noIOMMU discussion; how did it end? Do we still need that? Is this patch a full story to enable virtio on ARM?

Ok, We agreed that explicit __noiommu suffix not required, atleast for rte_xx_drv struct{}, as because sooner than later we'll have virtio working for both flavours ie... iommu/noiommu. My only worry was parsing for _noiommu and default vfio case, as because noiomu needed user to preset "enable_noiommu_" param for vfio driver to do mode switch. But we wont need that parsing as because if param is not set then binding won't happen, which Thomas rightly pointed out, therefore I choose to drop resource parsing for virtio-for-vfio case, now virtio driver to check only drv->kdrv == RTE_KDRV_VFIO so to make sure interface attached to vfio or not.

Quoted 5 lines

But perhaps when we have both flavours working for virtio, then we should at least prompt a INFO message on console that virtio pmd driver attached to default vfio or noIOMMU.

So we don't need explicit _noIOMMU.

Thanks for the explanation.

Quoted 4 lines

Yes this patch is to enable non-x86 arch to use virtio pmd driver (virtio 0.95 spec). After this patch merges-in, I am planning to
- replace sys/io.h entirely

Hmm, be more specific? Replace it with what?

Quoted 3 lines

- Add raw_read/raw_writel() api for arm/arm64 {Already proposed similar implementation in v2} so that they could use virtio 1.0spec mapped memory, for both UIO/VFIO mode.

PCI memory bar mapping works both with UIO/VFIO on ARM, without any extra efforts, right? If so, it should just work with my patch set and yours.

	--yliu
#37 lore raw

Re: [PATCH v6 6/8] virtio: add vfio api to rd/wr ioport space

Quoted 22 lines · Yuanhan Liu
Quoted 15 lines · Santosh Shukla
Quoted 4 lines

BTW, I didn't follow the noIOMMU discussion; how did it end? Do we still need that? Is this patch a full story to enable virtio on ARM?

Ok, We agreed that explicit __noiommu suffix not required, atleast for rte_xx_drv struct{}, as because sooner than later we'll have virtio working for both flavours ie... iommu/noiommu. My only worry was parsing for _noiommu and default vfio case, as because noiomu needed user to preset "enable_noiommu_" param for vfio driver to do mode switch. But we wont need that parsing as because if param is not set then binding won't happen, which Thomas rightly pointed out, therefore I choose to drop resource parsing for virtio-for-vfio case, now virtio driver to check only drv->kdrv == RTE_KDRV_VFIO so to make sure interface attached to vfio or not.

Quoted 5 lines

But perhaps when we have both flavours working for virtio, then we should at least prompt a INFO message on console that virtio pmd driver attached to default vfio or noIOMMU.

So we don't need explicit _noIOMMU.

Quoted 8 lines

Thanks for the explanation.

Quoted 4 lines

Yes this patch is to enable non-x86 arch to use virtio pmd driver (virtio 0.95 spec). After this patch merges-in, I am planning to
- replace sys/io.h entirely

Hmm, be more specific? Replace it with what?

Just to remove ifdef clutter in general from dpdk source and mo

Quoted 8 lines
Quoted 3 lines

- Add raw_read/raw_writel() api for arm/arm64 {Already proposed similar implementation in v2} so that they could use virtio 1.0spec mapped memory, for both UIO/VFIO mode.

PCI memory bar mapping works both with UIO/VFIO on ARM, without any extra efforts, right? If so, it should just work with my patch set and yours.

Mostl likely, That I have not tried. (todo),

Quoted 1 line
        --yliu
#38 lore raw

PATCH v6 7/8 virtio: extend pci rw api for vfio

In reply to Santosh Shukla

So far virtio handle rw access for uio / ioport interface, This patch to extend the support for vfio.

---
 drivers/net/virtio/virtio_io.h  |    2 +-
 drivers/net/virtio/virtio_pci.c |  110 ++++++++++++++++++++++++++++++++++-----
 2 files changed, 98 insertions(+), 14 deletions(-)
drivers/net/virtio/virtio_io.h +1 -1
index bfa1341..ce59e3f 100644
@@ -35,7 +35,7 @@
 #define _VIRTIO_IO_H_
 
 #include <rte_common.h>
-#include "virtio_logs.h"
+#include "virtio_vfio_io.h"
 
 #if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
 
drivers/net/virtio/virtio_pci.c +97 -13

127 lines not on this page · raw message

Signature · 1 line
1.7.9.5
#39 lore raw

PATCH v6 8/8 virtio: do not parse if interface is vfio

In reply to Santosh Shukla

If virtio interface attached to vfio driver then
do not parse for virtio resource. Instead exit with return 0;

---
v5-->v6:
- Removed _noimmu and using deafult rte_kdrv_vfio for drv check.

 drivers/net/virtio/virtio_pci.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/virtio/virtio_pci.c +3 -1
index 71d4a07..d73a3ad 100644
@@ -515,7 +515,9 @@ virtio_resource_init_by_ioports(struct rte_pci_device *pci_dev)
 static int
 legacy_virtio_resource_init(struct rte_pci_device *pci_dev)
 {
-	if (virtio_resource_init_by_uio(pci_dev) == 0)
+	if (pci_dev->kdrv == RTE_KDRV_VFIO)
+		return 0;
+	else if (virtio_resource_init_by_uio(pci_dev) == 0)
 		return 0;
 	else
 		return virtio_resource_init_by_ioports(pci_dev);
Signature · 1 line
1.7.9.5
#40 lore raw

Re: [PATCH v6 1/8] eal: pci: add api to rd/wr pci bar region

In reply to Santosh Shukla
Quoted 24 lines · Santosh Shukla

Introducing below api for pci bar region rd/wr.
Api's are:
- rte_eal_pci_read_bar
- rte_eal_pci_write_bar

---
v5-->v6:
- update api infor in rte_eal_version.map file
suggested by david manchand.

 lib/librte_eal/bsdapp/eal/eal_pci.c             |   19 ++++++++++++
 lib/librte_eal/bsdapp/eal/rte_eal_version.map   |    3 ++
 lib/librte_eal/common/include/rte_pci.h         |   38 +++++++++++++++++++++++
 lib/librte_eal/linuxapp/eal/eal_pci.c           |   34 ++++++++++++++++++++
 lib/librte_eal/linuxapp/eal/eal_pci_init.h      |    6 ++++
 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c      |   28 +++++++++++++++++
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |    3 ++
 7 files changed, 131 insertions(+)
lib/librte_eal/bsdapp/eal/eal_pci.c +0 -0
index 95c32c1..2e535ea 100644

...

lib/librte_eal/bsdapp/eal/eal_pci.c

Quoted 6 lines
lib/librte_eal/bsdapp/eal/eal_pci.c +6 -0
+int rte_eal_pci_read_bar(const struct rte_pci_device *device,
+			 void *buf, size_t len, off_t offset,
+			 int bar_idx)
+
+{
+	const struct rte_intr_handle *intr_handle = &device->intr_handle;

I'd suggest to reference this var inside pci_vfio_read/write_bar(), and pass device as the parmater instead.

lib/librte_eal/bsdapp/eal/eal_pci.c

Quoted 7 lines
lib/librte_eal/bsdapp/eal/eal_pci.c +7 -0
+
+	switch (device->kdrv) {
+	case RTE_KDRV_VFIO:
+		return pci_vfio_read_bar(intr_handle, buf, len,
+					 offset, bar_idx);
+	default:
+		RTE_LOG(ERR, EAL, "write bar not supported by driver\n");
                                   ^^^^^

typo.

BTW, I have a question about this API. Obviously, reading/writing bar space is supported with UIO (when memory resource is mmapped). And I know why you introduced such 2 APIs, for reading IO bar.

So, here is the question: what are the 2 APIs for, for being gerneric APIs to read/write bar spaces, or just to read IO bar spaces? If it's former, the message is wrong; if it's later, you may better rename it to rte_eal_pci_read/write_io_bar()?

David, what do you think of that?

Quoted 4 lines
lib/librte_eal/bsdapp/eal/eal_pci.c +4 -0
+		return -1;
+	}
+}
+

...

lib/librte_eal/bsdapp/eal/eal_pci.c

Quoted 6 lines
lib/librte_eal/bsdapp/eal/eal_pci.c +6 -0
+int
+pci_vfio_read_bar(const struct rte_intr_handle *intr_handle,
+		  void *buf, size_t len, off_t offs, int bar_idx)
+{
+	if (bar_idx < VFIO_PCI_BAR0_REGION_INDEX
+	   || bar_idx > VFIO_PCI_BAR5_REGION_INDEX) {

A minor nit: it's more nature to put the '||' at the end of expression, instead of at the front:

    if (bar_idx < VFIO_PCI_BAR0_REGION_INDEX ||
        bar_idx > VFIO_PCI_BAR5_REGION_INDEX) {


	--yliu
#41 lore raw

Re: [PATCH v6 1/8] eal: pci: add api to rd/wr pci bar region

Quoted 26 lines · Yuanhan Liu
Quoted 24 lines · Santosh Shukla

Introducing below api for pci bar region rd/wr.
Api's are:
- rte_eal_pci_read_bar
- rte_eal_pci_write_bar

---
v5-->v6:
- update api infor in rte_eal_version.map file
suggested by david manchand.

 lib/librte_eal/bsdapp/eal/eal_pci.c             |   19 ++++++++++++
 lib/librte_eal/bsdapp/eal/rte_eal_version.map   |    3 ++
 lib/librte_eal/common/include/rte_pci.h         |   38 +++++++++++++++++++++++
 lib/librte_eal/linuxapp/eal/eal_pci.c           |   34 ++++++++++++++++++++
 lib/librte_eal/linuxapp/eal/eal_pci_init.h      |    6 ++++
 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c      |   28 +++++++++++++++++
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |    3 ++
 7 files changed, 131 insertions(+)
lib/librte_eal/bsdapp/eal/eal_pci.c +0 -0
index 95c32c1..2e535ea 100644

...

Quoted 10 lines

lib/librte_eal/bsdapp/eal/eal_pci.c

Quoted 6 lines
lib/librte_eal/bsdapp/eal/eal_pci.c +6 -0
+int rte_eal_pci_read_bar(const struct rte_pci_device *device,
+                      void *buf, size_t len, off_t offset,
+                      int bar_idx)
+
+{
+     const struct rte_intr_handle *intr_handle = &device->intr_handle;

I'd suggest to reference this var inside pci_vfio_read/write_bar(), and pass device as the parmater instead.

(Sorry for late reply, I was travelling on Monday.) Make sense.

Quoted 10 lines

lib/librte_eal/bsdapp/eal/eal_pci.c

Quoted 7 lines
lib/librte_eal/bsdapp/eal/eal_pci.c +7 -0
+
+     switch (device->kdrv) {
+     case RTE_KDRV_VFIO:
+             return pci_vfio_read_bar(intr_handle, buf, len,
+                                      offset, bar_idx);
+     default:
+             RTE_LOG(ERR, EAL, "write bar not supported by driver\n");
                                   ^^^^^

typo.

Oh, r / write / read, right? sorry for typo error (:-

Quoted 10 lines

BTW, I have a question about this API. Obviously, reading/writing bar space is supported with UIO (when memory resource is mmapped). And I know why you introduced such 2 APIs, for reading IO bar.

So, here is the question: what are the 2 APIs for, for being gerneric APIs to read/write bar spaces, or just to read IO bar spaces? If it's former, the message is wrong; if it's later, you may better rename it to rte_eal_pci_read/write_io_bar()?

Current use-case is virtio: It is used as io_bar which is first bar[1]. But implementation is generic, can be used to do rd/wr for other bar index too. Also vfio facilitate user to do rd/wr to pci_bars w/o mapping that bar, So apis will be useful for such cases in future.

AFAIU: uio has read/write_config api only and Yes if bar region mapped then no need to do rd/wr, user can directly access the pci_memory. But use-case of this api entirely different: unmapped memory by application context i.e.. vfio_rd/wr-way {pread/pwrite-way}.

Is above explanation convincing? Pl. let me know.

[1] https://en.wikipedia.org/wiki/PCI_configuration_space (first bar offset 0x010)

Quoted 23 lines

David, what do you think of that?

Quoted 4 lines
lib/librte_eal/bsdapp/eal/eal_pci.c +4 -0
+             return -1;
+     }
+}
+

...

lib/librte_eal/bsdapp/eal/eal_pci.c

Quoted 6 lines
lib/librte_eal/bsdapp/eal/eal_pci.c +6 -0
+int
+pci_vfio_read_bar(const struct rte_intr_handle *intr_handle,
+               void *buf, size_t len, off_t offs, int bar_idx)
+{
+     if (bar_idx < VFIO_PCI_BAR0_REGION_INDEX
+        || bar_idx > VFIO_PCI_BAR5_REGION_INDEX) {

A minor nit: it's more nature to put the '||' at the end of expression, instead of at the front:

    if (bar_idx < VFIO_PCI_BAR0_REGION_INDEX ||
        bar_idx > VFIO_PCI_BAR5_REGION_INDEX) {


        --yliu
#42 lore raw

Re: [PATCH v6 1/8] eal: pci: add api to rd/wr pci bar region

Quoted 21 lines · Santosh Shukla
Quoted 10 lines

lib/librte_eal/linuxapp/eal/eal_pci.c int rte_eal_pci_write_config(const struct rte_pci_device *device, · line 629

Quoted 6 lines
lib/librte_eal/linuxapp/eal/eal_pci.c +6 -0
+int rte_eal_pci_read_bar(const struct rte_pci_device *device,
+                      void *buf, size_t len, off_t offset,
+                      int bar_idx)
+
+{
+     const struct rte_intr_handle *intr_handle = &device->intr_handle;

I'd suggest to reference this var inside pci_vfio_read/write_bar(), and pass device as the parmater instead.

(Sorry for late reply, I was travelling on Monday.) Make sense.

Quoted 7 lines
Quoted 7 lines
lib/librte_eal/linuxapp/eal/eal_pci.c +7 -0
+
+     switch (device->kdrv) {
+     case RTE_KDRV_VFIO:
+             return pci_vfio_read_bar(intr_handle, buf, len,
+                                      offset, bar_idx);
+     default:
+             RTE_LOG(ERR, EAL, "write bar not supported by driver\n");
Quoted 5 lines
Quoted 3 lines
                                   ^^^^^

typo.

Oh, r / write / read, right? sorry for typo error (:-

Right.

Quoted 17 lines
Quoted 11 lines

BTW, I have a question about this API. Obviously, reading/writing bar space is supported with UIO (when memory resource is mmapped). And I know why you introduced such 2 APIs, for reading IO bar.

So, here is the question: what are the 2 APIs for, for being gerneric APIs to read/write bar spaces, or just to read IO bar spaces? If it's former, the message is wrong; if it's later, you may better rename it to rte_eal_pci_read/write_io_bar()?

Current use-case is virtio: It is used as io_bar which is first bar[1]. But implementation is generic, can be used to do rd/wr for other bar index too. Also vfio facilitate user to do rd/wr to pci_bars w/o mapping that bar, So apis will be useful for such cases in future.

Quoted 6 lines

AFAIU: uio has read/write_config api only and Yes if bar region mapped then no need to do rd/wr, user can directly access the pci_memory. But use-case of this api entirely different: unmapped memory by application context i.e.. vfio_rd/wr-way {pread/pwrite-way}.

Is above explanation convincing? Pl. let me know.

TBH, not really. So, as you stated, it should be generic APIs to read/write bar space, but limiting it to VFIO only and claiming that read/write bar space is not support by other drivers (such as UIO) while in fact it can (in some ways) doesn't seem right to me.

Anyway, it's just some thoughts from me. David, comments?

	--yliu
#43 lore raw

Re: [PATCH v6 1/8] eal: pci: add api to rd/wr pci bar region

Quoted 19 lines · Yuanhan Liu
Quoted 11 lines · Santosh Shukla

Current use-case is virtio: It is used as io_bar which is first bar[1]. But implementation is generic, can be used to do rd/wr for other bar index too. Also vfio facilitate user to do rd/wr to pci_bars w/o mapping that bar, So apis will be useful for such cases in future.

AFAIU: uio has read/write_config api only and Yes if bar region mapped then no need to do rd/wr, user can directly access the pci_memory. But use-case of this api entirely different: unmapped memory by application context i.e.. vfio_rd/wr-way {pread/pwrite-way}.

Is above explanation convincing? Pl. let me know.

TBH, not really. So, as you stated, it should be generic APIs to read/write bar space, but limiting it to VFIO only and claiming that read/write bar space is not support by other drivers (such as UIO) while in fact it can (in some ways) doesn't seem right to me.

Quoted 3 lines

Anyway, it's just some thoughts from me. David, comments?

From the very start, same opinion.

We should have a unique api to access those, and eal should hide details like kernel drivers (uio, vfio, whatever) to the pmd.

Now the thing is, how to do this in an elegant and efficient way.

Regard,

Signature · 1 line
David Marchand
#44 lore raw

Re: [PATCH v6 1/8] eal: pci: add api to rd/wr pci bar region

Quoted 20 lines · David Marchand
Quoted 19 lines · Yuanhan Liu
Quoted 11 lines · Santosh Shukla

Current use-case is virtio: It is used as io_bar which is first bar[1]. But implementation is generic, can be used to do rd/wr for other bar index too. Also vfio facilitate user to do rd/wr to pci_bars w/o mapping that bar, So apis will be useful for such cases in future.

AFAIU: uio has read/write_config api only and Yes if bar region mapped then no need to do rd/wr, user can directly access the pci_memory. But use-case of this api entirely different: unmapped memory by application context i.e.. vfio_rd/wr-way {pread/pwrite-way}.

Is above explanation convincing? Pl. let me know.

TBH, not really. So, as you stated, it should be generic APIs to read/write bar space, but limiting it to VFIO only and claiming that read/write bar space is not support by other drivers (such as UIO) while in fact it can (in some ways) doesn't seem right to me.

Quoted 7 lines
Quoted 3 lines

Anyway, it's just some thoughts from me. David, comments?

From the very start, same opinion.

We should have a unique api to access those, and eal should hide details like kernel drivers (uio, vfio, whatever) to the pmd.

Now the thing is, how to do this in an elegant and efficient way.

I was thinking that we may just make it be IO port specific read/ write functions:

	rte_eal_pci_ioport_read(dev, bar, buf, size)
	{

		return if not an IO bar;

		if (has io)
			return inb/w/l();

		if (vfio)
			return vfio_ioport_read();

		else, claim aloud that io port read is not allowed
	}

Let us not handle memory bar resource here: in such case, you should go with rte_eal_pci_map_device() and do it with memory mapped io.

Does that make any sense?

	--yliu
#45 lore raw

Re: [PATCH v6 1/8] eal: pci: add api to rd/wr pci bar region

Quoted 23 lines · Yuanhan Liu
Quoted 22 lines · David Marchand
Quoted 20 lines · Yuanhan Liu
Quoted 11 lines · Santosh Shukla

Current use-case is virtio: It is used as io_bar which is first bar[1]. But implementation is generic, can be used to do rd/wr for other bar index too. Also vfio facilitate user to do rd/wr to pci_bars w/o mapping that bar, So apis will be useful for such cases in future.

AFAIU: uio has read/write_config api only and Yes if bar region mapped then no need to do rd/wr, user can directly access the pci_memory. But use-case of this api entirely different: unmapped memory by application context i.e.. vfio_rd/wr-way {pread/pwrite-way}.

Is above explanation convincing? Pl. let me know.

TBH, not really. So, as you stated, it should be generic APIs to read/write bar space, but limiting it to VFIO only and claiming that read/write bar space is not support by other drivers (such as UIO) while in fact it can (in some ways) doesn't seem right to me.

Anyway, it's just some thoughts from me. David, comments?

Quoted 9 lines
Quoted 5 lines
Quoted 1 line

From the very start, same opinion.

We should have a unique api to access those, and eal should hide details like kernel drivers (uio, vfio, whatever) to the pmd.

Now the thing is, how to do this in an elegant and efficient way.

I was thinking that we may just make it be IO port specific read/ write functions:

Ok,

Quoted 8 lines
        rte_eal_pci_ioport_read(dev, bar, buf, size)
        {

                return if not an IO bar;

                if (has io)
                        return inb/w/l();

In that case, It may be r / if (has io) / if (drv->kdrv == UIO)

Quoted 11 lines
                if (vfio)
                        return vfio_ioport_read();

                else, claim aloud that io port read is not allowed
        }

Let us not handle memory bar resource here: in such case, you should go with rte_eal_pci_map_device() and do it with memory mapped io.

Does that make any sense?

I am not entirely sure.
Are you considering IGB_UIO, UIO_GENERIC and NIC_UIO: all the cases ?

Quoted 1 line
        --yliu
#46 lore raw

Re: [PATCH v6 1/8] eal: pci: add api to rd/wr pci bar region

Quoted 53 lines · Santosh Shukla
Quoted 23 lines · Yuanhan Liu
Quoted 22 lines · David Marchand
Quoted 20 lines · Yuanhan Liu
Quoted 11 lines · Santosh Shukla

Current use-case is virtio: It is used as io_bar which is first bar[1]. But implementation is generic, can be used to do rd/wr for other bar index too. Also vfio facilitate user to do rd/wr to pci_bars w/o mapping that bar, So apis will be useful for such cases in future.

AFAIU: uio has read/write_config api only and Yes if bar region mapped then no need to do rd/wr, user can directly access the pci_memory. But use-case of this api entirely different: unmapped memory by application context i.e.. vfio_rd/wr-way {pread/pwrite-way}.

Is above explanation convincing? Pl. let me know.

TBH, not really. So, as you stated, it should be generic APIs to read/write bar space, but limiting it to VFIO only and claiming that read/write bar space is not support by other drivers (such as UIO) while in fact it can (in some ways) doesn't seem right to me.

Anyway, it's just some thoughts from me. David, comments?

Quoted 9 lines
Quoted 5 lines
Quoted 1 line

From the very start, same opinion.

We should have a unique api to access those, and eal should hide details like kernel drivers (uio, vfio, whatever) to the pmd.

Now the thing is, how to do this in an elegant and efficient way.

I was thinking that we may just make it be IO port specific read/ write functions:

Ok,

Quoted 8 lines
        rte_eal_pci_ioport_read(dev, bar, buf, size)
        {

                return if not an IO bar;

                if (has io)
                        return inb/w/l();

In that case, It may be r / if (has io) / if (drv->kdrv == UIO)

Quoted 6 lines
                if (vfio)
                        return vfio_ioport_read();

                else, claim aloud that io port read is not allowed
        }
Quoted 8 lines
Quoted 5 lines

Let us not handle memory bar resource here: in such case, you should go with rte_eal_pci_map_device() and do it with memory mapped io.

Does that make any sense?

I am not entirely sure.
Are you considering IGB_UIO, UIO_GENERIC and NIC_UIO: all the cases ?

Just came-up something below what Yuanhan has proposed, Does this look okay?

int rte_eal_pci_ioport_read(const struct rte_pci_device *device,
void *buf, size_t len,
off_t offset,
int bar_idx)

{
      if (bar_idx != 0) {
              RTE_LOG(ERR, EAL, "not a ioport bar\n");
              return -1;
       }

     switch (device->kdrv) {
     case RTE_KDRV_VFIO:
               return pci_vfio_ioport_read(device, buf, len, offset, bar_idx);
     case RTE_KDRV_IGB_UIO:
     case RTE_KDRV_UIO_GENERIC:
     case RTE_KDRV_NIC_UIO:
         {
              switch (size)
                      case 1: return inb(buf /*ioport address*/);
                      case 2: return inw(buf /* ioport address*/);
                      case 4: return inl(buf /* ioport address*/);
                      default:
                             RTE_LOG(ERR, EAL, "invalid size\n");
          }

       default:
                 RTE_LOG(ERR, EAL, "read bar not supported by driver\n");
                 return -1;
      }
}
Quoted 2 lines
Quoted 2 lines
        --yliu
#47 lore raw

Re: [PATCH v6 1/8] eal: pci: add api to rd/wr pci bar region

Quoted 87 lines · Santosh Shukla
Quoted 53 lines · Santosh Shukla
Quoted 23 lines · Yuanhan Liu
Quoted 22 lines · David Marchand
Quoted 20 lines · Yuanhan Liu
Quoted 11 lines · Santosh Shukla

Current use-case is virtio: It is used as io_bar which is first bar[1]. But implementation is generic, can be used to do rd/wr for other bar index too. Also vfio facilitate user to do rd/wr to pci_bars w/o mapping that bar, So apis will be useful for such cases in future.

AFAIU: uio has read/write_config api only and Yes if bar region mapped then no need to do rd/wr, user can directly access the pci_memory. But use-case of this api entirely different: unmapped memory by application context i.e.. vfio_rd/wr-way {pread/pwrite-way}.

Is above explanation convincing? Pl. let me know.

TBH, not really. So, as you stated, it should be generic APIs to read/write bar space, but limiting it to VFIO only and claiming that read/write bar space is not support by other drivers (such as UIO) while in fact it can (in some ways) doesn't seem right to me.

Anyway, it's just some thoughts from me. David, comments?

Quoted 9 lines
Quoted 5 lines
Quoted 1 line

From the very start, same opinion.

We should have a unique api to access those, and eal should hide details like kernel drivers (uio, vfio, whatever) to the pmd.

Now the thing is, how to do this in an elegant and efficient way.

I was thinking that we may just make it be IO port specific read/ write functions:

Ok,

Quoted 8 lines
        rte_eal_pci_ioport_read(dev, bar, buf, size)
        {

                return if not an IO bar;

                if (has io)
                        return inb/w/l();

In that case, It may be r / if (has io) / if (drv->kdrv == UIO)

Quoted 6 lines
                if (vfio)
                        return vfio_ioport_read();

                else, claim aloud that io port read is not allowed
        }
Quoted 8 lines
Quoted 5 lines

Let us not handle memory bar resource here: in such case, you should go with rte_eal_pci_map_device() and do it with memory mapped io.

Does that make any sense?

I am not entirely sure.
Are you considering IGB_UIO, UIO_GENERIC and NIC_UIO: all the cases ?

Just came-up something below what Yuanhan has proposed, Does this look okay?

int rte_eal_pci_ioport_read(const struct rte_pci_device *device,
void *buf, size_t len,
off_t offset,
int bar_idx)

{
      if (bar_idx != 0) {
              RTE_LOG(ERR, EAL, "not a ioport bar\n");
              return -1;
       }

     switch (device->kdrv) {
     case RTE_KDRV_VFIO:
               return pci_vfio_ioport_read(device, buf, len, offset, bar_idx);
     case RTE_KDRV_IGB_UIO:
     case RTE_KDRV_UIO_GENERIC:
     case RTE_KDRV_NIC_UIO:
         {
              switch (size)
                      case 1: return inb(buf /*ioport address*/);
                      case 2: return inw(buf /* ioport address*/);
                      case 4: return inl(buf /* ioport address*/);
                      default:
Quoted 9 lines
                             RTE_LOG(ERR, EAL, "invalid size\n");
          }

       default:
                 RTE_LOG(ERR, EAL, "read bar not supported by driver\n");
                 return -1;
      }
}

Ping?

Also can someone please review rest of series. This patchset going through multiple revision, Each revision get one / two comment, It would help if I get review comment for each patch.

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
        --yliu
#48 lore raw

Re: [PATCH v6 1/8] eal: pci: add api to rd/wr pci bar region

Quoted 91 lines · Santosh Shukla
Quoted 90 lines · Santosh Shukla
Quoted 53 lines · Santosh Shukla
Quoted 23 lines · Yuanhan Liu
Quoted 22 lines · David Marchand
Quoted 20 lines · Yuanhan Liu
Quoted 11 lines · Santosh Shukla

Current use-case is virtio: It is used as io_bar which is first bar[1]. But implementation is generic, can be used to do rd/wr for other bar index too. Also vfio facilitate user to do rd/wr to pci_bars w/o mapping that bar, So apis will be useful for such cases in future.

AFAIU: uio has read/write_config api only and Yes if bar region mapped then no need to do rd/wr, user can directly access the pci_memory. But use-case of this api entirely different: unmapped memory by application context i.e.. vfio_rd/wr-way {pread/pwrite-way}.

Is above explanation convincing? Pl. let me know.

TBH, not really. So, as you stated, it should be generic APIs to read/write bar space, but limiting it to VFIO only and claiming that read/write bar space is not support by other drivers (such as UIO) while in fact it can (in some ways) doesn't seem right to me.

Anyway, it's just some thoughts from me. David, comments?

Quoted 9 lines
Quoted 5 lines
Quoted 1 line

From the very start, same opinion.

We should have a unique api to access those, and eal should hide details like kernel drivers (uio, vfio, whatever) to the pmd.

Now the thing is, how to do this in an elegant and efficient way.

I was thinking that we may just make it be IO port specific read/ write functions:

Ok,

Quoted 8 lines
        rte_eal_pci_ioport_read(dev, bar, buf, size)
        {

                return if not an IO bar;

                if (has io)
                        return inb/w/l();

In that case, It may be r / if (has io) / if (drv->kdrv == UIO)

Quoted 6 lines
                if (vfio)
                        return vfio_ioport_read();

                else, claim aloud that io port read is not allowed
        }
Quoted 8 lines
Quoted 5 lines

Let us not handle memory bar resource here: in such case, you should go with rte_eal_pci_map_device() and do it with memory mapped io.

Does that make any sense?

I am not entirely sure.
Are you considering IGB_UIO, UIO_GENERIC and NIC_UIO: all the cases ?

Just came-up something below what Yuanhan has proposed, Does this look okay?

int rte_eal_pci_ioport_read(const struct rte_pci_device *device,
void *buf, size_t len,
off_t offset,
int bar_idx)

{
      if (bar_idx != 0) {
              RTE_LOG(ERR, EAL, "not a ioport bar\n");
              return -1;
       }

     switch (device->kdrv) {
     case RTE_KDRV_VFIO:
               return pci_vfio_ioport_read(device, buf, len, offset, bar_idx);
     case RTE_KDRV_IGB_UIO:
     case RTE_KDRV_UIO_GENERIC:
     case RTE_KDRV_NIC_UIO:
         {
              switch (size)
                      case 1: return inb(buf /*ioport address*/);
                      case 2: return inw(buf /* ioport address*/);
                      case 4: return inl(buf /* ioport address*/);
                      default:
                             RTE_LOG(ERR, EAL, "invalid size\n");
          }
Quoted 8 lines
Quoted 6 lines
       default:
                 RTE_LOG(ERR, EAL, "read bar not supported by driver\n");
                 return -1;
      }
}

Ping?

Please be a bit more patient. Everybody has work got to do; and today I was out for personal affairs the whole day.

Quoted 4 lines

Also can someone please review rest of series. This patchset going through multiple revision, Each revision get one / two comment, It would help if I get review comment for each patch.

The others looks good to me; if you have the EAL pci API resolved properly, I guess I could give my ACK.

	--yliu
#49 lore raw

Re: [PATCH v6 1/8] eal: pci: add api to rd/wr pci bar region

Quoted 7 lines · Yuanhan Liu
Quoted 3 lines · Santosh Shukla

Also can someone please review rest of series. This patchset going through multiple revision, Each revision get one / two comment, It would help if I get review comment for each patch.

The others looks good to me; if you have the EAL pci API resolved properly, I guess I could give my ACK.

As discussed offlist, I just sent a patchset [1] that proposes a new api. This is not perfect, but I think this should be fine for x86 / arm. Santosh should be able to rebase his code on top of it.

[1] http://dpdk.org/ml/archives/dev/2016-February/032778.html

Regards,

Signature · 1 line
David Marchand
#50 lore raw

Re: [PATCH v6 1/8] eal: pci: add api to rd/wr pci bar region

In reply to Santosh Shukla
Quoted 40 lines · Santosh Shukla
Quoted 39 lines · Santosh Shukla
Quoted 23 lines · Yuanhan Liu
Quoted 22 lines · David Marchand
Quoted 20 lines · Yuanhan Liu
Quoted 11 lines · Santosh Shukla

Current use-case is virtio: It is used as io_bar which is first bar[1]. But implementation is generic, can be used to do rd/wr for other bar index too. Also vfio facilitate user to do rd/wr to pci_bars w/o mapping that bar, So apis will be useful for such cases in future.

AFAIU: uio has read/write_config api only and Yes if bar region mapped then no need to do rd/wr, user can directly access the pci_memory. But use-case of this api entirely different: unmapped memory by application context i.e.. vfio_rd/wr-way {pread/pwrite-way}.

Is above explanation convincing? Pl. let me know.

TBH, not really. So, as you stated, it should be generic APIs to read/write bar space, but limiting it to VFIO only and claiming that read/write bar space is not support by other drivers (such as UIO) while in fact it can (in some ways) doesn't seem right to me.

Anyway, it's just some thoughts from me. David, comments?

Quoted 9 lines
Quoted 5 lines
Quoted 1 line

From the very start, same opinion.

We should have a unique api to access those, and eal should hide details like kernel drivers (uio, vfio, whatever) to the pmd.

Now the thing is, how to do this in an elegant and efficient way.

I was thinking that we may just make it be IO port specific read/ write functions:

Ok,

Quoted 3 lines

rte_eal_pci_ioport_read(dev, bar, buf, size) {

Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
                return if not an IO bar;

                if (has io)
                        return inb/w/l();

In that case, It may be r / if (has io) / if (drv->kdrv == UIO)

Nope, I meant platform supports inb/w/l() command.

Quoted 16 lines
Quoted 7 lines
Quoted 7 lines
                if (vfio)
                        return vfio_ioport_read();

                else, claim aloud that io port read is not allowed
        }
Quoted 8 lines
Quoted 5 lines

Let us not handle memory bar resource here: in such case, you should go with rte_eal_pci_map_device() and do it with memory mapped io.

Does that make any sense?

I am not entirely sure.
Are you considering IGB_UIO, UIO_GENERIC and NIC_UIO: all the cases ?

Quoted 6 lines

Just came-up something below what Yuanhan has proposed, Does this look okay?

int rte_eal_pci_ioport_read(const struct rte_pci_device *device,
void *buf, size_t len,
off_t offset,
int bar_idx)

Your implementation doesn't look right to me. But anyway, that's not important so far; the feasibility is.

David, would you please comment on this?

	--yliu
#51 lore raw

Re: [PATCH v6 1/8] eal: pci: add api to rd/wr pci bar region

In reply to Yuanhan Liu
Quoted 52 lines · Yuanhan Liu
Quoted 21 lines · Santosh Shukla
Quoted 10 lines

lib/librte_eal/linuxapp/eal/eal_pci.c int rte_eal_pci_write_config(const struct rte_pci_device *device, · line 629

Quoted 6 lines
lib/librte_eal/linuxapp/eal/eal_pci.c +6 -0
+int rte_eal_pci_read_bar(const struct rte_pci_device *device,
+                      void *buf, size_t len, off_t offset,
+                      int bar_idx)
+
+{
+     const struct rte_intr_handle *intr_handle = &device->intr_handle;

I'd suggest to reference this var inside pci_vfio_read/write_bar(), and pass device as the parmater instead.

(Sorry for late reply, I was travelling on Monday.) Make sense.

Quoted 7 lines
Quoted 7 lines
lib/librte_eal/linuxapp/eal/eal_pci.c +7 -0
+
+     switch (device->kdrv) {
+     case RTE_KDRV_VFIO:
+             return pci_vfio_read_bar(intr_handle, buf, len,
+                                      offset, bar_idx);
+     default:
+             RTE_LOG(ERR, EAL, "write bar not supported by driver\n");
Quoted 5 lines
Quoted 3 lines
                                   ^^^^^

typo.

Oh, r / write / read, right? sorry for typo error (:-

Right.

Quoted 22 lines
Quoted 11 lines

BTW, I have a question about this API. Obviously, reading/writing bar space is supported with UIO (when memory resource is mmapped). And I know why you introduced such 2 APIs, for reading IO bar.

So, here is the question: what are the 2 APIs for, for being gerneric APIs to read/write bar spaces, or just to read IO bar spaces? If it's former, the message is wrong; if it's later, you may better rename it to rte_eal_pci_read/write_io_bar()?

Current use-case is virtio: It is used as io_bar which is first bar[1]. But implementation is generic, can be used to do rd/wr for other bar index too. Also vfio facilitate user to do rd/wr to pci_bars w/o mapping that bar, So apis will be useful for such cases in future.

AFAIU: uio has read/write_config api only and Yes if bar region mapped then no need to do rd/wr, user can directly access the pci_memory. But use-case of this api entirely different: unmapped memory by application context i.e.. vfio_rd/wr-way {pread/pwrite-way}.

Quoted 8 lines
Quoted 1 line

Is above explanation convincing? Pl. let me know.

TBH, not really. So, as you stated, it should be generic APIs to read/write bar space, but limiting it to VFIO only and claiming that read/write bar space is not support by other drivers (such as UIO) while in fact it can (in some ways) doesn't seem right to me.

I agree.. But if UIO doesn't and need could, then I am confused what can be done? However we have a use-case for vfio so It make sense to me use this api. Or else If we all agree then I can export api only for VFIO.. but it will violate EAL abstraction.

Quoted 3 lines

Anyway, it's just some thoughts from me. David, comments?

        --yliu
#52 lore raw

Re: [PATCH v6 1/8] eal: pci: add api to rd/wr pci bar region

Quoted 54 lines · Santosh Shukla
Quoted 52 lines · Yuanhan Liu
Quoted 21 lines · Santosh Shukla
Quoted 10 lines

lib/librte_eal/linuxapp/eal/eal_pci.c int rte_eal_pci_write_config(const struct rte_pci_device *device, · line 629

Quoted 6 lines
lib/librte_eal/linuxapp/eal/eal_pci.c +6 -0
+int rte_eal_pci_read_bar(const struct rte_pci_device *device,
+                      void *buf, size_t len, off_t offset,
+                      int bar_idx)
+
+{
+     const struct rte_intr_handle *intr_handle = &device->intr_handle;

I'd suggest to reference this var inside pci_vfio_read/write_bar(), and pass device as the parmater instead.

(Sorry for late reply, I was travelling on Monday.) Make sense.

Quoted 7 lines
Quoted 7 lines
lib/librte_eal/linuxapp/eal/eal_pci.c +7 -0
+
+     switch (device->kdrv) {
+     case RTE_KDRV_VFIO:
+             return pci_vfio_read_bar(intr_handle, buf, len,
+                                      offset, bar_idx);
+     default:
+             RTE_LOG(ERR, EAL, "write bar not supported by driver\n");
Quoted 5 lines
Quoted 3 lines
                                   ^^^^^

typo.

Oh, r / write / read, right? sorry for typo error (:-

Right.

Quoted 22 lines
Quoted 11 lines

BTW, I have a question about this API. Obviously, reading/writing bar space is supported with UIO (when memory resource is mmapped). And I know why you introduced such 2 APIs, for reading IO bar.

So, here is the question: what are the 2 APIs for, for being gerneric APIs to read/write bar spaces, or just to read IO bar spaces? If it's former, the message is wrong; if it's later, you may better rename it to rte_eal_pci_read/write_io_bar()?

Current use-case is virtio: It is used as io_bar which is first bar[1]. But implementation is generic, can be used to do rd/wr for other bar index too. Also vfio facilitate user to do rd/wr to pci_bars w/o mapping that bar, So apis will be useful for such cases in future.

AFAIU: uio has read/write_config api only and Yes if bar region mapped then no need to do rd/wr, user can directly access the pci_memory. But use-case of this api entirely different: unmapped memory by application context i.e.. vfio_rd/wr-way {pread/pwrite-way}.

Quoted 9 lines
Quoted 8 lines
Quoted 1 line

Is above explanation convincing? Pl. let me know.

TBH, not really. So, as you stated, it should be generic APIs to read/write bar space, but limiting it to VFIO only and claiming that read/write bar space is not support by other drivers (such as UIO) while in fact it can (in some ways) doesn't seem right to me.

Sorry typo

Quoted 1 line

I agree.. But if UIO doesn't and need could, then I am confused what

r / But if UIO doesn't and need could / But if UIO doesn't and vfio could

Quoted 8 lines

can be done? However we have a use-case for vfio so It make sense to me use this api. Or else If we all agree then I can export api only for VFIO.. but it will violate EAL abstraction.

Quoted 3 lines

Anyway, it's just some thoughts from me. David, comments?

        --yliu
#53 lore raw

PATCH v8 3/4 eal/linux: vfio: ignore mapping for ioport region

In reply to a message not in the archive

vfio_pci_mmap() try to map all pci bars. ioport region are not mapped in vfio/kernel so ignore mmaping for ioport.

---
v7-->v8:
- included Anatoly acked-by:

 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c +20 -0
index ffa2dd0..4832313 100644
@@ -659,6 +659,7 @@ pci_vfio_map_resource(struct rte_pci_device *dev)
 	struct pci_map *maps;
 	uint32_t msix_table_offset = 0;
 	uint32_t msix_table_size = 0;
+	uint32_t ioport_bar;
 
 	dev->intr_handle.fd = -1;
 	dev->intr_handle.type = RTE_INTR_HANDLE_UNKNOWN;
@@ -853,6 +854,25 @@ pci_vfio_map_resource(struct rte_pci_device *dev)
 			return -1;
 		}
 
+		/* chk for io port region */
+		ret = pread64(vfio_dev_fd, &ioport_bar, sizeof(ioport_bar),
+			      VFIO_GET_REGION_ADDR(VFIO_PCI_CONFIG_REGION_INDEX)
+			      + PCI_BASE_ADDRESS_0 + i*4);
+
+		if (ret != sizeof(ioport_bar)) {
+			RTE_LOG(ERR, EAL,
+				"Cannot read command (%x) from config space!\n",
+				PCI_BASE_ADDRESS_0 + i*4);
+			return -1;
+		}
+
+		if (ioport_bar & PCI_BASE_ADDRESS_SPACE_IO) {
+			RTE_LOG(INFO, EAL,
+				"Ignore mapping IO port bar(%d) addr: %x\n",
+				 i, ioport_bar);
+			continue;
+		}
+
 		/* skip non-mmapable BARs */
 		if ((reg.flags & VFIO_REGION_INFO_FLAG_MMAP) == 0)
 			continue;
Signature · 1 line
1.7.9.5
#54 lore raw

PATCH v8 4/4 eal/linux: vfio: add pci ioport support

Include vfio map/rd/wr support for pci ioport.

---
v7->v8:
- Remove rte_pci_ioport malloc and rte_free()/unmap() func from v7.
- removed umap from git header.

 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c |   36 ++++++++++++++++++----------
 1 file changed, 24 insertions(+), 12 deletions(-)
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c +24 -12
index 4832313..9571ed8 100644
@@ -74,6 +74,7 @@ EAL_REGISTER_TAILQ(rte_vfio_tailq)
 #define VFIO_GROUP_FMT "/dev/vfio/%u"
 #define VFIO_NOIOMMU_GROUP_FMT "/dev/vfio/noiommu-%u"
 #define VFIO_GET_REGION_ADDR(x) ((uint64_t) x << 40ULL)
+#define VFIO_GET_REGION_IDX(x) (x >> 40)
 
 /* per-process VFIO config */
 static struct vfio_config vfio_cfg;
@@ -999,30 +1000,41 @@ int
 pci_vfio_ioport_map(struct rte_pci_device *dev, int bar,
 		    struct rte_pci_ioport *p)
 {
-	RTE_SET_USED(dev);
-	RTE_SET_USED(bar);
-	RTE_SET_USED(p);
-	return -1;
+	if (bar < VFIO_PCI_BAR0_REGION_INDEX ||
+	    bar > VFIO_PCI_BAR5_REGION_INDEX) {
+		RTE_LOG(ERR, EAL, "invalid bar (%d)!\n", bar);
+		return -1;
+	}
+
+	p->dev = dev;
+	p->offset = VFIO_GET_REGION_ADDR(bar);
+	return 0;
 }
 
 void
 pci_vfio_ioport_read(struct rte_pci_ioport *p,
 		     void *data, size_t len, off_t offset)
 {
-	RTE_SET_USED(p);
-	RTE_SET_USED(data);
-	RTE_SET_USED(len);
-	RTE_SET_USED(offset);
+	const struct rte_intr_handle *intr_handle = &p->dev->intr_handle;
+
+	if (pread64(intr_handle->vfio_dev_fd, data,
+		    len, p->offset + offset) <= 0)
+		RTE_LOG(ERR, EAL,
+			"Can't read from PCI bar (%" PRIu64 ") : offset (%x)\n",
+			VFIO_GET_REGION_IDX(p->offset), (int)offset);
 }
 
 void
 pci_vfio_ioport_write(struct rte_pci_ioport *p,
 		      const void *data, size_t len, off_t offset)
 {
-	RTE_SET_USED(p);
-	RTE_SET_USED(data);
-	RTE_SET_USED(len);
-	RTE_SET_USED(offset);
+	const struct rte_intr_handle *intr_handle = &p->dev->intr_handle;
+
+	if (pwrite64(intr_handle->vfio_dev_fd, data,
+		     len, p->offset + offset) <= 0)
+		RTE_LOG(ERR, EAL,
+			"Can't write to PCI bar (%" PRIu64 ") : offset (%x)\n",
+			VFIO_GET_REGION_IDX(p->offset), (int)offset);
 }
 
 int
Signature · 1 line
1.7.9.5
Acked-by on v8 4/4
#55 lore raw

Re: [PATCH v8 4/4] eal/linux: vfio: add pci ioport support

Quoted 79 lines

Include vfio map/rd/wr support for pci ioport.

---
v7->v8:
- Remove rte_pci_ioport malloc and rte_free()/unmap() func from v7.
- removed umap from git header.

 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c |   36 ++++++++++++++++++-------
---
 1 file changed, 24 insertions(+), 12 deletions(-)
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c +24 -12
index 4832313..9571ed8 100644
@@ -74,6 +74,7 @@ EAL_REGISTER_TAILQ(rte_vfio_tailq)
 #define VFIO_GROUP_FMT "/dev/vfio/%u"
 #define VFIO_NOIOMMU_GROUP_FMT "/dev/vfio/noiommu-%u"
 #define VFIO_GET_REGION_ADDR(x) ((uint64_t) x << 40ULL)
+#define VFIO_GET_REGION_IDX(x) (x >> 40)
 
 /* per-process VFIO config */
 static struct vfio_config vfio_cfg;
@@ -999,30 +1000,41 @@ int
 pci_vfio_ioport_map(struct rte_pci_device *dev, int bar,
 		    struct rte_pci_ioport *p)
 {
-	RTE_SET_USED(dev);
-	RTE_SET_USED(bar);
-	RTE_SET_USED(p);
-	return -1;
+	if (bar < VFIO_PCI_BAR0_REGION_INDEX ||
+	    bar > VFIO_PCI_BAR5_REGION_INDEX) {
+		RTE_LOG(ERR, EAL, "invalid bar (%d)!\n", bar);
+		return -1;
+	}
+
+	p->dev = dev;
+	p->offset = VFIO_GET_REGION_ADDR(bar);
+	return 0;
 }
 
 void
 pci_vfio_ioport_read(struct rte_pci_ioport *p,
 		     void *data, size_t len, off_t offset)
 {
-	RTE_SET_USED(p);
-	RTE_SET_USED(data);
-	RTE_SET_USED(len);
-	RTE_SET_USED(offset);
+	const struct rte_intr_handle *intr_handle = &p->dev->intr_handle;
+
+	if (pread64(intr_handle->vfio_dev_fd, data,
+		    len, p->offset + offset) <= 0)
+		RTE_LOG(ERR, EAL,
+			"Can't read from PCI bar (%" PRIu64 ") : offset
 (%x)\n",
+			VFIO_GET_REGION_IDX(p->offset), (int)offset);
 }
 
 void
 pci_vfio_ioport_write(struct rte_pci_ioport *p,
 		      const void *data, size_t len, off_t offset)
 {
-	RTE_SET_USED(p);
-	RTE_SET_USED(data);
-	RTE_SET_USED(len);
-	RTE_SET_USED(offset);
+	const struct rte_intr_handle *intr_handle = &p->dev->intr_handle;
+
+	if (pwrite64(intr_handle->vfio_dev_fd, data,
+		     len, p->offset + offset) <= 0)
+		RTE_LOG(ERR, EAL,
+			"Can't write to PCI bar (%" PRIu64 ") : offset (%x)\n",
+			VFIO_GET_REGION_IDX(p->offset), (int)offset);
 }
 
Quoted 3 lines

int
--
1.7.9.5

#56 lore raw

Re: [PATCH v8 4/4] eal/linux: vfio: add pci ioport support

Quoted 36 lines · Anatoly
Quoted 36 lines

Include vfio map/rd/wr support for pci ioport.

---
v7->v8:
- Remove rte_pci_ioport malloc and rte_free()/unmap() func from v7.
- removed umap from git header.

 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c |   36 ++++++++++++++++++-------
---
 1 file changed, 24 insertions(+), 12 deletions(-)
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c +4 -4
index 4832313..9571ed8 100644
@@ -74,6 +74,7 @@ EAL_REGISTER_TAILQ(rte_vfio_tailq)
 #define VFIO_GROUP_FMT "/dev/vfio/%u"
 #define VFIO_NOIOMMU_GROUP_FMT "/dev/vfio/noiommu-%u"
 #define VFIO_GET_REGION_ADDR(x) ((uint64_t) x << 40ULL)
+#define VFIO_GET_REGION_IDX(x) (x >> 40)
 
 /* per-process VFIO config */
 static struct vfio_config vfio_cfg;
@@ -999,30 +1000,41 @@ int
 pci_vfio_ioport_map(struct rte_pci_device *dev, int bar,
                  struct rte_pci_ioport *p)
 {
-     RTE_SET_USED(dev);
-     RTE_SET_USED(bar);
-     RTE_SET_USED(p);
-     return -1;
+     if (bar < VFIO_PCI_BAR0_REGION_INDEX ||
+         bar > VFIO_PCI_BAR5_REGION_INDEX) {
+             RTE_LOG(ERR, EAL, "invalid bar (%d)!\n", bar);
Quoted 8 lines

lib/librte_eal/linuxapp/eal/eal_pci_vfio.c int · line 1013

Quoted 8 lines
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c +6 -0
+             return -1;
+     }
+
+     p->dev = dev;
+     p->offset = VFIO_GET_REGION_ADDR(bar);
+     return 0;
 }
 

I still think we don't need this p->dev = dev.
But that's not important.

Quoted 1 line
Signature · 1 line
David Marchand
#57 lore raw

Re: [PATCH v8 4/4] eal/linux: vfio: add pci ioport support

Quoted 51 lines · David Marchand
Quoted 36 lines · Anatoly
Quoted 36 lines

Include vfio map/rd/wr support for pci ioport.

---
v7->v8:
- Remove rte_pci_ioport malloc and rte_free()/unmap() func from v7.
- removed umap from git header.

 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c |   36 ++++++++++++++++++-------
---
 1 file changed, 24 insertions(+), 12 deletions(-)
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c +4 -4
index 4832313..9571ed8 100644
@@ -74,6 +74,7 @@ EAL_REGISTER_TAILQ(rte_vfio_tailq)
 #define VFIO_GROUP_FMT "/dev/vfio/%u"
 #define VFIO_NOIOMMU_GROUP_FMT "/dev/vfio/noiommu-%u"
 #define VFIO_GET_REGION_ADDR(x) ((uint64_t) x << 40ULL)
+#define VFIO_GET_REGION_IDX(x) (x >> 40)
 
 /* per-process VFIO config */
 static struct vfio_config vfio_cfg;
@@ -999,30 +1000,41 @@ int
 pci_vfio_ioport_map(struct rte_pci_device *dev, int bar,
                  struct rte_pci_ioport *p)
 {
-     RTE_SET_USED(dev);
-     RTE_SET_USED(bar);
-     RTE_SET_USED(p);
-     return -1;
+     if (bar < VFIO_PCI_BAR0_REGION_INDEX ||
+         bar > VFIO_PCI_BAR5_REGION_INDEX) {
+             RTE_LOG(ERR, EAL, "invalid bar (%d)!\n", bar);
Quoted 8 lines

lib/librte_eal/linuxapp/eal/eal_pci_vfio.c int · line 1013

Quoted 8 lines
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c +6 -0
+             return -1;
+     }
+
+     p->dev = dev;
+     p->offset = VFIO_GET_REGION_ADDR(bar);
+     return 0;
 }
 

I still think we don't need this p->dev = dev.
But that's not important.

Quoted 4 lines
Quoted 1 line

Thomas, Can you pl. merge this patch?

Quoted 3 lines

--
David Marchand

#58 lore raw

Re: [PATCH v8 4/4] eal/linux: vfio: add pci ioport support

2016-02-18 10:55, Santosh Shukla:

Quoted 6 lines
Quoted 4 lines
Quoted 1 line

Thomas, Can you pl. merge this patch?

I must merge the whole series but there are still some comments to address. If you want to split the series, you're allowed to do it by re-sending a subset. Please use --in-reply-to as much as possible to keep all related patches in the same thread.