Fast mode is the default speed of i2c-designware which can be overridden
by platform data or by "clock-frequency" device property. Even though
the ACPI 5.1 can pass device properties via _DSD method, shipping systems
define the connection speed between I2C host and each slave in their
I2cSerialBus resources. Which means speed is not defined per bus but per
slave.

As there is now support in i2c-core to find the bus speed from ACPI use
that to set up the bus speed prior registering the I2C adapter.
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This patch enabled high speed mode. High speed mode can be turn on by
setting the clk_freq to 3400000. High speed HCNT and LCNT are needed
as there is no default value provided.
Signed-off-by: NWeifeng Voon <weifeng.voon@intel.com>
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

DW_IC_CON_MASTER, DW_IC_CON_SLAVE_DISABLE and DW_IC_CON_RESTART_EN are
common config that need to be set for i2c designware master. So, configure
it first without having to repeat inside the if else.
Signed-off-by: NWeifeng Voon <weifeng.voon@intel.com>
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This patch enabled fast mode plus. The fast mode plus and fast speed
share the same HCNT and LCNT register. So, the fast mode plus will only
run when the HCNT and LCNT value is provided. Else, it will run at fast
speed as default.
Signed-off-by: NWeifeng Voon <weifeng.voon@intel.com>
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

I2C designware controller can run at fast mode plus and high speed. This
patch adds the capability to get the HCNT, LCNT configuration via
FPCN (fast plus) and HSCN (high speed) ACPI method.
Signed-off-by: NWeifeng Voon <weifeng.voon@intel.com>
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

I2c designware controller operate speed is configured in the register
IC_CON. Previously the operate speed is determined by a local variable
clk_freq. This patch will move the local variable clk_freq into struct
dw_i2c_dev. This change will ease the set and get of the clk_freq.
Signed-off-by: NWeifeng Voon <weifeng.voon@intel.com>
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Add device HID AMDI0010 to match the AMD ACPI Vendor ID (AMDI) that
was registered in http://www.uefi.org/acpi_id_list, and the I2C
controller on future AMD paltform will use the HID instead of AMD0010.
Signed-off-by: NXiangliang Yu <Xiangliang.Yu@amd.com>
Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The current driver uses input clock source frequency to calculate
values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not
currently have a good way to provide the frequency information.
Instead, we can leverage the SSCN and FFCN ACPI methods, which can be used
to directly provide these values. So, the clock information should
no longer be required during probing.

However, since clk can be invalid, additional checks must be done where
we are making use of it.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Tested-by: NLoc Ho <lho@apm.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Enable APM X-Gene ACPI I2C device support by adding the
corresponding ACPI ID. The platform ACPI APD corresponding
change is required to provide the proper clock frequency input.
Signed-off-by: NLoc Ho <lho@apm.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add device HID AMDI0510 to match the I2C controlers on AMD Seattle platform
Signed-off-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

On an hardware shared I2C bus (certain Intel Baytrail SoC platforms) the
runtime PM disable depth keeps increasing over repeated modprobe/rmmod
cycle because pm_runtime_disable() is called without checking should it
be disabled already because of bus sharing.

This hasn't made any other harm than dev->power.disable_depth keeps
increasing but keep it sync by calling pm_runtime_disable() only when
runtime PM is not disabled.
Reported-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Because of some hardware limitation, AMD I2C controller can't
trigger pending interrupt if interrupt status has been changed
after clearing interrupt status bits. Then, I2C will lost
interrupt and IO timeout.

According to hardware design, this patch implements a workaround
to disable i2c controller interrupt and re-enable i2c interrupt
before exiting ISR.

To reduce the performance impacts on other vendors, use unlikely
function to check flag in ISR.
Signed-off-by: NXiangliang Yu <Xiangliang.Yu@amd.com>
Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

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: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or
device property compatible string match), enumerating I2C client devices
connected through an I2C mux needs a little extra work.

This change implements a method for describing an I2C device hierarchy that
includes mux devices by using an ACPI Device() for each mux channel along
with an _ADR to set the channel number for the device.  See
Documentation/acpi/i2c-muxes.txt for a simple example.

To make this work the ismt, i801, and designware pci/platform devs now
share an ACPI companion with their I2C adapter dev similar to how it's done
in OF.  This is done on the assumption that power management functions will
not be called directly on the I2C dev that is sharing the ACPI node.
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NDustin Byford <dustin@cumulusnetworks.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The patch reverts commit a445900c (i2c: designware: Add support for
AMD I2C controller). It never worked anyhow because it did not register
a proper clkdev.

Since kernel 4.1 starts to support APD, there is no need to get freq
from id->driver_data for AMD0010. clkdev is supposed to be already
registered in APD.

So, revert old design and make AMD0010 looks like other ones.
Signed-off-by: NKen Xue <Ken.Xue@amd.com>
Signed-off-by: NXiangliang Yu <Xiangliang.Yu@amd.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Commit ("i2c: designware: Rename platform driver probe and PM
functions") introduced "'dw_i2c_plat_prepare' undeclared here" and
"'dw_i2c_plat_complete' undeclared here" build errors when
CONFIG_PM_SLEEP is not set.

Fix this by renaming NULL defined dw_i2c_prepare and dw_i2c_complete PM
hooks to dw_i2c_plat_prepare and dw_i2c_plat_complete since this was
obviously missing from the commit.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

ACPI SSCN/FMCN methods were originally added because then the platform can
provide the most accurate HCNT/LCNT values to the driver. However, this
seems not to be true for Dell Inspiron 7348 where using these causes the
touchpad to fail in boot:

  i2c_hid i2c-DLL0675:00: failed to retrieve report from device.
  i2c_designware INT3433:00: i2c_dw_handle_tx_abort: lost arbitration
  i2c_hid i2c-DLL0675:00: failed to retrieve report from device.
  i2c_designware INT3433:00: controller timed out

The values received from ACPI are (in fast mode):

  HCNT: 72
  LCNT: 160

this translates to following timings (input clock is 100MHz on Broadwell):

  tHIGH: 720 ns (spec min 600 ns)
  tLOW: 1600 ns (spec min 1300 ns)
  Bus period: 2920 ns (assuming 300 ns tf and tr)
  Bus speed: 342.5 kHz

Both tHIGH and tLOW are within the I2C specification.

The calculated values when ACPI parameters are not used are (in fast mode):

  HCNT: 87
  LCNT: 159

which translates to:

  tHIGH: 870 ns (spec min 600 ns)
  tLOW: 1590 ns (spec min 1300 ns)
  Bus period 3060 ns (assuming 300 ns tf and tr)
  Bus speed 326.8 kHz

These values are also within the I2C specification.

Since both ACPI and calculated values meet the I2C specification timing
requirements it is hard to say why the touchpad does not function properly
with the ACPI values except that the bus speed is higher in this case (but
still well below the max 400kHz).

Solve this by adding DMI quirk to the driver that disables using ACPI
parameters on this particulare machine.
Reported-by: NPavel Roskin <plroskin@gmail.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: NPavel Roskin <plroskin@gmail.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

The core may register clients attached to this master which may use
funtionality from the master. So, RuntimePM must be enabled before, otherwise
this will fail.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: stable@kernel.org

There is some code duplication in i2c-designware-platdrv and
i2c-designware-pcidrv probe functions. What is even worse that duplication
requires i2c_dw_xfer(), i2c_dw_func() and i2c_dw_isr() i2c-designware-core
functions to be exported.

Therefore move common code into new i2c_dw_probe() and make functions above
local to i2c-designware-core.

While merging the code patch does following functional changes:

- I2C Adapter name will be "Synopsys DesignWare I2C adapter". Previously it
  was used for platform and ACPI devices but PCI device used
  "i2c-designware-pci".
- Using device name for interrupt name. Previous it was platform device name,
  ACPI device name or "i2c-designware-pci".
- Error code from devm_request_irq() and i2c_add_numbered_adapter() will be
  printed in case of error.
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Make it easier to distinguish between i2c-designware-platdrv and
i2c-designware-core functions and to be consistent with
i2c-designware-pcidrv.
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The driver calls pm_runtime_put() right before pm_runtime_disable() in its
->remove() hook to make sure clock is gated etc. However, it turns out that
pm_runtime_put() only calls ->idle() hook without actually suspending
anything. The following pm_runtime_disable() will prevent the driver from
suspending thus leaving it "active".

It is better to suspend the device synchronously to make sure it is
actually suspended before disabling runtime PM from it.

While there, undo call to pm_runtime_use_autosuspend().
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Commit 1fc2fe20 ("i2c: designware: Add runtime PM hooks") adds
runtime pm support using the same ops for system pm and runtime pm.
When suspend to ram, the i2c host may have been runtime suspended, thus
i2c_dw_disable() hangs.

Previously, I fixed this issue by separating ops for system pm and
runtime pm, then in the system suspend/resume path, runtime pm apis are
used to ensure the device is at correct state.

But as Mika Westerberg pointed out: it sounds a bit silly to resume the
device just because you want to call i2c_dw_disable() for it before
suspending again. He then suggested an elegant solution which keeps the
device runtime suspended during system suspend with the help of
'dev->power.direct_complete'. This patch adopted this solution, and in
fact Mika provided the main code.
Signed-off-by: NJisheng Zhang <jszhang@marvell.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Now that the ACPI companions of devices are represented by pointers
to struct fwnode_handle, it is not quite efficient to check whether
or not an ACPI companion of a device is present by evaluating the
ACPI_COMPANION() macro.

For this reason, introduce a special static inline routine for that,
has_acpi_companion(), and update the code to use it where applicable.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

With -EPROBE_DEFER, this message is confusing and we hope for a
centralized printout in the future anyhow.
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NChristian Ruppert <christian.ruppert@alitech.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This patch implements an I2C bus sharing mechanism between the host and platform
hardware on select Intel BayTrail SoC platforms using the X-Powers AXP288 PMIC.

On these platforms access to the PMIC must be shared with platform hardware. The
hardware unit assumes full control of the I2C bus and the host must request
access through a special semaphore. Hardware control of the bus also makes it
necessary to disable runtime pm to avoid interfering with hardware transactions.
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

We have a central copy of the GPL for that. Some addresses were already
outdated.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>

A platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Add support for AMD version of the DW I2C host controller. The device is
enumerated from ACPI namespace with ACPI ID AMD0010. Because the core
driver needs an input source clock, and this is not an Intel LPSS device
where clocks are provided through drivers/acpi/acpi_lpss.c, we register the
clock ourselves if the clock rate is given in ->driver_data
Signed-off-by: NCarl Peng <carlpeng008@gmail.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

In order to be able to create missing clock for AMD (and in future possibly
others) we move getting clock for the device a bit later. Also make ACPI/DT
configuration in the same place depending on from where the device was
enumerated from.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

There is no way in ACPI to tell in which speed the host controller is
supposed to run, so we default to fast mode (400KHz). Since this has been
the default all the time there should be no functional changes with this
change.

This is the first step required to refactor the driver probe so that we can
supply source clock from ACPI part of the driver to the core.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Use the platform data to set the clk_freq when there is no DT configuration
available. The clk_freq in turn will determine the I2C speed mode.

In Quark, there is currently no other configuration mechanism other than
board files.
Signed-off-by: NRaymond Tan <raymond.tan@intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NHock Leong Kweh <hock.leong.kweh@intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Some legacy devices support ony I2C standard mode at 100kHz.
This patch allows to select the standard mode through the DTS
with the use of the existing clock-frequency parameter.

When clock-frequency parameter is not set, the fast mode is selected.
Only when the parameter is set at 100000, the standard mode is selected.
Signed-off-by: NRomain Baeriswyl <romainba@abilis.com>
Reviewed-by: NChristian Ruppert <christian.ruppert@abilis.com>
Acked-by: NAlan Tull <atull@opensource.altera.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This may appear as PCI or ACPI depending upon the firmware so we
have to list both. All share the same ACPI identifier but not
the same PCI identifier.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This driver has been flagged to drop class based instantiation. The removal
improves boot-up time and is unneeded for embedded controllers. Users have been
warned to switch for some time now, so we can actually do the removal. Keep the
DEPRECATED flag, so the core can inform users that the behaviour finally
changed now. After another transition period, this flag can go, too.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

It is possible that after entering runtime PM suspend the controller
context is lost due the fact that its power is removed. This happens for
example on Asus T100, an Intel Baytrail based tablet/laptop.

In order to get the controller back to functional state, we need to
implement runtime PM hooks which will re-initialize the hardware during
runtime PM resume. We can re-use the existing system suspend hooks as the
steps to resume/suspend the controller are the same.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Userspace can initiate system suspend on arbitrary times which means that
device drivers must make sure that their device gets quiesced before system
suspend is entered. Therefore disable the I2C host controller in the driver
system suspend hook.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Warn users that class based instantiation is going away soon in favour
of more robust probing and faster bootup times.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This patch allows to set independantly SCL and SDA falling times.
The tLOW period is computed by taking into account the SCL falling time.
The tHIGH period is computed by taking into account the SDA falling time.

For instance in case the margin on tLOW is considered too small, it can
be increased by increasing the SCL falling time which is by default set
at 300ns.

The same applies for tHIGH period with the help of SDA falling time.
Signed-off-by: NRomain Baeriswyl <romainba@abilis.com>
Reviewed-by: NChristian Ruppert <christian.ruppert@abilis.com>
Acked-by: NShinya Kuribayashi <skuribay@pobox.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Newer Intel PCHs with LPSS have the same Designware I2C controllers than
Haswell but the ACPI IDs differ. Add these IDs to the driver list.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Subsystems like pinctrl and gpio rightfully make use of deferred probing at
core level. Now, deferred drivers won't be retried if they don't have a .probe
function specified in the driver struct. Fix this driver to have that, so the
devices it supports won't get lost in a deferred probe.
Reported-by: NZhangfei Gao <zhangfei.gao@linaro.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>