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

2016-01-02 Thread Wolfram Sang 
On Fri, Dec 11, 2015 at 02:55:10PM +0100, Bartosz Golaszewski wrote:
> 2015-12-11 13:08 GMT+01:00 Wolfram Sang :
> > On Wed, Dec 02, 2015 at 11:25:17AM +0100, Bartosz Golaszewski wrote:
> >> 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.
> >
> > Can't you instantiate a read-only EEPROM on this second address? Or a
> > seperate driver attaching to this address? What is the advantage of
> > having this in at24?
> >
> 
> The regular memory area and serial number read-only block share the
> internal address pointer. We must ensure that there's no race
> conditions between normal EEPROM reads/writes and serial number reads.

I don't get it. Both, regular at24 reads and the serial read, setup the
pointer every time by using two messages, first write to set the
pointer, then read. The per-adapter lock makes sure those two messages
will not get interrupted. So, it looks to me that it would be OK if a
serial read access gets inbetween a eeprom read access. Am I wrong?



signature.asc
Description: Digital signature

Re: [PATCH v2 0/2] i2c:dw: Add APM X-Gene ACPI I2C device support

2016-01-02 Thread Rafael J. Wysocki 
On Thursday, December 10, 2015 02:19:15 PM Loc Ho wrote:
> Add APM X-Gene ACPI I2C device support. These patches follow
> the same implementation as AMD I2C driver - changes in ACPI APD
> and Designware I2C drivers.
> 
> v2:
> * Spilt the acpi_apd change with defines for AMD and X-Gene I2C's
> 
> Signed-off-by: Loc Ho 
> ---
> Loc Ho (2):
>   acpi:apd: Add APM X-Gene ACPI I2C device support
>   i2c:dw: Add APM X-Gene ACPI I2C device support

Both patches applied, thanks!

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

2016-01-02 Thread Wolfram Sang 
On Sun, Dec 27, 2015 at 04:57:48PM +0200, Andy Shevchenko wrote:
> On Wed, Dec 23, 2015 at 9:18 PM, Akshay Bhat  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.


> 
> > Signed-off-by: Akshay Bhat 
> > ---
> >  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


signature.asc
Description: Digital signature

Re: [PATCH] DT: i2c: Add Epson RX8010 to list of trivial devices

2016-01-02 Thread Wolfram Sang 
On Sun, Dec 27, 2015 at 05:02:48PM +0200, Andy Shevchenko wrote:
> On Wed, Dec 23, 2015 at 8:38 PM, Akshay Bhat  wrote:
> > This adds devicetree documentation for the bindings of rtc-rx8010
> > driver.
> >
> > Signed-off-by: Akshay Bhat 
> > ---
> >  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?

I agree. Fixing that in all Epson RTC entries would be nice.



signature.asc
Description: Digital signature

Re: unmet direct dependencies in -next

2016-01-02 Thread Richard Weinberger 
Am 10.08.2015 um 13:12 schrieb Michal Marek:
> On 2015-08-10 11:14, Richard Weinberger wrote:
>> Am 10.08.2015 um 11:10 schrieb Lee Jones:
>>> On Sun, 09 Aug 2015, Richard Weinberger wrote:
>>>
 Hi!

 -next faces some build issues on UML because of unmet direct dependencies.
 Mostly due to HAS_IOMEM and I2C.

 warning: (MEDIA_SUBDRV_AUTOSELECT && VIDEO_CX231XX && INV_MPU6050_IIO) 
 selects I2C_MUX which has unmet direct dependencies (I2C && HAS_IOMEM)
 warning: (ST_IRQCHIP && HIP04_ETH && STMMAC_PLATFORM && DWMAC_IPQ806X && 
 DWMAC_LPC18XX && DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW 
 && PINCTRL_ROCKCHIP &&
 PINCTRL_DOVE && POWER_RESET_KEYSTONE && POWER_RESET_SYSCON && 
 POWER_RESET_SYSCON_POWEROFF && S3C2410_WATCHDOG && VIDEO_OMAP3 && 
 VIDEO_S5P_FIMC && RTC_DRV_AT91SAM9 && VIDEO_OMAP4 &&
 HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI) selects MFD_SYSCON which has 
 unmet direct dependencies (HAS_IOMEM)
 warning: (MEDIA_SUBDRV_AUTOSELECT && VIDEO_CX231XX && INV_MPU6050_IIO) 
 selects I2C_MUX which has unmet direct dependencies (I2C && HAS_IOMEM)
 warning: (ST_IRQCHIP && HIP04_ETH && STMMAC_PLATFORM && DWMAC_IPQ806X && 
 DWMAC_LPC18XX && DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW 
 && PINCTRL_ROCKCHIP &&
 PINCTRL_DOVE && POWER_RESET_KEYSTONE && POWER_RESET_SYSCON && 
 POWER_RESET_SYSCON_POWEROFF && S3C2410_WATCHDOG && VIDEO_OMAP3 && 
 VIDEO_S5P_FIMC && RTC_DRV_AT91SAM9 && VIDEO_OMAP4 &&
 HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI) selects MFD_SYSCON which has 
 unmet direct dependencies (HAS_IOMEM)

 For example MFD_SYSCON cannot build on UML as it depends on HAS_IOMEM.
 While the symbol MFD_SYSCON has correct dependencies some users of 
 MFD_SYSCON
 just issue a "select MFD_SYSCON" and bypass the HAS_IOMEM dependency and 
 causing the build to fail.

 This brings me to a question on kconfig itself, wouldn't it be better to 
 just disable a symbol if it has
 unmet direct dependencies?

FYI, -next is still facing:
warning: (ST_IRQCHIP && HIP04_ETH && STMMAC_PLATFORM && DWMAC_IPQ806X && 
DWMAC_LPC18XX && DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && 
PINCTRL_ROCKCHIP &&
PINCTRL_DOVE && POWER_RESET_KEYSTONE && POWER_RESET_SYSCON && 
POWER_RESET_SYSCON_POWEROFF && S3C2410_WATCHDOG && VIDEO_OMAP3 && 
VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9
&& LPC18XX_DMAMUX && VIDEO_OMAP4 && HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI && 
PHY_HI6220_USB) selects MFD_SYSCON which has unmet direct dependencies 
(HAS_IOMEM)
warning: (MEDIA_SUBDRV_AUTOSELECT && VIDEO_CX231XX && INV_MPU6050_IIO) selects 
I2C_MUX which has unmet direct dependencies (I2C && HAS_IOMEM)

Thanks,
//richard
--
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/5] i2c: img-scb: enchancements to support i2c on pistachio

2016-01-02 Thread Wolfram Sang 
On Thu, Nov 19, 2015 at 09:35:12AM +, Sifan Naeem wrote:
> The following patches are required to enchance the existing driver to
> support i2c on pistachio.
> 
> This patch series depends on the series of fixes posted earlier[1].
> The features added in this series were tested with the earlier fixes
> in place.
> 
> Tested on Pistachio bub and on tz1090 using an Adafruit I2C
> Non-Volatile FRAM Breakout (256Kbit / 32KByte) eeprom.
> 
> Used i2c buildroot tools to test the eeprom and the other i2c blocks.
> Also used dd commands to copy data to and then to dump data from the
> eeprom. i2ctransfer was used to test repeated starts and verified
> using a scope.

Applied to for-next, thanks! And thanks to James and James for the
reviews!



signature.asc
Description: Digital signature

Re: [PATCH 0/3] i2c: rcar: adapt PM usage to multi master case

2016-01-02 Thread Wolfram Sang 
On Wed, Dec 23, 2015 at 05:56:31PM +0100, Wolfram Sang wrote:
> If we are in a multi-master scenario, we need to block runtime PM so the
> arbitration circuit stays awake.
> 
> So, we define a new binding and adapt the i2c-rcar driver to have an example
> implementation.

Applied to for-next, thanks!



signature.asc
Description: Digital signature