Hi Ivan,
On 03/25/2015 06:40 PM, Ivan T. Ivanov wrote:
Hi Sricharan,
On Fri, 2015-03-13 at 23:19 +0530, Sricharan R wrote:
#define QUP_I2C_MASTER_GEN 0x408
+#define QUP_I2C_MASTER_CONFIG 0x408
Unused.
Ok, will remove it
#define QUP_READ_LIMIT 256
+#define MX_T
Hi Ivan,
On 03/25/2015 05:54 PM, Ivan T. Ivanov wrote:
Hi Sricharan,
On Fri, 2015-03-13 at 23:19 +0530, Sricharan R wrote:
From: Andy Gross
QUP from version 2.1.1 onwards, supports a new format of
i2c command tags. Tag codes instructs the controller to
perform a operation like read/write. T
> "IN" == Ioan Nicu writes:
IN> Probe deferral is not an error case. It happens only when
IN> the necessary dependencies are not there yet.
IN> The driver core is already printing a message when a driver
IN> requests probe deferral, so this can be traced in the logs
IN> without these error p
Probe deferral is not an error case. It happens only when
the necessary dependencies are not there yet.
The driver core is already printing a message when a driver
requests probe deferral, so this can be traced in the logs
without these error prints.
This patch changes the error messages from the
On Wed, Mar 25, 2015 at 05:15:04PM +0100, Wolfram Sang wrote:
> Guenter,
>
> thanks for the update
>
> > Ultimately, the real problem is how i2c-dev accesses a client, not how
> > i2c client drivers (who assume they have exclusive access to a chip)
> > handle multi-command sequences. Forcing exte
Guenter,
thanks for the update
> Ultimately, the real problem is how i2c-dev accesses a client, not how
> i2c client drivers (who assume they have exclusive access to a chip)
> handle multi-command sequences. Forcing extensive locking on all drivers
> because of i2c-dev just doesn't seem to be th
Hi,
Just wondering if this has gotten lost in the archives?
Regards,
ZubairLK
On 11/03/15 14:26, Zubair Lutfullah Kakakhel wrote:
> Hi,
>
> Here we have two patches that add support for the i2c
> controller present in the Ingenic JZ4780.
>
> V1 - > V2
> Rebased to v4.0-rc3
> Minor tweaks/fixe
There are devices that need to handle block transactions
regardless of the capabilities exported by the adapter.
For performance reasons, they need to use i2c read blocks
if available, otherwise emulate the block transaction with word
or byte transactions.
Add support for a helper function that wo
On 03/19/2015 02:39 PM, Wolfram Sang wrote:
Turns out this is really easy to reproduce. One process reads
the eeprom over and over again, another runs i2cdump in a loop,
and voila ... lots of corruptions. Scary, especially considering
how wide-spread this kind of i2c access is in the kernel.
Hi Sricharan,
On Fri, 2015-03-13 at 23:19 +0530, Sricharan R wrote:
> #define QUP_I2C_MASTER_GEN 0x408
> +#define QUP_I2C_MASTER_CONFIG 0x408
>
Unused.
> #define QUP_READ_LIMIT 256
> +#define MX_TX_RX_LEN SZ_64K
> +#define MX_BLOCKS
Hi Sricharan,
On Fri, 2015-03-13 at 23:19 +0530, Sricharan R wrote:
> From: Andy Gross
>
> QUP from version 2.1.1 onwards, supports a new format of
> i2c command tags. Tag codes instructs the controller to
> perform a operation like read/write. This new tagging version
> supports bam dma and tr
11 matches
Mail list logo
