On Tue, Jul 24, 2018 at 5:46 PM, Geert Uytterhoeven
<geert@xxxxxxxxxxxxxx> wrote:
> Hi Arnd,
>
> On Tue, Jul 24, 2018 at 5:40 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>> On Tue, Jul 24, 2018 at 5:15 PM, Geert Uytterhoeven
>> <geert@xxxxxxxxxxxxxx> wrote:
>> > On Tue, Jul 24, 2018 at 5:05 PM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>>
>> >> That's not the case I was describing here, I was thinking of what
>> >> Wolfram described with the Renesas SoC that has two i2c masters
>> >> multiplexed through the pinmux layer. I would assume that we
>> >> can still do the same thing in i3c by shutting down the current
>> >> master without a handover, and reprobing everything from scratch.
>> >
>> > The major disadvantage of reprobing is that it may cause visual disturbances
>> > when i2c slaves are involved with e.g. the display pipeline (think HDMI encoders
>> > etc.).
>>
>> Do you mean we should reuse the device pointer and association with
>> the driver even when we switch out the i3c master using the pinmux?
>>
>> Or do you mean we need to be prepared for driving a single
>> slave through multiple masters over the lifetime of that device,
>> but using the i3c master handover protocol?
>> In the second case, how do we decide which master to use
>> for accessing a device for a given request?
>
> I'll have to defer to Wolfram. He's the i2c and muxing expert.
On i2c, we only have the first case, and Wolfram said that it
intentionally does the reprobe to avoid the problems we discussed.
The question is what to do about this if it happens again on i3c.
Peter seemed to think that it was possibly something we might
have to handle, while Boris said that it wouldn't be because it's
not coverered by the i3c spec.
The second case is the one that started the discussion, and
this is where I said I'd prefer to associate each slave with at
most one master at boot time, while the current v6 patch
is prepared for having one slave be accessed alternatingly
by multiple masters using the master handover, though so
far nobody has been able to describe exactly how we'd pick
which master is active at what point, or what specific scenario
would require it.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
