Hi Sakari,
On 10/09/19 10:43, Sakari Ailus wrote:
> Hi Luca,
>
> On Tue, Jul 23, 2019 at 10:37:20PM +0200, Luca Ceresoli wrote:
>
> ...
>
>> +Device node example
>> +---
>> +
>> + {
>> +deser: deser@3d {
>> +compatible = "ti,ds90ub954-q1";
>> +
Hi Luca,
On Tue, Jul 23, 2019 at 10:37:20PM +0200, Luca Ceresoli wrote:
...
> +Device node example
> +---
> +
> + {
> + deser: deser@3d {
> + compatible = "ti,ds90ub954-q1";
> + reg-names = "main", "rxport0", "rxport1", "ser0", "ser1";
> +
Hi Luca,
> Now I got what you mean: the aliases in a pool are reserved to an ATR
> and not available to another ATR. What about hoisting the pool one level
> up in DT, to the adapter where the ATRs are connected?
Frankly, it sounds error prone to keep them in sync.
> As I understand it, we are
Hi Wolfram,
On 03/09/19 11:34, Wolfram Sang wrote:
>
>> Not if you define enough addresses in the pool. E.g. the DS90UB954
>> hardware can have 8 aliases per port, so if you have (n_ports * 8)
>> addresses in the pool the problem is solved.
>
> And then you plug-in somewhere another board with
> Not if you define enough addresses in the pool. E.g. the DS90UB954
> hardware can have 8 aliases per port, so if you have (n_ports * 8)
> addresses in the pool the problem is solved.
And then you plug-in somewhere another board with another need for ATR
and you are out of addresses.
> > And
Hi Wolfram,
On 02/09/19 22:48, Wolfram Sang wrote:
>
>> + - i2c-alias-pool: list of I2C addresses that are known to be available on
>> the
>> + "local" (SoC-to-deser) I2C bus; they will be picked at
>> + runtime and used as aliases to reach remove I2C chips
>
>
> + - i2c-alias-pool: list of I2C addresses that are known to be available on
> the
> + "local" (SoC-to-deser) I2C bus; they will be picked at
> +runtime and used as aliases to reach remove I2C chips
After some internal discussion, I have been kinda convinced
Hi Rob,
On 20/08/19 17:44, Rob Herring wrote:
+ - i2c-alias-pool: list of I2C addresses that are known to be available
on the
+ "local" (SoC-to-deser) I2C bus; they will be picked at
+ runtime and used as aliases to reach remove I2C chips
>>>
On Mon, Aug 19, 2019 at 5:41 PM Luca Ceresoli wrote:
>
> Hi Rob,
>
> thanks for your review.
>
> On 13/08/19 17:44, Rob Herring wrote:
> > On Tue, Jul 23, 2019 at 10:37:20PM +0200, Luca Ceresoli wrote:
> >> Describe the Texas Instruments DS90UB954-Q1, a 2-input video deserializer
> >> with I2C
Hi Rob,
thanks for your review.
On 13/08/19 17:44, Rob Herring wrote:
> On Tue, Jul 23, 2019 at 10:37:20PM +0200, Luca Ceresoli wrote:
>> Describe the Texas Instruments DS90UB954-Q1, a 2-input video deserializer
>> with I2C Address Translator and remote GPIOs.
>>
>> Signed-off-by: Luca Ceresoli
On Tue, Jul 23, 2019 at 10:37:20PM +0200, Luca Ceresoli wrote:
> Describe the Texas Instruments DS90UB954-Q1, a 2-input video deserializer
> with I2C Address Translator and remote GPIOs.
>
> Signed-off-by: Luca Ceresoli
>
> ---
>
> Changes RFCv1 -> RFCv2:
>
> - add explicit aliases for the
Describe the Texas Instruments DS90UB954-Q1, a 2-input video deserializer
with I2C Address Translator and remote GPIOs.
Signed-off-by: Luca Ceresoli
---
Changes RFCv1 -> RFCv2:
- add explicit aliases for the FPD-link RX ports (optional)
- add proper remote GPIO description
---
12 matches
Mail list logo
