rtc: enable adjustment of clock offset
Subsystems (3)
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.
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
@@ -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.
PATCH v2 2/8 rtc-pcf2123: clean up reads from the chip
In reply to Joshua ClaytonPut 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
@@ -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, ®,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.
PATCH v2 3/8 rtc-pcf2123: clean up writes to the rtc chip
In reply to Joshua ClaytonAdd 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
@@ -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.
PATCH v2 4/8 rtc-pcf2123: refactor chip reset into a function
In reply to Joshua ClaytonRefactor 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
@@ -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.
PATCH v2 5/8 rtc-pcf2123: avoid resetting the clock if possible
In reply to Joshua Claytonpcf2123 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
@@ -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.
PATCH v2 6/8 rtc: Add functions to set and read clock offset
In reply to Joshua ClaytonA 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
@@ -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
@@ -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.
PATCH v2 7/8 rtc: implement a sysfs interface for clock offset
In reply to Joshua ClaytonThe 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
@@ -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
@@ -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.
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_offsetorset_offsetimplemented, 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
Signed-off-by Joshua Clayton <[email protected]>--- drivers/rtc/interface.c | 2 +- drivers/rtc/rtc-sysfs.c | 29 +++++++++++++++++++++++++++++ 2 files changed, 30 insertions(+), 1 deletion(-)drivers/rtc/interface.c +1
-1@@ -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@@ -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.
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_offsetorset_offsetimplemented, 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.
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.
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
@@ -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
@@ -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.
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
@@ -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
@@ -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.
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 haveset_offsetimplemented.Signed-off-by Joshua Clayton <[email protected]>--- Documentation/rtc.txt | 6 ++++++ drivers/rtc/rtc-sysfs.c | 35 ++++++++++++++++++++++++++++++++++- 2 files changed, 40 insertions(+), 1 deletion(-)Documentation/rtc.txt +6
-0@@ -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@@ -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.
PATCH v3 3/3 rtc-pcf2123: implement read_offset and set_offset
In reply to Joshua Claytonpcf2123 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
@@ -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 , ®,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.
Re: [PATCH v3 1/3] rtc: Add functions to set and read rtc offset
In reply to Joshua ClaytonHi,
Quoted 22 lines · Joshua Clayton
drivers/rtc/interface.c +14
-0@@ -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@@ -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.
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@@ -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 testrtc->ops->read_offsetinstead.
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), returndrivers/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@@ -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_SIZE20include/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); voidrtc_timer_cancel(struct rtc_device *rtc, struct rtc_timer *timer); +intrtc_read_offset(struct rtc_device *rtc, long *offset); +intrtc_set_offset(struct rtc_device *rtc, long offset); voidrtc_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.
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 testrtc->ops->read_offsetinstead.
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.
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
@@ -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
@@ -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.
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
@@ -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
@@ -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.
PATCH v4 3/3 rtc-pcf2123: implement read_offset and set_offset
In reply to Joshua Claytonpcf2123 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
@@ -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 , ®,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.
Re: [PATCH v4 1/3] rtc: Add functions to set and read rtc offset
In reply to Joshua ClaytonOn 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
Signed-off-by Joshua Clayton <[email protected]>--- drivers/rtc/interface.c | 54+++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/rtc.h| 4 ++++ 2 files changed, 58 insertions(+)drivers/rtc/interface.c +0
-0@@ -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.
+ * Ifread_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), returndrivers/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@@ -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_SIZE20include/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(structrtc_device*rtc, structrtc_timer
*timer); +intrtc_read_offset(struct rtc_device *rtc, long *offset); +intrtc_set_offset(struct rtc_device *rtc, long offset);
voidrtc_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.
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. Thertc_read_offsetfunction checks for aread_offsetfunction and returns-EINVALif 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.
PATCH v2 8/8 rtc-pcf2123: implement read_offset and set_offset
In reply to Joshua Claytonpcf2123 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
@@ -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 , ®,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.
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 theBIT()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.
- MoveOSC_HAS_STOPPEDcheck intopcf2123_rtc_read_time, and get rid ofpcf2123_time_valid()
- Drop patches refactoring pcf2123 sysfs.
- Add rtc interface and rtc sysfs file for clock offsetJoshua 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: implementread_offsetandset_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.
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 theBIT()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.
- MoveOSC_HAS_STOPPEDcheck intopcf2123_rtc_read_time, and get rid ofpcf2123_time_valid()
- Drop patches refactoring pcf2123 sysfs.
- Add rtc interface and rtc sysfs file for clock offsetJoshua 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: implementread_offsetandset_offsetQuoted 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.
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
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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
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
@@ -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
PATCH v6 3/8 eal/linux: never check iopl for arm
In reply to Santosh Shuklaiopl() 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
@@ -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
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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH v6 5/8 virtio: move io header and api from virtio_pci.h
In reply to Santosh ShuklaMoving 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
@@ -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
@@ -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
@@ -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
PATCH v6 6/8 virtio: add vfio api to rd/wr ioport space
In reply to Santosh ShuklaFor 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
@@ -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
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.
Signed-off-by Santosh Shukla <[email protected]>Signed-off-by Rizwan Ansari <[email protected]>Signed-off-by Rakesh Krishnamurthy <[email protected]>---
v5-->v6:
- renamed inport_in/out to vfio_in/out
- Renamed file fromvirtio_vfio_rw.htovirtio_vfio_io.hdrivers/net/virtio/virtio_vfio_io.h | 104 +++++++++++++++++++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 drivers/net/virtio/virtio_vfio_io.hdrivers/net/virtio/virtio_vfio_io.h new file +0
-0
...
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
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.
Signed-off-by Santosh Shukla <[email protected]>Signed-off-by Rizwan Ansari <[email protected]>Signed-off-by Rakesh Krishnamurthy <[email protected]>---
v5-->v6:
- renamed inport_in/out to vfio_in/out
- Renamed file fromvirtio_vfio_rw.htovirtio_vfio_io.hdrivers/net/virtio/virtio_vfio_io.h | 104 +++++++++++++++++++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 drivers/net/virtio/virtio_vfio_io.hdrivers/net/virtio/virtio_vfio_io.h new file +0
-0...
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.
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
__noiommusuffix not required, atleast forrte_xx_drvstruct{}, as because sooner than later we'll have virtio working for both flavours ie... iommu/noiommu. My only worry was parsing for_noiommuand 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 onlydrv->kdrv==RTE_KDRV_VFIOso 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
- replacesys/io.hentirely
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
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
__noiommusuffix not required, atleast forrte_xx_drvstruct{}, as because sooner than later we'll have virtio working for both flavours ie... iommu/noiommu. My only worry was parsing for_noiommuand 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 onlydrv->kdrv==RTE_KDRV_VFIOso 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
- replacesys/io.hentirelyHmm, 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
PATCH v6 7/8 virtio: extend pci rw api for vfio
In reply to Santosh ShuklaSo 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
@@ -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
PATCH v6 8/8 virtio: do not parse if interface is vfio
In reply to Santosh ShuklaIf 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
@@ -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
Re: [PATCH v6 1/8] eal: pci: add api to rd/wr pci bar region
In reply to Santosh ShuklaQuoted 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_barSigned-off-by Santosh Shukla <[email protected]>---
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
...
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) {
--yliuRe: [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_barSigned-off-by Santosh Shukla <[email protected]>---
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...
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
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_barwhich 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 topci_barsw/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
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_barwhich 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 topci_barsw/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
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_barwhich 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 topci_barsw/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
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_barwhich 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 topci_barsw/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
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_barwhich 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 topci_barsw/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 consideringIGB_UIO,UIO_GENERICandNIC_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
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_barwhich 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 topci_barsw/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 consideringIGB_UIO,UIO_GENERICandNIC_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_tlen,off_toffset,
intbar_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
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_barwhich 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 topci_barsw/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 consideringIGB_UIO,UIO_GENERICandNIC_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_tlen,off_toffset,
intbar_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
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
Re: [PATCH v6 1/8] eal: pci: add api to rd/wr pci bar region
In reply to Santosh ShuklaQuoted 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_barwhich 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 topci_barsw/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 consideringIGB_UIO,UIO_GENERICandNIC_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_tlen,off_toffset,
intbar_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
Re: [PATCH v6 1/8] eal: pci: add api to rd/wr pci bar region
In reply to Yuanhan LiuQuoted 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_barwhich 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 topci_barsw/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
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_barwhich 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 topci_barsw/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
PATCH v8 3/4 eal/linux: vfio: ignore mapping for ioport region
In reply to a message not in the archivevfio_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
@@ -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
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
@@ -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
Re: [PATCH v8 4/4] eal/linux: vfio: add pci ioport support
Quoted 79 lines
Include vfio map/rd/wr support for pci ioport.
Signed-off-by Santosh Shukla <[email protected]>---
v7->v8:
- Removerte_pci_ioportmalloc 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@@ -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
David Marchand
Acked-byRe: [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.
Signed-off-by Santosh Shukla <[email protected]>---
v7->v8:
- Removerte_pci_ioportmalloc 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@@ -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
Acked-by Anatoly Burakov <[email protected]>
Signature · 1 line
David Marchand
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.
Signed-off-by Santosh Shukla <[email protected]>---
v7->v8:
- Removerte_pci_ioportmalloc 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@@ -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
Acked-by Anatoly Burakov <[email protected]>Acked-by David Marchand <[email protected]>
Thomas, Can you pl. merge this patch?
Quoted 3 lines
--
David Marchand
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
Acked-by Anatoly Burakov <[email protected]>Acked-by David Marchand <[email protected]>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.