Re: [PATCH v1 00/13] intel-lpss: support non-ACPI platforms

On Tue, Nov 24, 2015 at 9:00 PM, Arnd Bergmann wrote: > On Tuesday 24 November 2015 12:22:46 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

Re: [PATCH v1 11/13] mfd: intel-lpss: Pass HSUART configuration via properties

On Tuesday 24 November 2015 12:22:57 Andy Shevchenko wrote: > +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), > + { }, > If I

Re: [PATCH v1 00/13] intel-lpss: support non-ACPI platforms

On Tuesday 24 November 2015 12:22:46 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

Handling clocks on external busses

Hi, When a clock driver is controlling a clock that is controlled over I2C / SPI, we need to perform a write on that bus to enable the clock. However, such busses often have their own clocks that must be enabled. Since all clock prepares are controlled under one large mutex this easily causes

Re: i2c slave support für i.mx6

> Is the recognition of IAAS a hardware interrupt (according to manual, > yes)? I set IEN (I2C enable) and IIEN (Interrupt Enable). Ah, I thought you had a question about Renesas hardware. I dunno much about Freescale anymore. > I set the slave address to 0x1c (chosen at random). The IMX bus

[RESEND PATCH v2 8/9] eeprom: at24: remove a reduntant if

It seems as if the second check for I2C_FUNC_I2C functionality had been introduced accidentally during a merge. Tt's reduntant, so remove it. Signed-off-by: Bartosz Golaszewski --- drivers/misc/eeprom/at24.c | 3 --- 1 file changed, 3 deletions(-) diff --git

Re: [PATCH v1 11/13] mfd: intel-lpss: Pass HSUART configuration via properties

Hi Mika, [auto build test ERROR on v4.4-rc2] [also build test ERROR on next-20151124] [cannot apply to ljones-mfd/for-mfd-next] url: https://github.com/0day-ci/linux/commits/Andy-Shevchenko/device-property-always-check-for-fwnode-type/20151124-183221 config: x86_64-randconfig-x019-11241713

[PATCH v1 05/13] device property: helper macros for property entry creation

From: Heikki Krogerus Marcos for easier creation of build-in property entries. Signed-off-by: Heikki Krogerus Signed-off-by: Andy Shevchenko --- include/linux/property.h | 48

[PATCH v1 11/13] mfd: intel-lpss: Pass HSUART configuration via properties

From: Mika Westerberg 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

[PATCH v1 12/13] mfd: intel-lpss: Pass SDA hold time to I2C host controller driver

From: Mika Westerberg 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

Re: [PATCH v1 12/13] mfd: intel-lpss: Pass SDA hold time to I2C host controller driver

Hi Mika, [auto build test ERROR on v4.4-rc2] [also build test ERROR on next-20151124] [cannot apply to ljones-mfd/for-mfd-next] url: https://github.com/0day-ci/linux/commits/Andy-Shevchenko/device-property-always-check-for-fwnode-type/20151124-183221 config: x86_64-randconfig-x019-11241713

Re: [PATCH v1 13/13] i2c: designware: Convert to use unified device property API

On 11/24/2015 12:22 PM, Andy Shevchenko wrote: From: Mika Westerberg 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

[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

[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 --- drivers/base/property.c | 31 ---

[PATCH v1 06/13] device property: improve readability of macros

There is no functional change. Signed-off-by: Andy Shevchenko --- drivers/base/property.c | 28 ++-- include/linux/property.h | 4 ++-- 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/drivers/base/property.c

[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

[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 --- drivers/acpi/property.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-)

[RESEND PATCH v2 7/9] eeprom: at24: add the at24cs series to the list of supported devices

The infrastructure for reading of the factory-programmed serial number for at24cs EEPROM series is now in place. Add the chips that are actually equipped with the serial number memory area to the list of supported devices. Signed-off-by: Bartosz Golaszewski ---

[RESEND PATCH v2 9/9] eeprom: at24: readability tweaks

Move the macro definitions above the struct definitions and add some tabs for better readability. Signed-off-by: Bartosz Golaszewski --- drivers/misc/eeprom/at24.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git

[RESEND PATCH v2 1/9] eeprom: at24: platform_data: use BIT() macro

Use BIT() macro to replace the 0xXX constants in platform_data flags definitions. Signed-off-by: Bartosz Golaszewski --- include/linux/platform_data/at24.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/linux/platform_data/at24.h

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

[RESEND PATCH v2 6/9] eeprom: at24: improve the device_id table readability

Improve the readability of the device table by separating columns with tabs. Signed-off-by: Bartosz Golaszewski --- drivers/misc/eeprom/at24.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/drivers/misc/eeprom/at24.c

[RESEND PATCH v2 5/9] eeprom: at24: export the serial number through sysfs

The at24 driver is now capable of reading the serial number from at24cs EEPROM chips. Export the serial number through sysfs. Signed-off-by: Bartosz Golaszewski --- drivers/misc/eeprom/at24.c | 44 1 file changed, 40

[RESEND PATCH v2 0/9] eeprom: at24: at24cs series serial number read

Chips from the at24cs EEPROM series have an additional read-only memory area containing a factory pre-programmed serial number. In order to access it, a dummy write must be executed before reading the serial number bytes. This series adds support for reading the serial number through a sysfs

[RESEND PATCH v2 4/9] eeprom: at24: support reading of the serial number

The at24cs series EEPROM chips have an additional read-only memory area containing a factory pre-programmed serial number. In order to access it, one has to perform a dummy write before reading the serial number bytes. Add a function that allows to access the serial number. Signed-off-by:

[RESEND PATCH v2 2/9] eeprom: at24: new flag in platform_data

In preparation for supporting the at24cs EEPROM series add a new flag to platform data. When set, it should tell the driver that the chip has an additional read-only memory area that holds a factory pre-programmed serial number. Signed-off-by: Bartosz Golaszewski ---

[PATCH v1 10/13] mfd: intel-lpss: Add support for passing device properties

From: Mika Westerberg 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

[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 --- drivers/base/property.c | 22

[PATCH v1 13/13] i2c: designware: Convert to use unified device property API

From: Mika Westerberg 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

[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 ---

[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

[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

Re: [PATCH v1 13/13] i2c: designware: Convert to use unified device property API

On Tue, Nov 24, 2015 at 12:53:06PM +0200, Jarkko Nikula wrote: > Mika, Andy: Was this one able to go separately? At least it builds without > rest of the set but is there anything that could break DT based system if > there are no patches 1-8/13? As far as I can tell this should not break

Re: [PATCH v1 00/13] intel-lpss: support non-ACPI platforms

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

Re: [PATCH v1 03/13] device property: refactor built-in properties support

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

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

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

Re: [PATCH v1 11/13] mfd: intel-lpss: Pass HSUART configuration via properties

On Tue, Nov 24, 2015 at 06:44:53PM +0800, kbuild test robot wrote: > Hi Mika, > > [auto build test ERROR on v4.4-rc2] > [also build test ERROR on next-20151124] > [cannot apply to ljones-mfd/for-mfd-next] > > url: > https://github.com/0day-ci/linux/commits/Andy-Sh

[PATCH 3/3] ARM: dts: at91: specify DT property "atmel,twd-hold-cycles"

From: Wenyou Yang Specify the device tree property "atmel,twd-hold-cycles" to 25 to adapt to the PMIC ACT8945A. Signed-off-by: Wenyou Yang --- arch/arm/boot/dts/at91-sama5d2_xplained.dts | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [PATCH v2 1/1] x86/platform/iosf_mbi: Remove duplicate definitions

On Wed, Nov 11, 2015 at 07:59:29PM +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

[PATCH 1/3] i2c: at91: add setting HOLD field of TWIHS_CWGR via DT

From: Wenyou Yang Add the HOLD field management. Some i2c devices need a longer data hold time than the one given in the i2c bus specification. Since this value depends on the i2c device connected to the bus, add a DT property to configure it: "atmel,twd-hold-cycles".

[PATCH 2/3] i2c: at91: add DT property "atmel,twd-hold-cycles" to binding

From: Wenyou Yang Add a DT property "atmel,twd-hold-cycles" to specify the HOLD filed of TWIHS_CWGR register to increase the TWD hold time. Signed-off-by: Wenyou Yang Signed-off-by: Ludovic Desroches ---