From: Peter H. <Pet...@gm...> - 2012-09-02 20:41:55
|
Hi, I'm curious if there have ever been any attempts to emulate i2c devices under uml in order to facilitate driver development by using stub drivers. If there weren't any attemps yet, what to you thing would be the best strategy to achieve this goal? Are there any good starting points? The main thing I'm lacking is a good idea how to register the 'stub devices'. Or is this something that is not really desired by the uml project? Thanks, Peter |
From: Richard W. <ri...@no...> - 2012-09-03 12:52:59
Attachments:
signature.asc
|
Am 02.09.2012 22:45, schrieb Peter Hüwe: > I'm curious if there have ever been any attempts to emulate i2c devices under > uml in order to facilitate driver development by using stub drivers. I know none. > If there weren't any attemps yet, what to you thing would be the best strategy > to achieve this goal? > Are there any good starting points? > The main thing I'm lacking is a good idea how to register the 'stub devices'. Look at any i2c driver. Implement the i2c driver interface and instead of directly writing to hardware registers write to something else. Same for read... E.g. Your i2c emulator could have a TCP back-end. Host<->Guest i2c pass-through is also possible. BTW: All this is not UML specific. Iff it makes sense for only UML we can put it into arch/um/drivers/. Otherwise drivers/ is fine. > Or is this something that is not really desired by the uml project? If there is a use case, why not. :-) Thanks, //richard |
From: Peter H. <Pet...@gm...> - 2012-09-09 01:04:21
|
Hi Richard, sorry for the late reply. > > I'm curious if there have ever been any attempts to emulate i2c devices > > under uml in order to facilitate driver development by using stub > > drivers. > I know none. > If there is a use case, why not. :-) Thanks for your encouraging words ;) I had a look around and found the nice CONFIG_I2C_STUB driver, which is described in detail at http://www.kernel.org/doc/Documentation/i2c/i2c-stub """This module is a very simple fake I2C/SMBus driver. It implements five types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, (r/w) word data, and (r/w) I2C block data.""" which more or less exactly fits my need. The only thing that was missing was general support for I2C which is dependent on CONFIG_HAS_IOMEM which unfortunately isn't available on UML, but I simply added a || UML to the Kconfig and was now able to build the I2C Support, the i2c-dev module (for userspace access) and the i2c-stub driver. If I know load the i2c_stub module I have a emulated i2c device ;) I adapted the stub driver to my needs and was now able to create my own emulated i2c device and start with driver and tools development for it ;) I added the patch, in case you're interested. Unfortunately some I2C drivers fail to build if CONFIG_HAS_IOMEM = n, but don't have that dependency in Kconfig - I simply added it to prevent them from inclusion. Do you think I should try to push this mainline via the i2c subsystem? Thanks, Peter |
From: Geert U. <ge...@li...> - 2012-09-09 08:13:49
|
Hi Peter, On Sun, Sep 9, 2012 at 3:08 AM, Peter Hüwe <Pet...@gm...> wrote: >> > I'm curious if there have ever been any attempts to emulate i2c devices >> > under uml in order to facilitate driver development by using stub >> > drivers. >> I know none. > >> If there is a use case, why not. :-) > Thanks for your encouraging words ;) > > I had a look around and found the nice CONFIG_I2C_STUB driver, > which is described in detail at > http://www.kernel.org/doc/Documentation/i2c/i2c-stub > > """This module is a very simple fake I2C/SMBus driver. It implements five > types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, (r/w) > word data, and (r/w) I2C block data.""" > which more or less exactly fits my need. > > The only thing that was missing was general support for I2C which is dependent > on CONFIG_HAS_IOMEM which unfortunately isn't available on UML, > but I simply added a || UML to the Kconfig and was now able to build the I2C > Support, the i2c-dev module (for userspace access) and the i2c-stub driver. Yes, that's what you typically have to do to get such a thing working. JFYI, on several occasions, I worked on Amiga Zorro bus probing under UML, using fake Zorro devices and real but stubbed network and frame buffer drivers. > If I know load the i2c_stub module I have a emulated i2c device ;) > > I adapted the stub driver to my needs and was now able to create my own > emulated i2c device and start with driver and tools development for it ;) > > > I added the patch, in case you're interested. > > Unfortunately some I2C drivers fail to build if CONFIG_HAS_IOMEM = n, but > don't have that dependency in Kconfig - I simply added it to prevent them from > inclusion. That's because they rely on the HAS_IOMEM dependency for the whole subsystem. In fact, I'm surprised you didn't have to add HAS_IOMEM dependencies to more drivers. > Do you think I should try to push this mainline via the i2c subsystem? As long as there are no "real" i2c drivers for UML, but only dummy/development ones, that is up to the i2c maintainer (in CC). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Peter H. <Pet...@gm...> - 2012-09-09 10:45:16
|
Hi Geert, > That's because they rely on the HAS_IOMEM dependency for the whole > subsystem. In fact, I'm surprised you didn't have to add HAS_IOMEM > dependencies to more drivers. I changed only the ones which are available in UML. I now rewrote the patch to remove the global dependency and move it to all the drivers that really rely on HAS_IOMEM - see below. > > Do you think I should try to push this mainline via the i2c subsystem? > As long as there are no "real" i2c drivers for UML, but only > dummy/development ones, > that is up to the i2c maintainer (in CC). Nevertheless it would probably be a good starting point for developers - if a subsystem is available the probability that someone hacks on it is much higher ;) Thanks, Peter --- From 25268d4cdd4b1dd1e5d03c9b90c179758dd41e2e Mon Sep 17 00:00:00 2001 From: Peter Huewe <pet...@gm...> Date: Sun, 9 Sep 2012 03:03:29 +0200 Subject: [PATCH] i2c: Fix/Change dependencies to make I2C available on UML This patch removes the global dependency of the I2C subsystem on HAS_IOMEM and moves the dependency to the drivers which really rely on HAS_IOMEM. The generic I2C part does not need to have HAS_IOMEM set and thus now becomes available in UML so the I2C subsystem can now be used, e.g. by the i2c-stub driver, for development of I2C device drivers. Signed-off-by: Peter Huewe <pet...@gm...> --- drivers/i2c/Kconfig | 1 - drivers/i2c/busses/Kconfig | 60 ++++++++++++++++++++++++++----------------- 2 files changed, 36 insertions(+), 25 deletions(-) diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index 5a3bb3d..e4e02e2 100644 --- a/drivers/i2c/Kconfig +++ b/drivers/i2c/Kconfig @@ -4,7 +4,6 @@ menuconfig I2C tristate "I2C support" - depends on HAS_IOMEM select RT_MUTEXES ---help--- I2C (pronounce: I-squared-C) is a slow serial bus protocol used in diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index b4aaa1b..27d1d98 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -79,6 +79,7 @@ config I2C_AMD8111 config I2C_I801 tristate "Intel 82801 (ICH/PCH)" depends on PCI + depends on HAS_IOMEM select CHECK_SIGNATURE if X86 && DMI help If you say yes to this option, support will be included for the Intel @@ -264,7 +265,7 @@ comment "Mac SMBus host controller drivers" config I2C_HYDRA tristate "CHRP Apple Hydra Mac I/O I2C interface" - depends on PCI && PPC_CHRP && EXPERIMENTAL + depends on PCI && PPC_CHRP && EXPERIMENTAL && HAS_IOMEM select I2C_ALGOBIT help This supports the use of the I2C interface in the Apple Hydra Mac @@ -291,6 +292,7 @@ comment "I2C system bus drivers (mostly embedded / system- on-chip)" config I2C_AT91 tristate "Atmel AT91 I2C Two-Wire interface (TWI)" depends on ARCH_AT91 && EXPERIMENTAL && BROKEN + depends on HAS_IOMEM help This supports the use of the I2C interface on Atmel AT91 processors. @@ -305,7 +307,7 @@ config I2C_AT91 config I2C_AU1550 tristate "Au1550/Au1200/Au1300 SMBus interface" - depends on MIPS_ALCHEMY + depends on MIPS_ALCHEMY && HAS_IOMEM help If you say yes to this option, support will be included for the Au1550/Au1200/Au1300 SMBus interface. @@ -315,7 +317,7 @@ config I2C_AU1550 config I2C_BLACKFIN_TWI tristate "Blackfin TWI I2C support" - depends on BLACKFIN + depends on BLACKFIN && HAS_IOMEM depends on !BF561 && !BF531 && !BF532 && !BF533 help This is the I2C bus driver for Blackfin on-chip TWI interface. @@ -343,7 +345,7 @@ config I2C_CPM config I2C_DAVINCI tristate "DaVinci I2C driver" - depends on ARCH_DAVINCI + depends on ARCH_DAVINCI && HAS_IOMEM help Support for TI DaVinci I2C controller driver. @@ -356,7 +358,7 @@ config I2C_DAVINCI config I2C_DESIGNWARE_PLATFORM tristate "Synopsys DesignWare Platform" - depends on HAVE_CLK + depends on HAVE_CLK && HAS_IOMEM help If you say yes to this option, support will be included for the Synopsys DesignWare I2C adapter. Only master mode is supported. @@ -366,7 +368,7 @@ config I2C_DESIGNWARE_PLATFORM config I2C_DESIGNWARE_PCI tristate "Synopsys DesignWare PCI" - depends on PCI + depends on PCI && HAS_IOMEM help If you say yes to this option, support will be included for the Synopsys DesignWare I2C adapter. Only master mode is supported. @@ -399,7 +401,7 @@ config I2C_GPIO config I2C_HIGHLANDER tristate "Highlander FPGA SMBus interface" - depends on SH_HIGHLANDER + depends on SH_HIGHLANDER && HAS_IOMEM help If you say yes to this option, support will be included for the SMBus interface located in the FPGA on various Highlander @@ -421,7 +423,7 @@ config I2C_IBM_IIC config I2C_IMX tristate "IMX I2C interface" - depends on ARCH_MXC + depends on ARCH_MXC && HAS_IOMEM help Say Y here if you want to use the IIC bus controller on the Freescale i.MX/MXC processors. @@ -431,7 +433,7 @@ config I2C_IMX config I2C_INTEL_MID tristate "Intel Moorestown/Medfield Platform I2C controller" - depends on PCI + depends on PCI && HAS_IOMEM help Say Y here if you have an Intel Moorestown/Medfield platform I2C controller. @@ -442,6 +444,7 @@ config I2C_INTEL_MID config I2C_IOP3XX tristate "Intel IOPx3xx and IXP4xx on-chip I2C interface" depends on ARCH_IOP32X || ARCH_IOP33X || ARCH_IXP4XX || ARCH_IOP13XX + depends on HAS_IOMEM help Say Y here if you want to use the IIC bus controller on the Intel IOPx3xx I/O Processors or IXP4xx Network Processors. @@ -451,7 +454,7 @@ config I2C_IOP3XX config I2C_MPC tristate "MPC107/824x/85xx/512x/52xx/83xx/86xx" - depends on PPC + depends on PPC && HAS_IOMEM help If you say yes to this option, support will be included for the built-in I2C interface on the MPC107, Tsi107, MPC512x, MPC52xx, @@ -463,6 +466,7 @@ config I2C_MPC config I2C_MV64XXX tristate "Marvell mv64xxx I2C Controller" depends on (MV64X60 || PLAT_ORION) + depends on HAS_IOMEM help If you say yes to this option, support will be included for the built-in I2C interface on the Marvell 64xxx line of host bridges. @@ -473,6 +477,7 @@ config I2C_MV64XXX config I2C_MXS tristate "Freescale i.MX28 I2C interface" depends on SOC_IMX28 + depends on HAS_IOMEM select STMP_DEVICE help Say Y here if you want to use the I2C bus controller on @@ -483,7 +488,7 @@ config I2C_MXS config I2C_NOMADIK tristate "ST-Ericsson Nomadik/Ux500 I2C Controller" - depends on ARM_AMBA + depends on ARM_AMBA && HAS_IOMEM help If you say yes to this option, support will be included for the I2C interface from ST-Ericsson's Nomadik and Ux500 architectures, @@ -491,14 +496,14 @@ config I2C_NOMADIK config I2C_NUC900 tristate "NUC900 I2C Driver" - depends on ARCH_W90X900 + depends on ARCH_W90X900 && HAS_IOMEM help Say Y here to include support for I2C controller in the Winbond/Nuvoton NUC900 based System-on-Chip devices. config I2C_OCORES tristate "OpenCores I2C Controller" - depends on EXPERIMENTAL + depends on EXPERIMENTAL && HAS_IOMEM help If you say yes to this option, support will be included for the OpenCores I2C controller. For details see @@ -509,7 +514,7 @@ config I2C_OCORES config I2C_OMAP tristate "OMAP I2C adapter" - depends on ARCH_OMAP + depends on ARCH_OMAP && HAS_IOMEM default y if MACH_OMAP_H3 || MACH_OMAP_OSK help If you say yes to this option, support will be included for the @@ -525,6 +530,7 @@ config I2C_PASEMI config I2C_PCA_PLATFORM tristate "PCA9564/PCA9665 as platform device" + depends on HAS_IOMEM select I2C_ALGOPCA default n help @@ -536,7 +542,7 @@ config I2C_PCA_PLATFORM config I2C_PMCMSP tristate "PMC MSP I2C TWI Controller" - depends on PMC_MSP + depends on PMC_MSP && HAS_IOMEM help This driver supports the PMC TWI controller on MSP devices. @@ -546,6 +552,7 @@ config I2C_PMCMSP config I2C_PNX tristate "I2C bus support for Philips PNX and NXP LPC targets" depends on ARCH_PNX4008 || ARCH_LPC32XX + depends on HAS_IOMEM help This driver supports the Philips IP3204 I2C IP block master and/or slave controller @@ -567,6 +574,7 @@ config I2C_PUV3 config I2C_PXA tristate "Intel PXA2XX I2C adapter" depends on ARCH_PXA || ARCH_MMP || (X86_32 && PCI && OF) + depends on HAS_IOMEM help If you have devices in the PXA I2C bus, say yes to this option. This driver can also be built as a module. If so, the module @@ -592,14 +600,14 @@ config HAVE_S3C2410_I2C config I2C_S3C2410 tristate "S3C2410 I2C Driver" - depends on HAVE_S3C2410_I2C + depends on HAVE_S3C2410_I2C && HAS_IOMEM help Say Y here to include support for I2C controller in the Samsung SoCs. config I2C_S6000 tristate "S6000 I2C support" - depends on XTENSA_VARIANT_S6000 + depends on XTENSA_VARIANT_S6000 && HAS_IOMEM help This driver supports the on chip I2C device on the S6000 xtensa processor family. @@ -610,6 +618,7 @@ config I2C_S6000 config I2C_SH7760 tristate "Renesas SH7760 I2C Controller" depends on CPU_SUBTYPE_SH7760 + depends on HAS_IOMEM help This driver supports the 2 I2C interfaces on the Renesas SH7760. @@ -619,6 +628,7 @@ config I2C_SH7760 config I2C_SH_MOBILE tristate "SuperH Mobile I2C Controller" depends on SUPERH || ARCH_SHMOBILE + depends on HAS_IOMEM help If you say yes to this option, support will be included for the built-in I2C interface on the Renesas SH-Mobile processor. @@ -628,6 +638,7 @@ config I2C_SH_MOBILE config I2C_SIMTEC tristate "Simtec Generic I2C interface" + depends on HAS_IOMEM select I2C_ALGOBIT help If you say yes to this option, support will be included for @@ -640,7 +651,7 @@ config I2C_SIMTEC config I2C_SIRF tristate "CSR SiRFprimaII I2C interface" - depends on ARCH_PRIMA2 + depends on ARCH_PRIMA2 && HAS_IOMEM help If you say yes to this option, support will be included for the CSR SiRFprimaII I2C interface. @@ -650,7 +661,7 @@ config I2C_SIRF config I2C_STU300 tristate "ST Microelectronics DDC I2C interface" - depends on MACH_U300 + depends on MACH_U300 && HAS_IOMEM default y if MACH_U300 help If you say yes to this option, support will be included for the @@ -663,7 +674,7 @@ config I2C_STU300 config I2C_TEGRA tristate "NVIDIA Tegra internal I2C controller" - depends on ARCH_TEGRA + depends on ARCH_TEGRA && HAS_IOMEM help If you say yes to this option, support will be included for the I2C controller embedded in NVIDIA Tegra SOCs @@ -671,6 +682,7 @@ config I2C_TEGRA config I2C_VERSATILE tristate "ARM Versatile/Realview I2C bus support" depends on ARCH_VERSATILE || ARCH_REALVIEW || ARCH_VEXPRESS + depends on HAS_IOMEM select I2C_ALGOBIT help Say yes if you want to support the I2C serial bus on ARMs Versatile @@ -681,7 +693,7 @@ config I2C_VERSATILE config I2C_OCTEON tristate "Cavium OCTEON I2C bus support" - depends on CPU_CAVIUM_OCTEON + depends on CPU_CAVIUM_OCTEON && HAS_IOMEM help Say yes if you want to support the I2C serial bus on Cavium OCTEON SOC. @@ -701,7 +713,7 @@ config I2C_XILINX config I2C_XLR tristate "XLR I2C support" - depends on CPU_XLR + depends on CPU_XLR && HAS_IOMEM help This driver enables support for the on-chip I2C interface of the Netlogic XLR/XLS MIPS processors. @@ -772,7 +784,7 @@ config I2C_PARPORT_LIGHT config I2C_TAOS_EVM tristate "TAOS evaluation module" - depends on EXPERIMENTAL + depends on EXPERIMENTAL && HAS_IOMEM select SERIO select SERIO_SERPORT default n @@ -811,7 +823,7 @@ config I2C_ACORN config I2C_ELEKTOR tristate "Elektor ISA card" - depends on ISA && HAS_IOPORT && BROKEN_ON_SMP + depends on ISA && HAS_IOPORT && BROKEN_ON_SMP && HAS_IOMEM select I2C_ALGOPCF help This supports the PCF8584 ISA bus I2C adapter. Say Y if you own -- 1.7.8.6 |
From: Jean D. <kh...@li...> - 2012-09-09 11:51:20
|
Hi all, Thanks for the info. I thought UML was no longer used with all the virtualization solutions available, but apparently I was wrong. On Sun, 9 Sep 2012 12:49:03 +0200, Peter Hüwe wrote: > > That's because they rely on the HAS_IOMEM dependency for the whole > > subsystem. In fact, I'm surprised you didn't have to add HAS_IOMEM > > dependencies to more drivers. > I changed only the ones which are available in UML. > I now rewrote the patch to remove the global dependency and move it to all the > drivers that really rely on HAS_IOMEM - see below. My bet is that all I2C bus drivers do use I/O or memory mapped operations directly or indirectly, except i2c-stub. So it would probably make more sense, and be a less intrusive change, to move the HAS_IOMEM dependency to drivers/i2c/busses, and move (logically or for real) i2c-stub out of it. Or are there really other I2C bus drivers which make sense to enable under UML? Are there other subsystems where the HAS_IOMEM dependency is at the individual driver level? -- Jean Delvare |
From: Peter H. <Pet...@gm...> - 2012-09-09 12:11:12
|
Am Sonntag, 9. September 2012, 13:28:38 schrieb Jean Delvare: > Thanks for the info. I thought UML was no longer used with all the > virtualization solutions available, but apparently I was wrong. I guess it's mainly used for sandboxing, testing and development ;) > My bet is that all I2C bus drivers do use I/O or memory mapped > operations directly or indirectly, except i2c-stub. So it would > probably make more sense, and be a less intrusive change, to move the > HAS_IOMEM dependency to drivers/i2c/busses, and move (logically or for > real) i2c-stub out of it. > > Or are there really other I2C bus drivers which make sense to enable > under UML? The only other available in UML which doesn't rely on HAS_IOMEM is the PARPORT_LIGHT which relies on direct io access - so I guess this one doesn't make sense either. I created a patch for your proposed solution, I moved the stub driver to the end in order to have only one big if HAS_IOMEM. Thanks, Peter --- From 923bc2feac0a04ee35382e60bb523d08baf92d48 Mon Sep 17 00:00:00 2001 From: Peter Huewe <pet...@gm...> Date: Sun, 9 Sep 2012 14:10:05 +0200 Subject: [PATCH] i2c: Move HAS_IOMEM dependency to i2c/busses to make I2C available on UML This patch removes the global dependency of the I2C subsystem on HAS_IOMEM and moves the dependency to the i2c/busses submenu, with an exception for i2c-stub. The generic I2C part does not need to have HAS_IOMEM set and thus now becomes available in UML, so the I2C subsystem can now be used, e.g. by the i2c-stub driver, for development of I2C device drivers. Signed-off-by: Peter Huewe <pet...@gm...> --- drivers/i2c/Kconfig | 1 - drivers/i2c/busses/Kconfig | 28 +++++++++++++++------------- 2 files changed, 15 insertions(+), 14 deletions(-) diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index 5a3bb3d..e4e02e2 100644 --- a/drivers/i2c/Kconfig +++ b/drivers/i2c/Kconfig @@ -4,7 +4,6 @@ menuconfig I2C tristate "I2C support" - depends on HAS_IOMEM select RT_MUTEXES ---help--- I2C (pronounce: I-squared-C) is a slow serial bus protocol used in diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index b4aaa1b..84954de 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -4,6 +4,7 @@ menu "I2C Hardware Bus support" +if HAS_IOMEM comment "PC SMBus host controller drivers" depends on PCI @@ -843,19 +844,6 @@ config I2C_SIBYTE help Supports the SiByte SOC on-chip I2C interfaces (2 channels). -config I2C_STUB - tristate "I2C/SMBus Test Stub" - depends on EXPERIMENTAL && m - default 'n' - help - This module may be useful to developers of SMBus client drivers, - especially for certain kinds of sensor chips. - - If you do build this module, be sure to read the notes and warnings - in <file:Documentation/i2c/i2c-stub>. - - If you don't know what to do here, definitely say N. - config SCx200_I2C tristate "NatSemi SCx200 I2C using GPIO pins (DEPRECATED)" depends on SCx200_GPIO @@ -898,5 +886,19 @@ config SCx200_ACB This support is also available as a module. If so, the module will be called scx200_acb. +endif + +config I2C_STUB + tristate "I2C/SMBus Test Stub" + depends on EXPERIMENTAL && m + default 'n' + help + This module may be useful to developers of SMBus client drivers, + especially for certain kinds of sensor chips. + + If you do build this module, be sure to read the notes and warnings + in <file:Documentation/i2c/i2c-stub>. + + If you don't know what to do here, definitely say N. endmenu -- 1.7.8.6 |
From: Geert U. <ge...@li...> - 2012-09-09 12:21:29
|
On Sun, Sep 9, 2012 at 2:15 PM, Peter Hüwe <Pet...@gm...> wrote: >> My bet is that all I2C bus drivers do use I/O or memory mapped >> operations directly or indirectly, except i2c-stub. So it would >> probably make more sense, and be a less intrusive change, to move the >> HAS_IOMEM dependency to drivers/i2c/busses, and move (logically or for >> real) i2c-stub out of it. >> >> Or are there really other I2C bus drivers which make sense to enable >> under UML? > The only other available in UML which doesn't rely on HAS_IOMEM is the > PARPORT_LIGHT which relies on direct io access - so I guess this one doesn't > make sense either. > > I created a patch for your proposed solution, I moved the stub driver to the > end in order to have only one big if HAS_IOMEM. I was just going to comment that adding "&& HAS_IOMEM" doesn't make much sense for e.g. "depends on PPC", as we know PPC always has HAS_IOMEM. Only s390, PCI-less tile, and UML don't have HAS_IOMEM. Doing it in the submenu is indeed better. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Richard W. <ri...@no...> - 2012-09-09 12:23:20
Attachments:
signature.asc
|
Am 09.09.2012 14:15, schrieb Peter Hüwe: > Am Sonntag, 9. September 2012, 13:28:38 schrieb Jean Delvare: >> Thanks for the info. I thought UML was no longer used with all the >> virtualization solutions available, but apparently I was wrong. > I guess it's mainly used for sandboxing, testing and development ;) It's mostly used where KVM does not work. For example low end i586 servers in schools. Using UML you can still run 10+ instances on a P3 with 512MiB ram. > >> My bet is that all I2C bus drivers do use I/O or memory mapped >> operations directly or indirectly, except i2c-stub. So it would >> probably make more sense, and be a less intrusive change, to move the >> HAS_IOMEM dependency to drivers/i2c/busses, and move (logically or for >> real) i2c-stub out of it. >> >> Or are there really other I2C bus drivers which make sense to enable >> under UML? > The only other available in UML which doesn't rely on HAS_IOMEM is the > PARPORT_LIGHT which relies on direct io access - so I guess this one doesn't > make sense either. > > I created a patch for your proposed solution, I moved the stub driver to the > end in order to have only one big if HAS_IOMEM. UML does not have IO_MEM but some sub-systems have "depend HAS_IOMEM" which is often too coarse grained. To deal with that I've introduced GENERIC_IO some time ago to support MTD (and nandsim) on UML. Maybe some parts of the I2C sub-system can also just depend on GENERIC_IO instead of HAS_IOMEM. An arch has GENERIC_IO=y if it supports everything defined in generic-asm/io.h which is more than enough for most stub drivers. Please look at this patch series: https://lkml.org/lkml/2012/2/6/489 I'm sure it will help you in bringing I2C to UML. Thanks, //richard |
From: Peter H. <Pet...@gm...> - 2012-09-09 12:48:33
|
Am Sonntag, 9. September 2012, 14:23:06 schrieb Richard Weinberger: > UML does not have IO_MEM but some sub-systems have "depend HAS_IOMEM" which > is often too coarse grained. > To deal with that I've introduced GENERIC_IO some time ago to support MTD > (and nandsim) on UML. > Maybe some parts of the I2C sub-system can also just depend on GENERIC_IO > instead of HAS_IOMEM. > An arch has GENERIC_IO=y if it supports everything defined in > generic-asm/io.h which is more than enough for most stub drivers. The only thing which seems to be missing on UML is the ioremap function family ;/ Peter |
From: Richard W. <ri...@no...> - 2012-09-09 13:04:58
Attachments:
signature.asc
|
Am 09.09.2012 14:52, schrieb Peter Hüwe: > Am Sonntag, 9. September 2012, 14:23:06 schrieb Richard Weinberger: >> UML does not have IO_MEM but some sub-systems have "depend HAS_IOMEM" which >> is often too coarse grained. >> To deal with that I've introduced GENERIC_IO some time ago to support MTD >> (and nandsim) on UML. >> Maybe some parts of the I2C sub-system can also just depend on GENERIC_IO >> instead of HAS_IOMEM. >> An arch has GENERIC_IO=y if it supports everything defined in >> generic-asm/io.h which is more than enough for most stub drivers. > > The only thing which seems to be missing on UML is the ioremap function family > ;/ BTW: What about io_remap_pfn_range()? Thanks, //richard |
From: Richard W. <ri...@no...> - 2012-09-09 12:57:20
Attachments:
signature.asc
|
Am 09.09.2012 14:52, schrieb Peter Hüwe: > Am Sonntag, 9. September 2012, 14:23:06 schrieb Richard Weinberger: >> UML does not have IO_MEM but some sub-systems have "depend HAS_IOMEM" which >> is often too coarse grained. >> To deal with that I've introduced GENERIC_IO some time ago to support MTD >> (and nandsim) on UML. >> Maybe some parts of the I2C sub-system can also just depend on GENERIC_IO >> instead of HAS_IOMEM. >> An arch has GENERIC_IO=y if it supports everything defined in >> generic-asm/io.h which is more than enough for most stub drivers. > > The only thing which seems to be missing on UML is the ioremap function family > ;/ Why do you need ioremap() in a stub driver? This sounds strange. Thanks, //richard |
From: Peter H. <Pet...@gm...> - 2012-09-09 13:07:43
|
> >> Maybe some parts of the I2C sub-system can also just depend on > >> GENERIC_IO instead of HAS_IOMEM. > >> An arch has GENERIC_IO=y if it supports everything defined in > >> generic-asm/io.h which is more than enough for most stub drivers. > > > > The only thing which seems to be missing on UML is the ioremap function > > family ;/ > > Why do you need ioremap() in a stub driver? > This sounds strange. This was a misunderstanding - the main part of the I2C subsystem doesn't depend at all on HAS_IOMEM, only the main part of the i2c/busses section. And almost all of those drivers use ioremap. For my stub driver I don't need any of that, I'd be fine with the move of HAS_IOMEM as proposed by Jean. Peter |
From: Richard W. <ri...@no...> - 2012-09-09 13:27:19
Attachments:
signature.asc
|
Am 09.09.2012 15:11, schrieb Peter Hüwe: >>>> Maybe some parts of the I2C sub-system can also just depend on >>>> GENERIC_IO instead of HAS_IOMEM. >>>> An arch has GENERIC_IO=y if it supports everything defined in >>>> generic-asm/io.h which is more than enough for most stub drivers. >>> >>> The only thing which seems to be missing on UML is the ioremap function >>> family ;/ >> >> Why do you need ioremap() in a stub driver? >> This sounds strange. > > > This was a misunderstanding - the main part of the I2C subsystem doesn't > depend at all on HAS_IOMEM, only the main part of the i2c/busses section. > And almost all of those drivers use ioremap. Sure. They need real hardware. :-) > For my stub driver I don't need any of that, I'd be fine with the move of > HAS_IOMEM as proposed by Jean. IMHO you should replace the HAS_IOMEM with GENERIC_IO. Otherwise you may break the build on s390. Thanks, //richard |
From: Geert U. <ge...@li...> - 2012-09-09 14:52:13
|
On Sun, Sep 9, 2012 at 3:27 PM, Richard Weinberger <ri...@no...> wrote: >> For my stub driver I don't need any of that, I'd be fine with the move of >> HAS_IOMEM as proposed by Jean. > > IMHO you should replace the HAS_IOMEM with GENERIC_IO. > Otherwise you may break the build on s390. s390 has neither of HAS_IOMEM and GENERIC_IO, so it won't break their build. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Richard W. <ri...@no...> - 2012-09-09 15:00:50
|
Geert Uytterhoeven <ge...@li...> schrieb: >On Sun, Sep 9, 2012 at 3:27 PM, Richard Weinberger <ri...@no...> >wrote: >>> For my stub driver I don't need any of that, I'd be fine with the >move of >>> HAS_IOMEM as proposed by Jean. >> >> IMHO you should replace the HAS_IOMEM with GENERIC_IO. >> Otherwise you may break the build on s390. > >s390 has neither of HAS_IOMEM and GENERIC_IO, so it won't break their >build. > >Gr{oetje,eeting}s, > > Geert > >-- >Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- >ge...@li... > >In personal conversations with technical people, I call myself a >hacker. But >when I'm talking to journalists I just say "programmer" or something >like that. > -- Linus Torvalds That's why it may break. If you remove the depends on HAS_IOMEM, it will be built on s390 and fail if that codes uses io memory functions. Depending on GENERIC_IO fixes that. |
From: Jean D. <kh...@li...> - 2012-09-09 15:49:08
|
On Sun, 09 Sep 2012 17:00:54 +0200, Richard Weinberger wrote: > Geert Uytterhoeven <ge...@li...> schrieb: > >s390 has neither of HAS_IOMEM and GENERIC_IO, so it won't break their > >build. > > That's why it may break. If you remove the depends on HAS_IOMEM, it will be built on s390 and fail if that codes uses io memory functions. Depending on GENERIC_IO fixes that. Where "that" is a problem which may not exist in the first place. -- Jean Delvare |
From: Jean D. <kh...@li...> - 2012-09-09 18:40:53
|
Hallo Petter, On Sun, 9 Sep 2012 14:15:02 +0200, Peter Hüwe wrote: > I created a patch for your proposed solution, I moved the stub driver to the > end in order to have only one big if HAS_IOMEM. There is a problem with the mux chip drivers, which then no longer depend on HAS_IOMEM. Also, I think it is about time to admit that i2c-stub does not fit under "I2C Hardware Bus support". It is a driver for development, not hardware support. So I propose the following instead: drivers/i2c/Kconfig | 14 +++++++++++++- drivers/i2c/busses/Kconfig | 14 +------------- drivers/i2c/muxes/Kconfig | 2 +- 3 files changed, 15 insertions(+), 15 deletions(-) --- linux-3.6-rc4.orig/drivers/i2c/Kconfig 2012-07-21 22:58:29.000000000 +0200 +++ linux-3.6-rc4/drivers/i2c/Kconfig 2012-09-09 18:34:08.169196654 +0200 @@ -4,7 +4,6 @@ menuconfig I2C tristate "I2C support" - depends on HAS_IOMEM select RT_MUTEXES ---help--- I2C (pronounce: I-squared-C) is a slow serial bus protocol used in @@ -86,6 +85,19 @@ config I2C_SMBUS source drivers/i2c/algos/Kconfig source drivers/i2c/busses/Kconfig +config I2C_STUB + tristate "I2C/SMBus Test Stub" + depends on EXPERIMENTAL && m + default 'n' + help + This module may be useful to developers of SMBus client drivers, + especially for certain kinds of sensor chips. + + If you do build this module, be sure to read the notes and warnings + in <file:Documentation/i2c/i2c-stub>. + + If you don't know what to do here, definitely say N. + config I2C_DEBUG_CORE bool "I2C Core debugging messages" help --- linux-3.6-rc4.orig/drivers/i2c/busses/Kconfig 2012-09-08 09:36:32.086553711 +0200 +++ linux-3.6-rc4/drivers/i2c/busses/Kconfig 2012-09-09 18:33:58.598196535 +0200 @@ -3,6 +3,7 @@ # menu "I2C Hardware Bus support" + depends on HAS_IOMEM comment "PC SMBus host controller drivers" depends on PCI @@ -850,19 +851,6 @@ config I2C_SIBYTE help Supports the SiByte SOC on-chip I2C interfaces (2 channels). -config I2C_STUB - tristate "I2C/SMBus Test Stub" - depends on EXPERIMENTAL && m - default 'n' - help - This module may be useful to developers of SMBus client drivers, - especially for certain kinds of sensor chips. - - If you do build this module, be sure to read the notes and warnings - in <file:Documentation/i2c/i2c-stub>. - - If you don't know what to do here, definitely say N. - config SCx200_I2C tristate "NatSemi SCx200 I2C using GPIO pins (DEPRECATED)" depends on SCx200_GPIO --- linux-3.6-rc4.orig/drivers/i2c/muxes/Kconfig 2012-07-21 22:58:29.000000000 +0200 +++ linux-3.6-rc4/drivers/i2c/muxes/Kconfig 2012-09-09 19:20:13.032141164 +0200 @@ -3,7 +3,7 @@ # menu "Multiplexer I2C Chip support" - depends on I2C_MUX + depends on HAS_IOMEM && I2C_MUX config I2C_MUX_GPIO tristate "GPIO-based I2C multiplexer" -- Jean Delvare |
From: Peter H. <Pet...@gm...> - 2012-09-09 19:08:26
|
> That's why it may break. If you remove the depends on HAS_IOMEM, it will be > built on s390 and fail if that codes uses io memory functions. Depending > on GENERIC_IO fixes that. Everything I can select in I2C subsystem compiles fine on s390. (using defconfig + menuconfig). Just compiled it. Thanks, Peter |
From: Richard W. <ri...@no...> - 2012-09-09 20:08:17
Attachments:
signature.asc
|
Am 09.09.2012 21:12, schrieb Peter Hüwe: >> That's why it may break. If you remove the depends on HAS_IOMEM, it will be >> built on s390 and fail if that codes uses io memory functions. Depending >> on GENERIC_IO fixes that. > > Everything I can select in I2C subsystem compiles fine on s390. > (using defconfig + menuconfig). > Just compiled it. Very good. :-) Thanks, //richard |
From: Peter H. <Pet...@gm...> - 2012-09-09 19:13:32
|
Hi Jean, Am Sonntag, 9. September 2012, 20:40:36 schrieb Jean Delvare: > There is a problem with the mux chip drivers, which then no longer > depend on HAS_IOMEM. The selectables on my x86 and UML machine build fine ;) But you're correct, we should exclude/guard them. > Also, I think it is about time to admit that > i2c-stub does not fit under "I2C Hardware Bus support". It is a driver > for development, not hardware support. > > So I propose the following instead: > > drivers/i2c/Kconfig | 14 +++++++++++++- > drivers/i2c/busses/Kconfig | 14 +------------- > drivers/i2c/muxes/Kconfig | 2 +- > 3 files changed, 15 insertions(+), 15 deletions(-) I'm perfectly fine with this. Signed-off-by: Peter Huewe <pet...@gm...> |
From: Jean D. <kh...@li...> - 2012-09-10 07:29:42
|
On Sun, 9 Sep 2012 21:17:20 +0200, Peter Hüwe wrote: > Hi Jean, > Am Sonntag, 9. September 2012, 20:40:36 schrieb Jean Delvare: > > There is a problem with the mux chip drivers, which then no longer > > depend on HAS_IOMEM. > The selectables on my x86 and UML machine build fine ;) > But you're correct, we should exclude/guard them. > > > Also, I think it is about time to admit that > > i2c-stub does not fit under "I2C Hardware Bus support". It is a driver > > for development, not hardware support. > > > > So I propose the following instead: > > > > drivers/i2c/Kconfig | 14 +++++++++++++- > > drivers/i2c/busses/Kconfig | 14 +------------- > > drivers/i2c/muxes/Kconfig | 2 +- > > 3 files changed, 15 insertions(+), 15 deletions(-) > > > I'm perfectly fine with this. > > Signed-off-by: Peter Huewe <pet...@gm...> I slept over it and my approach makes little sense for multiplexing. i2c-mux is useless without at least one multiplexer driver, and with my patch, the user can't select any without CONFIG_IOMEM. So either i2c-mux should depend on CONFIG_IOMEM too (in which case we no longer need this dependency in drivers/i2c/muxes/Kconfig, as we will get it by transitivity) or we should let i2c multiplexer drivers be built even without CONFIG_IOMEM. After all, if they can be selected, they will build, as they are all accessing the hardware indirectly (through gpio or i2c layers.) At the moment, it makes no sense to enable multiplexing without CONFIG_IOMEM, as the only driver which can instantiate a root I2C segment is i2c-stub and that driver wouldn't know how to deal with multiplexing. So option #1 has my favors for now. If anyone ever implements multiplexing emulation in i2c-stub then we can revisit and let i2c-mux + the driver for the emulated mux chip be built under !CONFIG_IOMEM. OK? I also noticed that I2C_DEBUG_BUS has no effect under !CONFIG_IOMEM with my previous patch, so we can hide it. Leads me to: From: Peter Huewe <pet...@gm...> Subject: i2c: Make I2C available on UML Remove the global dependency of the I2C subsystem on HAS_IOMEM and move the dependency to the i2c/busses submenu, with an exception for i2c-stub. The generic I2C part does not need to have HAS_IOMEM set and thus now becomes available in UML, so the I2C subsystem can now be used, e.g. by the i2c-stub driver, for development of I2C device drivers. [JD: Some adjustments.] Signed-off-by: Peter Huewe <pet...@gm...> Signed-off-by: Jean Delvare <kh...@li...> --- drivers/i2c/Kconfig | 16 +++++++++++++++- drivers/i2c/busses/Kconfig | 14 +------------- 2 files changed, 16 insertions(+), 14 deletions(-) --- linux-3.6-rc4.orig/drivers/i2c/Kconfig 2012-07-21 22:58:29.000000000 +0200 +++ linux-3.6-rc4/drivers/i2c/Kconfig 2012-09-10 09:19:06.485756611 +0200 @@ -4,7 +4,6 @@ menuconfig I2C tristate "I2C support" - depends on HAS_IOMEM select RT_MUTEXES ---help--- I2C (pronounce: I-squared-C) is a slow serial bus protocol used in @@ -49,6 +48,7 @@ config I2C_CHARDEV config I2C_MUX tristate "I2C bus multiplexing support" + depends on HAS_IOMEM help Say Y here if you want the I2C core to support the ability to handle multiplexed I2C bus topologies, by presenting each @@ -86,6 +86,19 @@ config I2C_SMBUS source drivers/i2c/algos/Kconfig source drivers/i2c/busses/Kconfig +config I2C_STUB + tristate "I2C/SMBus Test Stub" + depends on EXPERIMENTAL && m + default 'n' + help + This module may be useful to developers of SMBus client drivers, + especially for certain kinds of sensor chips. + + If you do build this module, be sure to read the notes and warnings + in <file:Documentation/i2c/i2c-stub>. + + If you don't know what to do here, definitely say N. + config I2C_DEBUG_CORE bool "I2C Core debugging messages" help @@ -103,6 +116,7 @@ config I2C_DEBUG_ALGO config I2C_DEBUG_BUS bool "I2C Bus debugging messages" + depends on HAS_IOMEM help Say Y here if you want the I2C bus drivers to produce a bunch of debug messages to the system log. Select this if you are having --- linux-3.6-rc4.orig/drivers/i2c/busses/Kconfig 2012-09-08 09:36:32.000000000 +0200 +++ linux-3.6-rc4/drivers/i2c/busses/Kconfig 2012-09-09 18:33:58.598196535 +0200 @@ -3,6 +3,7 @@ # menu "I2C Hardware Bus support" + depends on HAS_IOMEM comment "PC SMBus host controller drivers" depends on PCI @@ -850,19 +851,6 @@ config I2C_SIBYTE help Supports the SiByte SOC on-chip I2C interfaces (2 channels). -config I2C_STUB - tristate "I2C/SMBus Test Stub" - depends on EXPERIMENTAL && m - default 'n' - help - This module may be useful to developers of SMBus client drivers, - especially for certain kinds of sensor chips. - - If you do build this module, be sure to read the notes and warnings - in <file:Documentation/i2c/i2c-stub>. - - If you don't know what to do here, definitely say N. - config SCx200_I2C tristate "NatSemi SCx200 I2C using GPIO pins (DEPRECATED)" depends on SCx200_GPIO If everybody is happy with this, I'll queue it up for 3.7. -- Jean Delvare |
From: Peter H. <Pet...@gm...> - 2012-09-10 19:17:58
|
Am Montag, 10. September 2012, 09:29:18 schrieb Jean Delvare: > If everybody is happy with this, I'll queue it up for 3.7. I'm happy with this ;) Thanks, Peter |
From: Richard W. <ri...@no...> - 2012-09-11 15:03:56
|
Am Mon, 10 Sep 2012 21:21:52 +0200 schrieb Peter Hüwe <Pet...@gm...>: > Am Montag, 10. September 2012, 09:29:18 schrieb Jean Delvare: > > If everybody is happy with this, I'll queue it up for 3.7. > > I'm happy with this ;) > As no UML specific changes are needed I'm also fine.^^ Thanks, //richard |