Document the I2C device tree binding for Broadcom iProc family of
SoCs
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
.../devicetree/bindings/i2c/brcm,iproc-i2c.txt | 37
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c
Add I2C device nodes and its properties in bcm-cygnus.dtsi but keep
them disabled there. Individual I2C devices can be enabled in board
specific dts file when I2C slave devices are enabled in the future
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm/boot/dts/bcm-cygnus.dtsi |
Add initial support to the Broadcom iProc I2C controller found in the
iProc family of SoCs.
The iProc I2C controller has separate internal TX and RX FIFOs, each has
a size of 64 bytes. The iProc I2C controller supports two bus speeds
including standard mode (100kHz) and fast mode (400kHz)
Signed-
This patchset contains the initial I2C support for Broadcom iProc family of
SoCs.
The iProc I2C controller has separate internal TX and RX FIFOs, each has a
size of 64 bytes. The iProc I2C controller supports two bus speeds including
standard mode (100 kHz) and fast mode (400 kHz)
Changes from v3
On Wed, Jan 14, 2015 at 07:24:22PM +0200, Pantelis Antoniou wrote:
> I’ll try to dig around tomorrow and see what the real device reference counts
> are, but my hunch goes like this:
>
> MUX
> +—- ADAPTER
> +— DEV.
>
> Mux remove method is called, i2c_del_mux_adapter is called on all the chan
On 1/13/2015 11:51 PM, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Jan 13, 2015 at 06:14:17PM -0800, Ray Jui wrote:
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
>>> irq == 0 should be handled as error, too.
>>>
>> Ah. I thought zero is a valid global interrupt number, and I s
Hi,
Expect something tonight should the latest tests run okay. I needed to include
an EPROBE_DEFER to address the unavailibity of the pci driver needed in order to
request the lock during probe of the i2c device. This due to the lock now being
requested during probe because of the hang.
Dave
On
Hi Jean,
> On Jan 14, 2015, at 19:14 , Jean Delvare wrote:
>
> Hi Guenter,
>
> On Wed, 14 Jan 2015 08:24:43 -0800, Guenter Roeck wrote:
>> On Wed, Jan 14, 2015 at 04:15:25PM +0100, Jean Delvare wrote:
>>> I did that. On my system the i2c-i801 driver instantiates an
>>> i2c-mux-gpio device. Unlo
Hi Guenter,
On Wed, 14 Jan 2015 08:24:43 -0800, Guenter Roeck wrote:
> On Wed, Jan 14, 2015 at 04:15:25PM +0100, Jean Delvare wrote:
> > I did that. On my system the i2c-i801 driver instantiates an
> > i2c-mux-gpio device. Unloading the i2c-i801 driver removes that device
> > and it works fine. No
On Wed, Jan 14, 2015 at 04:15:25PM +0100, Jean Delvare wrote:
> On Wed, 14 Jan 2015 15:54:52 +0200, Pantelis Antoniou wrote:
> > On Jan 14, 2015, at 15:49 , Jean Delvare wrote:
> > > That being said, nobody complained about this in 11 years, so I would
> > > be surprised if it was plain wrong. I'd
On Wed, Jan 14, 2015 at 04:18:56PM +0200, Pantelis Antoniou wrote:
> Hi Guenter,
>
> > On Jan 14, 2015, at 16:14 , Guenter Roeck wrote:
> >
> > On 01/14/2015 05:54 AM, Pantelis Antoniou wrote:
> >
> >>> That being said, nobody complained about this in 11 years, so I would
> >>> be surprised if
On Wed, 14 Jan 2015 15:54:52 +0200, Pantelis Antoniou wrote:
> On Jan 14, 2015, at 15:49 , Jean Delvare wrote:
> > That being said, nobody complained about this in 11 years, so I would
> > be surprised if it was plain wrong. I'd rather question the test code.
> > Where is it?
>
> No-one has appar
Am Mittwoch, den 14.01.2015, 15:25 +0100 schrieb Wolfram Sang:
> On Tue, Jan 06, 2015 at 03:48:21PM +0100, Philipp Zabel wrote:
> > This patch fixes up some whitespace issues and addresses a few
> > checkpatch warnings.
>
> Well, since you asked for it... I am not so strict with the 80 char
> limi
On Tue, Jan 06, 2015 at 03:48:21PM +0100, Philipp Zabel wrote:
> This patch fixes up some whitespace issues and addresses a few
> checkpatch warnings.
Well, since you asked for it... I am not so strict with the 80 char
limit:
> @@ -527,8 +528,10 @@ static int i2c_imx_start(struct imx_i2c_struct *
On Tue, Jan 06, 2015 at 03:48:20PM +0100, Philipp Zabel wrote:
> The ret variable is set and never used in the error path of
> i2c_imx_dma_request.
>
> Signed-off-by: Philipp Zabel
Applied to for-next, thanks!
signature.asc
Description: Digital signature
Hi Guenter,
> On Jan 14, 2015, at 16:14 , Guenter Roeck wrote:
>
> On 01/14/2015 05:54 AM, Pantelis Antoniou wrote:
>
>>> That being said, nobody complained about this in 11 years, so I would
>>> be surprised if it was plain wrong. I'd rather question the test code.
>>> Where is it?
>>>
>>
>>
On 01/14/2015 05:54 AM, Pantelis Antoniou wrote:
That being said, nobody complained about this in 11 years, so I would
be surprised if it was plain wrong. I'd rather question the test code.
Where is it?
No-one has apparently tested removing an i2c mux device on a running system
before.
Hi P
On Tue, Jan 06, 2015 at 03:48:19PM +0100, Philipp Zabel wrote:
> If the i2c device tree nodes don't contain the dmas and dma-names property, an
> error is displayed for each i2c device:
>
> of_dma_request_slave_channel: dma-names property of node
> '/soc/aips-bus@0210/i2c@021a' missin
Hi Michael,
> On Jan 14, 2015, at 16:06 , Michael Lawnick wrote:
>
> Am 14.01.2015 um 14:54 schrieb Pantelis Antoniou:
>> Hi Jean,
>>
>>> On Jan 14, 2015, at 15:49 , Jean Delvare wrote:
> ...
>>> That being said, nobody complained about this in 11 years, so I would
>>> be surprised if it was p
Am 14.01.2015 um 14:54 schrieb Pantelis Antoniou:
Hi Jean,
On Jan 14, 2015, at 15:49 , Jean Delvare wrote:
...
That being said, nobody complained about this in 11 years, so I would
be surprised if it was plain wrong. I'd rather question the test code.
Where is it?
No-one has apparently te
Hi Jean,
> On Jan 14, 2015, at 15:49 , Jean Delvare wrote:
>
> Hi Wolfram, Pantelis,
>
> On Tue, 13 Jan 2015 16:29:57 +0100, Wolfram Sang wrote:
>> On Mon, Jan 12, 2015 at 07:00:50PM +0200, Pantelis Antoniou wrote:
>>> Waiting for the device release method to be called when
>>> going through i2
Hi Wolfram, Pantelis,
On Tue, 13 Jan 2015 16:29:57 +0100, Wolfram Sang wrote:
> On Mon, Jan 12, 2015 at 07:00:50PM +0200, Pantelis Antoniou wrote:
> > Waiting for the device release method to be called when
> > going through i2c_del_adapter is wrong and leads to deadlock
> > when removing an i2c m
On Mon, Dec 29, 2014 at 03:48:48PM +0200, Mika Westerberg wrote:
> ACPI specification allows I2C devices with multiple addresses. The current
> implementation goes over all addresses and assigns the last one to the
> device. This is typically not the primary address of the device.
>
> Instead of d
On Wed, Jan 14, 2015 at 12:04:59AM +0530, Harini Katakam wrote:
> Cadence I2C controller has the following bugs:
> - completion indication is not given to the driver at the end of
> a read/receive transfer with HOLD bit set.
> - Invalid read transaction are generated on the bus when HW timeout
> co
Allow bus clock specification as a common clock handle. This makes this
controller easier to use in a setup based on common clock framework.
Signed-off-by: Max Filippov
---
.../devicetree/bindings/i2c/i2c-ocores.txt | 4 ++-
drivers/i2c/busses/i2c-ocores.c| 38 ++
25 matches
Mail list logo