Re: [PATCH] i2c: designware: retry transfer on transient failure
On Mon, 2016-01-04 at 20:49 +0100, Wolfram Sang wrote: > > After that, introduce a new property 'linux,i2c-retry-count' to be > > used > > as retries field in struct i2c_adapter. > > Hmm, to be honest, I always have difficulties with this "retries" > parameter; to me "try x milliseconds" makes more sense than "try 5 > times". It is there for ages, so we have to stick with it, but > frankly, > I wouldn't like to expose it too much :) Point taken. > I'm okay with the original patch putting some "sane" initial value. > It > can be modified at runtime via a i2c-dev ioctl if needed. Ah, good. So, I'm fine with it if no one has strong argument. -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c/designware: enable i2c controller to suspend/resume asynchronously
On Tue, 2016-01-05 at 10:53 +0200, Jarkko Nikula wrote: > Hi > > On 12/24/2015 04:30 PM, Fu, Zhonghui wrote: > > Now, PM core supports asynchronous suspend/resume mode for devices > > during system suspend/resume, and the power state transition of one > > device may be completed in separate kernel thread. PM core ensures > > all power state transition dependency between devices. This patch > > enables designware i2c controllers to suspend/resume > > asynchronously. > > This will take advantage of multicore and improve system > > suspend/resume > > speed. After enabling all i2c devices, i2c adapters and i2c > > controllers > > on ASUS T100TA tablet, the system suspend-to-idle time is reduced > > to > > about 510ms from 750ms, and the system resume time is reduced to > > about > > 790ms from 900ms. > > > Nice reduction :-) > > > diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c > > b/drivers/i2c/busses/i2c-designware-platdrv.c > > index 6b00061..395130b 100644 > > --- a/drivers/i2c/busses/i2c-designware-platdrv.c > > +++ b/drivers/i2c/busses/i2c-designware-platdrv.c > > @@ -230,6 +230,7 @@ static int dw_i2c_plat_probe(struct > > platform_device *pdev) > > } > > > > adap = >adapter; > > + device_enable_async_suspend(>dev); > > adap->owner = THIS_MODULE; > > adap->class = I2C_CLASS_DEPRECATED; > > ACPI_COMPANION_SET(>dev, ACPI_COMPANION( > > >dev)); > > Does device_enable_async_suspend() need to be called before enabling > runtime PM? I suppose not since there appears to have also related > sysfs > node for toggling it runtime. > > I'm thinking if you could move the device_enable_async_suspend() call > into drivers/i2c/busses/i2c-designware-core.c: i2c_dw_probe() and > then > also PCI enumerated adapter could take advantage of it. I concern about Intel BayTrail-T / Braswell / CherryTrail cases, since we have non-trivial PM for LPSS there. Zhonghui, have you a chance to stress test this on platforms based on mentioned SoCs? -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DT: i2c: Update vendor prefix for 24c00
On Sat, Jan 2, 2016 at 11:21 PM, Wolfram Sang <w...@the-dreams.de> wrote: > On Sun, Dec 27, 2015 at 04:57:48PM +0200, Andy Shevchenko wrote: >> On Wed, Dec 23, 2015 at 9:18 PM, Akshay Bhat <akshay.b...@timesys.com> wrote: >> > "at" is not a valid vendor prefix, correcting the same to "atmel" >> > >> >> I'm afraid you can't just do this change alone as it's used in some >> DTS. Though you may deprecated it along with update of current users. > > Well, in Linux, I2C core currently strips the vendor anyhow. This will > probably be changed somewhen (tm), but for now, the impact for Linux > should be extremly close to 0. Okay, no objections to the original patch then. > > >> >> > Signed-off-by: Akshay Bhat <akshay.b...@timesys.com> >> > --- >> > Documentation/devicetree/bindings/i2c/trivial-devices.txt | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt >> > b/Documentation/devicetree/bindings/i2c/trivial-devices.txt >> > index c50cf13..c4a01c0 100644 >> > --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt >> > +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt >> > @@ -20,11 +20,11 @@ adi,adt7476 +/-1C TDM Extended Temp Range I.C >> > adi,adt7490+/-1C TDM Extended Temp Range I.C >> > adi,adxl345Three-Axis Digital Accelerometer >> > adi,adxl346Three-Axis Digital Accelerometer >> > (backward-compatibility value "adi,adxl345" must be listed too) >> > -at,24c08 i2c serial eeprom (24cxx) >> > atmel,24c00i2c serial eeprom (24cxx) >> > atmel,24c01i2c serial eeprom (24cxx) >> > atmel,24c02i2c serial eeprom (24cxx) >> > atmel,24c04i2c serial eeprom (24cxx) >> > +atmel,24c08i2c serial eeprom (24cxx) >> > atmel,24c16i2c serial eeprom (24cxx) >> > atmel,24c32i2c serial eeprom (24cxx) >> > atmel,24c64i2c serial eeprom (24cxx) >> > -- >> > 2.6.3 >> > >> > -- >> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> > the body of a message to majord...@vger.kernel.org >> > More majordomo info at http://vger.kernel.org/majordomo-info.html >> > Please read the FAQ at http://www.tux.org/lkml/ >> >> >> >> -- >> With Best Regards, >> Andy Shevchenko -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: designware: retry transfer on transient failure
On Wed, 2015-12-23 at 18:43 +0200, Baruch Siach wrote:
> Set the i2c_adapter retries field to a sensible value. This allows
> the i2c core
> to retry master_xfer() when it returns -EAGAIN. Currently the i2c-
> designware
> driver returns -EAGAIN only on Tx arbitration failure
> (DW_IC_TX_ARB_LOST).
Wolfram, regarding to this patch I have the following idea (I would
like to discuss a road map before step in implementing that).
First of all I would like to refactor the existing API,
i.e. i2c_parse_fw_timings(). So, do exactly two things:
a) embed struct i2c_timings into struct i2c_adapter;
b) change prototype to be i2c_parse_fw_timings(struct i2c_adapter
*adapter, bool use_defaults).
After that, introduce a new property 'linux,i2c-retry-count' to be used
as retries field in struct i2c_adapter.
Then introduce where we do similar stuff
void i2c_parse_linux_retries(struct i2c_adapter *adapter, bool
use_defaults)
{
struct device *dev = adapter->dev.parent;
int ret;
ret = device_property_read_u{8,16,32?}(dev, "linux,i2c-retry-count",
>retries);
if (ret && use_defaults)
adapter->retries = 3;
}
And replace adapter.retries = 3 in the drivers by
i2c_parse_linux_retries(, true);
So, what do you think?
>
> Reported-by: Rolland Chau <zourongr...@gmail.com>
> Signed-off-by: Baruch Siach <bar...@tkos.co.il>
> ---
> drivers/i2c/busses/i2c-designware-core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/i2c/busses/i2c-designware-core.c
> b/drivers/i2c/busses/i2c-designware-core.c
> index de7fbbb374cd..f7b34b360dc9 100644
> --- a/drivers/i2c/busses/i2c-designware-core.c
> +++ b/drivers/i2c/busses/i2c-designware-core.c
> @@ -860,6 +860,7 @@ int i2c_dw_probe(struct dw_i2c_dev *dev)
>
> snprintf(adap->name, sizeof(adap->name),
> "Synopsys DesignWare I2C adapter");
> + adap->retries = 3;
> adap->algo = _dw_algo;
> adap->dev.parent = dev->dev;
> i2c_set_adapdata(adap, dev);
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DT: i2c: Update vendor prefix for 24c00
On Wed, Dec 23, 2015 at 9:18 PM, Akshay Bhat <akshay.b...@timesys.com> wrote: > "at" is not a valid vendor prefix, correcting the same to "atmel" > I'm afraid you can't just do this change alone as it's used in some DTS. Though you may deprecated it along with update of current users. > Signed-off-by: Akshay Bhat <akshay.b...@timesys.com> > --- > Documentation/devicetree/bindings/i2c/trivial-devices.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt > b/Documentation/devicetree/bindings/i2c/trivial-devices.txt > index c50cf13..c4a01c0 100644 > --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt > +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt > @@ -20,11 +20,11 @@ adi,adt7476 +/-1C TDM Extended Temp Range I.C > adi,adt7490+/-1C TDM Extended Temp Range I.C > adi,adxl345Three-Axis Digital Accelerometer > adi,adxl346Three-Axis Digital Accelerometer > (backward-compatibility value "adi,adxl345" must be listed too) > -at,24c08 i2c serial eeprom (24cxx) > atmel,24c00i2c serial eeprom (24cxx) > atmel,24c01i2c serial eeprom (24cxx) > atmel,24c02i2c serial eeprom (24cxx) > atmel,24c04i2c serial eeprom (24cxx) > +atmel,24c08i2c serial eeprom (24cxx) > atmel,24c16i2c serial eeprom (24cxx) > atmel,24c32i2c serial eeprom (24cxx) > atmel,24c64i2c serial eeprom (24cxx) > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DT: i2c: Add Epson RX8010 to list of trivial devices
On Wed, Dec 23, 2015 at 8:38 PM, Akshay Bhat <akshay.b...@timesys.com> wrote: > This adds devicetree documentation for the bindings of rtc-rx8010 > driver. > > Signed-off-by: Akshay Bhat <akshay.b...@timesys.com> > --- > Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt > b/Documentation/devicetree/bindings/i2c/trivial-devices.txt > index c50cf13..0f9c1de 100644 > --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt > +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt > @@ -49,6 +49,7 @@ dallas,ds4510 CPU Supervisor with Nonvolatile > Memory and Programmable I/O > dallas,ds75Digital Thermometer and Thermostat > dlg,da9053 DA9053: flexible system level PMIC with multicore > support > dlg,da9063 DA9063: system PMIC for quad-core application > processors > +epson,rx8010 I2C-BUS INTERFACE REAL TIME CLOCK MODULE Is it indeed required to have all those capital letters together? > epson,rx8025 High-Stability. I2C-Bus INTERFACE REAL TIME CLOCK > MODULE > epson,rx8581 I2C-BUS INTERFACE REAL TIME CLOCK MODULE > fsl,mag3110MAG3110: Xtrinsic High Accuracy, 3D Magnetometer > -- > 2.6.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9] i2c: designware: use to_pci_dev()
On Sun, Dec 27, 2015 at 12:45 PM, Geliang Tang <geliangt...@163.com> wrote:
> Use to_pci_dev() instead of open-coding it.
>
Reviewed-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
> Signed-off-by: Geliang Tang <geliangt...@163.com>
> ---
> drivers/i2c/busses/i2c-designware-pcidrv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c
> b/drivers/i2c/busses/i2c-designware-pcidrv.c
> index 1543d35d..7368be0 100644
> --- a/drivers/i2c/busses/i2c-designware-pcidrv.c
> +++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
> @@ -162,7 +162,7 @@ static struct dw_pci_controller dw_pci_controllers[] = {
> #ifdef CONFIG_PM
> static int i2c_dw_pci_suspend(struct device *dev)
> {
> - struct pci_dev *pdev = container_of(dev, struct pci_dev, dev);
> + struct pci_dev *pdev = to_pci_dev(dev);
>
> i2c_dw_disable(pci_get_drvdata(pdev));
> return 0;
> @@ -170,7 +170,7 @@ static int i2c_dw_pci_suspend(struct device *dev)
>
> static int i2c_dw_pci_resume(struct device *dev)
> {
> - struct pci_dev *pdev = container_of(dev, struct pci_dev, dev);
> + struct pci_dev *pdev = to_pci_dev(dev);
>
> return i2c_dw_init(pci_get_drvdata(pdev));
> }
> --
> 2.5.0
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] i2c: designware: Do not require clock when SSCN and FFCN are provided
ivers/i2c/busses/i2c-designware-platdrv.c
> index 8ffc36b..04edd09 100644
> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
Can we introduce
static int i2c_dw_plat_prepare_clk(struct dw_i2c_dev *i_dev, bool
prepare)
{
if (IS_ERR(i_dev->clk))
return PTR_ERR(i_dev->clk);
if (prepare)
/* REMOVEME: Yes, you have to check return value and this is one
benefit of this change */
return clk_prepare_enable(i_dev->clk);
clk_disable_unprepare(i_dev->clk);
return 0;
}
and…
> @@ -205,16 +205,14 @@ static int dw_i2c_plat_probe(struct
> platform_device *pdev)
> DW_IC_CON_RESTART_EN | DW_IC_CON_SPEED_FAST;
>
> dev->clk = devm_clk_get(>dev, NULL);
> - dev->get_clk_rate_khz = i2c_dw_get_clk_rate_khz;
> - if (IS_ERR(dev->clk))
> - return PTR_ERR(dev->clk);
> - clk_prepare_enable(dev->clk);
> -
> - if (!dev->sda_hold_time && ht) {
> - u32 ic_clk = dev->get_clk_rate_khz(dev);
> -
> - dev->sda_hold_time = div_u64((u64)ic_clk * ht +
> 50,
> - 100);
> + if (!IS_ERR(dev->clk)) {
> + dev->get_clk_rate_khz = i2c_dw_get_clk_rate_khz;
> + clk_prepare_enable(dev->clk);
if (!i2c_dw_plat_prepare_clk(dev, true)) {
dev->get_clk_rate_khz = i2c_dw_get_clk_rate_khz;
…
> +
> + if (!dev->sda_hold_time && ht)
> + dev->sda_hold_time = div_u64(
> + (u64)dev->get_clk_rate_khz(dev) * ht
> + 50,
> + 100);
> }
>
> if (!dev->tx_fifo_depth) {
> @@ -297,7 +295,8 @@ static int dw_i2c_plat_suspend(struct device
> *dev)
> struct dw_i2c_dev *i_dev = platform_get_drvdata(pdev);
>
> i2c_dw_disable(i_dev);
> - clk_disable_unprepare(i_dev->clk);
> + if (!IS_ERR(i_dev->clk))
> + clk_disable_unprepare(i_dev->clk);
i2c_dw_plat_prepare_clk(i_dev, false);
>
> return 0;
> }
> @@ -307,7 +306,8 @@ static int dw_i2c_plat_resume(struct device *dev)
> struct platform_device *pdev = to_platform_device(dev);
> struct dw_i2c_dev *i_dev = platform_get_drvdata(pdev);
>
> - clk_prepare_enable(i_dev->clk);
> + if (!IS_ERR(i_dev->clk))
> + clk_prepare_enable(i_dev->clk);
i2c_dw_plat_prepare_clk(i_dev, true);
>
> if (!i_dev->pm_runtime_disabled)
> i2c_dw_init(i_dev);
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: designware: retry transfer on transient failure
On Wed, 2015-12-23 at 18:43 +0200, Baruch Siach wrote: > Set the i2c_adapter retries field to a sensible value. This allows > the i2c core > to retry master_xfer() when it returns -EAGAIN. Currently the i2c- > designware > driver returns -EAGAIN only on Tx arbitration failure > (DW_IC_TX_ARB_LOST). While this patch looks okay I have another proposal. Let me time I'm going to mock up the idea. > > Reported-by: Rolland Chau <zourongr...@gmail.com> > Signed-off-by: Baruch Siach <bar...@tkos.co.il> > --- > drivers/i2c/busses/i2c-designware-core.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/i2c/busses/i2c-designware-core.c > b/drivers/i2c/busses/i2c-designware-core.c > index de7fbbb374cd..f7b34b360dc9 100644 > --- a/drivers/i2c/busses/i2c-designware-core.c > +++ b/drivers/i2c/busses/i2c-designware-core.c > @@ -860,6 +860,7 @@ int i2c_dw_probe(struct dw_i2c_dev *dev) > > snprintf(adap->name, sizeof(adap->name), > "Synopsys DesignWare I2C adapter"); > + adap->retries = 3; > adap->algo = _dw_algo; > adap->dev.parent = dev->dev; > i2c_set_adapdata(adap, dev); -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/3] i2c: rk3x: add calc_divs ops for new version
i2c->scl_fall_ns, i2c->sda_fall_ns,
>> -_low, _high);
>> +_low, _high, );
>> WARN_ONCE(ret != 0, "Could not reach SCL freq %u",
>> i2c->scl_frequency);
>>
>> clk_enable(i2c->clk);
>> i2c_writel(i2c, (div_high << 16) | (div_low & 0x),
>> REG_CLKDIV);
>> + i2c->time_con = con;
>> clk_disable(i2c->clk);
>>
>> t_low_ns = div_u64(((u64)div_low + 1) * 8 * 10, clk_rate);
>> @@ -661,13 +686,14 @@ static int rk3x_i2c_clk_notifier_cb(struct
>> notifier_block *nb, unsigned long
>> struct clk_notifier_data *ndata = data;
>> struct rk3x_i2c *i2c = container_of(nb, struct rk3x_i2c,
>> clk_rate_nb);
>> unsigned long div_low, div_high;
>> + unsigned int con = 0;
>>
>> switch (event) {
>> case PRE_RATE_CHANGE:
>> - if (rk3x_i2c_calc_divs(ndata->new_rate,
>> i2c->scl_frequency,
>> + if (i2c->ops.calc_divs(ndata->new_rate,
>> i2c->scl_frequency,
>>i2c->scl_rise_ns, i2c->scl_fall_ns,
>>i2c->sda_fall_ns,
>> - _low, _high) != 0)
>> + _low, _high, ) != 0)
>> return NOTIFY_STOP;
>>
>> /* scale up */
>> @@ -816,7 +842,8 @@ static int rk3x_i2c_xfer(struct i2c_adapter *adap,
>>
>> /* Force a STOP condition without interrupt */
>> i2c_writel(i2c, 0, REG_IEN);
>> - i2c_writel(i2c, REG_CON_EN | REG_CON_STOP,
>> REG_CON);
>> + i2c_writel(i2c, i2c->time_con | REG_CON_EN |
>> + REG_CON_STOP, REG_CON);
>>
>> i2c->state = STATE_IDLE;
>>
>> @@ -871,6 +898,7 @@ static int rk3x_i2c_probe(struct platform_device
>> *pdev)
>> u32 value;
>> int irq;
>> unsigned long clk_rate;
>> + unsigned int version;
>>
>> i2c = devm_kzalloc(>dev, sizeof(struct rk3x_i2c),
>> GFP_KERNEL);
>> if (!i2c)
>> @@ -983,6 +1011,10 @@ static int rk3x_i2c_probe(struct platform_device
>> *pdev)
>>
>> platform_set_drvdata(pdev, i2c);
>>
>> + version = (readl(i2c->regs + REG_CON) & VERSION_MASK) >>
>> VERSION_SHIFT;
>> + if (version == RK3X_I2C_V0)
>> + i2c->ops.calc_divs = rk3x_i2c_v0_calc_divs;
>> +
>> ret = clk_prepare(i2c->clk);
>> if (ret < 0) {
>> dev_err(>dev, "Could not prepare clock\n");
>>
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c: designware: Allow build Baytrail semaphore support when IOSF_MBI=m
On Thu, 2015-12-10 at 13:48 +0200, Jarkko Nikula wrote: > I believe i2c-designware-baytrail.c doesn't have strict dependency > that > Intel SoC IOSF Sideband support must be always built-in in order to > be > able to compile support for Intel Baytrail I2C bus sharing HW > semaphore. > > Redefine build dependencies so that CONFIG_IOSF_MBI=y is required > only > when CONFIG_I2C_DESIGNWARE_PLATFORM is built-in. > > Signed-off-by: Jarkko Nikula <jarkko.nik...@linux.intel.com> > --- > Hi David. Can you ack/nak this patch as I'm not fully familiar with > this > HW semaphore can there be problems when IOSF_MBI is built as a > module. > At least I'm getting similar sensible looking "punit semaphore > acquired/held for x ms" debug messages when I modprobe/rmmod > i2c_designware_platform independently is the CONFIG_IOSF_MBI=y or =m. > --- > drivers/i2c/busses/Kconfig | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig > index 69c46fe13777..76f4d024def0 100644 > --- a/drivers/i2c/busses/Kconfig > +++ b/drivers/i2c/busses/Kconfig > @@ -490,7 +490,9 @@ config I2C_DESIGNWARE_PCI > > config I2C_DESIGNWARE_BAYTRAIL > bool "Intel Baytrail I2C semaphore support" > - depends on I2C_DESIGNWARE_PLATFORM && IOSF_MBI=y && ACPI > + depends on ACPI > + depends on (I2C_DESIGNWARE_PLATFORM=m && IOSF_MBI) || \ > + (I2C_DESIGNWARE_PLATFORM=y && IOSF_MBI=y) Would it be more readable in the following way depends on ACPI depends on I2C_DESIGNWARE_PLATFORM depends on IOSF_MBI if I2C_DESIGNWARE_PLATFORM=m depends on IOSF_MBI=y if I2C_DESIGNWARE_PLATFORM=y > help > This driver enables managed host access to the PMIC I2C > bus on select > Intel BayTrail platforms using the X-Powers AXP288 PMIC. > It allows -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/9] i2c: add generic routine to parse DT for timing information
On Tue, 2015-12-08 at 22:51 +0100, Wolfram Sang wrote:
> On Tue, Dec 08, 2015 at 02:03:23PM +0100, Wolfram Sang wrote:
> >
> > > Too many && use_defaults. What about
> > >
> > > memset(t, 0, sizeof(*t));
> > >
> > > device_property_read_u32(dev, "i2c-scl-internal-delay-ns",
> > > > scl_int_delay_ns);
> > >
> > > if (!use_defaults)
> > > return;
> >
> > I like this! Thanks for the input.
>
> Oops, too enthusiastic. This skips parsing all the other
> properties...
> The defaults should only be applied if reading the properties fails.
Looks like property stuff is not destructive in case of error, so, what
about
paramX = use_defaults ? defaultX : 0;
device_property_read…(…, );
Or maybe just be a bit verbose like the original variant
int ret;
ret = device_property_read…(…);
if (ret && use_defaults) {
…
}
Among all variants I like the latter one here. What do you think?
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/9] i2c: add generic routine to parse DT for timing information
On Tue, 2015-12-08 at 10:37 +0100, Wolfram Sang wrote:
> From: Wolfram Sang <wsa+rene...@sang-engineering.com>
>
> Inspired from the i2c-rk3x driver (thanks guys!) but refactored and
> extended. See built-in docs for further information.
One style comment.
>
> Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com>
> ---
> drivers/i2c/i2c-core.c | 47
> +++
> include/linux/i2c.h| 18 ++
> 2 files changed, 65 insertions(+)
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index ba8eb087f22465..e94d2ca2aab4aa 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -53,6 +53,7 @@
> #include
> #include
> #include
> +#include
>
> #include "i2c-core.h"
>
> @@ -1438,6 +1439,52 @@ static void of_i2c_register_devices(struct
> i2c_adapter *adap)
> }
> }
>
> +/**
> + * i2c_parse_fw_timings - get I2C related timing parameters from
> firmware
> + * @dev: The device to scan for I2C timing properties
> + * @t: the i2c_timings struct to be filled with values
> + * @use_defaults: bool to use sane defaults derived from the I2C
> specification
> + * when properties are not found, otherwise use 0
> + *
> + * Scan the device for the generic I2C properties describing timing
> parameters
> + * for the signal and fill the given struct with the results. If a
> property was
> + * not found and use_defaults was true, then maximum timings are
> assumed which
> + * are derived from the I2C specification. If use_defaults is not
> used, the
> + * results will be 0, so drivers can apply their own defaults later.
> The latter
> + * is mainly intended for avoiding regressions of existing drivers
> which want
> + * to switch to this function. New drivers almost always should use
> the defaults.
> + */
> +
> +void i2c_parse_fw_timings(struct device *dev, struct i2c_timings *t,
> bool use_defaults)
> +{
> + memset(t, 0, sizeof(*t));
> +
> + if (device_property_read_u32(dev, "clock-frequency",
> >bus_freq_hz) && use_defaults)
> + t->bus_freq_hz = 10;
> +
> + if (device_property_read_u32(dev, "i2c-scl-rising-time-ns",
> >scl_rise_ns) && use_defaults) {
> + if (t->bus_freq_hz <= 10)
> + t->scl_rise_ns = 1000;
> + else if (t->bus_freq_hz <= 40)
> + t->scl_rise_ns = 300;
> + else
> + t->scl_rise_ns = 120;
> + }
> +
> + if (device_property_read_u32(dev, "i2c-scl-falling-time-ns",
> >scl_fall_ns) && use_defaults) {
> + if (t->bus_freq_hz <= 40)
> + t->scl_fall_ns = 300;
> + else
> + t->scl_fall_ns = 120;
> + }
> +
> + device_property_read_u32(dev, "i2c-scl-internal-delay-ns",
> >scl_int_delay_ns);
> +
> + if (device_property_read_u32(dev, "i2c-sda-falling-time-ns",
> >sda_fall_ns) && use_defaults)
> + t->sda_fall_ns = t->scl_fall_ns;
Too many && use_defaults. What about
memset(t, 0, sizeof(*t));
device_property_read_u32(dev, "i2c-scl-internal-delay-ns",
>scl_int_delay_ns);
if (!use_defaults)
return;
...
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/9] i2c: rcar: switch to i2c generic dt parsing
On Tue, 2015-12-08 at 10:37 +0100, Wolfram Sang wrote:
> From: Wolfram Sang <wsa+rene...@sang-engineering.com>
>
> Switch to the new generic functions. Plain convert, no functionality
> added yet.
One style nitpick.
>
> Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com>
> ---
> drivers/i2c/busses/i2c-rcar.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-
> rcar.c
> index d4322a9096786f..c663f4389bf898 100644
> --- a/drivers/i2c/busses/i2c-rcar.c
> +++ b/drivers/i2c/busses/i2c-rcar.c
> @@ -162,12 +162,15 @@ static int rcar_i2c_bus_barrier(struct
> rcar_i2c_priv *priv)
> return -EBUSY;
> }
>
> -static int rcar_i2c_clock_calculate(struct rcar_i2c_priv *priv, u32
> bus_speed)
> +static int rcar_i2c_clock_calculate(struct rcar_i2c_priv *priv,
> struct i2c_timings *t)
> {
> u32 scgd, cdf, round, ick, scl, cdf_width;
> unsigned long rate;
> struct device *dev = rcar_i2c_priv_to_dev(priv);
>
> + /* Fall back to previously used values if not supplied */
> + t->bus_freq_hz = t->bus_freq_hz ?: 10;
On one hand it seems enough space to put one more t->bus_freq_hz, on
the other why not
if (!t->bus_freq_hz)
= 10;
I think a bit better to maintain latter.
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API
On Wed, 2015-12-02 at 02:28 +0100, Rafael J. Wysocki wrote: > On Tuesday, December 01, 2015 12:33:51 PM Andy Shevchenko wrote: > > On Mon, 2015-11-30 at 20:58 +0100, Wolfram Sang wrote: > > > On Mon, Nov 30, 2015 at 05:11:44PM +0200, Andy Shevchenko wrote: > > > What is the bug fix here described in the cover letter? > > > > The cover letter mentioned 'last part' which I refer to as patches > > 14, > > 15 (though this is for UART), and 16. > > Hmm. > > So may I assume that patches [1-13/16] are for me and the rest is to > be applied > by the other respective maintainers? > > That should be easiest logistically IMHO. Have no objections. -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 16/16] i2c: designware: Convert to use unified device property API
On Mon, 2015-11-30 at 20:58 +0100, Wolfram Sang wrote: > On Mon, Nov 30, 2015 at 05:11:44PM +0200, Andy Shevchenko wrote: > > From: Mika Westerberg <mika.westerb...@linux.intel.com> > > > > With ACPI _DSD (introduced in ACPI v5.1) it is now possible to pass > > device > > configuration information from ACPI in addition to DT. In order to > > support > > this, convert the driver to use the unified device property > > accessors > > instead of DT specific. > > > > Change to ordering a bit so that we first try platform data and if > > that's > > not available look from device properties. ACPI *CNT methods are > > then used > > as last resort to override everything else. > > > > Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com> > > Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com> > > Acked-by: Jarkko Nikula <jarkko.nik...@linux.intel.com> > > What is the bug fix here described in the cover letter? The cover letter mentioned 'last part' which I refer to as patches 14, 15 (though this is for UART), and 16. -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 12/16] mfd: core: propagate device properties to sub devices drivers
In the similar way like we do for the platform data we propagate the device
properties. For example, in case of Intel LPSS drivers we may provide a
specific property to tell the actual device driver an additional information
such as platform name.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/mfd/mfd-core.c | 7 +++
include/linux/mfd/core.h | 5 +
2 files changed, 12 insertions(+)
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index 60b60dc..88bd1b1 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -192,6 +193,12 @@ static int mfd_add_device(struct device *parent, int id,
goto fail_alias;
}
+ if (cell->pset) {
+ ret = platform_device_add_properties(pdev, cell->pset);
+ if (ret)
+ goto fail_alias;
+ }
+
ret = mfd_platform_add_cell(pdev, cell, usage_count);
if (ret)
goto fail_alias;
diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
index 27dac3f..bc6f7e0 100644
--- a/include/linux/mfd/core.h
+++ b/include/linux/mfd/core.h
@@ -17,6 +17,7 @@
#include
struct irq_domain;
+struct property_set;
/* Matches ACPI PNP id, either _HID or _CID, or ACPI _ADR */
struct mfd_cell_acpi_match {
@@ -44,6 +45,10 @@ struct mfd_cell {
/* platform data passed to the sub devices drivers */
void*platform_data;
size_t pdata_size;
+
+ /* device properties passed to the sub devices drivers */
+ const struct property_set *pset;
+
/*
* Device Tree compatible string
* See: Documentation/devicetree/usage-model.txt Chapter 2.2 for details
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 10/16] driver core: platform: Add support for built-in device properties
From: Mika Westerberg <mika.westerb...@linux.intel.com>
Make it possible to pass built-in device properties to platform device
drivers. This is useful if the system does not have any firmware interface
like Device Tree or ACPI which provides these.
Properties associated with the platform device will be automatically
released when the corresponding device is removed.
Suggested-by: Arnd Bergmann <a...@arndb.de>
Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/base/platform.c | 25 +
include/linux/platform_device.h | 5 +
2 files changed, 30 insertions(+)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 1dd6d3b..d77ed0c 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include "base.h"
#include "power/power.h"
@@ -299,6 +300,22 @@ int platform_device_add_data(struct platform_device *pdev,
const void *data,
EXPORT_SYMBOL_GPL(platform_device_add_data);
/**
+ * platform_device_add_properties - add built-in properties to a platform
device
+ * @pdev: platform device to add properties to
+ * @pset: properties to add
+ *
+ * The function will take deep copy of the properties in @pset and attach
+ * the copy to the platform device. The memory associated with properties
+ * will be freed when the platform device is released.
+ */
+int platform_device_add_properties(struct platform_device *pdev,
+ const struct property_set *pset)
+{
+ return device_add_property_set(>dev, pset);
+}
+EXPORT_SYMBOL_GPL(platform_device_add_properties);
+
+/**
* platform_device_add - add a platform device to device hierarchy
* @pdev: platform device we're adding
*
@@ -409,6 +426,8 @@ void platform_device_del(struct platform_device *pdev)
if (r->parent)
release_resource(r);
}
+
+ device_remove_property_set(>dev);
}
}
EXPORT_SYMBOL_GPL(platform_device_del);
@@ -487,6 +506,12 @@ struct platform_device *platform_device_register_full(
if (ret)
goto err;
+ if (pdevinfo->pset) {
+ ret = platform_device_add_properties(pdev, pdevinfo->pset);
+ if (ret)
+ goto err;
+ }
+
ret = platform_device_add(pdev);
if (ret) {
err:
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index dc777be..dba40b1 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -18,6 +18,7 @@
#define PLATFORM_DEVID_AUTO(-2)
struct mfd_cell;
+struct property_set;
struct platform_device {
const char *name;
@@ -70,6 +71,8 @@ struct platform_device_info {
const void *data;
size_t size_data;
u64 dma_mask;
+
+ const struct property_set *pset;
};
extern struct platform_device *platform_device_register_full(
const struct platform_device_info *pdevinfo);
@@ -167,6 +170,8 @@ extern int platform_device_add_resources(struct
platform_device *pdev,
unsigned int num);
extern int platform_device_add_data(struct platform_device *pdev,
const void *data, size_t size);
+extern int platform_device_add_properties(struct platform_device *pdev,
+ const struct property_set *pset);
extern int platform_device_add(struct platform_device *pdev);
extern void platform_device_del(struct platform_device *pdev);
extern void platform_device_put(struct platform_device *pdev);
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/16] device property: refactor built-in properties support
Instead of using the type and nval fields we will use length (in bytes) of the
value. The sanity check is done in the accessors.
The built-in property accessors are split in the same way such as device tree.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/base/property.c | 150 ++-
include/linux/property.h | 8 +--
2 files changed, 113 insertions(+), 45 deletions(-)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index 2e01f3f..86834bd 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -63,45 +63,107 @@ static struct property_entry *pset_prop_get(struct
property_set *pset,
return NULL;
}
-static int pset_prop_read_array(struct property_set *pset, const char *name,
- enum dev_prop_type type, void *val, size_t nval)
+static void *pset_prop_find(struct property_set *pset, const char *propname,
+ size_t length)
{
struct property_entry *prop;
- unsigned int item_size;
+ void *pointer;
- prop = pset_prop_get(pset, name);
+ prop = pset_prop_get(pset, propname);
+ if (!prop)
+ return ERR_PTR(-EINVAL);
+ pointer = prop->value.raw_data;
+ if (!pointer)
+ return ERR_PTR(-ENODATA);
+ if (length > prop->length)
+ return ERR_PTR(-EOVERFLOW);
+ return pointer;
+}
+
+static int pset_prop_read_u8_array(struct property_set *pset,
+ const char *propname,
+ u8 *values, size_t nval)
+{
+ void *pointer;
+ size_t length = nval * sizeof(*values);
+
+ pointer = pset_prop_find(pset, propname, length);
+ if (IS_ERR(pointer))
+ return PTR_ERR(pointer);
+
+ memcpy(values, pointer, length);
+ return 0;
+}
+
+static int pset_prop_read_u16_array(struct property_set *pset,
+ const char *propname,
+ u16 *values, size_t nval)
+{
+ void *pointer;
+ size_t length = nval * sizeof(*values);
+
+ pointer = pset_prop_find(pset, propname, length);
+ if (IS_ERR(pointer))
+ return PTR_ERR(pointer);
+
+ memcpy(values, pointer, length);
+ return 0;
+}
+
+static int pset_prop_read_u32_array(struct property_set *pset,
+ const char *propname,
+ u32 *values, size_t nval)
+{
+ void *pointer;
+ size_t length = nval * sizeof(*values);
+
+ pointer = pset_prop_find(pset, propname, length);
+ if (IS_ERR(pointer))
+ return PTR_ERR(pointer);
+
+ memcpy(values, pointer, length);
+ return 0;
+}
+
+static int pset_prop_read_u64_array(struct property_set *pset,
+ const char *propname,
+ u64 *values, size_t nval)
+{
+ void *pointer;
+ size_t length = nval * sizeof(*values);
+
+ pointer = pset_prop_find(pset, propname, length);
+ if (IS_ERR(pointer))
+ return PTR_ERR(pointer);
+
+ memcpy(values, pointer, length);
+ return 0;
+}
+
+static int pset_prop_count_elems_of_size(struct property_set *pset,
+const char *propname, size_t length)
+{
+ struct property_entry *prop;
+
+ prop = pset_prop_get(pset, propname);
if (!prop)
- return -ENODATA;
-
- if (prop->type != type)
- return -EPROTO;
-
- if (!val)
- return prop->nval;
-
- if (prop->nval < nval)
- return -EOVERFLOW;
-
- switch (type) {
- case DEV_PROP_U8:
- item_size = sizeof(u8);
- break;
- case DEV_PROP_U16:
- item_size = sizeof(u16);
- break;
- case DEV_PROP_U32:
- item_size = sizeof(u32);
- break;
- case DEV_PROP_U64:
- item_size = sizeof(u64);
- break;
- case DEV_PROP_STRING:
- item_size = sizeof(const char *);
- break;
- default:
return -EINVAL;
- }
- memcpy(val, prop->value.raw_data, nval * item_size);
+
+ return prop->length / length;
+}
+
+static int pset_prop_read_string_array(struct property_set *pset,
+ const char *propname,
+ const char **strings, size_t nval)
+{
+ void *pointer;
+ size_t length = nval * sizeof(*strings);
+
+ pointer = pset_prop_find(pset, propname, length);
+ if (IS_ERR(pointer))
+ return PTR_ERR(pointer);
+
+ memcpy(strings, pointer, length);
return 0;
}
@@ -314,6 +376,10 @@ EXPORT_SYMBOL_GPL(device_property_match_string);
(val)
[PATCH v2 00/16] intel-lpss: support non-ACPI platforms
This series includes few logical sets that bring a support of non-ACPI platforms for Intel Skylake. First part is a refactoring of built-in device properties support: - keep single value inside the structure - provide helper macros to define built-in properties - fall back to secondary fwnode if primary has no asked property Second is a propagating built-in device properties in platform core. Third one is modifications to MFD code and intel-lpss.c driver in particular to define and pass built-in properties to the individual drivers. And last part is a fix for I2C bug found on Lenovo Yoga hardware and a first converted user. Built-in device properties is an alternative to platform data. It provides a unified API that drivers can use to cover all cases at once: DT, ACPI, and built-in properties. With this series applied a platform data can be considered obsolete. Moreover, built-in device properties allow to adjust the existing configuration, for example, in cases when ACPI values are wrong on some platforms. The series has been tested on available hardware and doesn't break current behaviour. But we ask people who have the affected hardware to apply the series on your side and check with Lenovo hardware. Changelog v2: - fix isuues found by kbuild bot (kbuild) - append a patch to propagate device properties in polatform code (Arnd) - update few existing and add couple of new patches due to above - check with kmemleak Andy Shevchenko (9): device property: always check for fwnode type device property: rename helper functions device property: refactor built-in properties support device property: keep single value inplace device property: improve readability of macros device property: return -EINVAL when property isn't found in ACPI device property: Fallback to secondary fwnode if primary misses the property mfd: core: propagate device properties to sub devices drivers mfd: intel-lpss: Pass HSUART configuration via properties Heikki Krogerus (1): device property: helper macros for property entry creation Mika Westerberg (6): device property: Take a copy of the property set driver core: platform: Add support for built-in device properties driver core: Do not overwrite secondary fwnode with NULL if it is set mfd: intel-lpss: Add support for passing device properties mfd: intel-lpss: Pass SDA hold time to I2C host controller driver i2c: designware: Convert to use unified device property API drivers/acpi/property.c | 10 +- drivers/base/core.c | 5 +- drivers/base/platform.c | 25 ++ drivers/base/property.c | 491 ++-- drivers/i2c/busses/i2c-designware-platdrv.c | 50 ++- drivers/mfd/intel-lpss-acpi.c | 19 +- drivers/mfd/intel-lpss-pci.c| 44 ++- drivers/mfd/intel-lpss.c| 16 +- drivers/mfd/intel-lpss.h| 2 + drivers/mfd/mfd-core.c | 7 + include/linux/mfd/core.h| 5 + include/linux/platform_device.h | 5 + include/linux/property.h| 99 +- 13 files changed, 621 insertions(+), 157 deletions(-) -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 04/16] device property: keep single value inplace
We may save a lot of lines of code and space by keeping single values inside
the struct property_entry. Refactor the implementation to do so.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/base/property.c | 33 ++---
include/linux/property.h | 31 +++
2 files changed, 53 insertions(+), 11 deletions(-)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index 86834bd..ad3cb09 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -72,7 +72,10 @@ static void *pset_prop_find(struct property_set *pset, const
char *propname,
prop = pset_prop_get(pset, propname);
if (!prop)
return ERR_PTR(-EINVAL);
- pointer = prop->value.raw_data;
+ if (prop->is_array)
+ pointer = prop->pointer.raw_data;
+ else
+ pointer = >value.raw_data;
if (!pointer)
return ERR_PTR(-ENODATA);
if (length > prop->length)
@@ -167,6 +170,31 @@ static int pset_prop_read_string_array(struct property_set
*pset,
return 0;
}
+static int pset_prop_read_string(struct property_set *pset,
+const char *propname, const char **strings)
+{
+ struct property_entry *prop;
+ const char **pointer;
+
+ prop = pset_prop_get(pset, propname);
+ if (!prop)
+ return -EINVAL;
+ if (!prop->is_string)
+ return -EILSEQ;
+ if (prop->is_array) {
+ pointer = prop->pointer.str;
+ if (!pointer)
+ return -ENODATA;
+ } else {
+ pointer = >value.str;
+ if (*pointer && strnlen(*pointer, prop->length) >= prop->length)
+ return -EILSEQ;
+ }
+
+ *strings = *pointer;
+ return 0;
+}
+
static inline struct fwnode_handle *dev_fwnode(struct device *dev)
{
return IS_ENABLED(CONFIG_OF) && dev->of_node ?
@@ -566,8 +594,7 @@ int fwnode_property_read_string(struct fwnode_handle
*fwnode,
return acpi_node_prop_read(fwnode, propname, DEV_PROP_STRING,
val, 1);
else if (is_pset_node(fwnode))
- return pset_prop_read_string_array(to_pset_node(fwnode),
- propname, val, 1);
+ return pset_prop_read_string(to_pset_node(fwnode), propname,
val);
return -ENXIO;
}
EXPORT_SYMBOL_GPL(fwnode_property_read_string);
diff --git a/include/linux/property.h b/include/linux/property.h
index c29460a..69a8a08 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -145,19 +145,34 @@ static inline int fwnode_property_read_u64(struct
fwnode_handle *fwnode,
* struct property_entry - "Built-in" device property representation.
* @name: Name of the property.
* @length: Length of data making up the value.
- * @value: Value of the property (an array of items of the given type).
+ * @is_array: True when the property is an array.
+ * @is_string: True when property is a string.
+ * @pointer: Pointer to the property (an array of items of the given type).
+ * @value: Value of the property (when it is a single item of the given type).
*/
struct property_entry {
const char *name;
size_t length;
+ bool is_array;
+ bool is_string;
union {
- void *raw_data;
- u8 *u8_data;
- u16 *u16_data;
- u32 *u32_data;
- u64 *u64_data;
- const char **str;
- } value;
+ union {
+ void *raw_data;
+ u8 *u8_data;
+ u16 *u16_data;
+ u32 *u32_data;
+ u64 *u64_data;
+ const char **str;
+ } pointer;
+ union {
+ unsigned long long raw_data;
+ u8 u8_data;
+ u16 u16_data;
+ u32 u32_data;
+ u64 u64_data;
+ const char *str;
+ } value;
+ };
};
/**
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 06/16] device property: improve readability of macros
There is no functional change.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/base/property.c | 28 ++--
include/linux/property.h | 4 ++--
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index ad3cb09..a3538cb 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -400,29 +400,29 @@ int device_property_match_string(struct device *dev,
const char *propname,
}
EXPORT_SYMBOL_GPL(device_property_match_string);
-#define OF_DEV_PROP_READ_ARRAY(node, propname, type, val, nval) \
- (val) ? of_property_read_##type##_array((node), (propname), (val),
(nval)) \
+#define OF_DEV_PROP_READ_ARRAY(node, propname, type, val, nval)
\
+ (val) ? of_property_read_##type##_array((node), (propname), (val),
(nval)) \
: of_property_count_elems_of_size((node), (propname),
sizeof(type))
#define PSET_PROP_READ_ARRAY(node, propname, type, val, nval)
\
(val) ? pset_prop_read_##type##_array((node), (propname), (val),
(nval))\
: pset_prop_count_elems_of_size((node), (propname), sizeof(type))
-#define FWNODE_PROP_READ_ARRAY(_fwnode_, _propname_, _type_, _proptype_,
_val_, _nval_) \
-({ \
- int _ret_; \
- if (is_of_node(_fwnode_)) \
- _ret_ = OF_DEV_PROP_READ_ARRAY(to_of_node(_fwnode_),
_propname_, \
- _type_, _val_, _nval_); \
- else if (is_acpi_node(_fwnode_)) \
- _ret_ = acpi_node_prop_read(_fwnode_, _propname_, _proptype_, \
- _val_, _nval_); \
+#define FWNODE_PROP_READ_ARRAY(_fwnode_, _propname_, _type_, _proptype_,
_val_, _nval_)\
+({
\
+ int _ret_;
\
+ if (is_of_node(_fwnode_))
\
+ _ret_ = OF_DEV_PROP_READ_ARRAY(to_of_node(_fwnode_),
_propname_,\
+ _type_, _val_, _nval_);
\
+ else if (is_acpi_node(_fwnode_))
\
+ _ret_ = acpi_node_prop_read(_fwnode_, _propname_, _proptype_,
\
+ _val_, _nval_);
\
else if (is_pset_node(_fwnode_))
\
_ret_ = PSET_PROP_READ_ARRAY(to_pset_node(_fwnode_),
_propname_,\
_type_, _val_, _nval_);
\
- else \
- _ret_ = -ENXIO; \
- _ret_; \
+ else
\
+ _ret_ = -ENXIO;
\
+ _ret_;
\
})
/**
diff --git a/include/linux/property.h b/include/linux/property.h
index e4f29d8..d1cf208 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -73,8 +73,8 @@ int fwnode_property_match_string(struct fwnode_handle *fwnode,
struct fwnode_handle *device_get_next_child_node(struct device *dev,
struct fwnode_handle *child);
-#define device_for_each_child_node(dev, child) \
- for (child = device_get_next_child_node(dev, NULL); child; \
+#define device_for_each_child_node(dev, child) \
+ for (child = device_get_next_child_node(dev, NULL); child; \
child = device_get_next_child_node(dev, child))
void fwnode_handle_put(struct fwnode_handle *fwnode);
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 05/16] device property: helper macros for property entry creation
From: Heikki Krogerus <heikki.kroge...@linux.intel.com>
Marcos for easier creation of build-in property entries.
Signed-off-by: Heikki Krogerus <heikki.kroge...@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
include/linux/property.h | 55
1 file changed, 55 insertions(+)
diff --git a/include/linux/property.h b/include/linux/property.h
index 69a8a08..e4f29d8 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -175,6 +175,61 @@ struct property_entry {
};
};
+#define PROPERTY_ENTRY_INTEGER_ARRAY(_name_, _type_, _val_)\
+{ \
+ .name = _name_, \
+ .length = ARRAY_SIZE(_val_) * sizeof(_type_), \
+ .is_array = true, \
+ .pointer._type_##_data = _val_, \
+}
+
+#define PROPERTY_ENTRY_U8_ARRAY(_name_, _val_) \
+ PROPERTY_ENTRY_INTEGER_ARRAY(_name_, u8, _val_)
+#define PROPERTY_ENTRY_U16_ARRAY(_name_, _val_)\
+ PROPERTY_ENTRY_INTEGER_ARRAY(_name_, u16, _val_)
+#define PROPERTY_ENTRY_U32_ARRAY(_name_, _val_)\
+ PROPERTY_ENTRY_INTEGER_ARRAY(_name_, u32, _val_)
+#define PROPERTY_ENTRY_U64_ARRAY(_name_, _val_)\
+ PROPERTY_ENTRY_INTEGER_ARRAY(_name_, u64, _val_)
+
+#define PROPERTY_ENTRY_STRING_ARRAY(_name_, _val_) \
+{ \
+ .name = _name_, \
+ .length = ARRAY_SIZE(_val_) * sizeof(const char *), \
+ .is_array = true, \
+ .is_string = true, \
+ .pointer.str = _val_, \
+}
+
+#define PROPERTY_ENTRY_INTEGER(_name_, _type_, _val_) \
+{ \
+ .name = _name_, \
+ .length = sizeof(_type_), \
+ .value._type_##_data = _val_, \
+}
+
+#define PROPERTY_ENTRY_U8(_name_, _val_) \
+ PROPERTY_ENTRY_INTEGER(_name_, u8, _val_)
+#define PROPERTY_ENTRY_U16(_name_, _val_) \
+ PROPERTY_ENTRY_INTEGER(_name_, u16, _val_)
+#define PROPERTY_ENTRY_U32(_name_, _val_) \
+ PROPERTY_ENTRY_INTEGER(_name_, u32, _val_)
+#define PROPERTY_ENTRY_U64(_name_, _val_) \
+ PROPERTY_ENTRY_INTEGER(_name_, u64, _val_)
+
+#define PROPERTY_ENTRY_STRING(_name_, _val_) \
+{ \
+ .name = _name_, \
+ .length = sizeof(_val_),\
+ .is_string = true, \
+ .value.str = _val_, \
+}
+
+#define PROPERTY_ENTRY_BOOL(_name_)\
+{ \
+ .name = _name_, \
+}
+
/**
* struct property_set - Collection of "built-in" device properties.
* @fwnode: Handle to be pointed to by the fwnode field of struct device.
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 15/16] mfd: intel-lpss: Pass HSUART configuration via properties
The HS-UART host controller driver needs to know certain properties like
width of the register set if it cannot get that information from ACPI or
DT. In order to support non-ACPI systems we pass this information to the
driver via device properties.
Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/mfd/intel-lpss-pci.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/mfd/intel-lpss-pci.c b/drivers/mfd/intel-lpss-pci.c
index a677480..a7136c7 100644
--- a/drivers/mfd/intel-lpss-pci.c
+++ b/drivers/mfd/intel-lpss-pci.c
@@ -80,9 +80,21 @@ static const struct intel_lpss_platform_info spt_i2c_info = {
.pset = _i2c_pset,
};
+static struct property_entry uart_properties[] = {
+ PROPERTY_ENTRY_U32("reg-io-width", 4),
+ PROPERTY_ENTRY_U32("reg-shift", 2),
+ PROPERTY_ENTRY_BOOL("snps,uart-16550-compatible"),
+ { },
+};
+
+static struct property_set uart_pset = {
+ .properties = uart_properties,
+};
+
static const struct intel_lpss_platform_info spt_uart_info = {
.clk_rate = 12000,
.clk_con_id = "baudclk",
+ .pset = _pset,
};
static const struct intel_lpss_platform_info bxt_info = {
@@ -92,6 +104,7 @@ static const struct intel_lpss_platform_info bxt_info = {
static const struct intel_lpss_platform_info bxt_uart_info = {
.clk_rate = 1,
.clk_con_id = "baudclk",
+ .pset = _pset,
};
static const struct intel_lpss_platform_info bxt_i2c_info = {
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 01/16] device property: always check for fwnode type
Currently the property accessors unconditionally fall back to built-in property set as a last resort. Make this strict and return an error in case the type of fwnode is unknown. This is actually a follow up to the commit 4fa7508e9f1c (device property: Return -ENXIO if there is no suitable FW interface). Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com> --- drivers/base/property.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/base/property.c b/drivers/base/property.c index 1325ff2..09e488d 100644 --- a/drivers/base/property.c +++ b/drivers/base/property.c @@ -135,8 +135,9 @@ bool fwnode_property_present(struct fwnode_handle *fwnode, const char *propname) return of_property_read_bool(to_of_node(fwnode), propname); else if (is_acpi_node(fwnode)) return !acpi_node_prop_get(fwnode, propname, NULL); - - return !!pset_prop_get(to_pset(fwnode), propname); + else if (is_pset(fwnode)) + return !!pset_prop_get(to_pset(fwnode), propname); + return false; } EXPORT_SYMBOL_GPL(fwnode_property_present); @@ -494,9 +495,10 @@ int fwnode_property_read_string(struct fwnode_handle *fwnode, else if (is_acpi_node(fwnode)) return acpi_node_prop_read(fwnode, propname, DEV_PROP_STRING, val, 1); - - return pset_prop_read_array(to_pset(fwnode), propname, - DEV_PROP_STRING, val, 1); + else if (is_pset(fwnode)) + return pset_prop_read_array(to_pset(fwnode), propname, + DEV_PROP_STRING, val, 1); + return -ENXIO; } EXPORT_SYMBOL_GPL(fwnode_property_read_string); -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 14/16] mfd: intel-lpss: Pass SDA hold time to I2C host controller driver
From: Mika Westerberg <mika.westerb...@linux.intel.com>
Intel Skylake the LPSS I2C pad circuit has internal delays that require
programming non-zero SDA hold time for the I2C host controller. If this is
not done communication to slave devices may fail with arbitration lost
errors like the one seen below taken from Lenovo Yoga 900:
i2c_hid i2c-SYNA2B29:00: Fetching the HID descriptor
i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: cmd=20 00
i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration
To fix this we follow what the Windows driver is doing and pass the default
SDA hold time of 230 ns to all Intel Skylake host controllers. This still
allows the platform to override these values by passing special ACPI
methods SSCN and FMCN.
Reported-by: Kevin Fenzi <ke...@scrye.com>
Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/mfd/intel-lpss-acpi.c | 19 +--
drivers/mfd/intel-lpss-pci.c | 31 +++
2 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/intel-lpss-acpi.c b/drivers/mfd/intel-lpss-acpi.c
index b6fd904..06f00d6 100644
--- a/drivers/mfd/intel-lpss-acpi.c
+++ b/drivers/mfd/intel-lpss-acpi.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "intel-lpss.h"
@@ -25,6 +26,20 @@ static const struct intel_lpss_platform_info spt_info = {
.clk_rate = 12000,
};
+static struct property_entry spt_i2c_properties[] = {
+ PROPERTY_ENTRY_U32("i2c-sda-hold-time-ns", 230),
+ { },
+};
+
+static struct property_set spt_i2c_pset = {
+ .properties = spt_i2c_properties,
+};
+
+static const struct intel_lpss_platform_info spt_i2c_info = {
+ .clk_rate = 12000,
+ .pset = _i2c_pset,
+};
+
static const struct intel_lpss_platform_info bxt_info = {
.clk_rate = 1,
};
@@ -35,8 +50,8 @@ static const struct intel_lpss_platform_info bxt_i2c_info = {
static const struct acpi_device_id intel_lpss_acpi_ids[] = {
/* SPT */
- { "INT3446", (kernel_ulong_t)_info },
- { "INT3447", (kernel_ulong_t)_info },
+ { "INT3446", (kernel_ulong_t)_i2c_info },
+ { "INT3447", (kernel_ulong_t)_i2c_info },
/* BXT */
{ "80860AAC", (kernel_ulong_t)_i2c_info },
{ "80860ABC", (kernel_ulong_t)_info },
diff --git a/drivers/mfd/intel-lpss-pci.c b/drivers/mfd/intel-lpss-pci.c
index 5bfdfcc..a677480 100644
--- a/drivers/mfd/intel-lpss-pci.c
+++ b/drivers/mfd/intel-lpss-pci.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include "intel-lpss.h"
@@ -65,6 +66,20 @@ static const struct intel_lpss_platform_info spt_info = {
.clk_rate = 12000,
};
+static struct property_entry spt_i2c_properties[] = {
+ PROPERTY_ENTRY_U32("i2c-sda-hold-time-ns", 230),
+ { },
+};
+
+static struct property_set spt_i2c_pset = {
+ .properties = spt_i2c_properties,
+};
+
+static const struct intel_lpss_platform_info spt_i2c_info = {
+ .clk_rate = 12000,
+ .pset = _i2c_pset,
+};
+
static const struct intel_lpss_platform_info spt_uart_info = {
.clk_rate = 12000,
.clk_con_id = "baudclk",
@@ -121,20 +136,20 @@ static const struct pci_device_id intel_lpss_pci_ids[] = {
{ PCI_VDEVICE(INTEL, 0x9d28), (kernel_ulong_t)_uart_info },
{ PCI_VDEVICE(INTEL, 0x9d29), (kernel_ulong_t)_info },
{ PCI_VDEVICE(INTEL, 0x9d2a), (kernel_ulong_t)_info },
- { PCI_VDEVICE(INTEL, 0x9d60), (kernel_ulong_t)_info },
- { PCI_VDEVICE(INTEL, 0x9d61), (kernel_ulong_t)_info },
- { PCI_VDEVICE(INTEL, 0x9d62), (kernel_ulong_t)_info },
- { PCI_VDEVICE(INTEL, 0x9d63), (kernel_ulong_t)_info },
- { PCI_VDEVICE(INTEL, 0x9d64), (kernel_ulong_t)_info },
- { PCI_VDEVICE(INTEL, 0x9d65), (kernel_ulong_t)_info },
+ { PCI_VDEVICE(INTEL, 0x9d60), (kernel_ulong_t)_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x9d61), (kernel_ulong_t)_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x9d62), (kernel_ulong_t)_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x9d63), (kernel_ulong_t)_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x9d64), (kernel_ulong_t)_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x9d65), (kernel_ulong_t)_i2c_info },
{ PCI_VDEVICE(INTEL, 0x9d66), (kernel_ulong_t)_uart_info },
/* SPT-H */
{ PCI_VDEVICE(INTEL, 0xa127), (kernel_ulong_t)_uart_info },
{ PCI_VDEVICE(INTEL, 0xa128), (kernel_ulong_t)_uart_info },
{ PCI_VDEVICE(INTEL, 0xa129), (kernel_ulong_t)_info },
{ PCI_VDEVICE(INTEL, 0xa12a), (kernel_ulong_t)_info },
- { PCI_VDEVICE(INTEL, 0xa160), (kernel_ulong_t)_info },
- { PCI_VDEVICE(INTEL, 0xa161), (kernel_ulong_t)_info },
+ { PCI_VDEVICE(INTEL, 0xa160), (kernel_ulong_t
[PATCH v2 09/16] device property: Take a copy of the property set
From: Mika Westerberg <mika.westerb...@linux.intel.com>
It is convenient if the property set associated with the device secondary
firmware node is a copy of the original. This allows passing property set
from a stack for example for devices created dynamically. This also ties
the property set lifetime to the associated device.
Because of that we provide new function device_remove_property_set() that
is used to disassociate and release memory allocated for the property set.
Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/base/property.c | 191 ++-
include/linux/property.h | 3 +-
2 files changed, 175 insertions(+), 19 deletions(-)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index ebcbe34..0b22c8a 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -19,24 +19,6 @@
#include
#include
-/**
- * device_add_property_set - Add a collection of properties to a device object.
- * @dev: Device to add properties to.
- * @pset: Collection of properties to add.
- *
- * Associate a collection of device properties represented by @pset with @dev
- * as its secondary firmware node.
- */
-void device_add_property_set(struct device *dev, struct property_set *pset)
-{
- if (!pset)
- return;
-
- pset->fwnode.type = FWNODE_PDATA;
- set_secondary_fwnode(dev, >fwnode);
-}
-EXPORT_SYMBOL_GPL(device_add_property_set);
-
static inline bool is_pset_node(struct fwnode_handle *fwnode)
{
return fwnode && fwnode->type == FWNODE_PDATA;
@@ -693,6 +675,179 @@ out:
EXPORT_SYMBOL_GPL(fwnode_property_match_string);
/**
+ * pset_free_set - releases memory allocated for copied property set
+ * @pset: Property set to release
+ *
+ * Function takes previously copied property set and releases all the
+ * memory allocated to it.
+ */
+static void pset_free_set(struct property_set *pset)
+{
+ const struct property_entry *prop;
+ size_t i, nval;
+
+ if (!pset)
+ return;
+
+ for (prop = pset->properties; prop->name; prop++) {
+ if (prop->is_array) {
+ if (prop->is_string && prop->pointer.str) {
+ nval = prop->length / sizeof(const char *);
+ for (i = 0; i < nval; i++)
+ kfree(prop->pointer.str[i]);
+ }
+ kfree(prop->pointer.raw_data);
+ } else if (prop->is_string) {
+ kfree(prop->value.str);
+ }
+ kfree(prop->name);
+ }
+
+ kfree(pset->properties);
+ kfree(pset);
+}
+
+static int pset_copy_entry(struct property_entry *dst,
+ const struct property_entry *src)
+{
+ const char **d, **s;
+ size_t i, nval;
+
+ dst->name = kstrdup(src->name, GFP_KERNEL);
+ if (!dst->name)
+ return -ENOMEM;
+
+ if (src->is_array) {
+ if (src->is_string) {
+ nval = src->length / sizeof(const char *);
+ dst->pointer.str = kcalloc(nval, sizeof(const char *),
+ GFP_KERNEL);
+ if (!dst->pointer.str)
+ return -ENOMEM;
+
+ d = dst->pointer.str;
+ s = src->pointer.str;
+ for (i = 0; i < nval; i++) {
+ d[i] = kstrdup(s[i], GFP_KERNEL);
+ if (!d[i] && s[i])
+ return -ENOMEM;
+ }
+ } else {
+ dst->pointer.raw_data = kmemdup(src->pointer.raw_data,
+ src->length,
GFP_KERNEL);
+ if (!dst->pointer.raw_data)
+ return -ENOMEM;
+ }
+ } else if (src->is_string) {
+ dst->value.str = kstrdup(src->value.str, GFP_KERNEL);
+ if (!dst->value.str && src->value.str)
+ return -ENOMEM;
+ } else {
+ dst->value.raw_data = src->value.raw_data;
+ }
+
+ dst->length = src->length;
+ dst->is_array = src->is_array;
+ dst->is_string = src->is_string;
+
+ return 0;
+}
+
+/**
+ * pset_copy_set - copies property set
+ * @pset: Property set to copy
+ *
+ * This function takes a deep copy of the given property set and returns
+ * pointer to the copy. Call device_free_property_set() to free resources
+ * allocated in this function.
+ *
+ * Re
[PATCH v2 13/16] mfd: intel-lpss: Add support for passing device properties
From: Mika Westerberg <mika.westerb...@linux.intel.com>
If the boot firmware does not support ACPI we need a way to pass device
configuration information to the drivers. The unified device properties API
already supports passing platform data via properties so let's take
advantage of that and allow probe drivers to pass set of properties to the
host controller driver.
In order to do that we need to be able to modify the MFD cell corresponding
the host controller, so make the core driver to take copy of the cell
instead of using it directly. Then we can assign info->pset to the
resulting copy of a cell and let the MFD core to assign that to the
resulting device.
Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/mfd/intel-lpss.c | 16
drivers/mfd/intel-lpss.h | 2 ++
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c
index 6255513..1743788 100644
--- a/drivers/mfd/intel-lpss.c
+++ b/drivers/mfd/intel-lpss.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -72,7 +73,7 @@ struct intel_lpss {
enum intel_lpss_dev_type type;
struct clk *clk;
struct clk_lookup *clock;
- const struct mfd_cell *cell;
+ struct mfd_cell *cell;
struct device *dev;
void __iomem *priv;
int devid;
@@ -217,6 +218,7 @@ static void intel_lpss_ltr_hide(struct intel_lpss *lpss)
static int intel_lpss_assign_devs(struct intel_lpss *lpss)
{
+ const struct mfd_cell *cell;
unsigned int type;
type = lpss->caps & LPSS_PRIV_CAPS_TYPE_MASK;
@@ -224,18 +226,22 @@ static int intel_lpss_assign_devs(struct intel_lpss *lpss)
switch (type) {
case LPSS_DEV_I2C:
- lpss->cell = _lpss_i2c_cell;
+ cell = _lpss_i2c_cell;
break;
case LPSS_DEV_UART:
- lpss->cell = _lpss_uart_cell;
+ cell = _lpss_uart_cell;
break;
case LPSS_DEV_SPI:
- lpss->cell = _lpss_spi_cell;
+ cell = _lpss_spi_cell;
break;
default:
return -ENODEV;
}
+ lpss->cell = devm_kmemdup(lpss->dev, cell, sizeof(*cell), GFP_KERNEL);
+ if (!lpss->cell)
+ return -ENOMEM;
+
lpss->type = type;
return 0;
@@ -401,6 +407,8 @@ int intel_lpss_probe(struct device *dev,
if (ret)
return ret;
+ lpss->cell->pset = info->pset;
+
intel_lpss_init_dev(lpss);
lpss->devid = ida_simple_get(_lpss_devid_ida, 0, 0, GFP_KERNEL);
diff --git a/drivers/mfd/intel-lpss.h b/drivers/mfd/intel-lpss.h
index 2c7f8d7..0dcea9e 100644
--- a/drivers/mfd/intel-lpss.h
+++ b/drivers/mfd/intel-lpss.h
@@ -16,12 +16,14 @@
struct device;
struct resource;
+struct property_set;
struct intel_lpss_platform_info {
struct resource *mem;
int irq;
unsigned long clk_rate;
const char *clk_con_id;
+ struct property_set *pset;
};
int intel_lpss_probe(struct device *dev,
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] x86/platform/iosf_mbi: Remove duplicate definitions
On Wed, 2015-11-25 at 15:20 +0100, Thomas Gleixner wrote: > On Wed, 11 Nov 2015, Andy Shevchenko wrote: > > > The read and write opcodes are global for all units on SoC and even > across > > Intel SoCs. Remove duplication of corresponding constants. At the > same time > > convert all current users. > > > > No functional change. > > > > Cc: Thomas Gleixner <t...@linutronix.de> > > Cc: Ingo Molnar <mi...@redhat.com> > > Cc: Peter Anvin <h...@zytor.com> > > Cc: Wolfram Sang <w...@the-dreams.de> > > Cc: Zhang Rui <rui.zh...@intel.com> > > Cc: Eduardo Valentin <edubez...@gmail.com> > > Cc: Hock Leong Kweh <hock.leong.k...@intel.com> Eduardo, Rui, can you provide your ACKs or comments about the patch? > > > > Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com> > > --- > > Since v1: > > - satisfy kbuild robot > > > > arch/x86/include/asm/iosf_mbi.h | 49 +--- > -- > > arch/x86/platform/atom/punit_atom_debug.c | 7 +--- > > arch/x86/platform/intel-quark/imr.c | 28 + > > drivers/i2c/busses/i2c-designware-baytrail.c | 17 +++- > > drivers/powercap/intel_rapl.c | 10 ++--- > > drivers/thermal/intel_quark_dts_thermal.c | 61 ++ > -- > > drivers/thermal/intel_soc_dts_iosf.c | 43 ++ > -- > > Hmm. Either we get acks of all maintainers and merge it through > tip/x86/... I prefer this way because… > or we do the following: > > Add the new constants w/o using them in a seperate patch and ship > that > linuswards now. Then the subsystem maintainers can pick the > individual > patches up and after the merge window closes we remove the old > constants in one go. > > Either way works for me. …we are working on another fix which is based also on this patch. Can you provide your ACK if you are okay with the changes to arch/x86 ? > > Thanks, > > tglx > > -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 05/13] device property: helper macros for property entry creation
From: Heikki Krogerus <heikki.kroge...@linux.intel.com>
Marcos for easier creation of build-in property entries.
Signed-off-by: Heikki Krogerus <heikki.kroge...@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
include/linux/property.h | 48
1 file changed, 48 insertions(+)
diff --git a/include/linux/property.h b/include/linux/property.h
index 5d0b9b6..2528a000 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -173,6 +173,54 @@ struct property_entry {
};
};
+#define PROPERTY_ENTRY_INTEGER_ARRAY(_name_, _type_, _val_)\
+{ \
+ .name = _name_, \
+ .length = ARRAY_SIZE(_val_) * sizeof(_type_), \
+ .is_array = true, \
+ .pointer._type_##_data = _val_, \
+}
+
+#define PROPERTY_ENTRY_U8_ARRAY(_name_, _val_) \
+ PROPERTY_ENTRY_INTEGER_ARRAY(_name_, u8, _val_)
+#define PROPERTY_ENTRY_U16_ARRAY(_name_, _val_)\
+ PROPERTY_ENTRY_INTEGER_ARRAY(_name_, u16, _val_)
+#define PROPERTY_ENTRY_U32_ARRAY(_name_, _val_)\
+ PROPERTY_ENTRY_INTEGER_ARRAY(_name_, u32, _val_)
+#define PROPERTY_ENTRY_U64_ARRAY(_name_, _val_)\
+ PROPERTY_ENTRY_INTEGER_ARRAY(_name_, u64, _val_)
+
+#define PROPERTY_ENTRY_STRING_ARRAY(_name_, _val_) \
+{ \
+ .name = _name_, \
+ .length = ARRAY_SIZE(_val_) * sizeof(const char *), \
+ .is_array = true, \
+ .pointer.str = _val_, \
+}
+
+#define PROPERTY_ENTRY_INTEGER(_name_, _type_, _val_) \
+{ \
+ .name = _name_, \
+ .length = sizeof(_type_), \
+ .value._type_##_data = _val_, \
+}
+
+#define PROPERTY_ENTRY_U8(_name_, _val_) \
+ PROPERTY_ENTRY_INTEGER(_name_, u8, _val_)
+#define PROPERTY_ENTRY_U16(_name_, _val_) \
+ PROPERTY_ENTRY_INTEGER(_name_, u16, _val_)
+#define PROPERTY_ENTRY_U32(_name_, _val_) \
+ PROPERTY_ENTRY_INTEGER(_name_, u32, _val_)
+#define PROPERTY_ENTRY_U64(_name_, _val_) \
+ PROPERTY_ENTRY_INTEGER(_name_, u64, _val_)
+
+#define PROPERTY_ENTRY_STRING(_name_, _val_) \
+{ \
+ .name = _name_, \
+ .length = sizeof(_val_),\
+ .value.str = _val_, \
+}
+
/**
* struct property_set - Collection of "built-in" device properties.
* @fwnode: Handle to be pointed to by the fwnode field of struct device.
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 11/13] mfd: intel-lpss: Pass HSUART configuration via properties
From: Mika Westerberg <mika.westerb...@linux.intel.com>
The HS-UART host controller driver needs to know certain properties like
width of the register set if it cannot get that information from ACPI or
DT. In order to support non-ACPI systems we pass this information to the
driver via device properties.
Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/mfd/intel-lpss-pci.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/mfd/intel-lpss-pci.c b/drivers/mfd/intel-lpss-pci.c
index 5bfdfcc..74f0d6d 100644
--- a/drivers/mfd/intel-lpss-pci.c
+++ b/drivers/mfd/intel-lpss-pci.c
@@ -65,9 +65,21 @@ static const struct intel_lpss_platform_info spt_info = {
.clk_rate = 12000,
};
+static struct property_entry uart_properties[] = {
+ PROPERTY_ENTRY_U32("reg-io-width", 4),
+ PROPERTY_ENTRY_U32("reg-shift", 2),
+ PROPERTY_ENTRY_U8("snps,uart-16550-compatible", 1),
+ { },
+};
+
+static struct property_set uart_pset = {
+ .properties = uart_properties,
+};
+
static const struct intel_lpss_platform_info spt_uart_info = {
.clk_rate = 12000,
.clk_con_id = "baudclk",
+ .pset = _pset,
};
static const struct intel_lpss_platform_info bxt_info = {
@@ -77,6 +89,7 @@ static const struct intel_lpss_platform_info bxt_info = {
static const struct intel_lpss_platform_info bxt_uart_info = {
.clk_rate = 1,
.clk_con_id = "baudclk",
+ .pset = _pset,
};
static const struct intel_lpss_platform_info bxt_i2c_info = {
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 12/13] mfd: intel-lpss: Pass SDA hold time to I2C host controller driver
From: Mika Westerberg <mika.westerb...@linux.intel.com>
Intel Skylake the LPSS I2C pad circuit has internal delays that require
programming non-zero SDA hold time for the I2C host controller. If this is
not done communication to slave devices may fail with arbitration lost
errors like the one seen below taken from Lenovo Yoga 900:
i2c_hid i2c-SYNA2B29:00: Fetching the HID descriptor
i2c_hid i2c-SYNA2B29:00: __i2c_hid_command: cmd=20 00
i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration
To fix this we follow what the Windows driver is doing and pass the default
SDA hold time of 230 ns to all Intel Skylake host controllers. This still
allows the platform to override these values by passing special ACPI
methods SSCN and FMCN.
Reported-by: Kevin Fenzi <ke...@scrye.com>
Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/mfd/intel-lpss-acpi.c | 18 --
drivers/mfd/intel-lpss-pci.c | 30 ++
2 files changed, 38 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/intel-lpss-acpi.c b/drivers/mfd/intel-lpss-acpi.c
index b6fd904..6c5bbda 100644
--- a/drivers/mfd/intel-lpss-acpi.c
+++ b/drivers/mfd/intel-lpss-acpi.c
@@ -25,6 +25,20 @@ static const struct intel_lpss_platform_info spt_info = {
.clk_rate = 12000,
};
+static struct property_entry spt_i2c_properties[] = {
+ PROPERTY_ENTRY_U32("i2c-sda-hold-time-ns", 230),
+ { },
+};
+
+static struct property_set spt_i2c_pset = {
+ .properties = spt_i2c_properties,
+};
+
+static const struct intel_lpss_platform_info spt_i2c_info = {
+ .clk_rate = 12000,
+ .pset = _i2c_pset,
+};
+
static const struct intel_lpss_platform_info bxt_info = {
.clk_rate = 1,
};
@@ -35,8 +49,8 @@ static const struct intel_lpss_platform_info bxt_i2c_info = {
static const struct acpi_device_id intel_lpss_acpi_ids[] = {
/* SPT */
- { "INT3446", (kernel_ulong_t)_info },
- { "INT3447", (kernel_ulong_t)_info },
+ { "INT3446", (kernel_ulong_t)_i2c_info },
+ { "INT3447", (kernel_ulong_t)_i2c_info },
/* BXT */
{ "80860AAC", (kernel_ulong_t)_i2c_info },
{ "80860ABC", (kernel_ulong_t)_info },
diff --git a/drivers/mfd/intel-lpss-pci.c b/drivers/mfd/intel-lpss-pci.c
index 74f0d6d..3c84ceb 100644
--- a/drivers/mfd/intel-lpss-pci.c
+++ b/drivers/mfd/intel-lpss-pci.c
@@ -65,6 +65,20 @@ static const struct intel_lpss_platform_info spt_info = {
.clk_rate = 12000,
};
+static struct property_entry spt_i2c_properties[] = {
+ PROPERTY_ENTRY_U32("i2c-sda-hold-time-ns", 230),
+ { },
+};
+
+static struct property_set spt_i2c_pset = {
+ .properties = spt_i2c_properties,
+};
+
+static const struct intel_lpss_platform_info spt_i2c_info = {
+ .clk_rate = 12000,
+ .pset = _i2c_pset,
+};
+
static struct property_entry uart_properties[] = {
PROPERTY_ENTRY_U32("reg-io-width", 4),
PROPERTY_ENTRY_U32("reg-shift", 2),
@@ -134,20 +148,20 @@ static const struct pci_device_id intel_lpss_pci_ids[] = {
{ PCI_VDEVICE(INTEL, 0x9d28), (kernel_ulong_t)_uart_info },
{ PCI_VDEVICE(INTEL, 0x9d29), (kernel_ulong_t)_info },
{ PCI_VDEVICE(INTEL, 0x9d2a), (kernel_ulong_t)_info },
- { PCI_VDEVICE(INTEL, 0x9d60), (kernel_ulong_t)_info },
- { PCI_VDEVICE(INTEL, 0x9d61), (kernel_ulong_t)_info },
- { PCI_VDEVICE(INTEL, 0x9d62), (kernel_ulong_t)_info },
- { PCI_VDEVICE(INTEL, 0x9d63), (kernel_ulong_t)_info },
- { PCI_VDEVICE(INTEL, 0x9d64), (kernel_ulong_t)_info },
- { PCI_VDEVICE(INTEL, 0x9d65), (kernel_ulong_t)_info },
+ { PCI_VDEVICE(INTEL, 0x9d60), (kernel_ulong_t)_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x9d61), (kernel_ulong_t)_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x9d62), (kernel_ulong_t)_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x9d63), (kernel_ulong_t)_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x9d64), (kernel_ulong_t)_i2c_info },
+ { PCI_VDEVICE(INTEL, 0x9d65), (kernel_ulong_t)_i2c_info },
{ PCI_VDEVICE(INTEL, 0x9d66), (kernel_ulong_t)_uart_info },
/* SPT-H */
{ PCI_VDEVICE(INTEL, 0xa127), (kernel_ulong_t)_uart_info },
{ PCI_VDEVICE(INTEL, 0xa128), (kernel_ulong_t)_uart_info },
{ PCI_VDEVICE(INTEL, 0xa129), (kernel_ulong_t)_info },
{ PCI_VDEVICE(INTEL, 0xa12a), (kernel_ulong_t)_info },
- { PCI_VDEVICE(INTEL, 0xa160), (kernel_ulong_t)_info },
- { PCI_VDEVICE(INTEL, 0xa161), (kernel_ulong_t)_info },
+ { PCI_VDEVICE(INTEL, 0xa160), (kernel_ulong_t)_i2c_info },
+ { PCI_VDEVICE(INTEL, 0xa161), (kernel_ulong_t)_i2c_info },
{ PCI_VDEVICE(INTEL, 0xa166), (kernel_ulong_t)_uart_info },
{ }
};
--
2.6.2
--
To
[PATCH v1 08/13] device property: Fallback to secondary fwnode if primary misses the property
The struct fwnode has notion of secondary fwnode. This is supposed to used
as fallback if the primary firmware interface (DT, ACPI) does not have the
property in question.
However, the current implementation never checks the secondary node which
prevents one to add default "built-in" properties to devices.
This patch adds fallback to the secondary fwnode if the primary fwnode
returns that the property does not exists.
Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/base/property.c | 109 ++--
1 file changed, 78 insertions(+), 31 deletions(-)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index c8e9722..1768e61 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -212,12 +212,8 @@ bool device_property_present(struct device *dev, const
char *propname)
}
EXPORT_SYMBOL_GPL(device_property_present);
-/**
- * fwnode_property_present - check if a property of a firmware node is present
- * @fwnode: Firmware node whose property to check
- * @propname: Name of the property
- */
-bool fwnode_property_present(struct fwnode_handle *fwnode, const char
*propname)
+static bool __fwnode_property_present(struct fwnode_handle *fwnode,
+ const char *propname)
{
if (is_of_node(fwnode))
return of_property_read_bool(to_of_node(fwnode), propname);
@@ -227,6 +223,21 @@ bool fwnode_property_present(struct fwnode_handle *fwnode,
const char *propname)
return !!pset_prop_get(to_pset_node(fwnode), propname);
return false;
}
+
+/**
+ * fwnode_property_present - check if a property of a firmware node is present
+ * @fwnode: Firmware node whose property to check
+ * @propname: Name of the property
+ */
+bool fwnode_property_present(struct fwnode_handle *fwnode, const char
*propname)
+{
+ bool ret;
+
+ ret = __fwnode_property_present(fwnode, propname);
+ if (ret == false && fwnode->secondary)
+ ret = __fwnode_property_present(fwnode->secondary, propname);
+ return ret;
+}
EXPORT_SYMBOL_GPL(fwnode_property_present);
/**
@@ -406,7 +417,7 @@ EXPORT_SYMBOL_GPL(device_property_match_string);
(val) ? pset_prop_read_##type##_array((node), (propname), (val),
(nval))\
: pset_prop_count_elems_of_size((node), (propname), sizeof(type))
-#define FWNODE_PROP_READ_ARRAY(_fwnode_, _propname_, _type_, _proptype_,
_val_, _nval_)\
+#define FWNODE_PROP_READ(_fwnode_, _propname_, _type_, _proptype_, _val_,
_nval_) \
({
\
int _ret_;
\
if (is_of_node(_fwnode_))
\
@@ -423,6 +434,17 @@ EXPORT_SYMBOL_GPL(device_property_match_string);
_ret_;
\
})
+#define FWNODE_PROP_READ_ARRAY(_fwnode_, _propname_, _type_, _proptype_,
_val_, _nval_)\
+({
\
+ int _ret_;
\
+ _ret_ = FWNODE_PROP_READ(_fwnode_, _propname_, _type_, _proptype_,
\
+_val_, _nval_);
\
+ if (_ret_ == -EINVAL && _fwnode_->secondary)
\
+ _ret_ = FWNODE_PROP_READ(_fwnode_->secondary, _propname_,
_type_, \
+ _proptype_, _val_, _nval_);
\
+ _ret_;
\
+})
+
/**
* fwnode_property_read_u8_array - return a u8 array property of firmware node
* @fwnode: Firmware node to get the property of
@@ -527,6 +549,41 @@ int fwnode_property_read_u64_array(struct fwnode_handle
*fwnode,
}
EXPORT_SYMBOL_GPL(fwnode_property_read_u64_array);
+static int __fwnode_property_read_string_array(struct fwnode_handle *fwnode,
+ const char *propname,
+ const char **val, size_t nval)
+{
+ if (is_of_node(fwnode))
+ return val ?
+ of_property_read_string_array(to_of_node(fwnode),
+ propname, val, nval) :
+ of_property_count_strings(to_of_node(fwnode), propname);
+ else if (is_acpi_node(fwnode))
+ return acpi_node_prop_read(fwnode, propname, DEV_PROP_STRING,
+ val, nval);
+ else if
[PATCH v1 04/13] device property: keep single value inplace
We may save a lot of lines of code and space by keeping single values inside
the struct property_entry. Refactor the implementation to do so.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/base/property.c | 31 ---
include/linux/property.h | 29 +
2 files changed, 49 insertions(+), 11 deletions(-)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index 86834bd..3e603c0 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -72,7 +72,10 @@ static void *pset_prop_find(struct property_set *pset, const
char *propname,
prop = pset_prop_get(pset, propname);
if (!prop)
return ERR_PTR(-EINVAL);
- pointer = prop->value.raw_data;
+ if (prop->is_array)
+ pointer = prop->pointer.raw_data;
+ else
+ pointer = >value.raw_data;
if (!pointer)
return ERR_PTR(-ENODATA);
if (length > prop->length)
@@ -167,6 +170,29 @@ static int pset_prop_read_string_array(struct property_set
*pset,
return 0;
}
+static int pset_prop_read_string(struct property_set *pset,
+const char *propname, const char **strings)
+{
+ struct property_entry *prop;
+ const char **pointer;
+
+ prop = pset_prop_get(pset, propname);
+ if (!prop)
+ return -EINVAL;
+ if (prop->is_array) {
+ pointer = prop->pointer.str;
+ if (!pointer)
+ return -ENODATA;
+ } else {
+ pointer = >value.str;
+ if (strnlen(*pointer, prop->length) >= prop->length)
+ return -EILSEQ;
+ }
+
+ *strings = *pointer;
+ return 0;
+}
+
static inline struct fwnode_handle *dev_fwnode(struct device *dev)
{
return IS_ENABLED(CONFIG_OF) && dev->of_node ?
@@ -566,8 +592,7 @@ int fwnode_property_read_string(struct fwnode_handle
*fwnode,
return acpi_node_prop_read(fwnode, propname, DEV_PROP_STRING,
val, 1);
else if (is_pset_node(fwnode))
- return pset_prop_read_string_array(to_pset_node(fwnode),
- propname, val, 1);
+ return pset_prop_read_string(to_pset_node(fwnode), propname,
val);
return -ENXIO;
}
EXPORT_SYMBOL_GPL(fwnode_property_read_string);
diff --git a/include/linux/property.h b/include/linux/property.h
index c29460a..5d0b9b6 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -145,19 +145,32 @@ static inline int fwnode_property_read_u64(struct
fwnode_handle *fwnode,
* struct property_entry - "Built-in" device property representation.
* @name: Name of the property.
* @length: Length of data making up the value.
- * @value: Value of the property (an array of items of the given type).
+ * @is_array: True when the property is an array.
+ * @pointer: Pointer to the property (an array of items of the given type).
+ * @value: Value of the property (when it is a single item of the given type).
*/
struct property_entry {
const char *name;
size_t length;
+ bool is_array;
union {
- void *raw_data;
- u8 *u8_data;
- u16 *u16_data;
- u32 *u32_data;
- u64 *u64_data;
- const char **str;
- } value;
+ union {
+ void *raw_data;
+ u8 *u8_data;
+ u16 *u16_data;
+ u32 *u32_data;
+ u64 *u64_data;
+ const char **str;
+ } pointer;
+ union {
+ unsigned long long raw_data;
+ u8 u8_data;
+ u16 u16_data;
+ u32 u32_data;
+ u64 u64_data;
+ const char *str;
+ } value;
+ };
};
/**
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 06/13] device property: improve readability of macros
There is no functional change.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/base/property.c | 28 ++--
include/linux/property.h | 4 ++--
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index 3e603c0..c8e9722 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -398,29 +398,29 @@ int device_property_match_string(struct device *dev,
const char *propname,
}
EXPORT_SYMBOL_GPL(device_property_match_string);
-#define OF_DEV_PROP_READ_ARRAY(node, propname, type, val, nval) \
- (val) ? of_property_read_##type##_array((node), (propname), (val),
(nval)) \
+#define OF_DEV_PROP_READ_ARRAY(node, propname, type, val, nval)
\
+ (val) ? of_property_read_##type##_array((node), (propname), (val),
(nval)) \
: of_property_count_elems_of_size((node), (propname),
sizeof(type))
#define PSET_PROP_READ_ARRAY(node, propname, type, val, nval)
\
(val) ? pset_prop_read_##type##_array((node), (propname), (val),
(nval))\
: pset_prop_count_elems_of_size((node), (propname), sizeof(type))
-#define FWNODE_PROP_READ_ARRAY(_fwnode_, _propname_, _type_, _proptype_,
_val_, _nval_) \
-({ \
- int _ret_; \
- if (is_of_node(_fwnode_)) \
- _ret_ = OF_DEV_PROP_READ_ARRAY(to_of_node(_fwnode_),
_propname_, \
- _type_, _val_, _nval_); \
- else if (is_acpi_node(_fwnode_)) \
- _ret_ = acpi_node_prop_read(_fwnode_, _propname_, _proptype_, \
- _val_, _nval_); \
+#define FWNODE_PROP_READ_ARRAY(_fwnode_, _propname_, _type_, _proptype_,
_val_, _nval_)\
+({
\
+ int _ret_;
\
+ if (is_of_node(_fwnode_))
\
+ _ret_ = OF_DEV_PROP_READ_ARRAY(to_of_node(_fwnode_),
_propname_,\
+ _type_, _val_, _nval_);
\
+ else if (is_acpi_node(_fwnode_))
\
+ _ret_ = acpi_node_prop_read(_fwnode_, _propname_, _proptype_,
\
+ _val_, _nval_);
\
else if (is_pset_node(_fwnode_))
\
_ret_ = PSET_PROP_READ_ARRAY(to_pset_node(_fwnode_),
_propname_,\
_type_, _val_, _nval_);
\
- else \
- _ret_ = -ENXIO; \
- _ret_; \
+ else
\
+ _ret_ = -ENXIO;
\
+ _ret_;
\
})
/**
diff --git a/include/linux/property.h b/include/linux/property.h
index 2528a000..e947403 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -73,8 +73,8 @@ int fwnode_property_match_string(struct fwnode_handle *fwnode,
struct fwnode_handle *device_get_next_child_node(struct device *dev,
struct fwnode_handle *child);
-#define device_for_each_child_node(dev, child) \
- for (child = device_get_next_child_node(dev, NULL); child; \
+#define device_for_each_child_node(dev, child) \
+ for (child = device_get_next_child_node(dev, NULL); child; \
child = device_get_next_child_node(dev, child))
void fwnode_handle_put(struct fwnode_handle *fwnode);
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 09/13] mfd: core: propagate device properties to sub devices drivers
In the similar way like we do for the platform data we propagate the device
properties. For example, in case of Intel LPSS drivers we may provide a
specific property to tell the actual device driver an additional information
such as platform name.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/mfd/mfd-core.c | 3 +++
include/linux/mfd/core.h | 5 +
2 files changed, 8 insertions(+)
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index 60b60dc..ec00f6f 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -192,6 +193,8 @@ static int mfd_add_device(struct device *parent, int id,
goto fail_alias;
}
+ device_add_property_set(>dev, cell->pset);
+
ret = mfd_platform_add_cell(pdev, cell, usage_count);
if (ret)
goto fail_alias;
diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
index 27dac3f..0c62f17 100644
--- a/include/linux/mfd/core.h
+++ b/include/linux/mfd/core.h
@@ -15,6 +15,7 @@
#define MFD_CORE_H
#include
+#include
struct irq_domain;
@@ -44,6 +45,10 @@ struct mfd_cell {
/* platform data passed to the sub devices drivers */
void*platform_data;
size_t pdata_size;
+
+ /* device properties passed to the sub devices drivers */
+ struct property_set *pset;
+
/*
* Device Tree compatible string
* See: Documentation/devicetree/usage-model.txt Chapter 2.2 for details
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 07/13] device property: return -EINVAL when property isn't found in ACPI
Change return code to be in align with OF and built-in device properties error
codes. In particular -EINVAL means property is not found.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/acpi/property.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index 88f4306..2aee416 100644
--- a/drivers/acpi/property.c
+++ b/drivers/acpi/property.c
@@ -346,7 +346,7 @@ void acpi_free_properties(struct acpi_device *adev)
*
* Return: %0 if property with @name has been found (success),
* %-EINVAL if the arguments are invalid,
- * %-ENODATA if the property doesn't exist,
+ * %-EINVAL if the property doesn't exist,
* %-EPROTO if the property value type doesn't match @type.
*/
static int acpi_data_get_property(struct acpi_device_data *data,
@@ -360,7 +360,7 @@ static int acpi_data_get_property(struct acpi_device_data
*data,
return -EINVAL;
if (!data->pointer || !data->properties)
- return -ENODATA;
+ return -EINVAL;
properties = data->properties;
for (i = 0; i < properties->package.count; i++) {
@@ -375,13 +375,13 @@ static int acpi_data_get_property(struct acpi_device_data
*data,
if (!strcmp(name, propname->string.pointer)) {
if (type != ACPI_TYPE_ANY && propvalue->type != type)
return -EPROTO;
- else if (obj)
+ if (obj)
*obj = propvalue;
return 0;
}
}
- return -ENODATA;
+ return -EINVAL;
}
/**
@@ -439,7 +439,7 @@ int acpi_node_prop_get(struct fwnode_handle *fwnode, const
char *propname,
*
* Return: %0 if array property (package) with @name has been found (success),
* %-EINVAL if the arguments are invalid,
- * %-ENODATA if the property doesn't exist,
+ * %-EINVAL if the property doesn't exist,
* %-EPROTO if the property is not a package or the type of its
elements
* doesn't match @type.
*/
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] x86/platform/iosf_mbi: Remove duplicate definitions
On Wed, 2015-11-11 at 19:59 +0200, Andy Shevchenko wrote: > The read and write opcodes are global for all units on SoC and even > across > Intel SoCs. Remove duplication of corresponding constants. At the > same time > convert all current users. > > No functional change. > > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Ingo Molnar <mi...@redhat.com> > Cc: Peter Anvin <h...@zytor.com> > Cc: Wolfram Sang <w...@the-dreams.de> > Cc: Zhang Rui <rui.zh...@intel.com> > Cc: Eduardo Valentin <edubez...@gmail.com> > Cc: Hock Leong Kweh <hock.leong.k...@intel.com> Any concerns, anyone? Btw, this patch has been tested on Intel BayTrail and Braswell. > > Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com> > --- > Since v1: > - satisfy kbuild robot > > arch/x86/include/asm/iosf_mbi.h | 49 +- > > arch/x86/platform/atom/punit_atom_debug.c| 7 +--- > arch/x86/platform/intel-quark/imr.c | 28 + > drivers/i2c/busses/i2c-designware-baytrail.c | 17 +++- > drivers/powercap/intel_rapl.c| 10 ++--- > drivers/thermal/intel_quark_dts_thermal.c| 61 ++-- > > drivers/thermal/intel_soc_dts_iosf.c | 43 ++-- > > 7 files changed, 85 insertions(+), 130 deletions(-) > > diff --git a/arch/x86/include/asm/iosf_mbi.h > b/arch/x86/include/asm/iosf_mbi.h > index b72ad0f..cdc5f63 100644 > --- a/arch/x86/include/asm/iosf_mbi.h > +++ b/arch/x86/include/asm/iosf_mbi.h > @@ -1,5 +1,5 @@ > /* > - * iosf_mbi.h: Intel OnChip System Fabric MailBox access support > + * Intel OnChip System Fabric MailBox access support > */ > > #ifndef IOSF_MBI_SYMS_H > @@ -16,6 +16,16 @@ > #define MBI_MASK_LO 0x00FF > #define MBI_ENABLE 0xF0 > > +/* IOSF SB read/write opcodes */ > +#define MBI_MMIO_READ0x00 > +#define MBI_MMIO_WRITE 0x01 > +#define MBI_CR_READ 0x06 > +#define MBI_CR_WRITE 0x07 > +#define MBI_REG_READ 0x10 > +#define MBI_REG_WRITE0x11 > +#define MBI_ESRAM_READ 0x12 > +#define MBI_ESRAM_WRITE 0x13 > + > /* Baytrail available units */ > #define BT_MBI_UNIT_AUNIT0x00 > #define BT_MBI_UNIT_SMC 0x01 > @@ -28,50 +38,13 @@ > #define BT_MBI_UNIT_SATA 0xA3 > #define BT_MBI_UNIT_PCIE 0xA6 > > -/* Baytrail read/write opcodes */ > -#define BT_MBI_AUNIT_READ0x10 > -#define BT_MBI_AUNIT_WRITE 0x11 > -#define BT_MBI_SMC_READ 0x10 > -#define BT_MBI_SMC_WRITE 0x11 > -#define BT_MBI_CPU_READ 0x10 > -#define BT_MBI_CPU_WRITE 0x11 > -#define BT_MBI_BUNIT_READ0x10 > -#define BT_MBI_BUNIT_WRITE 0x11 > -#define BT_MBI_PMC_READ 0x06 > -#define BT_MBI_PMC_WRITE 0x07 > -#define BT_MBI_GFX_READ 0x00 > -#define BT_MBI_GFX_WRITE 0x01 > -#define BT_MBI_SMIO_READ 0x06 > -#define BT_MBI_SMIO_WRITE0x07 > -#define BT_MBI_USB_READ 0x06 > -#define BT_MBI_USB_WRITE 0x07 > -#define BT_MBI_SATA_READ 0x00 > -#define BT_MBI_SATA_WRITE0x01 > -#define BT_MBI_PCIE_READ 0x00 > -#define BT_MBI_PCIE_WRITE0x01 > - > /* Quark available units */ > #define QRK_MBI_UNIT_HBA 0x00 > #define QRK_MBI_UNIT_HB 0x03 > #define QRK_MBI_UNIT_RMU 0x04 > #define QRK_MBI_UNIT_MM 0x05 > -#define QRK_MBI_UNIT_MMESRAM 0x05 > #define QRK_MBI_UNIT_SOC 0x31 > > -/* Quark read/write opcodes */ > -#define QRK_MBI_HBA_READ 0x10 > -#define QRK_MBI_HBA_WRITE0x11 > -#define QRK_MBI_HB_READ 0x10 > -#define QRK_MBI_HB_WRITE 0x11 > -#define QRK_MBI_RMU_READ 0x10 > -#define QRK_MBI_RMU_WRITE0x11 > -#define QRK_MBI_MM_READ 0x10 > -#define QRK_MBI_MM_WRITE 0x11 > -#define QRK_MBI_MMESRAM_READ 0x12 > -#define QRK_MBI_MMESRAM_WRITE0x13 > -#define QRK_MBI_SOC_READ 0x06 > -#define QRK_MBI_SOC_WRITE0x07 > - > #if IS_ENABLED(CONFIG_IOSF_MBI) > > bool iosf_mbi_available(void); > diff --git a/arch/x86/platform/atom/punit_atom_debug.c > b/arch/x86/platform/atom/punit_atom_debug.c > index 5ca8ead..81c769e 100644 > --- a/arch/x86/platform/atom/punit_atom_debug.c > +++ b/arch/x86/platform/atom/punit_atom_debug.c > @@ -25,8 +25,6 @@ > #include > #include > > -/* Side band Interface port */ > -#define PUNIT_PORT 0x04 > /* Power gate status reg */ > #define PWRGT_STATUS 0x61 > /* Subsystem config/status Video processor */ > @@ -85,9 +83,8
[PATCH v1 10/13] mfd: intel-lpss: Add support for passing device properties
From: Mika Westerberg <mika.westerb...@linux.intel.com>
If the boot firmware does not support ACPI we need a way to pass device
configuration information to the drivers. The unified device properties API
already supports passing platform data via properties so let's take
advantage of that and allow probe drivers to pass set of properties to the
host controller driver.
In order to do that we need to be able to modify the MFD cell corresponding
the host controller, so make the core driver to take copy of the cell
instead of using it directly. Then we can assign info->pset to the
resulting copy of a cell and let the MFD core to assign that to the
resulting device.
Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/mfd/intel-lpss.c | 16
drivers/mfd/intel-lpss.h | 2 ++
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c
index 6255513..1743788 100644
--- a/drivers/mfd/intel-lpss.c
+++ b/drivers/mfd/intel-lpss.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -72,7 +73,7 @@ struct intel_lpss {
enum intel_lpss_dev_type type;
struct clk *clk;
struct clk_lookup *clock;
- const struct mfd_cell *cell;
+ struct mfd_cell *cell;
struct device *dev;
void __iomem *priv;
int devid;
@@ -217,6 +218,7 @@ static void intel_lpss_ltr_hide(struct intel_lpss *lpss)
static int intel_lpss_assign_devs(struct intel_lpss *lpss)
{
+ const struct mfd_cell *cell;
unsigned int type;
type = lpss->caps & LPSS_PRIV_CAPS_TYPE_MASK;
@@ -224,18 +226,22 @@ static int intel_lpss_assign_devs(struct intel_lpss *lpss)
switch (type) {
case LPSS_DEV_I2C:
- lpss->cell = _lpss_i2c_cell;
+ cell = _lpss_i2c_cell;
break;
case LPSS_DEV_UART:
- lpss->cell = _lpss_uart_cell;
+ cell = _lpss_uart_cell;
break;
case LPSS_DEV_SPI:
- lpss->cell = _lpss_spi_cell;
+ cell = _lpss_spi_cell;
break;
default:
return -ENODEV;
}
+ lpss->cell = devm_kmemdup(lpss->dev, cell, sizeof(*cell), GFP_KERNEL);
+ if (!lpss->cell)
+ return -ENOMEM;
+
lpss->type = type;
return 0;
@@ -401,6 +407,8 @@ int intel_lpss_probe(struct device *dev,
if (ret)
return ret;
+ lpss->cell->pset = info->pset;
+
intel_lpss_init_dev(lpss);
lpss->devid = ida_simple_get(_lpss_devid_ida, 0, 0, GFP_KERNEL);
diff --git a/drivers/mfd/intel-lpss.h b/drivers/mfd/intel-lpss.h
index 2c7f8d7..0dcea9e 100644
--- a/drivers/mfd/intel-lpss.h
+++ b/drivers/mfd/intel-lpss.h
@@ -16,12 +16,14 @@
struct device;
struct resource;
+struct property_set;
struct intel_lpss_platform_info {
struct resource *mem;
int irq;
unsigned long clk_rate;
const char *clk_con_id;
+ struct property_set *pset;
};
int intel_lpss_probe(struct device *dev,
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 02/13] device property: rename helper functions
To be in align with the rest of fwnode types we rename the built-in property
set ones, i.e.
is_pset() -> is_pset_node()
to_pset() -> to_pset_node()
There is no functional change.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/base/property.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index 09e488d..2e01f3f 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -37,14 +37,14 @@ void device_add_property_set(struct device *dev, struct
property_set *pset)
}
EXPORT_SYMBOL_GPL(device_add_property_set);
-static inline bool is_pset(struct fwnode_handle *fwnode)
+static inline bool is_pset_node(struct fwnode_handle *fwnode)
{
return fwnode && fwnode->type == FWNODE_PDATA;
}
-static inline struct property_set *to_pset(struct fwnode_handle *fwnode)
+static inline struct property_set *to_pset_node(struct fwnode_handle *fwnode)
{
- return is_pset(fwnode) ?
+ return is_pset_node(fwnode) ?
container_of(fwnode, struct property_set, fwnode) : NULL;
}
@@ -135,8 +135,8 @@ bool fwnode_property_present(struct fwnode_handle *fwnode,
const char *propname)
return of_property_read_bool(to_of_node(fwnode), propname);
else if (is_acpi_node(fwnode))
return !acpi_node_prop_get(fwnode, propname, NULL);
- else if (is_pset(fwnode))
- return !!pset_prop_get(to_pset(fwnode), propname);
+ else if (is_pset_node(fwnode))
+ return !!pset_prop_get(to_pset_node(fwnode), propname);
return false;
}
EXPORT_SYMBOL_GPL(fwnode_property_present);
@@ -323,8 +323,8 @@ EXPORT_SYMBOL_GPL(device_property_match_string);
else if (is_acpi_node(_fwnode_)) \
_ret_ = acpi_node_prop_read(_fwnode_, _propname_, _proptype_, \
_val_, _nval_); \
- else if (is_pset(_fwnode_)) \
- _ret_ = pset_prop_read_array(to_pset(_fwnode_), _propname_, \
+ else if (is_pset_node(_fwnode_))
\
+ _ret_ = pset_prop_read_array(to_pset_node(_fwnode_),
_propname_,\
_proptype_, _val_, _nval_); \
else \
_ret_ = -ENXIO; \
@@ -465,8 +465,8 @@ int fwnode_property_read_string_array(struct fwnode_handle
*fwnode,
else if (is_acpi_node(fwnode))
return acpi_node_prop_read(fwnode, propname, DEV_PROP_STRING,
val, nval);
- else if (is_pset(fwnode))
- return pset_prop_read_array(to_pset(fwnode), propname,
+ else if (is_pset_node(fwnode))
+ return pset_prop_read_array(to_pset_node(fwnode), propname,
DEV_PROP_STRING, val, nval);
return -ENXIO;
}
@@ -495,8 +495,8 @@ int fwnode_property_read_string(struct fwnode_handle
*fwnode,
else if (is_acpi_node(fwnode))
return acpi_node_prop_read(fwnode, propname, DEV_PROP_STRING,
val, 1);
- else if (is_pset(fwnode))
- return pset_prop_read_array(to_pset(fwnode), propname,
+ else if (is_pset_node(fwnode))
+ return pset_prop_read_array(to_pset_node(fwnode), propname,
DEV_PROP_STRING, val, 1);
return -ENXIO;
}
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 13/13] i2c: designware: Convert to use unified device property API
From: Mika Westerberg <mika.westerb...@linux.intel.com>
With ACPI _DSD (introduced in ACPI v5.1) it is now possible to pass device
configuration information from ACPI in addition to DT. In order to support
this, convert the driver to use the unified device property accessors
instead of DT specific.
Change to ordering a bit so that we first try platform data and if that's
not available look from device properties. ACPI *CNT methods are then used
as last resort to override everything else.
Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/i2c/busses/i2c-designware-platdrv.c | 48 +
1 file changed, 22 insertions(+), 26 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 809579e..e9062be 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -156,33 +157,28 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
/* fast mode by default because of legacy reasons */
clk_freq = 40;
- if (has_acpi_companion(>dev)) {
- dw_i2c_acpi_configure(pdev);
- } else if (pdev->dev.of_node) {
- of_property_read_u32(pdev->dev.of_node,
- "i2c-sda-hold-time-ns", );
-
- of_property_read_u32(pdev->dev.of_node,
-"i2c-sda-falling-time-ns",
->sda_falling_time);
- of_property_read_u32(pdev->dev.of_node,
-"i2c-scl-falling-time-ns",
->scl_falling_time);
-
- of_property_read_u32(pdev->dev.of_node, "clock-frequency",
-_freq);
-
- /* Only standard mode at 100kHz and fast mode at 400kHz
-* are supported.
-*/
- if (clk_freq != 10 && clk_freq != 40) {
- dev_err(>dev, "Only 100kHz and 400kHz supported");
- return -EINVAL;
- }
+ if ((pdata = dev_get_platdata(>dev))) {
+ clk_freq = pdata->i2c_scl_freq;
} else {
- pdata = dev_get_platdata(>dev);
- if (pdata)
- clk_freq = pdata->i2c_scl_freq;
+ device_property_read_u32(>dev, "i2c-sda-hold-time-ns",
+);
+ device_property_read_u32(>dev, "i2c-sda-falling-time-ns",
+>sda_falling_time);
+ device_property_read_u32(>dev, "i2c-scl-falling-time-ns",
+>scl_falling_time);
+ device_property_read_u32(>dev, "clock-frequency",
+_freq);
+ }
+
+ if (has_acpi_companion(>dev))
+ dw_i2c_acpi_configure(pdev);
+
+ /* Only standard mode at 100kHz and fast mode at 400kHz
+* are supported.
+*/
+ if (clk_freq != 10 && clk_freq != 40) {
+ dev_err(>dev, "Only 100kHz and 400kHz supported");
+ return -EINVAL;
}
r = i2c_dw_eval_lock_support(dev);
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 03/13] device property: refactor built-in properties support
Instead of using the type and nval fields we will use length (in bytes) of the
value. The sanity check is done in the accessors.
The built-in property accessors are split in the same way such as device tree.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/base/property.c | 150 ++-
include/linux/property.h | 8 +--
2 files changed, 113 insertions(+), 45 deletions(-)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index 2e01f3f..86834bd 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -63,45 +63,107 @@ static struct property_entry *pset_prop_get(struct
property_set *pset,
return NULL;
}
-static int pset_prop_read_array(struct property_set *pset, const char *name,
- enum dev_prop_type type, void *val, size_t nval)
+static void *pset_prop_find(struct property_set *pset, const char *propname,
+ size_t length)
{
struct property_entry *prop;
- unsigned int item_size;
+ void *pointer;
- prop = pset_prop_get(pset, name);
+ prop = pset_prop_get(pset, propname);
+ if (!prop)
+ return ERR_PTR(-EINVAL);
+ pointer = prop->value.raw_data;
+ if (!pointer)
+ return ERR_PTR(-ENODATA);
+ if (length > prop->length)
+ return ERR_PTR(-EOVERFLOW);
+ return pointer;
+}
+
+static int pset_prop_read_u8_array(struct property_set *pset,
+ const char *propname,
+ u8 *values, size_t nval)
+{
+ void *pointer;
+ size_t length = nval * sizeof(*values);
+
+ pointer = pset_prop_find(pset, propname, length);
+ if (IS_ERR(pointer))
+ return PTR_ERR(pointer);
+
+ memcpy(values, pointer, length);
+ return 0;
+}
+
+static int pset_prop_read_u16_array(struct property_set *pset,
+ const char *propname,
+ u16 *values, size_t nval)
+{
+ void *pointer;
+ size_t length = nval * sizeof(*values);
+
+ pointer = pset_prop_find(pset, propname, length);
+ if (IS_ERR(pointer))
+ return PTR_ERR(pointer);
+
+ memcpy(values, pointer, length);
+ return 0;
+}
+
+static int pset_prop_read_u32_array(struct property_set *pset,
+ const char *propname,
+ u32 *values, size_t nval)
+{
+ void *pointer;
+ size_t length = nval * sizeof(*values);
+
+ pointer = pset_prop_find(pset, propname, length);
+ if (IS_ERR(pointer))
+ return PTR_ERR(pointer);
+
+ memcpy(values, pointer, length);
+ return 0;
+}
+
+static int pset_prop_read_u64_array(struct property_set *pset,
+ const char *propname,
+ u64 *values, size_t nval)
+{
+ void *pointer;
+ size_t length = nval * sizeof(*values);
+
+ pointer = pset_prop_find(pset, propname, length);
+ if (IS_ERR(pointer))
+ return PTR_ERR(pointer);
+
+ memcpy(values, pointer, length);
+ return 0;
+}
+
+static int pset_prop_count_elems_of_size(struct property_set *pset,
+const char *propname, size_t length)
+{
+ struct property_entry *prop;
+
+ prop = pset_prop_get(pset, propname);
if (!prop)
- return -ENODATA;
-
- if (prop->type != type)
- return -EPROTO;
-
- if (!val)
- return prop->nval;
-
- if (prop->nval < nval)
- return -EOVERFLOW;
-
- switch (type) {
- case DEV_PROP_U8:
- item_size = sizeof(u8);
- break;
- case DEV_PROP_U16:
- item_size = sizeof(u16);
- break;
- case DEV_PROP_U32:
- item_size = sizeof(u32);
- break;
- case DEV_PROP_U64:
- item_size = sizeof(u64);
- break;
- case DEV_PROP_STRING:
- item_size = sizeof(const char *);
- break;
- default:
return -EINVAL;
- }
- memcpy(val, prop->value.raw_data, nval * item_size);
+
+ return prop->length / length;
+}
+
+static int pset_prop_read_string_array(struct property_set *pset,
+ const char *propname,
+ const char **strings, size_t nval)
+{
+ void *pointer;
+ size_t length = nval * sizeof(*strings);
+
+ pointer = pset_prop_find(pset, propname, length);
+ if (IS_ERR(pointer))
+ return PTR_ERR(pointer);
+
+ memcpy(strings, pointer, length);
return 0;
}
@@ -314,6 +376,10 @@ EXPORT_SYMBOL_GPL(device_property_match_string);
(val)
[PATCH v1 01/13] device property: always check for fwnode type
Currently the property accessors unconditionally fall back to built-in property set as a last resort. Make this strict and return an error in case the type of fwnode is unknown. This is actually a follow up to the commit 4fa7508e9f1c (device property: Return -ENXIO if there is no suitable FW interface). Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com> --- drivers/base/property.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/base/property.c b/drivers/base/property.c index 1325ff2..09e488d 100644 --- a/drivers/base/property.c +++ b/drivers/base/property.c @@ -135,8 +135,9 @@ bool fwnode_property_present(struct fwnode_handle *fwnode, const char *propname) return of_property_read_bool(to_of_node(fwnode), propname); else if (is_acpi_node(fwnode)) return !acpi_node_prop_get(fwnode, propname, NULL); - - return !!pset_prop_get(to_pset(fwnode), propname); + else if (is_pset(fwnode)) + return !!pset_prop_get(to_pset(fwnode), propname); + return false; } EXPORT_SYMBOL_GPL(fwnode_property_present); @@ -494,9 +495,10 @@ int fwnode_property_read_string(struct fwnode_handle *fwnode, else if (is_acpi_node(fwnode)) return acpi_node_prop_read(fwnode, propname, DEV_PROP_STRING, val, 1); - - return pset_prop_read_array(to_pset(fwnode), propname, - DEV_PROP_STRING, val, 1); + else if (is_pset(fwnode)) + return pset_prop_read_array(to_pset(fwnode), propname, + DEV_PROP_STRING, val, 1); + return -ENXIO; } EXPORT_SYMBOL_GPL(fwnode_property_read_string); -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 00/13] intel-lpss: support non-ACPI platforms
This series includes few logical sets that bring a support of non-ACPI platforms for Intel Skylake. First part is a refactoring of built-in device properties support: - keep single value inside the structure - provide helper macros to define built-in properties - fall back to secondary fwnode if primary has no asked property Second one is modifications to MFD code and intel-lpss.c driver in particular to define and pass built-in properties to the individual drivers. Last part is a fix for I2C bug found on Lenovo Yoga hardware and a first converted user. Built-in device properties is an alternative to platform data. It provides a unified API that drivers can use to cover all cases at once: DT, ACPI, and built-in properties. With this series applied platform data can be considered obsolete. Moreover, built-in device properties allows to adjust existing configuration, for example, in cases when ACPI values are wrong on some platforms. The series has been tested on available hardware and doesn't break current behaviour. But we ask you, Kevin, to apply the series on your side and check with Lenovo hardware. Andy Shevchenko (8): device property: always check for fwnode type device property: rename helper functions device property: refactor built-in properties support device property: keep single value inplace device property: improve readability of macros device property: return -EINVAL when property isn't found in ACPI device property: Fallback to secondary fwnode if primary misses the property mfd: core: propagate device properties to sub devices drivers Heikki Krogerus (1): device property: helper macros for property entry creation Mika Westerberg (4): mfd: intel-lpss: Add support for passing device properties mfd: intel-lpss: Pass HSUART configuration via properties mfd: intel-lpss: Pass SDA hold time to I2C host controller driver i2c: designware: Convert to use unified device property API drivers/acpi/property.c | 10 +- drivers/base/property.c | 298 +--- drivers/i2c/busses/i2c-designware-platdrv.c | 48 ++--- drivers/mfd/intel-lpss-acpi.c | 18 +- drivers/mfd/intel-lpss-pci.c| 43 +++- drivers/mfd/intel-lpss.c| 16 +- drivers/mfd/intel-lpss.h| 2 + drivers/mfd/mfd-core.c | 3 + include/linux/mfd/core.h| 5 + include/linux/property.h| 87 ++-- 10 files changed, 394 insertions(+), 136 deletions(-) -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 03/13] device property: refactor built-in properties support
On Tue, 2015-11-24 at 15:37 +0100, Rafael J. Wysocki wrote: > On Tuesday, November 24, 2015 12:22:49 PM Andy Shevchenko wrote: > > Instead of using the type and nval fields we will use length (in > > bytes) of the > > value. The sanity check is done in the accessors. > > > > The built-in property accessors are split in the same way such as > > device tree. > > Do I understand correctly that this is indended to make the built-in > properties > follow the DT layout? Correct. > > Thanks, > Rafael > -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 00/13] intel-lpss: support non-ACPI platforms
On Tue, 2015-11-24 at 16:11 +0100, Rafael J. Wysocki wrote: > On Tuesday, November 24, 2015 12:22:46 PM Andy Shevchenko wrote: > > This series includes few logical sets that bring a support of non- > > ACPI > > platforms for Intel Skylake. > > > > First part is a refactoring of built-in device properties support: > > - keep single value inside the structure > > - provide helper macros to define built-in properties > > - fall back to secondary fwnode if primary has no asked property > > > > Second one is modifications to MFD code and intel-lpss.c driver in > > particular > > to define and pass built-in properties to the individual drivers. > > > > Last part is a fix for I2C bug found on Lenovo Yoga hardware and a > > first > > converted user. > > > > Built-in device properties is an alternative to platform data. It > > provides a > > unified API that drivers can use to cover all cases at once: DT, > > ACPI, and > > built-in properties. > > > > With this series applied platform data can be considered obsolete. > > Moreover, > > built-in device properties allows to adjust existing configuration, > > for > > example, in cases when ACPI values are wrong on some platforms. > > > > The series has been tested on available hardware and doesn't break > > current > > behaviour. But we ask you, Kevin, to apply the series on your side > > and check > > with Lenovo hardware. > > > > Andy Shevchenko (8): > > device property: always check for fwnode type > > device property: rename helper functions > > device property: refactor built-in properties support > > device property: keep single value inplace > > device property: improve readability of macros > > device property: return -EINVAL when property isn't found in ACPI > > device property: Fallback to secondary fwnode if primary misses > > the > > property > > mfd: core: propagate device properties to sub devices drivers > > > > Heikki Krogerus (1): > > device property: helper macros for property entry creation > > > > Mika Westerberg (4): > > mfd: intel-lpss: Add support for passing device properties > > mfd: intel-lpss: Pass HSUART configuration via properties > > mfd: intel-lpss: Pass SDA hold time to I2C host controller driver > > i2c: designware: Convert to use unified device property API > > > > drivers/acpi/property.c | 10 +- > > drivers/base/property.c | 298 > > +--- > > drivers/i2c/busses/i2c-designware-platdrv.c | 48 ++--- > > drivers/mfd/intel-lpss-acpi.c | 18 +- > > drivers/mfd/intel-lpss-pci.c| 43 +++- > > drivers/mfd/intel-lpss.c| 16 +- > > drivers/mfd/intel-lpss.h| 2 + > > drivers/mfd/mfd-core.c | 3 + > > include/linux/mfd/core.h | 5 + > > include/linux/property.h| 87 ++-- > > 10 files changed, 394 insertions(+), 136 deletions(-) > > All patches in this series look good to me overall, but please fix > the build > problems reported by 0-day and resubmit. Thanks for fast response. We will do that later this week while gathering comments from others. > Thanks, > Rafael > -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/1] i2c: core: replace boolean variable by integer
There is a warning when compiling i2c-core.c
drivers/i2c/i2c-core.c:2561:36: warning: dubious: x | !y
Replace boolean exdpression by a plain bitwise AND since I2C_M_RD is a bit 0
and thus we are on the safe side.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
Reviewed-by: Alexander Sverdlin <aleaxander.sverd...@nokia.com>
---
Changelog v3:
- add tag
- rephrase commit message
drivers/i2c/i2c-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 040af5c..873ca1c 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -2591,7 +2591,7 @@ static u8 i2c_smbus_pec(u8 crc, u8 *p, size_t count)
static u8 i2c_smbus_msg_pec(u8 pec, struct i2c_msg *msg)
{
/* The address will be sent first */
- u8 addr = (msg->addr << 1) | !!(msg->flags & I2C_M_RD);
+ u8 addr = (msg->addr << 1) | (msg->flags & I2C_M_RD);
pec = i2c_smbus_pec(pec, , 1);
/* The data buffer follows */
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/1] i2c: taos-evm: replace simple_strtoul by kstrtou8
On Wed, Nov 18, 2015 at 2:55 PM, LABBE Corentin
<clabbe.montj...@gmail.com> wrote:
> The simple_strtoul function is marked as obsolete.
> This patch replace it by kstrtou8.
>
Only one concern. simple_strto* goes through the string until it has
an invalid character or \0. In your case kstrtou8 will fail the
transfer. So, is there possible cases when HW returns such data?
And just a style nitpicks below.
> if (p[0] == 'x') {
> - data->byte = simple_strtol(p + 1, NULL, 16);
> + /*
> +* voluntarily dropping error code of kstrtou8 since
> all
-> Voluntarily…
> +* error code that it could return are invalid
> according
> +* to Documentation/i2c/fault-codes
-> …codes.
> +*/
> + if (kstrtou8(p + 1, 16, >byte))
> + return -EPROTO;
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] i2c-piix4: Add support for multiplexed main adapter in SB800
atic int piix4_probe(struct pci_dev *dev,
> const struct pci_device_id *id)
> if ((dev->vendor == PCI_VENDOR_ID_ATI &&
> dev->device == PCI_DEVICE_ID_ATI_SBX00_SMBUS &&
> dev->revision >= 0x40) ||
> - dev->vendor == PCI_VENDOR_ID_AMD)
> + dev->vendor == PCI_VENDOR_ID_AMD) {
> + if (!request_region(SB800_PIIX4_SMB_IDX, 2,
> "smba_idx")) {
> + dev_err(>dev,
> + "SMBus base address index region 0x%x
> already in use!\n",
> + SB800_PIIX4_SMB_IDX);
> + return -EBUSY;
> + }
> +
> /* base address location etc changed in SB800 */
> retval = piix4_setup_sb800(dev, id, 0);
> - else
> - retval = piix4_setup(dev, id);
> + if (retval < 0) {
> + release_region(SB800_PIIX4_SMB_IDX, 2);
> + return retval;
> + }
>
> - /* If no main SMBus found, give up */
> - if (retval < 0)
> - return retval;
> + /*
> + * Try to register multiplexed main SMBus adapter,
> + * give up if we can't
> + */
> + retval = piix4_add_adapters_sb800(dev, retval);
> + if (retval < 0) {
> + release_region(SB800_PIIX4_SMB_IDX, 2);
> + return retval;
> + }
> + } else {
> + retval = piix4_setup(dev, id);
> + if (retval < 0)
> + return retval;
>
> - /* Try to register main SMBus adapter, give up if we can't
> */
> - retval = piix4_add_adapter(dev, retval,
> _main_adapters[0]);
> - if (retval < 0)
> - return retval;
> + /* Try to register main SMBus adapter, give up if we
> can't */
> + retval = piix4_add_adapter(dev, retval,
> + _main_adapters[0]);
> + if (retval < 0)
> + return retval;
> + }
>
> /* Check for auxiliary SMBus on some AMD chipsets */
> retval = -ENODEV;
> @@ -669,7 +784,13 @@ static void piix4_adap_remove(struct i2c_adapter
> *adap)
>
> if (adapdata->smba) {
> i2c_del_adapter(adap);
> - release_region(adapdata->smba, SMBIOSIZE);
> + if (adapdata->port == 0) {
> + release_region(adapdata->smba, SMBIOSIZE);
> + if (adapdata->sb800_main) {
> + kfree(adapdata->mutex);
> + release_region(SB800_PIIX4_SMB_IDX,
> 2);
> + }
> + }
> kfree(adapdata);
> kfree(adap);
> }
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/3] Support multiplexed main SMBus interface on SB800
On Sun, 2015-11-15 at 12:33 +0100, Christian Fetzer wrote: > This is an attempt to upstream the patches created by Thomas Brandon > and > Eddi De Pieri to support the multiplexed main SMBus interface on the > SB800 > chipset. (https://www.mail-archive.com/linux-i2c@vger.kernel.org/msg0 > 6757.html) > > I have mainly rebased the latest patch version and tested the driver > on a > HP ProLiant MicroServer G7 N54L (where this patch allows to access > sensor data > from a w83795adg). > > The patched driver is running stable on the machine, given that > ic2_piix4 is > loaded before jc42 and w83795. If jc42 is loaded before i2c_piix4 > calling > sensors triggers some errors: > ERROR: Can't get value of subfeature temp1_min_alarm: Can't read > > While the kernel log shows: > i2c i2c-1: Transaction (pre): CNT=0c, CMD=05, ADD=31, DAT0=03, > DAT1=c0 > i2c i2c-1: Error: no response! > i2c i2c-1: Transaction (post): CNT=0c, CMD=05, ADD=31, DAT0=ff, > DAT1=ff > Unfortunately I don't know how to tackle this specific issue. > > Please review and let me know required changes in order to get this > upstream > finally. One nitpick in one patch, though it looks okay for me: Reviewed-by: Andy Shevchenko <andriy.shevche...@linux.intel.com> > > Eddi, Thomas, it would be great if you could verify the changes on > your > machines. > > Regards, > Christian > > v4: > - Incorporated changes requested by Andy > - added mutex to struct i2c_piix4_adapdata > - added flag for releasing SMBus index region to struct > i2c_piix4_adapdata > - this flag now indicates that the adapter is a sb800 main > adapter > - together with the port number it simplifies the adapter > releasing and the first patch in v3 is no more needed > - unfortunately patch 3 and 4 in v3 had to be combined as > only > the patch introducing multiplexing adds a separate > add_adapters_sb800 > method that can be used to set the flag. > - fixed releasing the SMBus index region in case setting up the > adapter fails > > v3: > - Incorporated changes requested by Mika and Andy > - main adapter name set to 'main' > - defined constant idx address > - block comment style, joined string literals, reworked for loops > into while loops > > v2: > - Incorporated changes requested by Mika > - remove adapter in reverse order > - ERROR label > - request base address index region only once > > Christian Fetzer (3): > i2c-piix4: Convert piix4_main_adapter to array > i2c-piix4: Add support for multiplexed main adapter in SB800 > i2c-piix4: Add adapter port name support for SB800 chipset > > drivers/i2c/busses/i2c-piix4.c | 194 > +++-- > 1 file changed, 165 insertions(+), 29 deletions(-) > -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/1] x86/platform/iosf_mbi: Remove duplicate definitions
The read and write opcodes are global for all units on SoC and even across
Intel SoCs. Remove duplication of corresponding constants. At the same time
convert all current users.
No functional change.
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: Peter Anvin <h...@zytor.com>
Cc: Wolfram Sang <w...@the-dreams.de>
Cc: Zhang Rui <rui.zh...@intel.com>
Cc: Eduardo Valentin <edubez...@gmail.com>
Cc: Hock Leong Kweh <hock.leong.k...@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
Since v1:
- satisfy kbuild robot
arch/x86/include/asm/iosf_mbi.h | 49 +-
arch/x86/platform/atom/punit_atom_debug.c| 7 +---
arch/x86/platform/intel-quark/imr.c | 28 +
drivers/i2c/busses/i2c-designware-baytrail.c | 17 +++-
drivers/powercap/intel_rapl.c| 10 ++---
drivers/thermal/intel_quark_dts_thermal.c| 61 ++--
drivers/thermal/intel_soc_dts_iosf.c | 43 ++--
7 files changed, 85 insertions(+), 130 deletions(-)
diff --git a/arch/x86/include/asm/iosf_mbi.h b/arch/x86/include/asm/iosf_mbi.h
index b72ad0f..cdc5f63 100644
--- a/arch/x86/include/asm/iosf_mbi.h
+++ b/arch/x86/include/asm/iosf_mbi.h
@@ -1,5 +1,5 @@
/*
- * iosf_mbi.h: Intel OnChip System Fabric MailBox access support
+ * Intel OnChip System Fabric MailBox access support
*/
#ifndef IOSF_MBI_SYMS_H
@@ -16,6 +16,16 @@
#define MBI_MASK_LO0x00FF
#define MBI_ENABLE 0xF0
+/* IOSF SB read/write opcodes */
+#define MBI_MMIO_READ 0x00
+#define MBI_MMIO_WRITE 0x01
+#define MBI_CR_READ0x06
+#define MBI_CR_WRITE 0x07
+#define MBI_REG_READ 0x10
+#define MBI_REG_WRITE 0x11
+#define MBI_ESRAM_READ 0x12
+#define MBI_ESRAM_WRITE0x13
+
/* Baytrail available units */
#define BT_MBI_UNIT_AUNIT 0x00
#define BT_MBI_UNIT_SMC0x01
@@ -28,50 +38,13 @@
#define BT_MBI_UNIT_SATA 0xA3
#define BT_MBI_UNIT_PCIE 0xA6
-/* Baytrail read/write opcodes */
-#define BT_MBI_AUNIT_READ 0x10
-#define BT_MBI_AUNIT_WRITE 0x11
-#define BT_MBI_SMC_READ0x10
-#define BT_MBI_SMC_WRITE 0x11
-#define BT_MBI_CPU_READ0x10
-#define BT_MBI_CPU_WRITE 0x11
-#define BT_MBI_BUNIT_READ 0x10
-#define BT_MBI_BUNIT_WRITE 0x11
-#define BT_MBI_PMC_READ0x06
-#define BT_MBI_PMC_WRITE 0x07
-#define BT_MBI_GFX_READ0x00
-#define BT_MBI_GFX_WRITE 0x01
-#define BT_MBI_SMIO_READ 0x06
-#define BT_MBI_SMIO_WRITE 0x07
-#define BT_MBI_USB_READ0x06
-#define BT_MBI_USB_WRITE 0x07
-#define BT_MBI_SATA_READ 0x00
-#define BT_MBI_SATA_WRITE 0x01
-#define BT_MBI_PCIE_READ 0x00
-#define BT_MBI_PCIE_WRITE 0x01
-
/* Quark available units */
#define QRK_MBI_UNIT_HBA 0x00
#define QRK_MBI_UNIT_HB0x03
#define QRK_MBI_UNIT_RMU 0x04
#define QRK_MBI_UNIT_MM0x05
-#define QRK_MBI_UNIT_MMESRAM 0x05
#define QRK_MBI_UNIT_SOC 0x31
-/* Quark read/write opcodes */
-#define QRK_MBI_HBA_READ 0x10
-#define QRK_MBI_HBA_WRITE 0x11
-#define QRK_MBI_HB_READ0x10
-#define QRK_MBI_HB_WRITE 0x11
-#define QRK_MBI_RMU_READ 0x10
-#define QRK_MBI_RMU_WRITE 0x11
-#define QRK_MBI_MM_READ0x10
-#define QRK_MBI_MM_WRITE 0x11
-#define QRK_MBI_MMESRAM_READ 0x12
-#define QRK_MBI_MMESRAM_WRITE 0x13
-#define QRK_MBI_SOC_READ 0x06
-#define QRK_MBI_SOC_WRITE 0x07
-
#if IS_ENABLED(CONFIG_IOSF_MBI)
bool iosf_mbi_available(void);
diff --git a/arch/x86/platform/atom/punit_atom_debug.c
b/arch/x86/platform/atom/punit_atom_debug.c
index 5ca8ead..81c769e 100644
--- a/arch/x86/platform/atom/punit_atom_debug.c
+++ b/arch/x86/platform/atom/punit_atom_debug.c
@@ -25,8 +25,6 @@
#include
#include
-/* Side band Interface port */
-#define PUNIT_PORT 0x04
/* Power gate status reg */
#define PWRGT_STATUS 0x61
/* Subsystem config/status Video processor */
@@ -85,9 +83,8 @@ static int punit_dev_state_show(struct seq_file *seq_file,
void *unused)
seq_puts(seq_file, "\n\nPUNIT NORTH COMPLEX DEVICES :\n");
while (punit_devp->name) {
- status = iosf_mbi_read(PUNIT_PORT, BT_MBI_PMC_READ,
- punit_devp->reg,
- _pwr_status);
+ status = iosf_mbi_read(BT_MBI_UNIT_PMC, MBI_REG_READ,
+ punit_devp->reg, _pwr_status);
if (status) {
seq_printf(seq_file, "%9s : Read Failed\n",
punit_devp->name);
diff --git a/arch/x86/platform/intel-quark/imr.c
[PATCH v1 1/1] x86/platform/iosf_mbi: Remove duplicate definitions
The read and write opcodes are global for all units on SoC and even across
Intel SoCs. Remove duplication of corresponding constants. At the same time
convert all current users.
No functional change.
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: Peter Anvin <h...@zytor.com>
Cc: Wolfram Sang <w...@the-dreams.de>
Cc: Zhang Rui <rui.zh...@intel.com>
Cc: Eduardo Valentin <edubez...@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
arch/x86/include/asm/iosf_mbi.h | 49 +-
arch/x86/platform/atom/punit_atom_debug.c| 7 +---
drivers/i2c/busses/i2c-designware-baytrail.c | 17 +++-
drivers/powercap/intel_rapl.c| 10 ++---
drivers/thermal/intel_quark_dts_thermal.c| 61 ++--
drivers/thermal/intel_soc_dts_iosf.c | 43 ++--
6 files changed, 75 insertions(+), 112 deletions(-)
diff --git a/arch/x86/include/asm/iosf_mbi.h b/arch/x86/include/asm/iosf_mbi.h
index b72ad0f..cdc5f63 100644
--- a/arch/x86/include/asm/iosf_mbi.h
+++ b/arch/x86/include/asm/iosf_mbi.h
@@ -1,5 +1,5 @@
/*
- * iosf_mbi.h: Intel OnChip System Fabric MailBox access support
+ * Intel OnChip System Fabric MailBox access support
*/
#ifndef IOSF_MBI_SYMS_H
@@ -16,6 +16,16 @@
#define MBI_MASK_LO0x00FF
#define MBI_ENABLE 0xF0
+/* IOSF SB read/write opcodes */
+#define MBI_MMIO_READ 0x00
+#define MBI_MMIO_WRITE 0x01
+#define MBI_CR_READ0x06
+#define MBI_CR_WRITE 0x07
+#define MBI_REG_READ 0x10
+#define MBI_REG_WRITE 0x11
+#define MBI_ESRAM_READ 0x12
+#define MBI_ESRAM_WRITE0x13
+
/* Baytrail available units */
#define BT_MBI_UNIT_AUNIT 0x00
#define BT_MBI_UNIT_SMC0x01
@@ -28,50 +38,13 @@
#define BT_MBI_UNIT_SATA 0xA3
#define BT_MBI_UNIT_PCIE 0xA6
-/* Baytrail read/write opcodes */
-#define BT_MBI_AUNIT_READ 0x10
-#define BT_MBI_AUNIT_WRITE 0x11
-#define BT_MBI_SMC_READ0x10
-#define BT_MBI_SMC_WRITE 0x11
-#define BT_MBI_CPU_READ0x10
-#define BT_MBI_CPU_WRITE 0x11
-#define BT_MBI_BUNIT_READ 0x10
-#define BT_MBI_BUNIT_WRITE 0x11
-#define BT_MBI_PMC_READ0x06
-#define BT_MBI_PMC_WRITE 0x07
-#define BT_MBI_GFX_READ0x00
-#define BT_MBI_GFX_WRITE 0x01
-#define BT_MBI_SMIO_READ 0x06
-#define BT_MBI_SMIO_WRITE 0x07
-#define BT_MBI_USB_READ0x06
-#define BT_MBI_USB_WRITE 0x07
-#define BT_MBI_SATA_READ 0x00
-#define BT_MBI_SATA_WRITE 0x01
-#define BT_MBI_PCIE_READ 0x00
-#define BT_MBI_PCIE_WRITE 0x01
-
/* Quark available units */
#define QRK_MBI_UNIT_HBA 0x00
#define QRK_MBI_UNIT_HB0x03
#define QRK_MBI_UNIT_RMU 0x04
#define QRK_MBI_UNIT_MM0x05
-#define QRK_MBI_UNIT_MMESRAM 0x05
#define QRK_MBI_UNIT_SOC 0x31
-/* Quark read/write opcodes */
-#define QRK_MBI_HBA_READ 0x10
-#define QRK_MBI_HBA_WRITE 0x11
-#define QRK_MBI_HB_READ0x10
-#define QRK_MBI_HB_WRITE 0x11
-#define QRK_MBI_RMU_READ 0x10
-#define QRK_MBI_RMU_WRITE 0x11
-#define QRK_MBI_MM_READ0x10
-#define QRK_MBI_MM_WRITE 0x11
-#define QRK_MBI_MMESRAM_READ 0x12
-#define QRK_MBI_MMESRAM_WRITE 0x13
-#define QRK_MBI_SOC_READ 0x06
-#define QRK_MBI_SOC_WRITE 0x07
-
#if IS_ENABLED(CONFIG_IOSF_MBI)
bool iosf_mbi_available(void);
diff --git a/arch/x86/platform/atom/punit_atom_debug.c
b/arch/x86/platform/atom/punit_atom_debug.c
index 5ca8ead..81c769e 100644
--- a/arch/x86/platform/atom/punit_atom_debug.c
+++ b/arch/x86/platform/atom/punit_atom_debug.c
@@ -25,8 +25,6 @@
#include
#include
-/* Side band Interface port */
-#define PUNIT_PORT 0x04
/* Power gate status reg */
#define PWRGT_STATUS 0x61
/* Subsystem config/status Video processor */
@@ -85,9 +83,8 @@ static int punit_dev_state_show(struct seq_file *seq_file,
void *unused)
seq_puts(seq_file, "\n\nPUNIT NORTH COMPLEX DEVICES :\n");
while (punit_devp->name) {
- status = iosf_mbi_read(PUNIT_PORT, BT_MBI_PMC_READ,
- punit_devp->reg,
- _pwr_status);
+ status = iosf_mbi_read(BT_MBI_UNIT_PMC, MBI_REG_READ,
+ punit_devp->reg, _pwr_status);
if (status) {
seq_printf(seq_file, "%9s : Read Failed\n",
punit_devp->name);
diff --git a/drivers/i2c/busses/i2c-designware-baytrail.c
b/drivers/i2c/busses/i2c-designware-baytrail.c
index 7d7ae97..e38c2bb 100644
--- a/drivers/i2c/busses/i2c-designware-baytrail.c
+++ b/drivers
Re: [PATCH v4 5/5] pwm-pca9685: enable ACPI device found on Galileo Gen2
On Fri, 2015-10-23 at 12:16 +0300, Andy Shevchenko wrote:
> There is a chip connected to i2c bus on Intel Galileo Gen2 board.
> Enable it via
> ACPI ID INT3492.
Thierry, ping?
>
> Cc: Thierry Reding <thierry.red...@gmail.com>
> Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
> ---
> drivers/pwm/Kconfig | 2 +-
> drivers/pwm/pwm-pca9685.c | 20
> 2 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 062630a..bb114ef 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -242,7 +242,7 @@ config PWM_MXS
>
> config PWM_PCA9685
> tristate "NXP PCA9685 PWM driver"
> - depends on OF && I2C
> + depends on I2C
> select REGMAP_I2C
> help
> Generic PWM framework driver for NXP PCA9685 LED
> controller.
> diff --git a/drivers/pwm/pwm-pca9685.c b/drivers/pwm/pwm-pca9685.c
> index 70448a6..117fccf 100644
> --- a/drivers/pwm/pwm-pca9685.c
> +++ b/drivers/pwm/pwm-pca9685.c
> @@ -19,9 +19,11 @@
> * this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> +#include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -297,7 +299,6 @@ static const struct regmap_config
> pca9685_regmap_i2c_config = {
> static int pca9685_pwm_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> - struct device_node *np = client->dev.of_node;
> struct pca9685 *pca;
> int ret;
> int mode2;
> @@ -320,12 +321,12 @@ static int pca9685_pwm_probe(struct i2c_client
> *client,
>
> regmap_read(pca->regmap, PCA9685_MODE2, );
>
> - if (of_property_read_bool(np, "invert"))
> + if (device_property_read_bool(>dev, "invert"))
> mode2 |= MODE2_INVRT;
> else
> mode2 &= ~MODE2_INVRT;
>
> - if (of_property_read_bool(np, "open-drain"))
> + if (device_property_read_bool(>dev, "open-drain"))
> mode2 &= ~MODE2_OUTDRV;
> else
> mode2 |= MODE2_OUTDRV;
> @@ -363,16 +364,27 @@ static const struct i2c_device_id pca9685_id[]
> = {
> };
> MODULE_DEVICE_TABLE(i2c, pca9685_id);
>
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id pca9685_acpi_ids[] = {
> + { "INT3492", 0 },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(acpi, pca9685_acpi_ids);
> +#endif
> +
> +#ifdef CONFIG_OF
> static const struct of_device_id pca9685_dt_ids[] = {
> { .compatible = "nxp,pca9685-pwm", },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, pca9685_dt_ids);
> +#endif
>
> static struct i2c_driver pca9685_i2c_driver = {
> .driver = {
> .name = "pca9685-pwm",
> - .of_match_table = pca9685_dt_ids,
> + .acpi_match_table = ACPI_PTR(pca9685_acpi_ids),
> + .of_match_table = of_match_ptr(pca9685_dt_ids),
> },
> .probe = pca9685_pwm_probe,
> .remove = pca9685_pwm_remove,
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] i2c: mediatek: add i2c first write then read optimization
On Mon, Nov 9, 2015 at 7:43 AM, Liguo Zhang <liguo.zh...@mediatek.com> wrote:
> For platform with auto restart support, between every transfer,
> i2c controller will trigger an interrupt and SW need to handle
> it to start new transfer. When doing write-then-read transfer,
> instead of restart mechanism, using WRRD mode to have controller
> send both transfer in one request to reduce latency.
> @@ -518,6 +529,16 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
> if (ret)
> return ret;
>
> + i2c->auto_restart = i2c->dev_comp->auto_restart;
> +
> + /* checking if we can skip restart and optimize using WRRD mode */
> + if (i2c->auto_restart && num == 2) {
> + if (!(msgs[0].flags & I2C_M_RD) && (msgs[1].flags & I2C_M_RD)
> &&
> + msgs[0].addr == msgs[1].addr) {
Nitpick (optional):
((msgs[0].flags & msgs[1].flags) & I2C_M_RD)
?
> + i2c->auto_restart = 0;
> + }
> + }
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/5] i2c-piix4: Request base address index region once for SB800
On Sat, 2015-11-07 at 12:35 +0100, Christian Fetzer wrote:
> Request the SMBus base address index region once in piix4_probe. This
> is particularly useful when using the multiplexed adapter in SB800 as
> it avoids requesting and releasing the region on every transfer.
>
> Signed-off-by: Christian Fetzer <fetzer...@gmail.com>
> ---
> drivers/i2c/busses/i2c-piix4.c | 37 --
> ---
> 1 file changed, 24 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-
> piix4.c
> index 0e4ae60..67ada1e 100644
> --- a/drivers/i2c/busses/i2c-piix4.c
> +++ b/drivers/i2c/busses/i2c-piix4.c
> @@ -78,6 +78,9 @@
> /* Multi-port constants */
> #define PIIX4_MAX_ADAPTERS 4
>
> +/* SB800 constants */
> +#define SB800_PIIX4_SMB_IDX 0xCD6
Small letters for value?
> +
> /* insmod parameters */
>
> /* If force is set to anything different from 0, we forcibly enable
> the
> @@ -125,6 +128,9 @@ static const struct dmi_system_id piix4_dmi_ibm[]
> = {
> { },
> };
>
> +/* SB800 globals */
> +static bool piix4_smb_idx_sb800;
> +
By the way, could it be part of driver data, i.e. member of struct
i2c_piix4_adapdata?
>
> struct i2c_piix4_adapdata {
> unsigned short smba;
> };
> @@ -232,7 +238,6 @@ static int piix4_setup_sb800(struct pci_dev
> *PIIX4_dev,
> const struct pci_device_id *id, u8 aux)
> {
> unsigned short piix4_smba;
> - unsigned short smba_idx = 0xcd6;
> u8 smba_en_lo, smba_en_hi, smb_en, smb_en_status;
> u8 i2ccfg, i2ccfg_offset = 0x10;
>
> @@ -254,16 +259,10 @@ static int piix4_setup_sb800(struct pci_dev
> *PIIX4_dev,
> else
> smb_en = (aux) ? 0x28 : 0x2c;
>
> - if (!request_region(smba_idx, 2, "smba_idx")) {
> - dev_err(_dev->dev, "SMBus base address index
> region "
> - "0x%x already in use!\n", smba_idx);
> - return -EBUSY;
> - }
> - outb_p(smb_en, smba_idx);
> - smba_en_lo = inb_p(smba_idx + 1);
> - outb_p(smb_en + 1, smba_idx);
> - smba_en_hi = inb_p(smba_idx + 1);
> - release_region(smba_idx, 2);
> + outb_p(smb_en, SB800_PIIX4_SMB_IDX);
> + smba_en_lo = inb_p(SB800_PIIX4_SMB_IDX + 1);
> + outb_p(smb_en + 1, SB800_PIIX4_SMB_IDX);
> + smba_en_hi = inb_p(SB800_PIIX4_SMB_IDX + 1);
>
> if (!smb_en) {
> smb_en_status = smba_en_lo & 0x10;
> @@ -621,11 +620,20 @@ static int piix4_probe(struct pci_dev *dev,
> const struct pci_device_id *id)
> if ((dev->vendor == PCI_VENDOR_ID_ATI &&
> dev->device == PCI_DEVICE_ID_ATI_SBX00_SMBUS &&
> dev->revision >= 0x40) ||
> - dev->vendor == PCI_VENDOR_ID_AMD)
> + dev->vendor == PCI_VENDOR_ID_AMD) {
> + if (!request_region(SB800_PIIX4_SMB_IDX, 2,
> "smba_idx")) {
> + dev_err(>dev,
> + "SMBus base address index region 0x%x
> already in use!\n",
> + SB800_PIIX4_SMB_IDX);
> + return -EBUSY;
> + }
> + piix4_smb_idx_sb800 = true;
> +
> /* base address location etc changed in SB800 */
> retval = piix4_setup_sb800(dev, id, 0);
> - else
> + } else {
> retval = piix4_setup(dev, id);
> + }
>
> /* If no main SMBus found, give up */
> if (retval < 0)
> @@ -692,6 +700,9 @@ static void piix4_remove(struct pci_dev *dev)
> piix4_adap_remove(piix4_aux_adapter, true);
> piix4_aux_adapter = NULL;
> }
> +
> + if (piix4_smb_idx_sb800)
> + release_region(SB800_PIIX4_SMB_IDX, 2);
> }
>
> static struct pci_driver piix4_driver = {
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/5] i2c-piix4: Add support for multiplexed main adapter in SB800
+ int retval;
> + struct i2c_piix4_adapdata *adapdata;
These lines better to exchange.
> +
> + for (port = 0; port < PIIX4_MAX_ADAPTERS; port++) {
> + retval = piix4_add_adapter(dev, smba,
> + _main_adapters[port
> ]);
> + if (retval < 0)
> + goto error;
> +
> + piix4_main_adapters[port]->algo =
> _smbus_algorithm_sb800;
> +
> + adapdata =
> i2c_get_adapdata(piix4_main_adapters[port]);
> + adapdata->port = port;
> + }
> +
> + return retval;
> +
> +error:
> + dev_err(>dev,
> + "Error setting up SB800 adapters.
> Unregistering!\n");
> + while (--port >= 0) {
> + adapdata =
> i2c_get_adapdata(piix4_main_adapters[port]);
> + if (adapdata->smba) {
> + i2c_del_adapter(piix4_main_adapters[port]);
> + kfree(adapdata);
> + kfree(piix4_main_adapters[port]);
> + piix4_main_adapters[port] = NULL;
> + }
> + }
> +
> + return retval;
> +}
> +
> static int piix4_probe(struct pci_dev *dev, const struct
> pci_device_id *id)
> {
> int retval;
> @@ -631,19 +717,28 @@ static int piix4_probe(struct pci_dev *dev,
> const struct pci_device_id *id)
>
> /* base address location etc changed in SB800 */
> retval = piix4_setup_sb800(dev, id, 0);
> + if (retval < 0)
> + return retval;
> +
> + /*
> + * Try to register multiplexed main SMBus adapter,
> + * give up if we can't
> + */
> + retval = piix4_add_adapters_sb800(dev, retval);
> } else {
> retval = piix4_setup(dev, id);
> + if (retval < 0)
> + return retval;
> +
> + /* Try to register main SMBus adapter, give up if we
> can't */
> + retval = piix4_add_adapter(dev, retval,
> + _main_adapters[0]);
> }
>
> /* If no main SMBus found, give up */
> if (retval < 0)
> return retval;
>
> - /* Try to register main SMBus adapter, give up if we can't
> */
> - retval = piix4_add_adapter(dev, retval,
> _main_adapters[0]);
> - if (retval < 0)
> - return retval;
> -
> /* Check for auxiliary SMBus on some AMD chipsets */
> retval = -ENODEV;
>
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [MinnowBoard] Linux x86 I2C device probing with ACPI
On Sun, 2015-11-01 at 22:37 +0100, Christophe Ricard wrote: > Hi Mika, > > Sorry for the delay. > After forcing _STA method to return 0xF You mean you able to fix firmware? Great! > and moving NFC1 node into > Scope(I2C7) node the probing went through. This one is not required anymore since commit 166c2ba398640278ae6037be4aa5562c03cf3d24 Author: Mika Westerberg <mika.westerb...@linux.intel.com> Date: Wed Oct 7 13:18:44 2015 +0300 i2c / ACPI: Rework I2C device scanning -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] i2c-piix4: Convert piix4_main_adapter to array
On Sun, 2015-11-01 at 17:32 +0100, Christian Fetzer wrote:
> The SB800 chipset supports a multiplexed main SMBus controller with
> four ports. Therefore the static variable piix4_main_adapter is
> converted into a piix4_main_adapters array that can hold one
> i2c_adapter for each multiplexed port.
>
> The auxiliary adapter remains unchanged since it represents the
> second
> (not multiplexed) SMBus controller on the SB800 chipset.
> @@ -675,9 +678,14 @@ static void piix4_adap_remove(struct i2c_adapter
> *adap, int free_smba)
>
> static void piix4_remove(struct pci_dev *dev)
> {
> - if (piix4_main_adapter) {
> - piix4_adap_remove(piix4_main_adapter, 1);
> - piix4_main_adapter = NULL;
> + int port;
> +
> + for (port = PIIX4_MAX_ADAPTERS - 1; port >= 0; port--) {
> + if (piix4_main_adapters[port]) {
> + piix4_adap_remove(piix4_main_adapters[port],
> + port == 0);
> + piix4_main_adapters[port] = NULL;
> + }
> }
Would it be
int port = PIIX4_MAX_ADAPTERS;
while (--port) {
if (…) {…}
}
?
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/5] i2c-piix4: Request base address index region once for SB800
On Sun, 2015-11-01 at 17:32 +0100, Christian Fetzer wrote:
> Request the SMBus base address index region once in piix4_probe. This
> is particularly useful when using the multiplexed adapter in SB800 as
> it avoids requesting and releasing the region on every transfer.
> @@ -616,16 +612,26 @@ static int piix4_add_adapter(struct pci_dev
> *dev, unsigned short smba,
>
> static int piix4_probe(struct pci_dev *dev, const struct
> pci_device_id *id)
> {
> + unsigned short smba_idx = 0xcd6;
> int retval;
>
> if ((dev->vendor == PCI_VENDOR_ID_ATI &&
> dev->device == PCI_DEVICE_ID_ATI_SBX00_SMBUS &&
> dev->revision >= 0x40) ||
> - dev->vendor == PCI_VENDOR_ID_AMD)
> + dev->vendor == PCI_VENDOR_ID_AMD) {
> +
Redundant empty line.
> + if (!request_region(smba_idx, 2, "smba_idx")) {
> + dev_err(>dev, "SMBus base address index
> region "
> + "0x%x already in use!\n", smba_idx);
Do not split string literals, something like following will be okay.
dev_err(>dev,
"SMBus base address index region 0x%x already in use!\n",
smba_idx);
> + return -EBUSY;
> + }
> + piix4_smb_idx_sb800 = smba_idx;
> +
> /* base address location etc changed in SB800 */
> retval = piix4_setup_sb800(dev, id, 0);
> - else
> + } else {
> retval = piix4_setup(dev, id);
> + }
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/5] i2c-piix4: Add support for multiplexed main adapter in SB800
On Sun, 2015-11-01 at 17:32 +0100, Christian Fetzer wrote:
> The SB800 chipset supports a multiplexed main SMBus controller with
> four ports. The multiplexed ports share the same SMBus address and
> register set. The port is selected by bits 2:1 of the smb_en register
> (0x2C).
>
> Only one port can be active at any point in time therefore a mutex is
> needed in order to synchronize access.
>
> Tested on HP ProLiant MicroServer G7 N54L (where this patch adds
> support to access sensor data from the w83795adg).
>
> +static int piix4_add_adapters_sb800(struct pci_dev *dev, unsigned
> short smba)
> +{
> + unsigned short port;
> + int retval;
> + struct i2c_piix4_adapdata *adapdata;
> +
> + for (port = 0; port < PIIX4_MAX_ADAPTERS; port++) {
> + retval = piix4_add_adapter(dev, smba,
> + _main_adapters[port
> ]);
> + if (retval < 0)
> + goto error;
> +
> + piix4_main_adapters[port]->algo =
> _smbus_algorithm_sb800;
> +
> + adapdata =
> i2c_get_adapdata(piix4_main_adapters[port]);
> + adapdata->port = port;
> + }
> +
> + return retval;
> +
> +error:
> + dev_err(>dev, "Error setting up SB800 adapters. "
> + "Unregistering all adapters!\n");
This one Mika told already about.
You might use as well
dev_err(>dev,
"…\n")
> + for (port--; port >= 0; port--) {
Isn't look complicated? Like I comment in one of previous patches:
while (--port) {
> + adapdata =
> i2c_get_adapdata(piix4_main_adapters[port]);
> + if (adapdata->smba) {
> + i2c_del_adapter(piix4_main_adapters[port]);
> + kfree(adapdata);
> + kfree(piix4_main_adapters[port]);
> + piix4_main_adapters[port] = NULL;
> + }
> + }
> +
> + return retval;
> +}
> +
> static int piix4_probe(struct pci_dev *dev, const struct
> pci_device_id *id)
> {
> unsigned short smba_idx = 0xcd6;
> @@ -629,19 +714,26 @@ static int piix4_probe(struct pci_dev *dev,
> const struct pci_device_id *id)
>
> /* base address location etc changed in SB800 */
> retval = piix4_setup_sb800(dev, id, 0);
> + if (retval < 0)
> + return retval;
> +
> + /* Try to register multiplexed main SMBus adapter,
> + * give up if we can't */
Block comment
/*
* text1
* text2
*/
> + retval = piix4_add_adapters_sb800(dev, retval);
> } else {
> retval = piix4_setup(dev, id);
> + if (retval < 0)
> + return retval;
> +
> + /* Try to register main SMBus adapter, give up if we
> can't */
> + retval = piix4_add_adapter(dev, retval,
> + _main_adapters[0]);
> }
>
> /* If no main SMBus found, give up */
> if (retval < 0)
> return retval;
>
> - /* Try to register main SMBus adapter, give up if we can't
> */
> - retval = piix4_add_adapter(dev, retval,
> _main_adapters[0]);
> - if (retval < 0)
> - return retval;
> -
> /* Check for auxiliary SMBus on some AMD chipsets */
> retval = -ENODEV;
>
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/5] i2c-piix4: Add adapter port name support for SB800 chipset
On Sun, 2015-11-01 at 17:32 +0100, Christian Fetzer wrote:
> This patch adds support for port names for the SB800 chipset.
> Since the chipset supports a multiplexed main SMBus controller,
> adding
> the channel name to the adapter name is necessary to differentiate
> the
> ports better (for example in sensors output).
> +static const char *piix4_main_port_names_sb800[4] = {
Would it be constant you defined instead of magic number?
> + "SDA0", "SDA2", "SDA3", "SDA4"
> +};
> +static const char *piix4_aux_port_name_sb800 = "SDA1";
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] enable I2C devices behind I2C bus on Gen2
On Fri, Oct 30, 2015 at 8:54 PM, Lee Jones <lee.jo...@linaro.org> wrote: > On Wed, 21 Oct 2015, Andy Shevchenko wrote: > >> On Wed, 2015-10-07 at 13:18 +0300, Andy Shevchenko wrote: >> > There is a board in the wild, i.e. Intel Galileo Gen2, that has ACPI >> > enumerated >> > devices behind I2C bus. >> >> Lee, since Wolfram is going to apply patches 1 and 5, how could we >> proceed with the rest? Patches are indeed build independent, though >> they are unified by enabling logically piece-by-piece. It would be >> great if you think you may apply them to your v4.4 queue. > > So we're just waiting for Thierry's Ack now, right? That's right. Either Ack, or he might apply patch by himself. It wouldn't be harmful in any case. -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/5] mfd: intel_quark_i2c_gpio: support devices behind i2c bus
On Intel Galileo Gen2 the GPIO expanders are connected to the i2c bus. For
those devices the ACPI table has specific parameters that refer to an actual
i2c host controller. Since MFD now copes with that specific configuration we
have to provide a necessary information how to distinguish devices in ACPI
namespace. Here the _ADR values are provided.
Acked-by: Lee Jones <lee.jo...@linaro.org>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/mfd/intel_quark_i2c_gpio.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
b/drivers/mfd/intel_quark_i2c_gpio.c
index 958c134..0421374 100644
--- a/drivers/mfd/intel_quark_i2c_gpio.c
+++ b/drivers/mfd/intel_quark_i2c_gpio.c
@@ -31,6 +31,10 @@
#define MFD_I2C_BAR0
#define MFD_GPIO_BAR 1
+/* ACPI _ADR value to match the child node */
+#define MFD_ACPI_MATCH_GPIO0ULL
+#define MFD_ACPI_MATCH_I2C 1ULL
+
/* The base GPIO number under GPIOLIB framework */
#define INTEL_QUARK_MFD_GPIO_BASE 8
@@ -82,16 +86,25 @@ static struct resource intel_quark_i2c_res[] = {
},
};
+static struct mfd_cell_acpi_match intel_quark_acpi_match_i2c = {
+ .adr = MFD_ACPI_MATCH_I2C,
+};
+
static struct resource intel_quark_gpio_res[] = {
[INTEL_QUARK_IORES_MEM] = {
.flags = IORESOURCE_MEM,
},
};
+static struct mfd_cell_acpi_match intel_quark_acpi_match_gpio = {
+ .adr = MFD_ACPI_MATCH_GPIO,
+};
+
static struct mfd_cell intel_quark_mfd_cells[] = {
{
.id = MFD_GPIO_BAR,
.name = "gpio-dwapb",
+ .acpi_match = _quark_acpi_match_gpio,
.num_resources = ARRAY_SIZE(intel_quark_gpio_res),
.resources = intel_quark_gpio_res,
.ignore_resource_conflicts = true,
@@ -99,6 +112,7 @@ static struct mfd_cell intel_quark_mfd_cells[] = {
{
.id = MFD_I2C_BAR,
.name = "i2c_designware",
+ .acpi_match = _quark_acpi_match_i2c,
.num_resources = ARRAY_SIZE(intel_quark_i2c_res),
.resources = intel_quark_i2c_res,
.ignore_resource_conflicts = true,
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/5] mfd: core: redo ACPI matching of the children devices
There is at least one board on the market, i.e. Intel Galileo Gen2, that uses
_ADR to distinguish the devices under one actual device. Due to this we have to
improve the quirk in the MFD core to handle that board.
Acked-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Acked-by: Lee Jones <lee.jo...@linaro.org>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
Documentation/acpi/enumeration.txt | 11 +---
drivers/mfd/mfd-core.c | 52 ++
include/linux/mfd/core.h | 10 ++--
3 files changed, 52 insertions(+), 21 deletions(-)
diff --git a/Documentation/acpi/enumeration.txt
b/Documentation/acpi/enumeration.txt
index b731b29..a91ec5a 100644
--- a/Documentation/acpi/enumeration.txt
+++ b/Documentation/acpi/enumeration.txt
@@ -347,13 +347,18 @@ For the first case, the MFD drivers do not need to do
anything. The
resulting child platform device will have its ACPI_COMPANION() set to point
to the parent device.
-If the ACPI namespace has a device that we can match using an ACPI id,
-the id should be set like:
+If the ACPI namespace has a device that we can match using an ACPI id or ACPI
+adr, the cell should be set like:
+
+ static struct mfd_cell_acpi_match my_subdevice_cell_acpi_match = {
+ .pnpid = "XYZ0001",
+ .adr = 0,
+ };
static struct mfd_cell my_subdevice_cell = {
.name = "my_subdevice",
/* set the resources relative to the parent */
- .acpi_pnpid = "XYZ0001",
+ .acpi_match = _subdevice_cell_acpi_match,
};
The ACPI id "XYZ0001" is then used to lookup an ACPI device directly under
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index c17635d..60b60dc 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -82,29 +82,49 @@ static int mfd_platform_add_cell(struct platform_device
*pdev,
static void mfd_acpi_add_device(const struct mfd_cell *cell,
struct platform_device *pdev)
{
- struct acpi_device *parent_adev;
+ const struct mfd_cell_acpi_match *match = cell->acpi_match;
+ struct acpi_device *parent, *child;
struct acpi_device *adev;
- parent_adev = ACPI_COMPANION(pdev->dev.parent);
- if (!parent_adev)
+ parent = ACPI_COMPANION(pdev->dev.parent);
+ if (!parent)
return;
/*
-* MFD child device gets its ACPI handle either from the ACPI
-* device directly under the parent that matches the acpi_pnpid or
-* it will use the parent handle if is no acpi_pnpid is given.
+* MFD child device gets its ACPI handle either from the ACPI device
+* directly under the parent that matches the either _HID or _CID, or
+* _ADR or it will use the parent handle if is no ID is given.
+*
+* Note that use of _ADR is a grey area in the ACPI specification,
+* though Intel Galileo Gen2 is using it to distinguish the children
+* devices.
*/
- adev = parent_adev;
- if (cell->acpi_pnpid) {
- struct acpi_device_id ids[2] = {};
- struct acpi_device *child_adev;
-
- strlcpy(ids[0].id, cell->acpi_pnpid, sizeof(ids[0].id));
- list_for_each_entry(child_adev, _adev->children, node)
- if (acpi_match_device_ids(child_adev, ids)) {
- adev = child_adev;
- break;
+ adev = parent;
+ if (match) {
+ if (match->pnpid) {
+ struct acpi_device_id ids[2] = {};
+
+ strlcpy(ids[0].id, match->pnpid, sizeof(ids[0].id));
+ list_for_each_entry(child, >children, node) {
+ if (acpi_match_device_ids(child, ids)) {
+ adev = child;
+ break;
+ }
+ }
+ } else {
+ unsigned long long adr;
+ acpi_status status;
+
+ list_for_each_entry(child, >children, node) {
+ status = acpi_evaluate_integer(child->handle,
+ "_ADR", NULL,
+ );
+ if (ACPI_SUCCESS(status) && match->adr == adr) {
+ adev = child;
+ break;
+ }
}
+ }
}
ACPI_COMPANION_SET(>dev, adev);
diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
index
[PATCH v4 4/5] at24: enable ACPI device found on Galileo Gen2
There is a 24c08 chip connected to i2c bus on Intel Galileo Gen2 board. Enable
it via ACPI ID INT3499.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/misc/eeprom/at24.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index c6cb7f8..5d7c090 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -131,6 +132,12 @@ static const struct i2c_device_id at24_ids[] = {
};
MODULE_DEVICE_TABLE(i2c, at24_ids);
+static const struct acpi_device_id at24_acpi_ids[] = {
+ { "INT3499", AT24_DEVICE_MAGIC(8192 / 8, 0) },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, at24_acpi_ids);
+
/*-*/
/*
@@ -467,21 +474,29 @@ static void at24_get_ofdata(struct i2c_client *client,
static int at24_probe(struct i2c_client *client, const struct i2c_device_id
*id)
{
struct at24_platform_data chip;
+ kernel_ulong_t magic = 0;
bool writable;
int use_smbus = 0;
int use_smbus_write = 0;
struct at24_data *at24;
int err;
unsigned i, num_addresses;
- kernel_ulong_t magic;
if (client->dev.platform_data) {
chip = *(struct at24_platform_data *)client->dev.platform_data;
} else {
- if (!id->driver_data)
+ if (id) {
+ magic = id->driver_data;
+ } else {
+ const struct acpi_device_id *aid;
+
+ aid = acpi_match_device(at24_acpi_ids, >dev);
+ if (aid)
+ magic = aid->driver_data;
+ }
+ if (!magic)
return -ENODEV;
- magic = id->driver_data;
chip.byte_len = BIT(magic & AT24_BITMASK(AT24_SIZE_BYTELEN));
magic >>= AT24_SIZE_BYTELEN;
chip.flags = magic & AT24_BITMASK(AT24_SIZE_FLAGS);
@@ -661,6 +676,7 @@ static int at24_remove(struct i2c_client *client)
static struct i2c_driver at24_driver = {
.driver = {
.name = "at24",
+ .acpi_match_table = ACPI_PTR(at24_acpi_ids),
},
.probe = at24_probe,
.remove = at24_remove,
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/5] enable I2C devices behind I2C bus on Gen2
On Fri, 2015-10-23 at 14:38 +0200, Wolfram Sang wrote: > > Wolfram, since Lee acknowledged patches 1-3, can you pull them to > > your tree? > > So, I picked patches 1-4 to my for-next. Patch 5 is missing an ACK. Right. Thanks! -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/5] enable I2C devices behind I2C bus on Gen2
There is a board in the wild, i.e. Intel Galileo Gen2, that has ACPI enumerated devices behind I2C bus. This patch series dedicated to enable those devices. The MFD framework is also updated to cope with interesting implementation of the cell descriptions under ACPI MFD (patch 1). The patches 5 and 6 are pretty independent and could be applied ahead, though they don't make much sense without previous ones. Wolfram, since Lee acknowledged patches 1-3, can you pull them to your tree? Tested on the actual Intel Galileo Gen2 by Ismo (gpio expanders) and me (at24). Cc: Thierry Reding <thierry.red...@gmail.com> Changelog v4: - amend at24 patch to satisfy sparse (Wolfram) - drop applied patches Changelog v3: - append ACKs from Rafael (from ACPI angle) - drop upstreamed patches (GPIO pca953x) Changelog v2: - append tags - re-make patch 3 (suggested by Lee) - improve patch 8 (suggested by Thierry) Andy Shevchenko (5): mfd: core: redo ACPI matching of the children devices mfd: intel_quark_i2c_gpio: load gpio driver first mfd: intel_quark_i2c_gpio: support devices behind i2c bus at24: enable ACPI device found on Galileo Gen2 pwm-pca9685: enable ACPI device found on Galileo Gen2 Documentation/acpi/enumeration.txt | 11 +--- drivers/mfd/intel_quark_i2c_gpio.c | 33 drivers/mfd/mfd-core.c | 52 ++ drivers/misc/eeprom/at24.c | 22 +--- drivers/pwm/Kconfig| 2 +- drivers/pwm/pwm-pca9685.c | 20 --- include/linux/mfd/core.h | 10 ++-- 7 files changed, 111 insertions(+), 39 deletions(-) -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/5] mfd: intel_quark_i2c_gpio: load gpio driver first
On Intel Galileo boards the GPIO expander is connected to i2c bus. Moreover it
is able to generate interrupt, but interrupt line is connected to GPIO. That's
why we have to have GPIO driver in place when we will probe i2c host with
device connected to it.
Acked-by: Lee Jones <lee.jo...@linaro.org>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/mfd/intel_quark_i2c_gpio.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
b/drivers/mfd/intel_quark_i2c_gpio.c
index 1ce1603..958c134 100644
--- a/drivers/mfd/intel_quark_i2c_gpio.c
+++ b/drivers/mfd/intel_quark_i2c_gpio.c
@@ -90,19 +90,19 @@ static struct resource intel_quark_gpio_res[] = {
static struct mfd_cell intel_quark_mfd_cells[] = {
{
- .id = MFD_I2C_BAR,
- .name = "i2c_designware",
- .num_resources = ARRAY_SIZE(intel_quark_i2c_res),
- .resources = intel_quark_i2c_res,
- .ignore_resource_conflicts = true,
- },
- {
.id = MFD_GPIO_BAR,
.name = "gpio-dwapb",
.num_resources = ARRAY_SIZE(intel_quark_gpio_res),
.resources = intel_quark_gpio_res,
.ignore_resource_conflicts = true,
},
+ {
+ .id = MFD_I2C_BAR,
+ .name = "i2c_designware",
+ .num_resources = ARRAY_SIZE(intel_quark_i2c_res),
+ .resources = intel_quark_i2c_res,
+ .ignore_resource_conflicts = true,
+ },
};
static const struct pci_device_id intel_quark_mfd_ids[] = {
@@ -248,12 +248,11 @@ static int intel_quark_mfd_probe(struct pci_dev *pdev,
dev_set_drvdata(>dev, quark_mfd);
- ret = intel_quark_i2c_setup(pdev, _quark_mfd_cells[MFD_I2C_BAR]);
+ ret = intel_quark_i2c_setup(pdev, _quark_mfd_cells[1]);
if (ret)
return ret;
- ret = intel_quark_gpio_setup(pdev,
-_quark_mfd_cells[MFD_GPIO_BAR]);
+ ret = intel_quark_gpio_setup(pdev, _quark_mfd_cells[0]);
if (ret)
return ret;
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 5/5] pwm-pca9685: enable ACPI device found on Galileo Gen2
There is a chip connected to i2c bus on Intel Galileo Gen2 board. Enable it via
ACPI ID INT3492.
Cc: Thierry Reding <thierry.red...@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/pwm/Kconfig | 2 +-
drivers/pwm/pwm-pca9685.c | 20
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 062630a..bb114ef 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -242,7 +242,7 @@ config PWM_MXS
config PWM_PCA9685
tristate "NXP PCA9685 PWM driver"
- depends on OF && I2C
+ depends on I2C
select REGMAP_I2C
help
Generic PWM framework driver for NXP PCA9685 LED controller.
diff --git a/drivers/pwm/pwm-pca9685.c b/drivers/pwm/pwm-pca9685.c
index 70448a6..117fccf 100644
--- a/drivers/pwm/pwm-pca9685.c
+++ b/drivers/pwm/pwm-pca9685.c
@@ -19,9 +19,11 @@
* this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include
#include
#include
#include
+#include
#include
#include
#include
@@ -297,7 +299,6 @@ static const struct regmap_config pca9685_regmap_i2c_config
= {
static int pca9685_pwm_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- struct device_node *np = client->dev.of_node;
struct pca9685 *pca;
int ret;
int mode2;
@@ -320,12 +321,12 @@ static int pca9685_pwm_probe(struct i2c_client *client,
regmap_read(pca->regmap, PCA9685_MODE2, );
- if (of_property_read_bool(np, "invert"))
+ if (device_property_read_bool(>dev, "invert"))
mode2 |= MODE2_INVRT;
else
mode2 &= ~MODE2_INVRT;
- if (of_property_read_bool(np, "open-drain"))
+ if (device_property_read_bool(>dev, "open-drain"))
mode2 &= ~MODE2_OUTDRV;
else
mode2 |= MODE2_OUTDRV;
@@ -363,16 +364,27 @@ static const struct i2c_device_id pca9685_id[] = {
};
MODULE_DEVICE_TABLE(i2c, pca9685_id);
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id pca9685_acpi_ids[] = {
+ { "INT3492", 0 },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(acpi, pca9685_acpi_ids);
+#endif
+
+#ifdef CONFIG_OF
static const struct of_device_id pca9685_dt_ids[] = {
{ .compatible = "nxp,pca9685-pwm", },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, pca9685_dt_ids);
+#endif
static struct i2c_driver pca9685_i2c_driver = {
.driver = {
.name = "pca9685-pwm",
- .of_match_table = pca9685_dt_ids,
+ .acpi_match_table = ACPI_PTR(pca9685_acpi_ids),
+ .of_match_table = of_match_ptr(pca9685_dt_ids),
},
.probe = pca9685_pwm_probe,
.remove = pca9685_pwm_remove,
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] i2c: core: fix a code to suppress a warning
On Fri, 2015-09-18 at 14:06 +0300, Andy Shevchenko wrote:
> There is a warning when compiling i2c-core.c
> drivers/i2c/i2c-core.c:2561:36: warning: dubious: x | !y
>
> Fix it by using a plain bitwise AND since I2C_M_RD is a bit 0 and
> thus we are
> on the safe side.
Wolfram, as of today I didn't see this in linux-next. Should I amend
this one somehow?
>
> Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
> ---
> drivers/i2c/i2c-core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index 5f89f1e..a732107 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -2555,7 +2555,7 @@ static u8 i2c_smbus_pec(u8 crc, u8 *p, size_t
> count)
> static u8 i2c_smbus_msg_pec(u8 pec, struct i2c_msg *msg)
> {
> /* The address will be sent first */
> - u8 addr = (msg->addr << 1) | !!(msg->flags & I2C_M_RD);
> + u8 addr = (msg->addr << 1) | (msg->flags & I2C_M_RD);
> pec = i2c_smbus_pec(pec, , 1);
>
> /* The data buffer follows */
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] enable I2C devices behind I2C bus on Gen2
On Wed, 2015-10-07 at 13:18 +0300, Andy Shevchenko wrote: > There is a board in the wild, i.e. Intel Galileo Gen2, that has ACPI > enumerated > devices behind I2C bus. Lee, since Wolfram is going to apply patches 1 and 5, how could we proceed with the rest? Patches are indeed build independent, though they are unified by enabling logically piece-by-piece. It would be great if you think you may apply them to your v4.4 queue. > This patch series dedicated to enable those devices. Meanwhile it > also changes > I2C core to cope with ACPI 6.0 specification (patch 1). > > The MFD framework is also updated to cope with interesting > implementation of > the cell descriptions under ACPI MFD (patch 2). > > The patches 5 and 6 are pretty independent and could be applied > ahead, though > they don't make much sense without previous ones. > > Srinivas, it would be nice to see your tag (ideally Tested-by) to be > sure we > don't break ISH stuff. > > Since it touches multiple subsystems someone needs to create an > immutable > branch. I don't actually know whose subsystem better here. Wolfram? > > Tested on the actual Intel Galileo Gen2 by Ismo (gpio expanders) and > me (at24). > > Changelog v3: > - append ACKs from Rafael (from ACPI angle) > - drop upstreamed patches (GPIO pca953x) > > Changelog v2: > - append tags > - re-make patch 3 (suggested by Lee) > - improve patch 8 (suggested by Thierry) > > Andy Shevchenko (5): > mfd: core: redo ACPI matching of the children devices > mfd: intel_quark_i2c_gpio: load gpio driver first > mfd: intel_quark_i2c_gpio: support devices behind i2c bus > at24: enable ACPI device found on Galileo Gen2 > pwm-pca9685: enable ACPI device found on Galileo Gen2 > > Mika Westerberg (1): > i2c / ACPI: Rework I2C device scanning > > Documentation/acpi/enumeration.txt | 11 +++-- > drivers/i2c/i2c-core.c | 82 +++- > -- > drivers/mfd/intel_quark_i2c_gpio.c | 33 ++- > drivers/mfd/mfd-core.c | 52 > drivers/misc/eeprom/at24.c | 22 -- > drivers/pwm/Kconfig| 2 +- > drivers/pwm/pwm-pca9685.c | 20 -- > include/linux/mfd/core.h | 10 - > 8 files changed, 170 insertions(+), 62 deletions(-) > -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: designware: fix platform driver probe rename
On Wed, 2015-10-21 at 11:16 +0200, Arnd Bergmann wrote:
> A function rename was incomplete and missed the !CONFIG_PM
> case:
>
> i2c-designware-platdrv.c:340:13: error: 'dw_i2c_plat_prepare'
> undeclared here (not in a function)
> i2c-designware-platdrv.c:341:14: error: 'dw_i2c_plat_complete'
> undeclared here (not in a function)
>
> This renames the macros accordingly.
Jarkko sent this already couple hours ago.
>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> Fixes: 6ad6fde3970c ("i2c: designware: Rename platform driver probe
> and PM functions")
> ---
> Found on ARM randconfig builds
>
> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
> b/drivers/i2c/busses/i2c-designware-platdrv.c
> index f6b252a8ffd1..eb55760ccd9f 100644
> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> @@ -307,8 +307,8 @@ static void dw_i2c_plat_complete(struct device
> *dev)
> pm_request_resume(dev);
> }
> #else
> -#define dw_i2c_prepare NULL
> -#define dw_i2c_complete NULL
> +#define dw_i2c_plat_prepare NULL
> +#define dw_i2c_plat_complete NULL
> #endif
>
> #ifdef CONFIG_PM
>
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/1] i2c: add ACPI support for I2C mux ports
ux.c b/drivers/i2c/i2c-mux.c
> index 2ba7c0f..00fc5b1 100644
> --- a/drivers/i2c/i2c-mux.c
> +++ b/drivers/i2c/i2c-mux.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> /* multiplexer per channel data */
> struct i2c_mux_priv {
> @@ -173,6 +174,13 @@ struct i2c_adapter *i2c_add_mux_adapter(struct
> i2c_adapter *parent,
> }
> }
>
> + /*
> + * Associate the mux channel with an ACPI node.
> + */
> + if (has_acpi_companion(mux_dev))
> + acpi_preset_companion(>adap.dev,
> ACPI_COMPANION(mux_dev),
> + chan_id);
> +
> if (force_nr) {
> priv->adap.nr = force_nr;
> ret = i2c_add_numbered_adapter(>adap);
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 51a96a8..66564f8 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -505,6 +505,12 @@ static inline bool has_acpi_companion(struct
> device *dev)
> return false;
> }
>
> +static inline void acpi_preset_companion(struct device *dev,
> + struct acpi_device *parent,
> u64 addr)
> +{
> + return;
> +}
> +
> static inline const char *acpi_dev_name(struct acpi_device *adev)
> {
> return NULL;
For me seems this one can go separately. Rafael, what do you think?
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/6] pwm-pca9685: enable ACPI device found on Galileo Gen2
On Wed, 2015-10-07 at 13:18 +0300, Andy Shevchenko wrote:
> There is a chip connected to i2c bus on Intel Galileo Gen2 board.
> Enable it via
> ACPI ID INT3492.
Thierry, can you Ack or take this one, please?
>
> Cc: Thierry Reding <thierry.red...@gmail.com>
> Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
> ---
> drivers/pwm/Kconfig | 2 +-
> drivers/pwm/pwm-pca9685.c | 20
> 2 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 0cfaf6b..2f4641a 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -272,7 +272,7 @@ config PWM_MXS
>
> config PWM_PCA9685
> tristate "NXP PCA9685 PWM driver"
> - depends on OF && I2C
> + depends on I2C
> select REGMAP_I2C
> help
> Generic PWM framework driver for NXP PCA9685 LED
> controller.
> diff --git a/drivers/pwm/pwm-pca9685.c b/drivers/pwm/pwm-pca9685.c
> index 70448a6..117fccf 100644
> --- a/drivers/pwm/pwm-pca9685.c
> +++ b/drivers/pwm/pwm-pca9685.c
> @@ -19,9 +19,11 @@
> * this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> +#include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -297,7 +299,6 @@ static const struct regmap_config
> pca9685_regmap_i2c_config = {
> static int pca9685_pwm_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> - struct device_node *np = client->dev.of_node;
> struct pca9685 *pca;
> int ret;
> int mode2;
> @@ -320,12 +321,12 @@ static int pca9685_pwm_probe(struct i2c_client
> *client,
>
> regmap_read(pca->regmap, PCA9685_MODE2, );
>
> - if (of_property_read_bool(np, "invert"))
> + if (device_property_read_bool(>dev, "invert"))
> mode2 |= MODE2_INVRT;
> else
> mode2 &= ~MODE2_INVRT;
>
> - if (of_property_read_bool(np, "open-drain"))
> + if (device_property_read_bool(>dev, "open-drain"))
> mode2 &= ~MODE2_OUTDRV;
> else
> mode2 |= MODE2_OUTDRV;
> @@ -363,16 +364,27 @@ static const struct i2c_device_id pca9685_id[]
> = {
> };
> MODULE_DEVICE_TABLE(i2c, pca9685_id);
>
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id pca9685_acpi_ids[] = {
> + { "INT3492", 0 },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(acpi, pca9685_acpi_ids);
> +#endif
> +
> +#ifdef CONFIG_OF
> static const struct of_device_id pca9685_dt_ids[] = {
> { .compatible = "nxp,pca9685-pwm", },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, pca9685_dt_ids);
> +#endif
>
> static struct i2c_driver pca9685_i2c_driver = {
> .driver = {
> .name = "pca9685-pwm",
> - .of_match_table = pca9685_dt_ids,
> + .acpi_match_table = ACPI_PTR(pca9685_acpi_ids),
> + .of_match_table = of_match_ptr(pca9685_dt_ids),
> },
> .probe = pca9685_pwm_probe,
> .remove = pca9685_pwm_remove,
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c: designware: enable High-speed mode for pcidrv
On Thu, 2015-10-15 at 11:32 +0300, Jarkko Nikula wrote: > On 10/15/2015 08:46 AM, Xiang Wang wrote: > > > > In conclusion, we have 2 solutions to set the i2c controller speed > > mode (pci driver): > > 1) use hardcode value in pci driver > > 2) use frequency setting of "i2c device" in ACPI table (more > > flexible, > > but looks a bit strange) > > > > Do you have any preference/suggestions for above solutions? Thanks > > I don't think we can hard code especially the high-speed mode because > > most typically buses are populated with slower devices. > > Things are a bit more clear when ACPI provides timing parameters for > the > bus (for standard and fast speed modes at the moment in > i2c-designware-platdrv.c: dw_i2c_acpi_configure()) but still I think > the > ACPI namespace walk may be needed against potential BIOS > misconfigurations. For instance if it provides timing parameters for > all > speeds but there are devices with lower speed on the same bus. > > I'd take these timing parameters as configuration data for bus > features > but actual speed (speed bits in IC_CON register) is defined > separately. > To me it looks only way to achieve that is to pick slowest device > from > I2cSerialBus resource descriptors. Should it (ACPI walk) be done in PCI case as well? If so, then it needs to be done up to i2c-core. There you may adjust the bus speed whenever slave device is enumerated. For PCI case you have still to have hardcoded values and it should be maximum supported by the bus I think. When you have implemented above algorithm you may do this safely. Am I missing something? -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MAINTAINERS: add maintainers for Synopsis Designware I2C drivers
On Thu, 2015-10-15 at 15:58 +0200, Wolfram Sang wrote: > Those guys already have been helpful in the past and are actively > working on this driver, unlike me. > > Signed-off-by: Wolfram Sang <w...@the-dreams.de> > Acked-by: Jarkko Nikula <jarkko.nik...@linux.intel.com> > Cc: Andy Shevchenko <andriy.shevche...@linux.intel.com> > Cc: Mika Westerberg <mika.westerb...@linux.intel.com> > --- Acked-by: Andy Shevchenko <andriy.shevche...@linux.intel.com> > > As suggested by Jarkko here: > http://article.gmane.org/gmane.linux.drivers.i2c/24834 > > MAINTAINERS | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 5f467845ef725f..58d6b02d2dea78 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -9101,6 +9101,15 @@ S: Supported > F: Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt > F: drivers/net/ethernet/synopsys/dwc_eth_qos.c > > +SYNOPSYS DESIGNWARE I2C DRIVER > +M: Andy Shevchenko <andriy.shevche...@linux.intel.com> > +M: Jarkko Nikula <jarkko.nik...@linux.intel.com> > +M: Mika Westerberg <mika.westerb...@linux.intel.com> > +L: linux-i2c@vger.kernel.org > +S: Maintained > +F: drivers/i2c/busses/i2c-designware-* > +F: include/linux/platform_data/i2c-designware.h > + > SYNOPSYS DESIGNWARE MMC/SD/SDIO DRIVER > M: Seungwon Jeon <tgih@samsung.com> > M: Jaehoon Chung <jh80.ch...@samsung.com> -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c: designware: enable High-speed mode for pcidrv
On Mon, 2015-10-12 at 15:41 +0800, Xiang Wang wrote:
> Hi, Andy
> Thanks for your comments.
>
> [Andy] Don't see a relationship between PCI driver and this ACPI
> stuff.
> Although this is a pci driver, we may enumerate the i2c devices from
> DSDT table while i2c controllers are enumerated via PCI. In this
> scenario, in DSDT, there are descriptions of i2c devices as well as
> i2c controllers. The ACPI node of i2c controllers are bond to i2c PCI
> devices via pci-acpi glue.
> So if we want to determine the i2c devices' settings (e.g. bus
> speed),
> we should leverage ACPI.
>
> Above is also the reason why the ACPI stuff is put in
> i2c-designware-core: i2c_dw_acpi_setup_speed can be used by both plat
> and pci driver. Thanks
Wait, first of all let's divide parameters to two groups: a) to be
applied to host driver, and b) to be applied to slave devices.
The drivers/i2c/busses/i2c-designware* is about host driver parameters.
Thus, PCI driver comes with hardcoded values since it's enumerated via
PCI, and platform driver utilizes ACPI values.
For slave devices everything is done in i2c-core.c.
So, what exactly you are trying to enhance?
>
> 2015-10-09 17:31 GMT+08:00 Andy Shevchenko <
> andriy.shevche...@linux.intel.com>:
> > On Fri, 2015-10-09 at 16:47 +0800, wangx...@gmail.com wrote:
> > > From: Xiang Wang <xiang.a.w...@intel.com>
> > >
> > > 1. Support setting hs_hcnt and hs_lcnt
> > > 2. Get bus speed mode from ACPI companion of the
> > > i2c controller.
> > >
> > > Signed-off-by: Xiang Wang <xiang.a.w...@intel.com>
> > > ---
> > > drivers/i2c/busses/i2c-designware-pcidrv.c | 7 +++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c
> > > b/drivers/i2c/busses/i2c-designware-pcidrv.c
> > > index 6643d2d..0f4c0c4 100644
> > > --- a/drivers/i2c/busses/i2c-designware-pcidrv.c
> > > +++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
> > > @@ -54,8 +54,10 @@ enum dw_pci_ctl_id_t {
> > > struct dw_scl_sda_cfg {
> > > u32 ss_hcnt;
> > > u32 fs_hcnt;
> > > + u32 hs_hcnt;
> > > u32 ss_lcnt;
> > > u32 fs_lcnt;
> > > + u32 hs_lcnt;
> > > u32 sda_hold;
> > > };
> > >
> > > @@ -237,8 +239,10 @@ static int i2c_dw_pci_probe(struct pci_dev
> > > *pdev,
> > > cfg = controller->scl_sda_cfg;
> > > dev->ss_hcnt = cfg->ss_hcnt;
> > > dev->fs_hcnt = cfg->fs_hcnt;
> > > + dev->hs_hcnt = cfg->hs_hcnt;
> > > dev->ss_lcnt = cfg->ss_lcnt;
> > > dev->fs_lcnt = cfg->fs_lcnt;
> > > + dev->hs_lcnt = cfg->hs_lcnt;
> > > dev->sda_hold_time = cfg->sda_hold;
> > > }
> > >
> > > @@ -246,6 +250,9 @@ static int i2c_dw_pci_probe(struct pci_dev
> > > *pdev,
> > >
> > > dev->tx_fifo_depth = controller->tx_fifo_depth;
> > > dev->rx_fifo_depth = controller->rx_fifo_depth;
> > > +
> > > + i2c_dw_acpi_setup_speed(>dev, dev);
> >
> > Don't see a relationship between PCI driver and this ACPI stuff.
> >
> > > +
> > > r = i2c_dw_init(dev);
> > > if (r)
> > > return r;
> >
> > --
> > Andy Shevchenko <andriy.shevche...@linux.intel.com>
> > Intel Finland Oy
>
>
>
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] i2c: designware: add High-speed mode support
_walk_namespace(ACPI_TYPE_DEVICE, handle, 1,
> + acpi_i2c_find_device_speed,
> NULL,
> + dev, NULL);
> + if (ACPI_FAILURE(status))
> + dev_warn(pdev, "failed to get I2C bus freq\n");
> +}
> +
> +#else
> +void i2c_dw_acpi_setup_speed(struct device *pdev, struct dw_i2c_dev
> *dev) {}
> +#endif
> +EXPORT_SYMBOL_GPL(i2c_dw_acpi_setup_speed);
> +
> /*
> * Waiting for bus not busy
> */
> diff --git a/drivers/i2c/busses/i2c-designware-core.h
> b/drivers/i2c/busses/i2c-designware-core.h
> index 9630222..16f53d8 100644
> --- a/drivers/i2c/busses/i2c-designware-core.h
> +++ b/drivers/i2c/busses/i2c-designware-core.h
> @@ -24,12 +24,17 @@
>
>
> #define DW_IC_CON_MASTER 0x1
> +#define DW_IC_SPEED_MASK 0x6
> #define DW_IC_CON_SPEED_STD 0x2
> #define DW_IC_CON_SPEED_FAST 0x4
> +#define DW_IC_CON_SPEED_HIGH 0x6
> #define DW_IC_CON_10BITADDR_MASTER 0x10
> #define DW_IC_CON_RESTART_EN 0x20
> #define DW_IC_CON_SLAVE_DISABLE 0x40
>
> +#define DW_STD_SPEED 10
> +#define DW_FAST_SPEED40
> +#define DW_HIGH_SPEED340
>
> /**
> * struct dw_i2c_dev - private i2c-designware data
> @@ -61,6 +66,8 @@
> * @ss_lcnt: standard speed LCNT value
> * @fs_hcnt: fast speed HCNT value
> * @fs_lcnt: fast speed LCNT value
> + * @hs_hcnt: high speed HCNT value
> + * @hs_lcnt: high speed LCNT value
> * @acquire_lock: function to acquire a hardware lock on the bus
> * @release_lock: function to release a hardware lock on the bus
> * @pm_runtime_disabled: true if pm runtime is disabled
> @@ -104,6 +111,8 @@ struct dw_i2c_dev {
> u16 ss_lcnt;
> u16 fs_hcnt;
> u16 fs_lcnt;
> + u16 hs_hcnt;
> + u16 hs_lcnt;
> int (*acquire_lock)(struct dw_i2c_dev
> *dev);
> void(*release_lock)(struct dw_i2c_dev
> *dev);
> boolpm_runtime_disabled;
> @@ -114,6 +123,8 @@ struct dw_i2c_dev {
>
> extern u32 dw_readl(struct dw_i2c_dev *dev, int offset);
> extern void dw_writel(struct dw_i2c_dev *dev, u32 b, int offset);
> +extern void i2c_dw_acpi_setup_speed(struct device *pdev,
> + struct dw_i2c_dev *dev);
> extern int i2c_dw_init(struct dw_i2c_dev *dev);
> extern int i2c_dw_xfer(struct i2c_adapter *adap, struct i2c_msg
> msgs[],
> int num);
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c: designware: enable High-speed mode for pcidrv
On Fri, 2015-10-09 at 16:47 +0800, wangx...@gmail.com wrote:
> From: Xiang Wang <xiang.a.w...@intel.com>
>
> 1. Support setting hs_hcnt and hs_lcnt
> 2. Get bus speed mode from ACPI companion of the
> i2c controller.
>
> Signed-off-by: Xiang Wang <xiang.a.w...@intel.com>
> ---
> drivers/i2c/busses/i2c-designware-pcidrv.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c
> b/drivers/i2c/busses/i2c-designware-pcidrv.c
> index 6643d2d..0f4c0c4 100644
> --- a/drivers/i2c/busses/i2c-designware-pcidrv.c
> +++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
> @@ -54,8 +54,10 @@ enum dw_pci_ctl_id_t {
> struct dw_scl_sda_cfg {
> u32 ss_hcnt;
> u32 fs_hcnt;
> + u32 hs_hcnt;
> u32 ss_lcnt;
> u32 fs_lcnt;
> + u32 hs_lcnt;
> u32 sda_hold;
> };
>
> @@ -237,8 +239,10 @@ static int i2c_dw_pci_probe(struct pci_dev
> *pdev,
> cfg = controller->scl_sda_cfg;
> dev->ss_hcnt = cfg->ss_hcnt;
> dev->fs_hcnt = cfg->fs_hcnt;
> + dev->hs_hcnt = cfg->hs_hcnt;
> dev->ss_lcnt = cfg->ss_lcnt;
> dev->fs_lcnt = cfg->fs_lcnt;
> + dev->hs_lcnt = cfg->hs_lcnt;
> dev->sda_hold_time = cfg->sda_hold;
> }
>
> @@ -246,6 +250,9 @@ static int i2c_dw_pci_probe(struct pci_dev *pdev,
>
> dev->tx_fifo_depth = controller->tx_fifo_depth;
> dev->rx_fifo_depth = controller->rx_fifo_depth;
> +
> + i2c_dw_acpi_setup_speed(>dev, dev);
Don't see a relationship between PCI driver and this ACPI stuff.
> +
> r = i2c_dw_init(dev);
> if (r)
> return r;
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/6] mfd: intel_quark_i2c_gpio: support devices behind i2c bus
On Intel Galileo Gen2 the GPIO expanders are connected to the i2c bus. For
those devices the ACPI table has specific parameters that refer to an actual
i2c host controller. Since MFD now copes with that specific configuration we
have to provide a necessary information how to distinguish devices in ACPI
namespace. Here the _ADR values are provided.
Acked-by: Lee Jones <lee.jo...@linaro.org>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/mfd/intel_quark_i2c_gpio.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
b/drivers/mfd/intel_quark_i2c_gpio.c
index 958c134..0421374 100644
--- a/drivers/mfd/intel_quark_i2c_gpio.c
+++ b/drivers/mfd/intel_quark_i2c_gpio.c
@@ -31,6 +31,10 @@
#define MFD_I2C_BAR0
#define MFD_GPIO_BAR 1
+/* ACPI _ADR value to match the child node */
+#define MFD_ACPI_MATCH_GPIO0ULL
+#define MFD_ACPI_MATCH_I2C 1ULL
+
/* The base GPIO number under GPIOLIB framework */
#define INTEL_QUARK_MFD_GPIO_BASE 8
@@ -82,16 +86,25 @@ static struct resource intel_quark_i2c_res[] = {
},
};
+static struct mfd_cell_acpi_match intel_quark_acpi_match_i2c = {
+ .adr = MFD_ACPI_MATCH_I2C,
+};
+
static struct resource intel_quark_gpio_res[] = {
[INTEL_QUARK_IORES_MEM] = {
.flags = IORESOURCE_MEM,
},
};
+static struct mfd_cell_acpi_match intel_quark_acpi_match_gpio = {
+ .adr = MFD_ACPI_MATCH_GPIO,
+};
+
static struct mfd_cell intel_quark_mfd_cells[] = {
{
.id = MFD_GPIO_BAR,
.name = "gpio-dwapb",
+ .acpi_match = _quark_acpi_match_gpio,
.num_resources = ARRAY_SIZE(intel_quark_gpio_res),
.resources = intel_quark_gpio_res,
.ignore_resource_conflicts = true,
@@ -99,6 +112,7 @@ static struct mfd_cell intel_quark_mfd_cells[] = {
{
.id = MFD_I2C_BAR,
.name = "i2c_designware",
+ .acpi_match = _quark_acpi_match_i2c,
.num_resources = ARRAY_SIZE(intel_quark_i2c_res),
.resources = intel_quark_i2c_res,
.ignore_resource_conflicts = true,
--
2.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/6] enable I2C devices behind I2C bus on Gen2
There is a board in the wild, i.e. Intel Galileo Gen2, that has ACPI enumerated devices behind I2C bus. This patch series dedicated to enable those devices. Meanwhile it also changes I2C core to cope with ACPI 6.0 specification (patch 1). The MFD framework is also updated to cope with interesting implementation of the cell descriptions under ACPI MFD (patch 2). The patches 5 and 6 are pretty independent and could be applied ahead, though they don't make much sense without previous ones. Srinivas, it would be nice to see your tag (ideally Tested-by) to be sure we don't break ISH stuff. Since it touches multiple subsystems someone needs to create an immutable branch. I don't actually know whose subsystem better here. Wolfram? Tested on the actual Intel Galileo Gen2 by Ismo (gpio expanders) and me (at24). Changelog v3: - append ACKs from Rafael (from ACPI angle) - drop upstreamed patches (GPIO pca953x) Changelog v2: - append tags - re-make patch 3 (suggested by Lee) - improve patch 8 (suggested by Thierry) Andy Shevchenko (5): mfd: core: redo ACPI matching of the children devices mfd: intel_quark_i2c_gpio: load gpio driver first mfd: intel_quark_i2c_gpio: support devices behind i2c bus at24: enable ACPI device found on Galileo Gen2 pwm-pca9685: enable ACPI device found on Galileo Gen2 Mika Westerberg (1): i2c / ACPI: Rework I2C device scanning Documentation/acpi/enumeration.txt | 11 +++-- drivers/i2c/i2c-core.c | 82 +++--- drivers/mfd/intel_quark_i2c_gpio.c | 33 ++- drivers/mfd/mfd-core.c | 52 drivers/misc/eeprom/at24.c | 22 -- drivers/pwm/Kconfig| 2 +- drivers/pwm/pwm-pca9685.c | 20 -- include/linux/mfd/core.h | 10 - 8 files changed, 170 insertions(+), 62 deletions(-) -- 2.5.3 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/6] i2c / ACPI: Rework I2C device scanning
From: Mika Westerberg <mika.westerb...@linux.intel.com>
The way we currently scan I2C devices behind an I2C host controller does not
work in cases where the I2C device in question is not declared directly below
the host controller ACPI node.
This is perfectly legal according the ACPI 6.0 specification and some existing
systems are doing this.
To be able to enumerate all devices which are connected to a certain I2C host
controller we need to rework the current I2C scanning routine a bit. Instead of
scanning directly below the host controller we scan the whole ACPI namespace
for present devices with valid I2cSerialBus() connection pointing to the host
controller in question.
Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/i2c/i2c-core.c | 82 --
1 file changed, 59 insertions(+), 23 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index a732107..24e516e 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -99,27 +99,40 @@ struct gsb_buffer {
};
} __packed;
-static int acpi_i2c_add_resource(struct acpi_resource *ares, void *data)
+struct acpi_i2c_lookup {
+ struct i2c_board_info *info;
+ acpi_handle adapter_handle;
+ acpi_handle device_handle;
+};
+
+static int acpi_i2c_find_address(struct acpi_resource *ares, void *data)
{
- struct i2c_board_info *info = data;
+ struct acpi_i2c_lookup *lookup = data;
+ struct i2c_board_info *info = lookup->info;
+ struct acpi_resource_i2c_serialbus *sb;
+ acpi_handle adapter_handle;
+ acpi_status status;
- if (ares->type == ACPI_RESOURCE_TYPE_SERIAL_BUS) {
- struct acpi_resource_i2c_serialbus *sb;
+ if (info->addr || ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS)
+ return 1;
- sb = >data.i2c_serial_bus;
- if (!info->addr && sb->type == ACPI_RESOURCE_SERIAL_TYPE_I2C) {
- info->addr = sb->slave_address;
- if (sb->access_mode == ACPI_I2C_10BIT_MODE)
- info->flags |= I2C_CLIENT_TEN;
- }
- } else if (!info->irq) {
- struct resource r;
+ sb = >data.i2c_serial_bus;
+ if (sb->type != ACPI_RESOURCE_SERIAL_TYPE_I2C)
+ return 1;
- if (acpi_dev_resource_interrupt(ares, 0, ))
- info->irq = r.start;
+ /*
+* Extract the ResourceSource and make sure that the handle matches
+* with the I2C adapter handle.
+*/
+ status = acpi_get_handle(lookup->device_handle,
+sb->resource_source.string_ptr,
+_handle);
+ if (ACPI_SUCCESS(status) && adapter_handle == lookup->adapter_handle) {
+ info->addr = sb->slave_address;
+ if (sb->access_mode == ACPI_I2C_10BIT_MODE)
+ info->flags |= I2C_CLIENT_TEN;
}
- /* Tell the ACPI core to skip this resource */
return 1;
}
@@ -128,6 +141,8 @@ static acpi_status acpi_i2c_add_device(acpi_handle handle,
u32 level,
{
struct i2c_adapter *adapter = data;
struct list_head resource_list;
+ struct acpi_i2c_lookup lookup;
+ struct resource_entry *entry;
struct i2c_board_info info;
struct acpi_device *adev;
int ret;
@@ -140,14 +155,37 @@ static acpi_status acpi_i2c_add_device(acpi_handle
handle, u32 level,
memset(, 0, sizeof(info));
info.fwnode = acpi_fwnode_handle(adev);
+ memset(, 0, sizeof(lookup));
+ lookup.adapter_handle = ACPI_HANDLE(adapter->dev.parent);
+ lookup.device_handle = handle;
+ lookup.info =
+
+ /*
+* Look up for I2cSerialBus resource with ResourceSource that
+* matches with this adapter.
+*/
INIT_LIST_HEAD(_list);
ret = acpi_dev_get_resources(adev, _list,
-acpi_i2c_add_resource, );
+acpi_i2c_find_address, );
acpi_dev_free_resource_list(_list);
if (ret < 0 || !info.addr)
return AE_OK;
+ /* Then fill IRQ number if any */
+ ret = acpi_dev_get_resources(adev, _list, NULL, NULL);
+ if (ret < 0)
+ return AE_OK;
+
+ resource_list_for_each_entry(entry, _list) {
+ if (resource_type(entry->res) == IORESOURCE_IRQ) {
+ info.irq = entry->res->start;
+ break;
+ }
+ }
+
+ acpi_dev_free_resource_list(_list);
+
adev->power.flags.ignore_parent =
[PATCH v3 2/6] mfd: core: redo ACPI matching of the children devices
There is at least one board on the market, i.e. Intel Galileo Gen2, that uses
_ADR to distinguish the devices under one actual device. Due to this we have to
improve the quirk in the MFD core to handle that board.
Acked-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
Documentation/acpi/enumeration.txt | 11 +---
drivers/mfd/mfd-core.c | 52 ++
include/linux/mfd/core.h | 10 ++--
3 files changed, 52 insertions(+), 21 deletions(-)
diff --git a/Documentation/acpi/enumeration.txt
b/Documentation/acpi/enumeration.txt
index b731b29..a91ec5a 100644
--- a/Documentation/acpi/enumeration.txt
+++ b/Documentation/acpi/enumeration.txt
@@ -347,13 +347,18 @@ For the first case, the MFD drivers do not need to do
anything. The
resulting child platform device will have its ACPI_COMPANION() set to point
to the parent device.
-If the ACPI namespace has a device that we can match using an ACPI id,
-the id should be set like:
+If the ACPI namespace has a device that we can match using an ACPI id or ACPI
+adr, the cell should be set like:
+
+ static struct mfd_cell_acpi_match my_subdevice_cell_acpi_match = {
+ .pnpid = "XYZ0001",
+ .adr = 0,
+ };
static struct mfd_cell my_subdevice_cell = {
.name = "my_subdevice",
/* set the resources relative to the parent */
- .acpi_pnpid = "XYZ0001",
+ .acpi_match = _subdevice_cell_acpi_match,
};
The ACPI id "XYZ0001" is then used to lookup an ACPI device directly under
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index c17635d..60b60dc 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -82,29 +82,49 @@ static int mfd_platform_add_cell(struct platform_device
*pdev,
static void mfd_acpi_add_device(const struct mfd_cell *cell,
struct platform_device *pdev)
{
- struct acpi_device *parent_adev;
+ const struct mfd_cell_acpi_match *match = cell->acpi_match;
+ struct acpi_device *parent, *child;
struct acpi_device *adev;
- parent_adev = ACPI_COMPANION(pdev->dev.parent);
- if (!parent_adev)
+ parent = ACPI_COMPANION(pdev->dev.parent);
+ if (!parent)
return;
/*
-* MFD child device gets its ACPI handle either from the ACPI
-* device directly under the parent that matches the acpi_pnpid or
-* it will use the parent handle if is no acpi_pnpid is given.
+* MFD child device gets its ACPI handle either from the ACPI device
+* directly under the parent that matches the either _HID or _CID, or
+* _ADR or it will use the parent handle if is no ID is given.
+*
+* Note that use of _ADR is a grey area in the ACPI specification,
+* though Intel Galileo Gen2 is using it to distinguish the children
+* devices.
*/
- adev = parent_adev;
- if (cell->acpi_pnpid) {
- struct acpi_device_id ids[2] = {};
- struct acpi_device *child_adev;
-
- strlcpy(ids[0].id, cell->acpi_pnpid, sizeof(ids[0].id));
- list_for_each_entry(child_adev, _adev->children, node)
- if (acpi_match_device_ids(child_adev, ids)) {
- adev = child_adev;
- break;
+ adev = parent;
+ if (match) {
+ if (match->pnpid) {
+ struct acpi_device_id ids[2] = {};
+
+ strlcpy(ids[0].id, match->pnpid, sizeof(ids[0].id));
+ list_for_each_entry(child, >children, node) {
+ if (acpi_match_device_ids(child, ids)) {
+ adev = child;
+ break;
+ }
+ }
+ } else {
+ unsigned long long adr;
+ acpi_status status;
+
+ list_for_each_entry(child, >children, node) {
+ status = acpi_evaluate_integer(child->handle,
+ "_ADR", NULL,
+ );
+ if (ACPI_SUCCESS(status) && match->adr == adr) {
+ adev = child;
+ break;
+ }
}
+ }
}
ACPI_COMPANION_SET(>dev, adev);
diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
index a76bc10..27dac3f 100644
--- a/include/linux/mfd/cor
[PATCH v3 5/6] at24: enable ACPI device found on Galileo Gen2
There is a 24c08 chip connected to i2c bus on Intel Galileo Gen2 board. Enable
it via ACPI ID INT3499.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/misc/eeprom/at24.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index c6cb7f8..ed009a3 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -131,6 +132,12 @@ static const struct i2c_device_id at24_ids[] = {
};
MODULE_DEVICE_TABLE(i2c, at24_ids);
+static const struct acpi_device_id at24_acpi_ids[] = {
+ { "INT3499", AT24_DEVICE_MAGIC(8192 / 8, 0) },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, at24_acpi_ids);
+
/*-*/
/*
@@ -473,15 +480,23 @@ static int at24_probe(struct i2c_client *client, const
struct i2c_device_id *id)
struct at24_data *at24;
int err;
unsigned i, num_addresses;
- kernel_ulong_t magic;
+ kernel_ulong_t magic = 0;
if (client->dev.platform_data) {
chip = *(struct at24_platform_data *)client->dev.platform_data;
} else {
- if (!id->driver_data)
+ if (id) {
+ magic = id->driver_data;
+ } else {
+ const struct acpi_device_id *id;
+
+ id = acpi_match_device(at24_acpi_ids, >dev);
+ if (id)
+ magic = id->driver_data;
+ }
+ if (!magic)
return -ENODEV;
- magic = id->driver_data;
chip.byte_len = BIT(magic & AT24_BITMASK(AT24_SIZE_BYTELEN));
magic >>= AT24_SIZE_BYTELEN;
chip.flags = magic & AT24_BITMASK(AT24_SIZE_FLAGS);
@@ -661,6 +676,7 @@ static int at24_remove(struct i2c_client *client)
static struct i2c_driver at24_driver = {
.driver = {
.name = "at24",
+ .acpi_match_table = ACPI_PTR(at24_acpi_ids),
},
.probe = at24_probe,
.remove = at24_remove,
--
2.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/6] mfd: intel_quark_i2c_gpio: load gpio driver first
On Intel Galileo boards the GPIO expander is connected to i2c bus. Moreover it
is able to generate interrupt, but interrupt line is connected to GPIO. That's
why we have to have GPIO driver in place when we will probe i2c host with
device connected to it.
Acked-by: Lee Jones <lee.jo...@linaro.org>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/mfd/intel_quark_i2c_gpio.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
b/drivers/mfd/intel_quark_i2c_gpio.c
index 1ce1603..958c134 100644
--- a/drivers/mfd/intel_quark_i2c_gpio.c
+++ b/drivers/mfd/intel_quark_i2c_gpio.c
@@ -90,19 +90,19 @@ static struct resource intel_quark_gpio_res[] = {
static struct mfd_cell intel_quark_mfd_cells[] = {
{
- .id = MFD_I2C_BAR,
- .name = "i2c_designware",
- .num_resources = ARRAY_SIZE(intel_quark_i2c_res),
- .resources = intel_quark_i2c_res,
- .ignore_resource_conflicts = true,
- },
- {
.id = MFD_GPIO_BAR,
.name = "gpio-dwapb",
.num_resources = ARRAY_SIZE(intel_quark_gpio_res),
.resources = intel_quark_gpio_res,
.ignore_resource_conflicts = true,
},
+ {
+ .id = MFD_I2C_BAR,
+ .name = "i2c_designware",
+ .num_resources = ARRAY_SIZE(intel_quark_i2c_res),
+ .resources = intel_quark_i2c_res,
+ .ignore_resource_conflicts = true,
+ },
};
static const struct pci_device_id intel_quark_mfd_ids[] = {
@@ -248,12 +248,11 @@ static int intel_quark_mfd_probe(struct pci_dev *pdev,
dev_set_drvdata(>dev, quark_mfd);
- ret = intel_quark_i2c_setup(pdev, _quark_mfd_cells[MFD_I2C_BAR]);
+ ret = intel_quark_i2c_setup(pdev, _quark_mfd_cells[1]);
if (ret)
return ret;
- ret = intel_quark_gpio_setup(pdev,
-_quark_mfd_cells[MFD_GPIO_BAR]);
+ ret = intel_quark_gpio_setup(pdev, _quark_mfd_cells[0]);
if (ret)
return ret;
--
2.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 6/6] pwm-pca9685: enable ACPI device found on Galileo Gen2
There is a chip connected to i2c bus on Intel Galileo Gen2 board. Enable it via
ACPI ID INT3492.
Cc: Thierry Reding <thierry.red...@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/pwm/Kconfig | 2 +-
drivers/pwm/pwm-pca9685.c | 20
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 0cfaf6b..2f4641a 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -272,7 +272,7 @@ config PWM_MXS
config PWM_PCA9685
tristate "NXP PCA9685 PWM driver"
- depends on OF && I2C
+ depends on I2C
select REGMAP_I2C
help
Generic PWM framework driver for NXP PCA9685 LED controller.
diff --git a/drivers/pwm/pwm-pca9685.c b/drivers/pwm/pwm-pca9685.c
index 70448a6..117fccf 100644
--- a/drivers/pwm/pwm-pca9685.c
+++ b/drivers/pwm/pwm-pca9685.c
@@ -19,9 +19,11 @@
* this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include
#include
#include
#include
+#include
#include
#include
#include
@@ -297,7 +299,6 @@ static const struct regmap_config pca9685_regmap_i2c_config
= {
static int pca9685_pwm_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- struct device_node *np = client->dev.of_node;
struct pca9685 *pca;
int ret;
int mode2;
@@ -320,12 +321,12 @@ static int pca9685_pwm_probe(struct i2c_client *client,
regmap_read(pca->regmap, PCA9685_MODE2, );
- if (of_property_read_bool(np, "invert"))
+ if (device_property_read_bool(>dev, "invert"))
mode2 |= MODE2_INVRT;
else
mode2 &= ~MODE2_INVRT;
- if (of_property_read_bool(np, "open-drain"))
+ if (device_property_read_bool(>dev, "open-drain"))
mode2 &= ~MODE2_OUTDRV;
else
mode2 |= MODE2_OUTDRV;
@@ -363,16 +364,27 @@ static const struct i2c_device_id pca9685_id[] = {
};
MODULE_DEVICE_TABLE(i2c, pca9685_id);
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id pca9685_acpi_ids[] = {
+ { "INT3492", 0 },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(acpi, pca9685_acpi_ids);
+#endif
+
+#ifdef CONFIG_OF
static const struct of_device_id pca9685_dt_ids[] = {
{ .compatible = "nxp,pca9685-pwm", },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, pca9685_dt_ids);
+#endif
static struct i2c_driver pca9685_i2c_driver = {
.driver = {
.name = "pca9685-pwm",
- .of_match_table = pca9685_dt_ids,
+ .acpi_match_table = ACPI_PTR(pca9685_acpi_ids),
+ .of_match_table = of_match_ptr(pca9685_dt_ids),
},
.probe = pca9685_pwm_probe,
.remove = pca9685_pwm_remove,
--
2.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/8] enable I2C devices behind I2C bus on Gen2
On Mon, 2015-10-05 at 09:20 +0200, Linus Walleij wrote: > On Thu, Oct 1, 2015 at 1:20 PM, Andy Shevchenko > <andriy.shevche...@linux.intel.com> wrote: > > > The patches 7 and 8 are pretty independent, though they don't make > > much sense > > without previous ones applied. > > To me it seems patches 5 & 6 (GPIO patches) can be applied as-is > to my GPIO tree without any bad side effects. Is this correct? Yes, that's correct. > > In that case I will apply them. > > Yours, > Linus Walleij -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/8] mfd: intel_quark_i2c_gpio: load gpio driver first
On Thu, 2015-10-01 at 15:54 +0100, Lee Jones wrote:
> On Thu, 01 Oct 2015, Andy Shevchenko wrote:
>
> > On Intel Galileo boards the GPIO expander is connected to i2c bus.
> > Moreover it
> > is able to generate interrupt, but interrupt line is connected to
> > GPIO. That's
> > why we have to have GPIO driver in place when we will probe i2c
> > host with
> > device connected to it.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
> > ---
> > drivers/mfd/intel_quark_i2c_gpio.c | 19 +--
> > 1 file changed, 9 insertions(+), 10 deletions(-)
>
> Acked-by: Lee Jones <lee.jo...@linaro.org>
>
> Are there build dependancies in this set? Or can all patches filter
> through their own subsystems?
Practically patches 4-8 can go by their own, though it makes not much
sense since it doesn't add a value (they will be not enumerated until
patches 1-4 made an upstream).
>
> > diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
> > b/drivers/mfd/intel_quark_i2c_gpio.c
> > index 1ce1603..958c134 100644
> > --- a/drivers/mfd/intel_quark_i2c_gpio.c
> > +++ b/drivers/mfd/intel_quark_i2c_gpio.c
> > @@ -90,19 +90,19 @@ static struct resource intel_quark_gpio_res[] =
> > {
> >
> > static struct mfd_cell intel_quark_mfd_cells[] = {
> > {
> > - .id = MFD_I2C_BAR,
> > - .name = "i2c_designware",
> > - .num_resources = ARRAY_SIZE(intel_quark_i2c_res),
> > - .resources = intel_quark_i2c_res,
> > - .ignore_resource_conflicts = true,
> > - },
> > - {
> > .id = MFD_GPIO_BAR,
> > .name = "gpio-dwapb",
> > .num_resources = ARRAY_SIZE(intel_quark_gpio_res),
> > .resources = intel_quark_gpio_res,
> > .ignore_resource_conflicts = true,
> > },
> > + {
> > + .id = MFD_I2C_BAR,
> > + .name = "i2c_designware",
> > + .num_resources = ARRAY_SIZE(intel_quark_i2c_res),
> > + .resources = intel_quark_i2c_res,
> > + .ignore_resource_conflicts = true,
> > + },
> > };
> >
> > static const struct pci_device_id intel_quark_mfd_ids[] = {
> > @@ -248,12 +248,11 @@ static int intel_quark_mfd_probe(struct
> > pci_dev *pdev,
> >
> > dev_set_drvdata(>dev, quark_mfd);
> >
> > - ret = intel_quark_i2c_setup(pdev,
> > _quark_mfd_cells[MFD_I2C_BAR]);
> > + ret = intel_quark_i2c_setup(pdev,
> > _quark_mfd_cells[1]);
> > if (ret)
> > return ret;
> >
> > - ret = intel_quark_gpio_setup(pdev,
> > -
> > _quark_mfd_cells[MFD_GPIO_BAR]);
> > + ret = intel_quark_gpio_setup(pdev,
> > _quark_mfd_cells[0]);
> > if (ret)
> > return ret;
> >
>
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/8] mfd: core: redo ACPI matching of the children devices
There is at least one board on the market, i.e. Intel Galileo Gen2, that uses
_ADR to distinguish the devices under one actual device. Due to this we have to
improve the quirk in the MFD core to handle that board.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
Documentation/acpi/enumeration.txt | 11 +---
drivers/mfd/mfd-core.c | 52 ++
include/linux/mfd/core.h | 10 ++--
3 files changed, 52 insertions(+), 21 deletions(-)
diff --git a/Documentation/acpi/enumeration.txt
b/Documentation/acpi/enumeration.txt
index b731b29..a91ec5a 100644
--- a/Documentation/acpi/enumeration.txt
+++ b/Documentation/acpi/enumeration.txt
@@ -347,13 +347,18 @@ For the first case, the MFD drivers do not need to do
anything. The
resulting child platform device will have its ACPI_COMPANION() set to point
to the parent device.
-If the ACPI namespace has a device that we can match using an ACPI id,
-the id should be set like:
+If the ACPI namespace has a device that we can match using an ACPI id or ACPI
+adr, the cell should be set like:
+
+ static struct mfd_cell_acpi_match my_subdevice_cell_acpi_match = {
+ .pnpid = "XYZ0001",
+ .adr = 0,
+ };
static struct mfd_cell my_subdevice_cell = {
.name = "my_subdevice",
/* set the resources relative to the parent */
- .acpi_pnpid = "XYZ0001",
+ .acpi_match = _subdevice_cell_acpi_match,
};
The ACPI id "XYZ0001" is then used to lookup an ACPI device directly under
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index c17635d..60b60dc 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -82,29 +82,49 @@ static int mfd_platform_add_cell(struct platform_device
*pdev,
static void mfd_acpi_add_device(const struct mfd_cell *cell,
struct platform_device *pdev)
{
- struct acpi_device *parent_adev;
+ const struct mfd_cell_acpi_match *match = cell->acpi_match;
+ struct acpi_device *parent, *child;
struct acpi_device *adev;
- parent_adev = ACPI_COMPANION(pdev->dev.parent);
- if (!parent_adev)
+ parent = ACPI_COMPANION(pdev->dev.parent);
+ if (!parent)
return;
/*
-* MFD child device gets its ACPI handle either from the ACPI
-* device directly under the parent that matches the acpi_pnpid or
-* it will use the parent handle if is no acpi_pnpid is given.
+* MFD child device gets its ACPI handle either from the ACPI device
+* directly under the parent that matches the either _HID or _CID, or
+* _ADR or it will use the parent handle if is no ID is given.
+*
+* Note that use of _ADR is a grey area in the ACPI specification,
+* though Intel Galileo Gen2 is using it to distinguish the children
+* devices.
*/
- adev = parent_adev;
- if (cell->acpi_pnpid) {
- struct acpi_device_id ids[2] = {};
- struct acpi_device *child_adev;
-
- strlcpy(ids[0].id, cell->acpi_pnpid, sizeof(ids[0].id));
- list_for_each_entry(child_adev, _adev->children, node)
- if (acpi_match_device_ids(child_adev, ids)) {
- adev = child_adev;
- break;
+ adev = parent;
+ if (match) {
+ if (match->pnpid) {
+ struct acpi_device_id ids[2] = {};
+
+ strlcpy(ids[0].id, match->pnpid, sizeof(ids[0].id));
+ list_for_each_entry(child, >children, node) {
+ if (acpi_match_device_ids(child, ids)) {
+ adev = child;
+ break;
+ }
+ }
+ } else {
+ unsigned long long adr;
+ acpi_status status;
+
+ list_for_each_entry(child, >children, node) {
+ status = acpi_evaluate_integer(child->handle,
+ "_ADR", NULL,
+ );
+ if (ACPI_SUCCESS(status) && match->adr == adr) {
+ adev = child;
+ break;
+ }
}
+ }
}
ACPI_COMPANION_SET(>dev, adev);
diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
index a76bc10..27dac3f 100644
--- a/include/linux/mfd/core.h
+++ b/include/linux/mfd/core.h
@@ -18,6 +18,12 @@
struct
[PATCH v2 3/8] mfd: intel_quark_i2c_gpio: load gpio driver first
On Intel Galileo boards the GPIO expander is connected to i2c bus. Moreover it
is able to generate interrupt, but interrupt line is connected to GPIO. That's
why we have to have GPIO driver in place when we will probe i2c host with
device connected to it.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/mfd/intel_quark_i2c_gpio.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
b/drivers/mfd/intel_quark_i2c_gpio.c
index 1ce1603..958c134 100644
--- a/drivers/mfd/intel_quark_i2c_gpio.c
+++ b/drivers/mfd/intel_quark_i2c_gpio.c
@@ -90,19 +90,19 @@ static struct resource intel_quark_gpio_res[] = {
static struct mfd_cell intel_quark_mfd_cells[] = {
{
- .id = MFD_I2C_BAR,
- .name = "i2c_designware",
- .num_resources = ARRAY_SIZE(intel_quark_i2c_res),
- .resources = intel_quark_i2c_res,
- .ignore_resource_conflicts = true,
- },
- {
.id = MFD_GPIO_BAR,
.name = "gpio-dwapb",
.num_resources = ARRAY_SIZE(intel_quark_gpio_res),
.resources = intel_quark_gpio_res,
.ignore_resource_conflicts = true,
},
+ {
+ .id = MFD_I2C_BAR,
+ .name = "i2c_designware",
+ .num_resources = ARRAY_SIZE(intel_quark_i2c_res),
+ .resources = intel_quark_i2c_res,
+ .ignore_resource_conflicts = true,
+ },
};
static const struct pci_device_id intel_quark_mfd_ids[] = {
@@ -248,12 +248,11 @@ static int intel_quark_mfd_probe(struct pci_dev *pdev,
dev_set_drvdata(>dev, quark_mfd);
- ret = intel_quark_i2c_setup(pdev, _quark_mfd_cells[MFD_I2C_BAR]);
+ ret = intel_quark_i2c_setup(pdev, _quark_mfd_cells[1]);
if (ret)
return ret;
- ret = intel_quark_gpio_setup(pdev,
-_quark_mfd_cells[MFD_GPIO_BAR]);
+ ret = intel_quark_gpio_setup(pdev, _quark_mfd_cells[0]);
if (ret)
return ret;
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/8] enable I2C devices behind I2C bus on Gen2
There is a board in the wild, i.e. Intel Galileo Gen2, that has ACPI enumerated devices behind I2C bus. This patch series dedicated to enable those devices. Meanwhile it also changes I2C core to cope with ACPI 6.0 specification (patch 1/8). The MFD framework is also updated to cope with interesting implementation of the cell descriptions under ACPI MFD (patch 2/8). The patches 7 and 8 are pretty independent, though they don't make much sense without previous ones applied. Srinivas, it would be nice to see your tag (ideally Tested-by) to be sure we don't break ISH stuff. Rafael, can you Ack / comment on patch 2 (and maybe 1)? Since it touches multiple subsystems someone needs to create an immutable branch. I don't actually know whose subsystem better here. Lee, Wolfram? Apparently we would like to get ACKs / comments from the rest. Tested on the actual Intel Galileo Gen2 by Ismo (gpio expanders) and me (at24). Changelog v2: - append tags - re-make patch 3 (suggested by Lee) - improve patch 8 (suggested by Thierry) Andy Shevchenko (7): mfd: core: redo ACPI matching of the children devices mfd: intel_quark_i2c_gpio: load gpio driver first mfd: intel_quark_i2c_gpio: support devices behind i2c bus gpio: pca953x: store driver_data for future use gpio: pca953x: support ACPI devices found on Galileo Gen2 at24: enable ACPI device found on Galileo Gen2 pwm-pca9685: enable ACPI device found on Galileo Gen2 Mika Westerberg (1): i2c / ACPI: Rework I2C device scanning Documentation/acpi/enumeration.txt | 11 +++-- drivers/gpio/gpio-pca953x.c| 36 + drivers/i2c/i2c-core.c | 82 +++--- drivers/mfd/intel_quark_i2c_gpio.c | 33 ++- drivers/mfd/mfd-core.c | 52 drivers/misc/eeprom/at24.c | 22 -- drivers/pwm/Kconfig| 2 +- drivers/pwm/pwm-pca9685.c | 20 -- include/linux/mfd/core.h | 10 - 9 files changed, 199 insertions(+), 69 deletions(-) -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/8] mfd: intel_quark_i2c_gpio: support devices behind i2c bus
On Intel Galileo Gen2 the GPIO expanders are connected to the i2c bus. For
those devices the ACPI table has specific parameters that refer to an actual
i2c host controller. Since MFD now copes with that specific configuration we
have to provide a necessary information how to distinguish devices in ACPI
namespace. Here the _ADR values are provided.
Acked-by: Lee Jones <lee.jo...@linaro.org>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/mfd/intel_quark_i2c_gpio.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
b/drivers/mfd/intel_quark_i2c_gpio.c
index 958c134..0421374 100644
--- a/drivers/mfd/intel_quark_i2c_gpio.c
+++ b/drivers/mfd/intel_quark_i2c_gpio.c
@@ -31,6 +31,10 @@
#define MFD_I2C_BAR0
#define MFD_GPIO_BAR 1
+/* ACPI _ADR value to match the child node */
+#define MFD_ACPI_MATCH_GPIO0ULL
+#define MFD_ACPI_MATCH_I2C 1ULL
+
/* The base GPIO number under GPIOLIB framework */
#define INTEL_QUARK_MFD_GPIO_BASE 8
@@ -82,16 +86,25 @@ static struct resource intel_quark_i2c_res[] = {
},
};
+static struct mfd_cell_acpi_match intel_quark_acpi_match_i2c = {
+ .adr = MFD_ACPI_MATCH_I2C,
+};
+
static struct resource intel_quark_gpio_res[] = {
[INTEL_QUARK_IORES_MEM] = {
.flags = IORESOURCE_MEM,
},
};
+static struct mfd_cell_acpi_match intel_quark_acpi_match_gpio = {
+ .adr = MFD_ACPI_MATCH_GPIO,
+};
+
static struct mfd_cell intel_quark_mfd_cells[] = {
{
.id = MFD_GPIO_BAR,
.name = "gpio-dwapb",
+ .acpi_match = _quark_acpi_match_gpio,
.num_resources = ARRAY_SIZE(intel_quark_gpio_res),
.resources = intel_quark_gpio_res,
.ignore_resource_conflicts = true,
@@ -99,6 +112,7 @@ static struct mfd_cell intel_quark_mfd_cells[] = {
{
.id = MFD_I2C_BAR,
.name = "i2c_designware",
+ .acpi_match = _quark_acpi_match_i2c,
.num_resources = ARRAY_SIZE(intel_quark_i2c_res),
.resources = intel_quark_i2c_res,
.ignore_resource_conflicts = true,
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/8] i2c / ACPI: Rework I2C device scanning
From: Mika Westerberg <mika.westerb...@linux.intel.com>
The way we currently scan I2C devices behind an I2C host controller does not
work in cases where the I2C device in question is not declared directly below
the host controller ACPI node.
This is perfectly legal according the ACPI 6.0 specification and some existing
systems are doing this.
To be able to enumerate all devices which are connected to a certain I2C host
controller we need to rework the current I2C scanning routine a bit. Instead of
scanning directly below the host controller we scan the whole ACPI namespace
for present devices with valid I2cSerialBus() connection pointing to the host
controller in question.
Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/i2c/i2c-core.c | 82 --
1 file changed, 59 insertions(+), 23 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index a732107..24e516e 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -99,27 +99,40 @@ struct gsb_buffer {
};
} __packed;
-static int acpi_i2c_add_resource(struct acpi_resource *ares, void *data)
+struct acpi_i2c_lookup {
+ struct i2c_board_info *info;
+ acpi_handle adapter_handle;
+ acpi_handle device_handle;
+};
+
+static int acpi_i2c_find_address(struct acpi_resource *ares, void *data)
{
- struct i2c_board_info *info = data;
+ struct acpi_i2c_lookup *lookup = data;
+ struct i2c_board_info *info = lookup->info;
+ struct acpi_resource_i2c_serialbus *sb;
+ acpi_handle adapter_handle;
+ acpi_status status;
- if (ares->type == ACPI_RESOURCE_TYPE_SERIAL_BUS) {
- struct acpi_resource_i2c_serialbus *sb;
+ if (info->addr || ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS)
+ return 1;
- sb = >data.i2c_serial_bus;
- if (!info->addr && sb->type == ACPI_RESOURCE_SERIAL_TYPE_I2C) {
- info->addr = sb->slave_address;
- if (sb->access_mode == ACPI_I2C_10BIT_MODE)
- info->flags |= I2C_CLIENT_TEN;
- }
- } else if (!info->irq) {
- struct resource r;
+ sb = >data.i2c_serial_bus;
+ if (sb->type != ACPI_RESOURCE_SERIAL_TYPE_I2C)
+ return 1;
- if (acpi_dev_resource_interrupt(ares, 0, ))
- info->irq = r.start;
+ /*
+* Extract the ResourceSource and make sure that the handle matches
+* with the I2C adapter handle.
+*/
+ status = acpi_get_handle(lookup->device_handle,
+sb->resource_source.string_ptr,
+_handle);
+ if (ACPI_SUCCESS(status) && adapter_handle == lookup->adapter_handle) {
+ info->addr = sb->slave_address;
+ if (sb->access_mode == ACPI_I2C_10BIT_MODE)
+ info->flags |= I2C_CLIENT_TEN;
}
- /* Tell the ACPI core to skip this resource */
return 1;
}
@@ -128,6 +141,8 @@ static acpi_status acpi_i2c_add_device(acpi_handle handle,
u32 level,
{
struct i2c_adapter *adapter = data;
struct list_head resource_list;
+ struct acpi_i2c_lookup lookup;
+ struct resource_entry *entry;
struct i2c_board_info info;
struct acpi_device *adev;
int ret;
@@ -140,14 +155,37 @@ static acpi_status acpi_i2c_add_device(acpi_handle
handle, u32 level,
memset(, 0, sizeof(info));
info.fwnode = acpi_fwnode_handle(adev);
+ memset(, 0, sizeof(lookup));
+ lookup.adapter_handle = ACPI_HANDLE(adapter->dev.parent);
+ lookup.device_handle = handle;
+ lookup.info =
+
+ /*
+* Look up for I2cSerialBus resource with ResourceSource that
+* matches with this adapter.
+*/
INIT_LIST_HEAD(_list);
ret = acpi_dev_get_resources(adev, _list,
-acpi_i2c_add_resource, );
+acpi_i2c_find_address, );
acpi_dev_free_resource_list(_list);
if (ret < 0 || !info.addr)
return AE_OK;
+ /* Then fill IRQ number if any */
+ ret = acpi_dev_get_resources(adev, _list, NULL, NULL);
+ if (ret < 0)
+ return AE_OK;
+
+ resource_list_for_each_entry(entry, _list) {
+ if (resource_type(entry->res) == IORESOURCE_IRQ) {
+ info.irq = entry->res->start;
+ break;
+ }
+ }
+
+ acpi_dev_free_resource_list(_list);
+
adev->power.flags.ignore_parent = true;
strlcpy(info.type, dev_name(>dev), sizeof(info.typ
[PATCH v2 6/8] gpio: pca953x: support ACPI devices found on Galileo Gen2
This patch adds a support of the expandes found on Intel Galileo Gen2 board.
The platform information comes from ACPI.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/gpio/gpio-pca953x.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 242e244..0220b38 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -21,6 +21,7 @@
#ifdef CONFIG_OF_GPIO
#include
#endif
+#include
#define PCA953X_INPUT 0
#define PCA953X_OUTPUT 1
@@ -75,6 +76,12 @@ static const struct i2c_device_id pca953x_id[] = {
};
MODULE_DEVICE_TABLE(i2c, pca953x_id);
+static const struct acpi_device_id pca953x_acpi_ids[] = {
+ { "INT3491", 16 | PCA953X_TYPE | PCA_INT, },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, pca953x_acpi_ids);
+
#define MAX_BANK 5
#define BANK_SZ 8
@@ -675,7 +682,18 @@ static int pca953x_probe(struct i2c_client *client,
chip->client = client;
- chip->driver_data = id->driver_data;
+ if (id) {
+ chip->driver_data = id->driver_data;
+ } else {
+ const struct acpi_device_id *id;
+
+ id = acpi_match_device(pca953x_acpi_ids, >dev);
+ if (!id)
+ return -ENODEV;
+
+ chip->driver_data = id->driver_data;
+ }
+
chip->chip_type = PCA_CHIP_TYPE(chip->driver_data);
mutex_init(>i2c_lock);
@@ -768,6 +786,7 @@ static struct i2c_driver pca953x_driver = {
.driver = {
.name = "pca953x",
.of_match_table = pca953x_dt_ids,
+ .acpi_match_table = ACPI_PTR(pca953x_acpi_ids),
},
.probe = pca953x_probe,
.remove = pca953x_remove,
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/8] gpio: pca953x: store driver_data for future use
Instead of using id->driver_data directly we copied it to the internal
structure. This will help to adapt driver for ACPI use.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/gpio/gpio-pca953x.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 50caeb1..242e244 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -42,6 +42,9 @@
#define PCA_INT0x0100
#define PCA953X_TYPE 0x1000
#define PCA957X_TYPE 0x2000
+#define PCA_TYPE_MASK 0xF000
+
+#define PCA_CHIP_TYPE(x) ((x) & PCA_TYPE_MASK)
static const struct i2c_device_id pca953x_id[] = {
{ "pca9505", 40 | PCA953X_TYPE | PCA_INT, },
@@ -95,6 +98,7 @@ struct pca953x_chip {
struct gpio_chip gpio_chip;
const char *const *names;
int chip_type;
+ unsigned long driver_data;
};
static inline struct pca953x_chip *to_pca(struct gpio_chip *gc)
@@ -517,14 +521,13 @@ static irqreturn_t pca953x_irq_handler(int irq, void
*devid)
}
static int pca953x_irq_setup(struct pca953x_chip *chip,
-const struct i2c_device_id *id,
int irq_base)
{
struct i2c_client *client = chip->client;
int ret, i, offset = 0;
if (client->irq && irq_base != -1
- && (id->driver_data & PCA_INT)) {
+ && (chip->driver_data & PCA_INT)) {
switch (chip->chip_type) {
case PCA953X_TYPE:
@@ -581,12 +584,11 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
#else /* CONFIG_GPIO_PCA953X_IRQ */
static int pca953x_irq_setup(struct pca953x_chip *chip,
-const struct i2c_device_id *id,
int irq_base)
{
struct i2c_client *client = chip->client;
- if (irq_base != -1 && (id->driver_data & PCA_INT))
+ if (irq_base != -1 && (chip->driver_data & PCA_INT))
dev_warn(>dev, "interrupt support not compiled in\n");
return 0;
@@ -673,14 +675,15 @@ static int pca953x_probe(struct i2c_client *client,
chip->client = client;
- chip->chip_type = id->driver_data & (PCA953X_TYPE | PCA957X_TYPE);
+ chip->driver_data = id->driver_data;
+ chip->chip_type = PCA_CHIP_TYPE(chip->driver_data);
mutex_init(>i2c_lock);
/* initialize cached registers from their original values.
* we can't share this chip with another i2c master.
*/
- pca953x_setup_gpio(chip, id->driver_data & PCA_GPIO_MASK);
+ pca953x_setup_gpio(chip, chip->driver_data & PCA_GPIO_MASK);
if (chip->chip_type == PCA953X_TYPE)
ret = device_pca953x_init(chip, invert);
@@ -693,7 +696,7 @@ static int pca953x_probe(struct i2c_client *client,
if (ret)
return ret;
- ret = pca953x_irq_setup(chip, id, irq_base);
+ ret = pca953x_irq_setup(chip, irq_base);
if (ret)
return ret;
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 8/8] pwm-pca9685: enable ACPI device found on Galileo Gen2
There is a chip connected to i2c bus on Intel Galileo Gen2 board. Enable it via
ACPI ID INT3492.
Cc: Thierry Reding <thierry.red...@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/pwm/Kconfig | 2 +-
drivers/pwm/pwm-pca9685.c | 20
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 062630a..bb114ef 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -242,7 +242,7 @@ config PWM_MXS
config PWM_PCA9685
tristate "NXP PCA9685 PWM driver"
- depends on OF && I2C
+ depends on I2C
select REGMAP_I2C
help
Generic PWM framework driver for NXP PCA9685 LED controller.
diff --git a/drivers/pwm/pwm-pca9685.c b/drivers/pwm/pwm-pca9685.c
index 70448a6..117fccf 100644
--- a/drivers/pwm/pwm-pca9685.c
+++ b/drivers/pwm/pwm-pca9685.c
@@ -19,9 +19,11 @@
* this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include
#include
#include
#include
+#include
#include
#include
#include
@@ -297,7 +299,6 @@ static const struct regmap_config pca9685_regmap_i2c_config
= {
static int pca9685_pwm_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- struct device_node *np = client->dev.of_node;
struct pca9685 *pca;
int ret;
int mode2;
@@ -320,12 +321,12 @@ static int pca9685_pwm_probe(struct i2c_client *client,
regmap_read(pca->regmap, PCA9685_MODE2, );
- if (of_property_read_bool(np, "invert"))
+ if (device_property_read_bool(>dev, "invert"))
mode2 |= MODE2_INVRT;
else
mode2 &= ~MODE2_INVRT;
- if (of_property_read_bool(np, "open-drain"))
+ if (device_property_read_bool(>dev, "open-drain"))
mode2 &= ~MODE2_OUTDRV;
else
mode2 |= MODE2_OUTDRV;
@@ -363,16 +364,27 @@ static const struct i2c_device_id pca9685_id[] = {
};
MODULE_DEVICE_TABLE(i2c, pca9685_id);
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id pca9685_acpi_ids[] = {
+ { "INT3492", 0 },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(acpi, pca9685_acpi_ids);
+#endif
+
+#ifdef CONFIG_OF
static const struct of_device_id pca9685_dt_ids[] = {
{ .compatible = "nxp,pca9685-pwm", },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, pca9685_dt_ids);
+#endif
static struct i2c_driver pca9685_i2c_driver = {
.driver = {
.name = "pca9685-pwm",
- .of_match_table = pca9685_dt_ids,
+ .acpi_match_table = ACPI_PTR(pca9685_acpi_ids),
+ .of_match_table = of_match_ptr(pca9685_dt_ids),
},
.probe = pca9685_pwm_probe,
.remove = pca9685_pwm_remove,
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/8] at24: enable ACPI device found on Galileo Gen2
There is a 24c08 chip connected to i2c bus on Intel Galileo Gen2 board. Enable
it via ACPI ID INT3499.
Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
---
drivers/misc/eeprom/at24.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index c6cb7f8..ed009a3 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -131,6 +132,12 @@ static const struct i2c_device_id at24_ids[] = {
};
MODULE_DEVICE_TABLE(i2c, at24_ids);
+static const struct acpi_device_id at24_acpi_ids[] = {
+ { "INT3499", AT24_DEVICE_MAGIC(8192 / 8, 0) },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, at24_acpi_ids);
+
/*-*/
/*
@@ -473,15 +480,23 @@ static int at24_probe(struct i2c_client *client, const
struct i2c_device_id *id)
struct at24_data *at24;
int err;
unsigned i, num_addresses;
- kernel_ulong_t magic;
+ kernel_ulong_t magic = 0;
if (client->dev.platform_data) {
chip = *(struct at24_platform_data *)client->dev.platform_data;
} else {
- if (!id->driver_data)
+ if (id) {
+ magic = id->driver_data;
+ } else {
+ const struct acpi_device_id *id;
+
+ id = acpi_match_device(at24_acpi_ids, >dev);
+ if (id)
+ magic = id->driver_data;
+ }
+ if (!magic)
return -ENODEV;
- magic = id->driver_data;
chip.byte_len = BIT(magic & AT24_BITMASK(AT24_SIZE_BYTELEN));
magic >>= AT24_SIZE_BYTELEN;
chip.flags = magic & AT24_BITMASK(AT24_SIZE_FLAGS);
@@ -661,6 +676,7 @@ static int at24_remove(struct i2c_client *client)
static struct i2c_driver at24_driver = {
.driver = {
.name = "at24",
+ .acpi_match_table = ACPI_PTR(at24_acpi_ids),
},
.probe = at24_probe,
.remove = at24_remove,
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] i2c: ismt: improve usage of devres API
On Wed, 2015-09-16 at 17:23 +0300, Andy Shevchenko wrote:
> pcim_release() will release any requested region. There is no need to
> duplicate
> this effort in the driver.
Any comments on that clean up series?
>
> Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
> ---
> drivers/i2c/busses/i2c-ismt.c | 18 +-
> 1 file changed, 5 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-ismt.c b/drivers/i2c/busses/i2c
> -ismt.c
> index f994712..b7a68b5 100644
> --- a/drivers/i2c/busses/i2c-ismt.c
> +++ b/drivers/i2c/busses/i2c-ismt.c
> @@ -904,8 +904,7 @@ ismt_probe(struct pci_dev *pdev, const struct
> pci_device_id *id)
> priv->smba = pcim_iomap(pdev, SMBBAR, len);
> if (!priv->smba) {
> dev_err(>dev, "Unable to ioremap SMBus
> BAR\n");
> - err = -ENODEV;
> - goto fail;
> + return -ENODEV;
> }
>
> if ((pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) != 0) ||
> @@ -915,32 +914,26 @@ ismt_probe(struct pci_dev *pdev, const struct
> pci_device_id *id)
>DMA_BIT_MASK(32))
> != 0)) {
> dev_err(>dev, "pci_set_dma_mask fail
> %p\n",
> pdev);
> - err = -ENODEV;
> - goto fail;
> + return -ENODEV;
> }
> }
>
> err = ismt_dev_init(priv);
> if (err)
> - goto fail;
> + return err;
>
> ismt_hw_init(priv);
>
> err = ismt_int_init(priv);
> if (err)
> - goto fail;
> + return err;
>
> err = i2c_add_adapter(>adapter);
> if (err) {
> dev_err(>dev, "Failed to add SMBus iSMT
> adapter\n");
> - err = -ENODEV;
> - goto fail;
> + return -ENODEV;
> }
> return 0;
> -
> -fail:
> - pci_release_region(pdev, SMBBAR);
> - return err;
> }
>
> /**
> @@ -952,7 +945,6 @@ static void ismt_remove(struct pci_dev *pdev)
> struct ismt_priv *priv = pci_get_drvdata(pdev);
>
> i2c_del_adapter(>adapter);
> - pci_release_region(pdev, SMBBAR);
> }
>
> /**
--
Andy Shevchenko <andriy.shevche...@linux.intel.com>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 2/8] mfd: core: redo ACPI matching of the children devices
On Tue, 2015-09-22 at 23:15 +0100, Lee Jones wrote:
> On Tue, 22 Sep 2015, Andy Shevchenko wrote:
>
> > There is at least one board on the market, i.e. Intel Galileo Gen2,
> > that uses
> > _ADR to distinguish the devices under one actual device. Due to
> > this we have to
> > improve the quirk in the MFD core to handle that board.
>
> This will require an ACPI Ack.
Rafael is Cc'ed, so, I hope he will comment on this.
>
> > Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
> > ---
> > Documentation/acpi/enumeration.txt | 11 +---
> > drivers/mfd/mfd-core.c | 52 ++
> >
> > include/linux/mfd/core.h | 10 ++--
> > 3 files changed, 52 insertions(+), 21 deletions(-)
> >
> > diff --git a/Documentation/acpi/enumeration.txt
> > b/Documentation/acpi/enumeration.txt
> > index b731b29..a91ec5a 100644
> > --- a/Documentation/acpi/enumeration.txt
> > +++ b/Documentation/acpi/enumeration.txt
> > @@ -347,13 +347,18 @@ For the first case, the MFD drivers do not
> > need to do anything. The
> > resulting child platform device will have its ACPI_COMPANION() set
> > to point
> > to the parent device.
> >
> > -If the ACPI namespace has a device that we can match using an ACPI
> > id,
> > -the id should be set like:
> > +If the ACPI namespace has a device that we can match using an ACPI
> > id or ACPI
> > +adr, the cell should be set like:
> > +
> > + static struct mfd_cell_acpi_match
> > my_subdevice_cell_acpi_match = {
> > + .pnpid = "XYZ0001",
> > + .adr = 0,
> > + };
> >
> > static struct mfd_cell my_subdevice_cell = {
> > .name = "my_subdevice",
> > /* set the resources relative to the parent */
> > - .acpi_pnpid = "XYZ0001",
> > + .acpi_match = _subdevice_cell_acpi_match,
> > };
> >
> > The ACPI id "XYZ0001" is then used to lookup an ACPI device
> > directly under
> > diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> > index c17635d..60b60dc 100644
> > --- a/drivers/mfd/mfd-core.c
> > +++ b/drivers/mfd/mfd-core.c
> > @@ -82,29 +82,49 @@ static int mfd_platform_add_cell(struct
> > platform_device *pdev,
> > static void mfd_acpi_add_device(const struct mfd_cell *cell,
> > struct platform_device *pdev)
> > {
> > - struct acpi_device *parent_adev;
> > + const struct mfd_cell_acpi_match *match = cell
> > ->acpi_match;
> > + struct acpi_device *parent, *child;
> > struct acpi_device *adev;
> >
> > - parent_adev = ACPI_COMPANION(pdev->dev.parent);
> > - if (!parent_adev)
> > + parent = ACPI_COMPANION(pdev->dev.parent);
> > + if (!parent)
> > return;
> >
> > /*
> > -* MFD child device gets its ACPI handle either from the
> > ACPI
> > -* device directly under the parent that matches the
> > acpi_pnpid or
> > -* it will use the parent handle if is no acpi_pnpid is
> > given.
> > +* MFD child device gets its ACPI handle either from the
> > ACPI device
> > +* directly under the parent that matches the either _HID
> > or _CID, or
> > +* _ADR or it will use the parent handle if is no ID is
> > given.
> > +*
> > +* Note that use of _ADR is a grey area in the ACPI
> > specification,
> > +* though Intel Galileo Gen2 is using it to distinguish
> > the children
> > +* devices.
> > */
> > - adev = parent_adev;
> > - if (cell->acpi_pnpid) {
> > - struct acpi_device_id ids[2] = {};
> > - struct acpi_device *child_adev;
> > -
> > - strlcpy(ids[0].id, cell->acpi_pnpid,
> > sizeof(ids[0].id));
> > - list_for_each_entry(child_adev, _adev
> > ->children, node)
> > - if (acpi_match_device_ids(child_adev,
> > ids)) {
> > - adev = child_adev;
> > - break;
> > + adev = parent;
> > + if (match) {
> > + if (match->pnpid) {
> > + struct acpi_device_id ids[2] = {};
> > +
> > + strlcpy(ids[0].id, match->pnpid,
> > sizeof(ids[0].id));
> > + list_for_each_entry(child,
> > ->children, node) {
> > +
Re: [PATCH v1 8/8] pwm-pca9685: enable ACPI device found on Galileo Gen2
On Wed, 2015-09-23 at 14:48 +0200, Thierry Reding wrote: > > > > > On Wed, Sep 23, 2015 at 11:41:26AM +0300, Andy Shevchenko wrote: > > On Tue, 2015-09-22 at 16:37 +0200, Thierry Reding wrote: > > > On Tue, Sep 22, 2015 at 01:10:19PM +0300, Andy Shevchenko wrote: > > > > > > > > > .of_match_table = pca9685_dt_ids, > > > > > > Similarly to the above, this should use of_match_ptr(), which in > > > turn > > > will require #ifdef protection for the table to avoid warnings. > > > > Hmm... my patch do not touches that part. Perhaps another patch for > > this? > > Your patch does touch that part by removing the dependency on OF. > That > makes it possible to build this code with !OF, which in turn would > make > the OF match table unused. Ah, you're right. Will amend this part as well. Thanks! > > Thierry -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
