* Re: [PATCH] mfd: axp20x-i2c: Add i2c-ids to fix module auto-loading
From: Wolfram Sang @ 2016-10-24 10:47 UTC (permalink / raw)
To: Lee Jones
Cc: Hans de Goede, Chen-Yu Tsai, Sebastian Reichel, Dennis Gilmore,
Maxime Ripard, open list:THERMAL, linux-arm-kernel, linux-i2c
In-Reply-To: <20161024103428.GA8574@dell>
[-- Attachment #1: Type: text/plain, Size: 193 bytes --]
> I was under the impression it was all but ready.
Then, I would have applied it.
> What are you waiting on?
Lee, I don't want to explain it *again*. Please re-read Kieran's last
attempt.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c: rk3x: Give the tuning value 0 during rk3x_i2c_v0_calc_timings
From: Andy Yan @ 2016-10-24 11:55 UTC (permalink / raw)
To: David Wu, heiko, wsa
Cc: devicetree, linux-kernel, dianders, linux-rockchip, linux-i2c,
linux-arm-kernel
In-Reply-To: <1477125822-30644-1-git-send-email-david.wu@rock-chips.com>
Hi:
On 2016年10月22日 16:43, David Wu wrote:
> We found a bug that i2c transfer sometimes failed on 3066a board with
> stabel-4.8, the con register would be updated by uninitialized tuning
> value, it made the i2c transfer failed.
>
> So give the tuning value to be zero during rk3x_i2c_v0_calc_timings.
>
> Signed-off-by: David Wu <david.wu@rock-chips.com>
> ---
> drivers/i2c/busses/i2c-rk3x.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
> index 50702c7..df22066 100644
> --- a/drivers/i2c/busses/i2c-rk3x.c
> +++ b/drivers/i2c/busses/i2c-rk3x.c
> @@ -694,6 +694,8 @@ static int rk3x_i2c_v0_calc_timings(unsigned long clk_rate,
> t_calc->div_low--;
> t_calc->div_high--;
>
> + /* Give the tuning value 0, that would not update con register */
> + t_calc->tuning = 0;
> /* Maximum divider supported by hw is 0xffff */
> if (t_calc->div_low > 0xffff) {
> t_calc->div_low = 0xffff;
rk3066a based board can't boot up(with endless i2c irq messages print
out) from linux-4.8 without this fix.
Tested-by: Andy Yan <andy.yan@rock-chips.com>
^ permalink raw reply
* Re: [PATCH v2 1/2] spi: mark device nodes only in case of successful instantiation
From: Mark Brown @ 2016-10-24 17:30 UTC (permalink / raw)
To: Ralf Ramsauer
Cc: Geert Uytterhoeven, Wolfram Sang, Linux SPI, Linux I2C,
linux-kernel @ vger . kernel . org, Pantelis Antoniou
In-Reply-To: <20161017135957.20297-2-ralf@ramses-pyramidenbau.de>
[-- Attachment #1: Type: text/plain, Size: 820 bytes --]
On Mon, Oct 17, 2016 at 03:59:56PM +0200, Ralf Ramsauer wrote:
> Instantiated SPI device nodes are marked with OF_POPULATE. This was
> introduced in bd6c164. On unloading, loaded device nodes will of course
Please include human readable descriptions of things like commits and
issues being discussed in e-mail in your mails, this makes them much
easier for humans to read especially when they have no internet access.
I do frequently catch up on my mail on flights or while otherwise
travelling so this is even more pressing for me than just being about
making things a bit easier to read.
Please also use longer hashes - the kernel repository is big enough that
we do actually have a few collisons on shorter hash lengths IIRC. The
standard thing is 12 characthers (you can set core.abbrev to 12 to help
with this).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Applied "spi: mark device nodes only in case of successful instantiation" to the spi tree
From: Mark Brown @ 2016-10-24 18:05 UTC (permalink / raw)
To: Ralf Ramsauer; +Cc: Pantelis Antoniou, Mark Brown, stable
In-Reply-To: <20161017135957.20297-2-ralf@ramses-pyramidenbau.de>
The patch
spi: mark device nodes only in case of successful instantiation
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From e0af98a7e025a7263ae7e50264f6f79ed29642a7 Mon Sep 17 00:00:00 2001
From: Ralf Ramsauer <ralf@ramses-pyramidenbau.de>
Date: Mon, 17 Oct 2016 15:59:56 +0200
Subject: [PATCH] spi: mark device nodes only in case of successful
instantiation
Instantiated SPI device nodes are marked with OF_POPULATE. This was
introduced in bd6c164. On unloading, loaded device nodes will of course
be unmarked. The problem are nodes that fail during initialisation: If a
node fails, it won't be unloaded and hence not be unmarked.
If a SPI driver module is unloaded and reloaded, it will skip nodes that
failed before.
Skip device nodes that are already populated and mark them only in case
of success.
Note that the same issue exists for I2C.
Fixes: bd6c164 ("spi: Mark instantiated device nodes with OF_POPULATE")
Signed-off-by: Ralf Ramsauer <ralf@ramses-pyramidenbau.de>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
---
drivers/spi/spi.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 5787b723b593..838783c3fed0 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1618,9 +1618,11 @@ static void of_register_spi_devices(struct spi_master *master)
if (of_node_test_and_set_flag(nc, OF_POPULATED))
continue;
spi = of_register_spi_device(master, nc);
- if (IS_ERR(spi))
+ if (IS_ERR(spi)) {
dev_warn(&master->dev, "Failed to create SPI device for %s\n",
nc->full_name);
+ of_node_clear_flag(nc, OF_POPULATED);
+ }
}
}
#else
@@ -3131,6 +3133,7 @@ static int of_spi_notify(struct notifier_block *nb, unsigned long action,
if (IS_ERR(spi)) {
pr_err("%s: failed to create for '%s'\n",
__func__, rd->dn->full_name);
+ of_node_clear_flag(rd->dn, OF_POPULATED);
return notifier_from_errno(PTR_ERR(spi));
}
break;
--
2.8.1
^ permalink raw reply related
* Re: [PATCH] i2c: rk3x: Give the tuning value 0 during rk3x_i2c_v0_calc_timings
From: Doug Anderson @ 2016-10-24 18:29 UTC (permalink / raw)
To: David Wu
Cc: Heiko Stübner, Wolfram Sang,
linux-arm-kernel@lists.infradead.org,
open list:ARM/Rockchip SoC..., linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1477125822-30644-1-git-send-email-david.wu@rock-chips.com>
Hi,
On Sat, Oct 22, 2016 at 1:43 AM, David Wu <david.wu@rock-chips.com> wrote:
> We found a bug that i2c transfer sometimes failed on 3066a board with
> stabel-4.8, the con register would be updated by uninitialized tuning
> value, it made the i2c transfer failed.
>
> So give the tuning value to be zero during rk3x_i2c_v0_calc_timings.
>
> Signed-off-by: David Wu <david.wu@rock-chips.com>
> ---
> drivers/i2c/busses/i2c-rk3x.c | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* Re: [PATCH] i2c: xgene: Avoid dma_buffer overrun
From: Hoan Tran @ 2016-10-24 22:30 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c
Cc: lkml, Phil Endecott, Loc Ho, Tin Huynh, patches, Hoan Tran
In-Reply-To: <1476119590-21489-1-git-send-email-hotran@apm.com>
On Mon, Oct 10, 2016 at 10:13 AM, Hoan Tran <hotran@apm.com> wrote:
> SMBus block command uses the first byte of buffer for the data length.
> The dma_buffer should be increased by 1 to avoid the overrun issue.
>
> Reported-by: Phil Endecott <phil_gjouf_endecott@chezphil.org>
> Signed-off-by: Hoan Tran <hotran@apm.com>
> ---
> drivers/i2c/busses/i2c-xgene-slimpro.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-xgene-slimpro.c b/drivers/i2c/busses/i2c-xgene-slimpro.c
> index 4233f56..3c38029 100644
> --- a/drivers/i2c/busses/i2c-xgene-slimpro.c
> +++ b/drivers/i2c/busses/i2c-xgene-slimpro.c
> @@ -105,7 +105,7 @@ struct slimpro_i2c_dev {
> struct mbox_chan *mbox_chan;
> struct mbox_client mbox_client;
> struct completion rd_complete;
> - u8 dma_buffer[I2C_SMBUS_BLOCK_MAX];
> + u8 dma_buffer[I2C_SMBUS_BLOCK_MAX + 1]; /* dma_buffer[0] is used for length */
> u32 *resp_msg;
> };
>
> --
> 1.9.1
>
Any comments on this patch.
Thanks
Hoan
^ permalink raw reply
* Re: [Patch V3] i2c: imx: add low power i2c bus driver
From: Vladimir Zapolskiy @ 2016-10-24 23:15 UTC (permalink / raw)
To: Gao Pan, wsa, u.kleine-koenig, cmo; +Cc: linux-i2c, frank.li, fugang.duan
In-Reply-To: <1471420784-11727-1-git-send-email-pandy.gao@nxp.com>
Hello Pandy,
On 17.08.2016 10:59, Gao Pan wrote:
> This patch adds low power i2c bus driver to support new i.MX
> products which use low power i2c instead of the old imx i2c.
>
> The low power i2c can continue operating in stop mode when
> an appropriate clock is available. It is also designed for
> low CPU overhead with DMA offloading of FIFO register accesses.
>
> Signed-off-by: Gao Pan <pandy.gao@nxp.com>
> Reviewed-by: Fugang Duan <B38611@freescale.com>
> ---
> V2:
> -stop i2c transfer under the wrong condition
> -add timeout check in while() domain
>
> V3:
> -fix typo inside commit message and the driver.
>
> .../devicetree/bindings/i2c/i2c-imx-lpi2c.txt | 25 +
> drivers/i2c/busses/Kconfig | 10 +
> drivers/i2c/busses/Makefile | 1 +
> drivers/i2c/busses/i2c-imx-lpi2c.c | 667 +++++++++++++++++++++
> 4 files changed, 703 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt
> new file mode 100644
> index 0000000..1f10cbf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt
> @@ -0,0 +1,25 @@
> +* Freescale Low Power Inter IC (LPI2C) for i.MX
> +
> +Required properties:
> +- compatible :
> + - "fsl,imx8dv-lpi2c" for LPI2C compatible with the one integrated on i.MX8DV soc
> + - "fsl,imx7ulp-lpi2c" for LPI2C compatible with the one integrated on i.MX7ULP soc
> +- reg : Should contain LPI2C registers location and length
> +- interrupts : Should contain LPI2C interrupt
> +- clocks : Should contain LPI2C clock specifier
> +- power-domains : should contain LPI2C power domain
> +
> +Optional properties:
> +- clock-frequency : Constains desired LPI2C bus clock frequency in Hz.
typo, what is "constains"? Contains, constrains?
> + The absence of the property indicates the default frequency 100 kHz.
> +
> +Examples:
> +
> +i2c1: i2c@5e110000 { /* LPI2C on i.MX8DV */
> + compatible = "fsl,imx8dv-lpi2c";
> + reg = <0x0 0x5e110000 0x0 0x4000>;
> + interrupts = <0 88 4>;
> + clocks = <&clk IMX8DV_I2C1_CLK>;
> + clock-names = "per";
> + power-domains = <&pd_lsio_i2c1>;
> +};
For this part please send the change to devicetree mailing list and get
Rob Herring's ack. You may split it into a separate patch.
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index efa3d9b..1fc7a10 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -596,6 +596,16 @@ config I2C_IMX
> This driver can also be built as a module. If so, the module
> will be called i2c-imx.
>
> +config I2C_IMX_LPI2C
> + tristate "IMX Low Power I2C interface"
> + depends on ARCH_MXC || COMPILE_TEST
> + help
> + Say Y here if you want to use the Low Power IIC bus controller
> + on the Freescale i.MX processors.
> +
> + This driver can also be built as a module. If so, the module
> + will be called i2c-imx-lpi2c.
> +
> config I2C_IOP3XX
> tristate "Intel IOPx3xx and IXP4xx on-chip I2C interface"
> depends on ARCH_IOP32X || ARCH_IOP33X || ARCH_IXP4XX || ARCH_IOP13XX
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 37f2819..cc93457 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -56,6 +56,7 @@ obj-$(CONFIG_I2C_HIX5HD2) += i2c-hix5hd2.o
> obj-$(CONFIG_I2C_IBM_IIC) += i2c-ibm_iic.o
> obj-$(CONFIG_I2C_IMG) += i2c-img-scb.o
> obj-$(CONFIG_I2C_IMX) += i2c-imx.o
> +obj-$(CONFIG_I2C_IMX_LPI2C) += i2c-imx-lpi2c.o
> obj-$(CONFIG_I2C_IOP3XX) += i2c-iop3xx.o
> obj-$(CONFIG_I2C_JZ4780) += i2c-jz4780.o
> obj-$(CONFIG_I2C_KEMPLD) += i2c-kempld.o
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
> new file mode 100644
> index 0000000..308ecf5
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -0,0 +1,667 @@
> +/*
> + * This is i.MX low power i2c controller driver.
> + *
> + * Copyright 2016 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/completion.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/errno.h>
> +#include <linux/i2c.h>
> +#include <linux/init.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/sched.h>
> +#include <linux/slab.h>
> +
> +#define DRIVER_NAME "imx-lpi2c"
> +
> +#define LPI2C_PARAM 0x04 /* i2c RX/TX FIFO size */
> +#define LPI2C_MCR 0x10 /* i2c contrl register */
> +#define LPI2C_MSR 0x14 /* i2c status register */
> +#define LPI2C_MIER 0x18 /* i2c interrupt enable */
> +#define LPI2C_MCFGR0 0x20 /* i2c master configuration */
> +#define LPI2C_MCFGR1 0x24 /* i2c master configuration */
> +#define LPI2C_MCFGR2 0x28 /* i2c master configuration */
> +#define LPI2C_MCFGR3 0x2C /* i2c master configuration */
> +#define LPI2C_MCCR0 0x48 /* i2c master clk configuration */
> +#define LPI2C_MCCR1 0x50 /* i2c master clk configuration */
> +#define LPI2C_MFCR 0x58 /* i2c master FIFO control */
> +#define LPI2C_MFSR 0x5C /* i2c master FIFO status */
> +#define LPI2C_MTDR 0x60 /* i2c master TX data register */
> +#define LPI2C_MRDR 0x70 /* i2c master RX data register */
> +
> +/* i2c command */
> +#define TRAN_DATA 0X00
> +#define RECV_DATA 0X01
> +#define GEN_STOP 0X02
> +#define RECV_DISCARD 0X03
> +#define GEN_START 0X04
> +#define START_NACK 0X05
> +#define START_HIGH 0X06
> +#define START_HIGH_NACK 0X07
> +
> +#define MCR_MEN (1 << 0)
> +#define MCR_RST (1 << 1)
> +#define MCR_DOZEN (1 << 2)
> +#define MCR_DBGEN (1 << 3)
> +#define MCR_RTF (1 << 8)
> +#define MCR_RRF (1 << 9)
> +#define MSR_TDF (1 << 0)
> +#define MSR_RDF (1 << 1)
> +#define MSR_SDF (1 << 9)
> +#define MSR_NDF (1 << 10)
> +#define MSR_ALF (1 << 11)
> +#define MSR_MBF (1 << 24)
> +#define MSR_BBF (1 << 25)
> +#define MIER_TDIE (1 << 0)
> +#define MIER_RDIE (1 << 1)
> +#define MIER_SDIE (1 << 9)
> +#define MIER_NDIE (1 << 10)
> +#define MCFGR1_AUTOSTOP (1 << 8)
> +#define MCFGR1_IGNACK (1 << 9)
> +#define MRDR_RXEMPTY (1 << 14)
Please use BIT() helper above.
Also please don't use tab symbol between #define and a token.
> +
> +#define I2C_CLK_RATIO 2
> +#define CHUNK_DATA 256
> +
> +#define LPI2C_RX_FIFOSIZE 4
> +#define LPI2C_TX_FIFOSIZE 4
> +
> +#define LPI2C_DEFAULT_RATE 100000
> +#define STARDARD_MAX_BITRATE 400000
> +#define FAST_MAX_BITRATE 1000000
> +#define FAST_PLUS_MAX_BITRATE 3400000
> +#define HIGHSPEED_MAX_BITRATE 5000000
Please don't use tab symbol right after #define
> +
> +
Double empty line, this kind of problem is reported by
checkpatch --strict, please pay attention to all of them:
total: 0 errors, 2 warnings, 33 checks, 715 lines checked
> +enum lpi2c_imx_mode {
> + STANDARD, /* 100+Kbps */
> + FAST, /* 400+Kbps */
> + FAST_PLUS, /* 1.0+Mbps */
> + ULTRA_FAST, /* 5.0+Mbps */
> + HS, /* 3.4+Mbps */
Any reason why the list is not sorted by bus speed?
> +};
> +
> +enum lpi2c_imx_pincfg {
> + TWO_PIN_OD, /* 2-pin open drain mode */
> + TWO_PIN_OO, /* 2-pin output only mode (utra-fast mode) */
> + TWO_PIN_PP, /* 2-pin push-pull mode */
> + FOUR_PIN_PP, /* 4-pin push-pull mode */
> + TWO_PIN_OD_SS, /* 2-pin open drain mode with separate slave */
Unused.
> + TWO_PIN_OO_SS, /* 2-pin output only mode with separate slave */
Unused.
> + TWO_PIN_PP_SS, /* 2-pin push-pull mode with separate slave */
Unused.
> + FOUR_PIN_PP_IO, /* 4-pin push-pull mode (inverted output) */
Unused.
> +};
> +
> +struct lpi2c_imx_clkcfg {
> + u8 prescale;
> + u8 filtscl;
> + u8 filtsda;
> + u8 sethold;
> + u8 clklo;
> + u8 clkhi;
> + u8 datavd;
> +};
> +
> +struct lpi2c_imx_struct {
> + struct i2c_adapter adapter;
> + struct clk *per_clk;
> + void __iomem *base;
> + __u8 *rx_buf;
> + __u8 *tx_buf;
> + struct completion complete;
> + unsigned int msglen;
> + unsigned int delivered;
> + unsigned int block_data;
> + unsigned int bitrate;
> + enum lpi2c_imx_mode mode;
> +};
> +
> +static void lpi2c_imx_intctrl(
> + struct lpi2c_imx_struct *lpi2c_imx, unsigned int enable)
Indentation issue.
> +{
> + writel(enable, lpi2c_imx->base + LPI2C_MIER);
> +}
> +
> +static int lpi2c_imx_bus_busy(struct lpi2c_imx_struct *lpi2c_imx)
> +{
> + unsigned long orig_jiffies = jiffies;
> + unsigned int temp;
> +
> + while (1) {
> + temp = readl(lpi2c_imx->base + LPI2C_MSR);
> +
> + /* check for arbitration lost, clear if set */
> + if (temp & MSR_ALF) {
> + writel(temp, lpi2c_imx->base + LPI2C_MSR);
> + return -EAGAIN;
> + }
> +
> + if ((temp & MSR_BBF) && (temp & MSR_MBF))
if (temp & (MSR_BBF | MSR_MBF))
> + break;
> +
> + if (time_after(jiffies, orig_jiffies + msecs_to_jiffies(500))) {
> + dev_dbg(&lpi2c_imx->adapter.dev, "bus not work\n");
> + return -ETIMEDOUT;
> + }
> + schedule();
> + }
> +
> + return 0;
> +}
> +
> +static void lpi2c_imx_set_mode(struct lpi2c_imx_struct *lpi2c_imx)
> +{
> + enum lpi2c_imx_mode mode;
> + unsigned int bitrate = lpi2c_imx->bitrate;
unsigned int bitrate = lpi2c_imx->bitrate;
enum lpi2c_imx_mode mode;
If possible please use "reverse christmas tree" order while declaring
local variables, this applies to some other functions below as well.
I see that you mainly use "christmas tree" order, but this style
isn't commonly used in the Linux kernel sources.
> +
> + if (bitrate < STARDARD_MAX_BITRATE)
> + mode = STANDARD;
> + else if (bitrate < FAST_MAX_BITRATE)
> + mode = FAST;
> + else if (bitrate < FAST_PLUS_MAX_BITRATE)
> + mode = FAST_PLUS;
> + else if (bitrate < HIGHSPEED_MAX_BITRATE)
> + mode = HS;
> + else
> + mode = ULTRA_FAST;
> +
> + lpi2c_imx->mode = mode;
> +}
> +
> +static int lpi2c_imx_start(struct lpi2c_imx_struct *lpi2c_imx,
> + struct i2c_msg *msgs)
> +{
> + u8 read;
> + unsigned int temp;
> +
> + temp = readl(lpi2c_imx->base + LPI2C_MCR);
> + temp |= MCR_RRF | MCR_RTF;
> + writel(temp, lpi2c_imx->base + LPI2C_MCR);
> + writel(0x7f00, lpi2c_imx->base + LPI2C_MSR);
> +
> + read = msgs->flags & I2C_M_RD;
> + temp = (msgs->addr << 1 | read) | (GEN_START << 8);
> + writel(temp, lpi2c_imx->base + LPI2C_MTDR);
> +
> + return lpi2c_imx_bus_busy(lpi2c_imx);
> +}
> +
> +static void lpi2c_imx_stop(struct lpi2c_imx_struct *lpi2c_imx)
> +{
> + unsigned int temp;
> + unsigned long orig_jiffies = jiffies;
> +
> + writel(GEN_STOP << 8, lpi2c_imx->base + LPI2C_MTDR);
Add an empty line here.
> + do {
> + temp = readl(lpi2c_imx->base + LPI2C_MSR);
> + if (temp & MSR_SDF)
> + break;
> +
> + if (time_after(jiffies, orig_jiffies + msecs_to_jiffies(500))) {
> + dev_dbg(&lpi2c_imx->adapter.dev, "stop timeout\n");
> + break;
> + }
> + schedule();
> +
> + } while (1);
> +}
> +
> +
> +/* CLKLO = I2C_CLK_RATIO * CLKHI, SETHOLD = CLKHI, DATAVD = CLKHI/2 */
> +static int lpi2c_imx_config(struct lpi2c_imx_struct *lpi2c_imx)
> +{
> + unsigned int temp;
> + unsigned int per_clk_rate;
> + unsigned int prescale, clk_high, clk_low, clk_cycle;
> + enum lpi2c_imx_pincfg pincfg;
> + struct lpi2c_imx_clkcfg clkcfg;
> +
> + lpi2c_imx_set_mode(lpi2c_imx);
> + per_clk_rate = clk_get_rate(lpi2c_imx->per_clk);
> +
> + if (lpi2c_imx->mode == HS || lpi2c_imx->mode == ULTRA_FAST)
if (lpi2c_imx->mode > FAST_PLUS)
> + clkcfg.filtscl = clkcfg.filtsda = 0;
> + else
> + clkcfg.filtscl = clkcfg.filtsda = 2;
> +
Multiple assignments on a single line are not welcome, in this
case one variable "filt" assigned to 0 or 2 should be enough.
Why do you need struct lpi2c_imx_clkcfg in general?
clkcfg.filtscl, clkcfg.filtsda etc. are all used locally inside
this function only, it should be sufficient to replace "clkcfg"
with a number of local variables.
> + for (prescale = 0; prescale <= 7; prescale++) {
> + clk_cycle = per_clk_rate / ((1 << prescale) * lpi2c_imx->bitrate)
> + - 3 - (clkcfg.filtscl >> 1);
> + clk_high = (clk_cycle + I2C_CLK_RATIO) / (I2C_CLK_RATIO + 1);
> + clk_low = clk_cycle - clk_high;
> + if (clk_low < 64)
> + break;
> + }
> +
> + if (prescale > 7)
> + return -EINVAL;
> +
> + clkcfg.prescale = prescale;
> + clkcfg.sethold = clk_high;
> + clkcfg.clklo = clk_low;
> + clkcfg.clkhi = clk_high;
> + clkcfg.datavd = clk_high >> 1;
Useless duplication of variables, see a note above.
> +
> + /* set MCFGR1: PINCFG, PRESCALE, IGNACK */
> + if (lpi2c_imx->mode == ULTRA_FAST)
> + pincfg = TWO_PIN_OO;
> + else
> + pincfg = TWO_PIN_OD;
> + temp = clkcfg.prescale | pincfg << 24;
> +
> + if (lpi2c_imx->mode == ULTRA_FAST)
> + temp |= MCFGR1_IGNACK;
> +
> + writel(temp, lpi2c_imx->base + LPI2C_MCFGR1);
> +
> + /* set MCFGR2: FILTSDA, FILTSCL */
> + temp = (clkcfg.filtscl << 16) | (clkcfg.filtsda << 24);
> + writel(temp, lpi2c_imx->base + LPI2C_MCFGR2);
> +
> +
> + /* set MCCR: DATAVD, SETHOLD, CLKHI, CLKLO */
> + temp = clkcfg.datavd << 24 | clkcfg.sethold << 16 |
> + clkcfg.clkhi << 8 | clkcfg.clklo;
> +
> + if (lpi2c_imx->mode == HS)
> + writel(temp, lpi2c_imx->base + LPI2C_MCCR1);
> + else
> + writel(temp, lpi2c_imx->base + LPI2C_MCCR0);
> +
> + return 0;
> +}
> +
> +static int lpi2c_imx_master_enable(struct lpi2c_imx_struct *lpi2c_imx)
> +{
> + int ret;
> + unsigned int temp;
> +
> + ret = clk_prepare_enable(lpi2c_imx->per_clk);
You can do clk_prepare() in probe function and clk_unprepare() in remove
function to avoid potential sleeping in runtime, then here you just
do clk_enable()/clk_disable().
> + if (ret)
> + return ret;
> +
> + temp = MCR_RST;
> + writel(temp, lpi2c_imx->base + LPI2C_MCR);
> + writel(0, lpi2c_imx->base + LPI2C_MCR);
> +
> + ret = lpi2c_imx_config(lpi2c_imx);
> + if (ret)
> + return ret;
> +
> + temp = readl(lpi2c_imx->base + LPI2C_MCR);
> + temp |= MCR_MEN;
> + writel(temp, lpi2c_imx->base + LPI2C_MCR);
> +
> + return 0;
> +}
> +
> +static int lpi2c_imx_master_disable(struct lpi2c_imx_struct *lpi2c_imx)
> +{
> + unsigned int temp = 0;
> +
> + temp = readl(lpi2c_imx->base + LPI2C_MCR);
> + temp &= ~MCR_MEN;
> + writel(temp, lpi2c_imx->base + LPI2C_MCR);
> +
> + clk_disable_unprepare(lpi2c_imx->per_clk);
See a note above.
> +
> + return 0;
> +}
> +
> +static int lpi2c_imx_msg_complete(struct lpi2c_imx_struct *lpi2c_imx)
> +{
> + unsigned int timeout;
> +
> + timeout = wait_for_completion_timeout(&lpi2c_imx->complete, HZ);
> +
> + return timeout ? 0 : -ETIMEDOUT;
> +}
> +
> +static int lpi2c_imx_txfifo_empty(struct lpi2c_imx_struct *lpi2c_imx)
> +{
> + u32 txcnt;
> + unsigned long orig_jiffies = jiffies;
> +
> + do {
> + txcnt = readl(lpi2c_imx->base + LPI2C_MFSR) & 0xff;
> +
> + if (readl(lpi2c_imx->base + LPI2C_MSR) & MSR_NDF) {
> + dev_dbg(&lpi2c_imx->adapter.dev, "NDF detected\n");
> + return -EIO;
> + }
> +
> + if (time_after(jiffies, orig_jiffies + msecs_to_jiffies(500))) {
> + dev_dbg(&lpi2c_imx->adapter.dev, "txfifo empty timeout\n");
> + return -ETIMEDOUT;
> + }
> + schedule();
> +
> + } while (txcnt);
> +
> + return 0;
> +}
> +
> +static void lpi2c_imx_set_tx_watermark(struct lpi2c_imx_struct *lpi2c_imx)
> +{
> + unsigned int temp;
> +
> + temp = LPI2C_TX_FIFOSIZE >> 1;
> + writel(temp, lpi2c_imx->base + LPI2C_MFCR);
writel(LPI2C_TX_FIFOSIZE >> 1, lpi2c_imx->base + LPI2C_MFCR);
> +}
> +
> +static void lpi2c_imx_set_rx_watermark(struct lpi2c_imx_struct *lpi2c_imx)
> +{
> + unsigned int temp, remaining;
> +
> + remaining = lpi2c_imx->msglen - lpi2c_imx->delivered;
> +
> + if (remaining > (LPI2C_RX_FIFOSIZE >> 1))
> + temp = LPI2C_RX_FIFOSIZE >> 1;
> + else
> + temp = 0;
> +
> + writel(temp << 16, lpi2c_imx->base + LPI2C_MFCR);
> +}
> +
> +static void lpi2c_imx_write_txfifo(struct lpi2c_imx_struct *lpi2c_imx)
> +{
> + unsigned int data, txcnt;
> +
> + txcnt = readl(lpi2c_imx->base + LPI2C_MFSR) & 0xff;
Add an empty line here.
> + while (txcnt < LPI2C_TX_FIFOSIZE) {
> + if (lpi2c_imx->delivered == lpi2c_imx->msglen)
> + break;
Add an empty line here.
> + data = lpi2c_imx->tx_buf[lpi2c_imx->delivered++];
> + writel(data, lpi2c_imx->base + LPI2C_MTDR);
> + txcnt++;
> + }
> +
> + if (lpi2c_imx->delivered < lpi2c_imx->msglen)
> + lpi2c_imx_intctrl(lpi2c_imx, MIER_TDIE | MIER_NDIE);
> + else
> + complete(&lpi2c_imx->complete);
> +}
> +
> +static void lpi2c_imx_read_rxfifo(struct lpi2c_imx_struct *lpi2c_imx)
> +{
> + unsigned int temp, data;
> + unsigned int blocklen, remaining;
> +
> + do {
> + data = readl(lpi2c_imx->base + LPI2C_MRDR);
> + if (data & MRDR_RXEMPTY)
> + break;
Add an empty line here.
> + lpi2c_imx->rx_buf[lpi2c_imx->delivered++] = data & 0xff;
> + } while (1);
> +
> + /*
> + * First byte is the length of remaining packet in the SMBus block
> + * data read. Add it to msgs->len.
> + */
> + if (lpi2c_imx->block_data) {
> + blocklen = lpi2c_imx->rx_buf[0];
> + lpi2c_imx->msglen += blocklen;
> + }
> +
> + remaining = lpi2c_imx->msglen - lpi2c_imx->delivered;
> + /* not finished, still waiting for rx data */
Please move the comment under if (remaining) condition.
> + if (remaining) {
> + lpi2c_imx_set_rx_watermark(lpi2c_imx);
> + /* multiple receive commands */
> + if (lpi2c_imx->block_data) {
> + lpi2c_imx->block_data = 0;
> + temp = remaining;
> + temp |= (RECV_DATA << 8);
> + writel(temp, lpi2c_imx->base + LPI2C_MTDR);
> + } else if (!(lpi2c_imx->delivered & 0xff)) {
> + temp = remaining > CHUNK_DATA ?
> + CHUNK_DATA - 1 : (remaining - 1);
> + temp |= (RECV_DATA << 8);
> + writel(temp, lpi2c_imx->base + LPI2C_MTDR);
> + }
> +
> + lpi2c_imx_intctrl(lpi2c_imx, MIER_RDIE);
> + } else
> + complete(&lpi2c_imx->complete);
Start it from
if (!remaining) {
complete(&lpi2c_imx->complete);
return;
}
/* not finished, still waiting for rx data */
....
Then you get less indentations. Generally please use more return points
instead of if-if-if constructions.
> +}
> +
> +static void lpi2c_imx_write(struct lpi2c_imx_struct *lpi2c_imx,
> + struct i2c_msg *msgs)
> +{
> + lpi2c_imx->tx_buf = msgs->buf;
> + lpi2c_imx_set_tx_watermark(lpi2c_imx);
> + lpi2c_imx_write_txfifo(lpi2c_imx);
> +}
> +
> +static void lpi2c_imx_read(struct lpi2c_imx_struct *lpi2c_imx,
> + struct i2c_msg *msgs)
> +{
> + unsigned int temp;
> +
> + lpi2c_imx->rx_buf = msgs->buf;
> + lpi2c_imx->block_data = msgs->flags & I2C_M_RECV_LEN;
> +
> + lpi2c_imx_set_rx_watermark(lpi2c_imx);
> + temp = msgs->len > CHUNK_DATA ? CHUNK_DATA - 1 : msgs->len - 1;
> + temp |= (RECV_DATA << 8);
> + writel(temp, lpi2c_imx->base + LPI2C_MTDR);
> +
> + lpi2c_imx_intctrl(lpi2c_imx, MIER_RDIE | MIER_NDIE);
> +}
> +
> +static int lpi2c_imx_xfer(struct i2c_adapter *adapter,
> + struct i2c_msg *msgs, int num)
> +{
> + int i, result;
> + unsigned int temp;
> + struct lpi2c_imx_struct *lpi2c_imx = i2c_get_adapdata(adapter);
> +
> + result = lpi2c_imx_master_enable(lpi2c_imx);
> + if (result)
> + return result;
> +
> + for (i = 0; i < num; i++) {
> + result = lpi2c_imx_start(lpi2c_imx, &msgs[i]);
> + if (result)
> + goto disable;
> +
> + /* quick smbus */
> + if (num == 1 && msgs[0].len == 0)
> + goto stop;
> +
> + lpi2c_imx->delivered = 0;
> + lpi2c_imx->msglen = msgs[i].len;
> + init_completion(&lpi2c_imx->complete);
> +
> + if (msgs[i].flags & I2C_M_RD)
> + lpi2c_imx_read(lpi2c_imx, &msgs[i]);
> + else
> + lpi2c_imx_write(lpi2c_imx, &msgs[i]);
> +
> + result = lpi2c_imx_msg_complete(lpi2c_imx);
> + if (result)
> + goto stop;
> +
> + if (!(msgs[i].flags & I2C_M_RD)) {
> + result = lpi2c_imx_txfifo_empty(lpi2c_imx);
> + if (result)
> + goto stop;
> + }
> + }
> +
> +stop:
> + lpi2c_imx_stop(lpi2c_imx);
> +
> + temp = readl(lpi2c_imx->base + LPI2C_MSR);
> + if ((temp & MSR_NDF) && !result)
> + result = -EIO;
Zero-length transactions are not supported, right?
> +
> +disable:
> + lpi2c_imx_master_disable(lpi2c_imx);
> +
> + dev_dbg(&lpi2c_imx->adapter.dev, "<%s> exit with: %s: %d\n", __func__,
> + (result < 0) ? "error" : "success msg",
> + (result < 0) ? result : num);
> +
> + return (result < 0) ? result : num;
> +}
> +
> +static irqreturn_t lpi2c_imx_isr(int irq, void *dev_id)
> +{
> + unsigned int temp;
> + struct lpi2c_imx_struct *lpi2c_imx = dev_id;
> +
> + lpi2c_imx_intctrl(lpi2c_imx, 0);
> + temp = readl(lpi2c_imx->base + LPI2C_MSR);
> +
> + if (temp & MSR_RDF) {
> + lpi2c_imx_read_rxfifo(lpi2c_imx);
> + return IRQ_HANDLED;
> + }
> +
> + if (temp & MSR_TDF) {
> + lpi2c_imx_write_txfifo(lpi2c_imx);
> + return IRQ_HANDLED;
> + }
> +
> + complete(&lpi2c_imx->complete);
Add an empty line here.
> + return IRQ_HANDLED;
> +}
> +
> +static u32 lpi2c_imx_func(struct i2c_adapter *adapter)
> +{
> + return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL
> + | I2C_FUNC_SMBUS_READ_BLOCK_DATA;
checkpatch does not complain? I expect it should be
return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL |
I2C_FUNC_SMBUS_READ_BLOCK_DATA;
> +}
> +
> +static struct i2c_algorithm lpi2c_imx_algo = {
> + .master_xfer = lpi2c_imx_xfer,
> + .functionality = lpi2c_imx_func,
> +};
> +
> +static const struct of_device_id lpi2c_imx_of_match[] = {
> + { .compatible = "fsl,imx8dv-lpi2c" },
> + { .compatible = "fsl,imx7ulp-lpi2c" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, lpi2c_imx_of_match)
> +
> +static int lpi2c_imx_probe(struct platform_device *pdev)
> +{
> + int irq, ret;
> + void __iomem *base;
> + struct resource *res;
> + struct lpi2c_imx_struct *lpi2c_imx;
> +
> + lpi2c_imx = devm_kzalloc(&pdev->dev,
> + sizeof(*lpi2c_imx), GFP_KERNEL);
> + if (!lpi2c_imx)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0) {
> + dev_err(&pdev->dev, "can't get irq number\n");
> + return irq;
> + }
> +
> + lpi2c_imx->adapter.owner = THIS_MODULE;
> + lpi2c_imx->adapter.algo = &lpi2c_imx_algo;
> + lpi2c_imx->adapter.dev.parent = &pdev->dev;
> + lpi2c_imx->adapter.nr = pdev->id;
Do you really need it? Please consider to use i2c_add_adapter().
> + lpi2c_imx->base = base;
For sake of consistency please initialize lpi2c_imx->adapter fields
in a row.
You don't need this local 'base' variable, use lpi2c_imx->base instead.
> + lpi2c_imx->adapter.dev.of_node = pdev->dev.of_node;
> + strlcpy(lpi2c_imx->adapter.name, pdev->name,
> + sizeof(lpi2c_imx->adapter.name));
> +
> + lpi2c_imx->per_clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(lpi2c_imx->per_clk)) {
> + dev_err(&pdev->dev, "can't get I2C peripheral clock\n");
> + return PTR_ERR(lpi2c_imx->per_clk);
> + }
> +
> + ret = of_property_read_u32(pdev->dev.of_node,
> + "clock-frequency", &lpi2c_imx->bitrate);
> + if (ret)
> + lpi2c_imx->bitrate = LPI2C_DEFAULT_RATE;
> +
> + ret = devm_request_irq(&pdev->dev, irq, lpi2c_imx_isr, 0,
> + pdev->name, lpi2c_imx);
> + if (ret) {
> + dev_err(&pdev->dev, "can't claim irq %d\n", irq);
> + goto ret;
Just return ret;
> + }
> +
> + i2c_set_adapdata(&lpi2c_imx->adapter, lpi2c_imx);
> + platform_set_drvdata(pdev, lpi2c_imx);
> +
> + ret = i2c_add_numbered_adapter(&lpi2c_imx->adapter);
> + if (ret) {
> + dev_err(&pdev->dev, "registration failed\n");
> + goto ret;
Just return ret;
> + }
> +
> + dev_info(&lpi2c_imx->adapter.dev, "LPI2C adapter registered\n");
> +
> +ret:
> + return ret;
return 0;
> +}
> +
> +static int lpi2c_imx_remove(struct platform_device *pdev)
> +{
> + struct lpi2c_imx_struct *lpi2c_imx = platform_get_drvdata(pdev);
> +
> + i2c_del_adapter(&lpi2c_imx->adapter);
> +
> + return 0;
> +}
> +
> +static struct platform_driver lpi2c_imx_driver = {
> + .probe = lpi2c_imx_probe,
> + .remove = lpi2c_imx_remove,
> + .driver = {
> + .name = DRIVER_NAME,
> + .of_match_table = lpi2c_imx_of_match,
> + },
> +};
> +
> +static int __init i2c_adap_imx_init(void)
> +{
> + return platform_driver_register(&lpi2c_imx_driver);
> +}
> +module_init(i2c_adap_imx_init);
> +
> +static void __exit i2c_adap_imx_exit(void)
> +{
> + platform_driver_unregister(&lpi2c_imx_driver);
> +}
> +module_exit(i2c_adap_imx_exit);
> +
Please use module_platform_driver(lpi2c_imx_driver);
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Gao Pan <pandy.gao@nxp.com>");
> +MODULE_DESCRIPTION("I2C adapter driver for LPI2C bus");
> +MODULE_ALIAS("platform:" DRIVER_NAME);
>
Are you sure that the driver needs a platform alias here?
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH v1] I2C Designware Core Supports SMBUS BLOCK
From: tnhuynh @ 2016-10-25 4:35 UTC (permalink / raw)
To: Jarkko Nikula, Andy Shevchenko, Mika Westerberg, Wolfram Sang,
linux-i2c, linux-kernel
Cc: Loc Ho, Thang Nguyen, Phong Vo, patches, Tin Huynh
From: Tin Huynh <tnhuynh@apm.com>
Free and Open IPMI use SMBUS BLOCK Read/Write to support SSIF protocol.
However, I2C Designwave Core Driver doesn't handle the case at the moment.
The below patch supports this feature.
Signed-off-by: Tin Huynh <tnhuynh@apm.com>
---
drivers/i2c/busses/i2c-designware-core.c | 42 +++++++++++++++++++++++++--
drivers/i2c/busses/i2c-designware-platdrv.c | 1 +
2 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-core.c b/drivers/i2c/busses/i2c-designware-core.c
index 1fe93c4..3abf0e5 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -588,8 +588,17 @@ static void i2c_dw_xfer_init(struct dw_i2c_dev *dev)
* detected from the registers so we set it always
* when writing/reading the last byte.
*/
+
+ /*
+ * i2c-core.c always set the buffer length of
+ * I2C_FUNC_SMBUS_BLOCK_DATA to 1. The length will
+ * be adjusted when receiving the first byte.
+ * Thus we can't stop the transaction here.
+ */
+
if (dev->msg_write_idx == dev->msgs_num - 1 &&
- buf_len == 1)
+ buf_len == 1 &&
+ !(msgs[dev->msg_write_idx].flags & I2C_M_RECV_LEN))
cmd |= BIT(9);
if (need_restart) {
@@ -614,7 +623,14 @@ static void i2c_dw_xfer_init(struct dw_i2c_dev *dev)
dev->tx_buf = buf;
dev->tx_buf_len = buf_len;
- if (buf_len > 0) {
+ /*
+ * Because we don't know the buffer length in the
+ * I2C_FUNC_SMBUS_BLOCK_DATA case, we can't stop
+ * the transcation here.
+ */
+
+ if (buf_len > 0 ||
+ msgs[dev->msg_write_idx].flags & I2C_M_RECV_LEN) {
/* more bytes to be written */
dev->status |= STATUS_WRITE_IN_PROGRESS;
break;
@@ -659,7 +675,27 @@ static void i2c_dw_xfer_init(struct dw_i2c_dev *dev)
rx_valid = dw_readl(dev, DW_IC_RXFLR);
for (; len > 0 && rx_valid > 0; len--, rx_valid--) {
- *buf++ = dw_readl(dev, DW_IC_DATA_CMD);
+ *buf = dw_readl(dev, DW_IC_DATA_CMD);
+ /* ensure length byte is a valid value */
+ if (msgs[dev->msg_read_idx].flags & I2C_M_RECV_LEN
+ && *buf <= I2C_SMBUS_BLOCK_MAX && *buf > 0) {
+ /*
+ * Adjust the buffer length and mask the flag
+ * after receiving the first byte
+ */
+ msgs[dev->msg_read_idx].flags &=
+ ~I2C_M_RECV_LEN;
+ len = *buf + 1;
+ /* Increase one with PEC flag */
+ if (msgs[dev->msg_read_idx].flags &
+ I2C_CLIENT_PEC)
+ len++;
+
+ dev->tx_buf_len = len > dev->rx_outstanding ?
+ len - dev->rx_outstanding : 0;
+ msgs[dev->msg_read_idx].len = len;
+ }
+ buf++;
dev->rx_outstanding--;
}
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 0b42a12..886fb62 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -220,6 +220,7 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
I2C_FUNC_SMBUS_BYTE |
I2C_FUNC_SMBUS_BYTE_DATA |
I2C_FUNC_SMBUS_WORD_DATA |
+ I2C_FUNC_SMBUS_BLOCK_DATA |
I2C_FUNC_SMBUS_I2C_BLOCK;
dev->master_cfg = DW_IC_CON_MASTER | DW_IC_CON_SLAVE_DISABLE |
--
1.7.1
--
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and contains information that
is confidential and proprietary to Applied Micro Circuits Corporation or
its subsidiaries. It is to be used solely for the purpose of furthering the
parties' business relationship. All unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.
^ permalink raw reply related
* Re: [PATCH v1] I2C Designware Core Supports SMBUS BLOCK
From: Jarkko Nikula @ 2016-10-25 7:58 UTC (permalink / raw)
To: tnhuynh, Andy Shevchenko, Mika Westerberg, Wolfram Sang,
linux-i2c, linux-kernel
Cc: Loc Ho, Thang Nguyen, Phong Vo, patches
In-Reply-To: <1477370113-15145-1-git-send-email-tnhuynh@apm.com>
Hi
On 10/25/2016 07:35 AM, tnhuynh@apm.com wrote:
> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> @@ -220,6 +220,7 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
> I2C_FUNC_SMBUS_BYTE |
> I2C_FUNC_SMBUS_BYTE_DATA |
> I2C_FUNC_SMBUS_WORD_DATA |
> + I2C_FUNC_SMBUS_BLOCK_DATA |
> I2C_FUNC_SMBUS_I2C_BLOCK;
>
I guess you need to add the same to DW_DEFAULT_FUNCTIONALITY in
drivers/i2c/busses/i2c-designware-pcidrv.c too.
--
Jarkko
^ permalink raw reply
* Re: [PATCH] i2c: hix5hd2: allow build with ARCH_HISI
From: Wolfram Sang @ 2016-10-25 9:10 UTC (permalink / raw)
To: Ruqiang Ju; +Cc: linux-i2c, linux-kernel, xuejiancheng, yanhaifeng
In-Reply-To: <1477298389-13462-1-git-send-email-juruqiang@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 258 bytes --]
On Mon, Oct 24, 2016 at 04:39:49PM +0800, Ruqiang Ju wrote:
> This driver should be buildable with ARCH_HISI,
> because some of other HiSilicon SoCs also use it.
>
> Signed-off-by: Ruqiang Ju <juruqiang@huawei.com>
Applied to for-current, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c: rk3x: Give the tuning value 0 during rk3x_i2c_v0_calc_timings
From: Wolfram Sang @ 2016-10-25 9:12 UTC (permalink / raw)
To: David Wu
Cc: heiko, dianders, linux-arm-kernel, linux-rockchip, linux-i2c,
devicetree, linux-kernel
In-Reply-To: <1477125822-30644-1-git-send-email-david.wu@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 435 bytes --]
On Sat, Oct 22, 2016 at 04:43:42PM +0800, David Wu wrote:
> We found a bug that i2c transfer sometimes failed on 3066a board with
> stabel-4.8, the con register would be updated by uninitialized tuning
> value, it made the i2c transfer failed.
>
> So give the tuning value to be zero during rk3x_i2c_v0_calc_timings.
>
> Signed-off-by: David Wu <david.wu@rock-chips.com>
Added stable and applied to for-current, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] i2c: mark device nodes only in case of successful instantiation
From: Wolfram Sang @ 2016-10-25 9:23 UTC (permalink / raw)
To: Ralf Ramsauer
Cc: Mark Brown, Geert Uytterhoeven, Linux SPI, Linux I2C,
linux-kernel @ vger . kernel . org, Pantelis Antoniou
In-Reply-To: <20161017135957.20297-3-ralf@ramses-pyramidenbau.de>
[-- Attachment #1: Type: text/plain, Size: 767 bytes --]
On Mon, Oct 17, 2016 at 03:59:57PM +0200, Ralf Ramsauer wrote:
> Instantiated I2C device nodes are marked with OF_POPULATE. This was
> introduced in 4f001fd. On unloading, loaded device nodes will of course
> be unmarked. The problem are nodes that fail during initialisation: If a
> node fails, it won't be unloaded and hence not be unmarked.
>
> If a I2C driver module is unloaded and reloaded, it will skip nodes that
> failed before.
>
> Skip device nodes that are already populated and mark them only in case
> of success.
>
> Note that the same issue exists for SPI.
>
> Fixes: 4f001fd ("i2c: Mark instantiated device nodes with OF_POPULATE")
> Signed-off-by: Ralf Ramsauer <ralf@ramses-pyramidenbau.de>
Applied to for-current, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c: allow configuration of imx driver for ColdFire architecture
From: Wolfram Sang @ 2016-10-25 9:24 UTC (permalink / raw)
To: Greg Ungerer; +Cc: linux-i2c, angelo
In-Reply-To: <1476669245-3678-1-git-send-email-gerg@linux-m68k.org>
[-- Attachment #1: Type: text/plain, Size: 463 bytes --]
On Mon, Oct 17, 2016 at 11:54:05AM +1000, Greg Ungerer wrote:
> The i2c controller used by Freescales iMX processors is the same
> hardware module used on Freescales ColdFire family of processors.
>
> We can use the existing i2c-imx driver on ColdFire family members.
> Modify the configuration to allow it to be selected when compiling
> for ColdFire targets.
>
> Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Applied to for-current, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] i2c: Fix module autoload for some i2c busses platform drivers
From: Wolfram Sang @ 2016-10-25 9:32 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, Baruch Siach, linux-arm-kernel, linux-i2c
In-Reply-To: <1476824508-4679-1-git-send-email-javier@osg.samsung.com>
[-- Attachment #1: Type: text/plain, Size: 346 bytes --]
On Tue, Oct 18, 2016 at 06:01:44PM -0300, Javier Martinez Canillas wrote:
> Hello Wolfram,
>
> I noticed that module autoload won't be working in some of the i2c
> busses drivers. This patch series contains the fixes for these.
>
> Best regards,
> Javier
Applied to for-current, thank you very much for doing this
subsystem-wide!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers/i2c/i2c-dev: Fix kernel memory disclosure
From: Wolfram Sang @ 2016-10-25 9:45 UTC (permalink / raw)
To: Vlad Tsyrklevich; +Cc: linux-i2c
In-Reply-To: <1476190348-37589-1-git-send-email-vlad@tsyrklevich.net>
[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]
On Tue, Oct 11, 2016 at 02:52:28PM +0200, Vlad Tsyrklevich wrote:
> i2c_smbus_xfer() does not always fill an entire block, allowing
> kernel stack memory disclosure through the temp variable. Clear
> it before it's read to.
>
> Signed-off-by: Vlad Tsyrklevich <vlad@tsyrklevich.net>
Yes, thanks. But what about clearing 'temp' when it is declared? This
would be rock-solid for all future code paths.
>
> ---
> drivers/i2c/i2c-dev.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c
> index 66f323f..62cb111 100644
> --- a/drivers/i2c/i2c-dev.c
> +++ b/drivers/i2c/i2c-dev.c
> @@ -393,6 +393,8 @@ static noinline int i2cdev_ioctl_smbus(struct i2c_client *client,
> (data_arg.read_write == I2C_SMBUS_WRITE)) {
> if (copy_from_user(&temp, data_arg.data, datasize))
> return -EFAULT;
> + } else {
> + memset(&temp, 0, datasize);
> }
> if (data_arg.size == I2C_SMBUS_I2C_BLOCK_BROKEN) {
> /* Convert old I2C block commands to the new
> --
> 2.7.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c: xgene: Avoid dma_buffer overrun
From: Wolfram Sang @ 2016-10-25 9:50 UTC (permalink / raw)
To: Hoan Tran
Cc: linux-i2c, linux-kernel, Phil Endecott, Loc Ho, tnhuynh, patches
In-Reply-To: <1476119590-21489-1-git-send-email-hotran@apm.com>
[-- Attachment #1: Type: text/plain, Size: 373 bytes --]
On Mon, Oct 10, 2016 at 10:13:10AM -0700, Hoan Tran wrote:
> SMBus block command uses the first byte of buffer for the data length.
> The dma_buffer should be increased by 1 to avoid the overrun issue.
>
> Reported-by: Phil Endecott <phil_gjouf_endecott@chezphil.org>
> Signed-off-by: Hoan Tran <hotran@apm.com>
Added stable and applied to for-current, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2] i2c: i801: Fix I2C Block Read on 8-Series/C220 and later
From: Wolfram Sang @ 2016-10-25 10:02 UTC (permalink / raw)
To: Jean Delvare; +Cc: Linux I2C, Jarkko Nikula, Mika Westerberg
In-Reply-To: <20161011131327.0eabd227@endymion>
[-- Attachment #1: Type: text/plain, Size: 987 bytes --]
On Tue, Oct 11, 2016 at 01:13:27PM +0200, Jean Delvare wrote:
> Starting with the 8-Series/C220 PCH (Lynx Point), the SMBus
> controller includes a SPD EEPROM protection mechanism. Once the SPD
> Write Disable bit is set, only reads are allowed to slave addresses
> 0x50-0x57.
>
> However the legacy implementation of I2C Block Read since the ICH5
> looks like a write, and is therefore blocked by the SPD protection
> mechanism. This causes the eeprom and at24 drivers to fail.
>
> So assume that I2C Block Read is implemented as an actual read on
> these chipsets. I tested it on my Q87 chipset and it seems to work
> just fine.
>
> Signed-off-by: Jean Delvare <jdelvare@suse.de>
> Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com>
> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> Cc: Wolfram Sang <wsa@the-dreams.de>
Fixed the BIT() issue mentioned by Jarkko and applied to for-current,
thanks! But please double check my commit once I pushed out.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c: designware: Avoid aborted transfers with fast reacting I2C slaves
From: Wolfram Sang @ 2016-10-25 10:10 UTC (permalink / raw)
To: Jarkko Nikula; +Cc: linux-i2c, Andy Shevchenko, Mika Westerberg, Jukka Laitinen
In-Reply-To: <20160929130459.11345-1-jarkko.nikula@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 902 bytes --]
On Thu, Sep 29, 2016 at 04:04:59PM +0300, Jarkko Nikula wrote:
> I2C DesignWare may abort transfer with arbitration lost if I2C slave pulls
> SDA down quickly after falling edge of SCL. Reason for this is unknown but
> after trial and error it was found this can be avoided by enabling non-zero
> SDA RX hold time for the receiver.
>
> By the specification SDA RX hold time extends incoming SDA low to high
> transition by n * ic_clk cycles but only when SCL is high. However it
> seems to help avoid above faulty arbitration lost error.
>
> Bits 23:16 in IC_SDA_HOLD register define the SDA RX hold time for the
> receiver. Be conservative and enable 1 ic_clk cycle long hold time in
> case boot firmware hasn't set it up.
>
> Reported-by: Jukka Laitinen <jukka.laitinen@intel.com>
> Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Applied to for-current, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c: imx: defer probe if bus recovery GPIOs are not ready
From: Wolfram Sang @ 2016-10-25 10:16 UTC (permalink / raw)
To: Stefan Agner; +Cc: leoyang.li, linux-i2c, u.kleine-koenig, linux-kernel
In-Reply-To: <20160927001858.11601-1-stefan@agner.ch>
[-- Attachment #1: Type: text/plain, Size: 527 bytes --]
On Mon, Sep 26, 2016 at 05:18:58PM -0700, Stefan Agner wrote:
> Some SoC might load the GPIO driver after the I2C driver and
> using the I2C bus recovery mechanism via GPIOs. In this case
> it is crucial to defer probing if the GPIO request functions
> do so, otherwise the I2C driver gets loaded without recovery
> mechanisms enabled.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Added stable and applied to for-current, thanks! Please consider adding
a "Fixes: <sha-id>" next time. This would be helpful.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* True Parallel Port Interface for Bit-banging?
From: Sebastian Frias @ 2016-10-25 11:21 UTC (permalink / raw)
To: Sudip Mukherjee; +Cc: philb, Jean Delvare, linux-parport, tim, linux-i2c
Hi,
(NOTE: I also included "I2C over Parallel Port" maintainers in CC because
it seems they do bit-banging for it)
I would guess this question may have been asked before but I did not find references
to an answer, sorry for repeating if that's the case.
I have a legacy application that requires a True Parallel port (ISA compatible)
for bit-banging.
As you know, most computers nowadays do not include a True Parallel port anymore.
There are ExpressCard adaptors, but their base address is not ISA compliant
(378h, 278h).
The legacy application is DOS, so I was thinking of virtualising it under Linux
so that Linux works at ExpressCard address, hoping that the port would end up
being exposed to the virtualised DOS at the right (ISA-legacy) address.
Would that make sense and/or be feasible? Are there better/easier solutions?
Alternatively, does anybody knows if the Parallel Port available thru Laptop
docking stations (Dell, HP, Thinkpad, etc.) are True Parallel Ports (ISA
compatible)?
Thanks in advance.
Best regards,
Sebastian
^ permalink raw reply
* Re: [PATCH v1] I2C Designware Core Supports SMBUS BLOCK
From: Mika Westerberg @ 2016-10-25 11:50 UTC (permalink / raw)
To: tnhuynh
Cc: Jarkko Nikula, Andy Shevchenko, Wolfram Sang, linux-i2c,
linux-kernel, Loc Ho, Thang Nguyen, Phong Vo, patches
In-Reply-To: <1477370113-15145-1-git-send-email-tnhuynh@apm.com>
On Tue, Oct 25, 2016 at 11:35:13AM +0700, tnhuynh@apm.com wrote:
> From: Tin Huynh <tnhuynh@apm.com>
>
> Free and Open IPMI use SMBUS BLOCK Read/Write to support SSIF protocol.
> However, I2C Designwave Core Driver doesn't handle the case at the moment.
> The below patch supports this feature.
>
> Signed-off-by: Tin Huynh <tnhuynh@apm.com>
> ---
> drivers/i2c/busses/i2c-designware-core.c | 42 +++++++++++++++++++++++++--
> drivers/i2c/busses/i2c-designware-platdrv.c | 1 +
> 2 files changed, 40 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-designware-core.c b/drivers/i2c/busses/i2c-designware-core.c
> index 1fe93c4..3abf0e5 100644
> --- a/drivers/i2c/busses/i2c-designware-core.c
> +++ b/drivers/i2c/busses/i2c-designware-core.c
> @@ -588,8 +588,17 @@ static void i2c_dw_xfer_init(struct dw_i2c_dev *dev)
> * detected from the registers so we set it always
> * when writing/reading the last byte.
> */
> +
> + /*
> + * i2c-core.c always set the buffer length of
> + * I2C_FUNC_SMBUS_BLOCK_DATA to 1. The length will
> + * be adjusted when receiving the first byte.
> + * Thus we can't stop the transaction here.
> + */
> +
No empty line here.
> if (dev->msg_write_idx == dev->msgs_num - 1 &&
> - buf_len == 1)
> + buf_len == 1 &&
> + !(msgs[dev->msg_write_idx].flags & I2C_M_RECV_LEN))
Why not store flags somewhere in local variable. Then you do not need
the ugly line splitting above.
So instead
if (dev->msg_write_idx == dev->msgs_num -1 &&
buf_len == 1 && !(flags & I2C_M_RECV_LEN))
but even that starts to require small helper function, I think.
> cmd |= BIT(9);
>
> if (need_restart) {
> @@ -614,7 +623,14 @@ static void i2c_dw_xfer_init(struct dw_i2c_dev *dev)
> dev->tx_buf = buf;
> dev->tx_buf_len = buf_len;
>
> - if (buf_len > 0) {
> + /*
> + * Because we don't know the buffer length in the
> + * I2C_FUNC_SMBUS_BLOCK_DATA case, we can't stop
> + * the transcation here.
^^^^^^^^^^^
transaction
> + */
> +
No empty line here.
> + if (buf_len > 0 ||
> + msgs[dev->msg_write_idx].flags & I2C_M_RECV_LEN) {
Here also same comments about "flags".
> /* more bytes to be written */
> dev->status |= STATUS_WRITE_IN_PROGRESS;
> break;
> @@ -659,7 +675,27 @@ static void i2c_dw_xfer_init(struct dw_i2c_dev *dev)
> rx_valid = dw_readl(dev, DW_IC_RXFLR);
>
> for (; len > 0 && rx_valid > 0; len--, rx_valid--) {
> - *buf++ = dw_readl(dev, DW_IC_DATA_CMD);
> + *buf = dw_readl(dev, DW_IC_DATA_CMD);
> + /* ensure length byte is a valid value */
> + if (msgs[dev->msg_read_idx].flags & I2C_M_RECV_LEN
> + && *buf <= I2C_SMBUS_BLOCK_MAX && *buf > 0) {
And here. Also you have " " between I2C_SMBUS_BLOCK_MAX and &&.
> + /*
> + * Adjust the buffer length and mask the flag
> + * after receiving the first byte
> + */
> + msgs[dev->msg_read_idx].flags &=
> + ~I2C_M_RECV_LEN;
And here.
Actually you should move the whole block into a helper function.
> + len = *buf + 1;
> + /* Increase one with PEC flag */
> + if (msgs[dev->msg_read_idx].flags &
> + I2C_CLIENT_PEC)
> + len++;
> +
> + dev->tx_buf_len = len > dev->rx_outstanding ?
> + len - dev->rx_outstanding : 0;
> + msgs[dev->msg_read_idx].len = len;
> + }
> + buf++;
> dev->rx_outstanding--;
> }
>
> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
> index 0b42a12..886fb62 100644
> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> @@ -220,6 +220,7 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
> I2C_FUNC_SMBUS_BYTE |
> I2C_FUNC_SMBUS_BYTE_DATA |
> I2C_FUNC_SMBUS_WORD_DATA |
> + I2C_FUNC_SMBUS_BLOCK_DATA |
> I2C_FUNC_SMBUS_I2C_BLOCK;
>
> dev->master_cfg = DW_IC_CON_MASTER | DW_IC_CON_SLAVE_DISABLE |
> --
> 1.7.1
>
>
> --
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
> for the sole use of the intended recipient(s) and contains information that
> is confidential and proprietary to Applied Micro Circuits Corporation or
> its subsidiaries. It is to be used solely for the purpose of furthering the
> parties' business relationship. All unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all copies of the original
> message.
Yeah, right.
^ permalink raw reply
* Re: True Parallel Port Interface for Bit-banging?
From: Wolfram Sang @ 2016-10-25 12:09 UTC (permalink / raw)
To: Sebastian Frias
Cc: Sudip Mukherjee, linux-parport, philb, tim, Jean Delvare,
linux-i2c
In-Reply-To: <580F4042.5070201@laposte.net>
[-- Attachment #1: Type: text/plain, Size: 419 bytes --]
> Would that make sense and/or be feasible? Are there better/easier solutions?
Binary patching the DOS application? Port accesses should be easy to
find.
Getting a laptop with parallel port via auction site?
> Alternatively, does anybody knows if the Parallel Port available thru Laptop
> docking stations (Dell, HP, Thinkpad, etc.) are True Parallel Ports (ISA
> compatible)?
The older, the likelier, I'd say :)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v1] I2C Designware Core Supports SMBUS BLOCK
From: Andy Shevchenko @ 2016-10-25 12:34 UTC (permalink / raw)
To: Mika Westerberg, tnhuynh
Cc: Jarkko Nikula, Wolfram Sang, linux-i2c, linux-kernel, Loc Ho,
Thang Nguyen, Phong Vo, patches
In-Reply-To: <20161025115025.GI1476@lahna.fi.intel.com>
On Tue, 2016-10-25 at 14:50 +0300, Mika Westerberg wrote:
> On Tue, Oct 25, 2016 at 11:35:13AM +0700, tnhuynh@apm.com wrote:
> > --
> > CONFIDENTIALITY NOTICE: This e-mail message, including any
> > attachments, is
> > for the sole use of the intended recipient(s) and contains
> > information that
> > is confidential and proprietary to Applied Micro Circuits
> > Corporation or
> > its subsidiaries. It is to be used solely for the purpose of
> > furthering the
> > parties' business relationship. All unauthorized review, use,
> > disclosure or
> > distribution is prohibited. If you are not the intended recipient,
> > please
> > contact the sender by reply e-mail and destroy all copies of the
> > original
> > message.
Tin Huynh, if you want to continue, you *have to* get rid of this
footer, otherwise no one is going to commit even *the best feature
ever*.
Perhaps you need to talk to your lawyers first.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: True Parallel Port Interface for Bit-banging?
From: Jean Delvare @ 2016-10-25 13:22 UTC (permalink / raw)
To: Sebastian Frias; +Cc: Sudip Mukherjee, linux-parport, philb, tim, linux-i2c
In-Reply-To: <580F4042.5070201@laposte.net>
On mar., 2016-10-25 at 13:21 +0200, Sebastian Frias wrote:
> Alternatively, does anybody knows if the Parallel Port available thru Laptop
> docking stations (Dell, HP, Thinkpad, etc.) are True Parallel Ports (ISA
> compatible)?
Some laptops such as the ThinkPad T42 had parallel ports, without the
need of a docking station. I know because my dad still has one. But well
these are 2004 machines, may be hard to find these days.
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply
* Re: True Parallel Port Interface for Bit-banging?
From: Sebastian Frias @ 2016-10-25 14:20 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Jean Delvare, linux-parport, linux-i2c, philb, tim
In-Reply-To: <20161025120951.GL1597@katana>
On 10/25/2016 02:09 PM, Wolfram Sang wrote:
>
>> Would that make sense and/or be feasible? Are there better/easier solutions?
>
> Binary patching the DOS application? Port accesses should be easy to
> find.
Would the ExpressCard Parallel Port appear always at the same address?
While this could work, it wouldn't be generic. I would have to do the operation
for N apps.
>
> Getting a laptop with parallel port via auction site?
:-)
I would like to avoid having to buy another laptop.
The virtualisation idea is not good then?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox