From: vitor <vitor.soares@synopsys.com>
To: Przemyslaw Gaj <pgaj@cadence.com>, vitor <vitor.soares@synopsys.com>
Cc: linux-i3c@lists.infradead.org,
Boris Brezillon <boris.brezillon@collabora.com>,
rafalc@cadence.com, agolec@cadence.com, bbrezillon@kernel.org
Subject: Re: [PATCH v4 1/6] i3c: add addr and lvr to i2c_dev_desc structure
Date: Tue, 2 Apr 2019 12:32:41 +0100 [thread overview]
Message-ID: <b9a810fb-6d92-1d8b-c2e0-35d3617e4e64@synopsys.com> (raw)
In-Reply-To: <20190402112244.GA23976@global.cadence.com>
On 02/04/19 12:22, Przemyslaw Gaj wrote:
> Hi,
>
> The 04/02/2019 12:10, vitor wrote:
>> Hi,
>>
>>
>> On 01/04/19 20:24, Boris Brezillon wrote:
>>> On Mon, 1 Apr 2019 19:48:45 +0100
>>> vitor <vitor.soares@synopsys.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> On 01/04/19 19:31, Boris Brezillon wrote:
>>>>> On Mon, 1 Apr 2019 19:17:03 +0100
>>>>> vitor <vitor.soares@synopsys.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 30/03/19 14:36, Boris Brezillon wrote:
>>>>>>> On Sun, 10 Mar 2019 13:58:38 +0000
>>>>>>> Przemyslaw Gaj <pgaj@cadence.com> wrote:
>>>>>>>
>>>>>>>> I need to store address and lvr value for I2C devices without static definition
>>>>>>>> in DT. This allows secondary master to transmit DEFSLVS command properly.
>>>>>>>>
>>>>>>>> Signed-off-by: Przemyslaw Gaj <pgaj@cadence.com>
>>>>>>>> ---
>>>>>>>> include/linux/i3c/master.h | 5 +++++
>>>>>>>> 1 file changed, 5 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h
>>>>>>>> index eca8337..3c27d9f 100644
>>>>>>>> --- a/include/linux/i3c/master.h
>>>>>>>> +++ b/include/linux/i3c/master.h
>>>>>>>> @@ -71,6 +71,9 @@ struct i2c_dev_boardinfo {
>>>>>>>> * @common: common part of the I2C device descriptor
>>>>>>>> * @boardinfo: pointer to the boardinfo attached to this I2C device
>>>>>>>> * @dev: I2C device object registered to the I2C framework
>>>>>>>> + * @addr: I2C device address
>>>>>>>> + * @lvr: LVR (Legacy Virtual Register) needed by the I3C core to know about
>>>>>>>> + * the I2C device limitations
>>>>>>>> *
>>>>>>>> * Each I2C device connected on the bus will have an i2c_dev_desc.
>>>>>>>> * This object is created by the core and later attached to the controller
>>>>>>>> @@ -84,6 +87,8 @@ struct i2c_dev_desc {
>>>>>>>> struct i3c_i2c_dev_desc common;
>>>>>>>> const struct i2c_dev_boardinfo *boardinfo;
>>>>>>>> struct i2c_client *dev;
>>>>>>>> + u16 addr;
>>>>>>>> + u8 lvr;
>>>>>>> You also need to remove lvr from i2c_dev_boardinfo and adjust the code
>>>>>>> to use i2c_dev_desc->addr and i2c_dev_desc->lvr in this patch, not in
>>>>>>> patch 3.
>>>>>>>
>>>>>> Why can't we keep the lvr and addr in i2c_dev_boardinfo and need this information on i2c_dev_desc?
>>>>> Because i2c_dev_boardinfo is extracted from the DT and the secondary
>>>>> slaves does not necessarily have this description. The idea is to keep
>>>>> reserving the address slot for the I2C device even if we don't expose
>>>>> it to the upper layers.
>>>> So you are using i2c_dev_boardinfo just for DT devices?
>>> All devices that are described in some way, can be through DT, ACPI or
>>> board-file desc (only DT is supported right now, but we can easily add
>>> support for other formats).
>> We can drop i2c_dev_boardinfo.
>>
> Why you think we can drop it? We are still using it for DT devices.
Until now you need it to hold LVR, if you pass it to i2c_dev_desc, the i2c_board_info can be used for DT.
>
>>>> Because at end we need to register the new i2c devs.
>>> No, only those that have a valid description, because there's nothing
>>> you can expose if you only have the address and LVR values. You at
>>> least need to know which driver this dev should be attached to
>>> (compatible string in your DT) and most drivers also need extra
>>> information (basically all the DT props that are described a the DT
>>> binding).
>> In any case the HC need to know the bus mode, how is this done?
> LVR is passed through DEFSLVS command.
Is HC driver who set the bus mode? Shouldn't be the subsystem when you register all devices?
_______________________________________________
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
next prev parent reply other threads:[~2019-04-02 11:32 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-10 13:58 [PATCH v4 0/6] Add the I3C mastership request Przemyslaw Gaj
2019-03-10 13:58 ` [PATCH v4 1/6] i3c: add addr and lvr to i2c_dev_desc structure Przemyslaw Gaj
2019-03-30 14:36 ` Boris Brezillon
2019-04-01 18:17 ` vitor
2019-04-01 18:31 ` Boris Brezillon
2019-04-01 18:48 ` vitor
2019-04-01 19:10 ` Przemyslaw Gaj
2019-04-01 19:24 ` Boris Brezillon
2019-04-02 11:10 ` vitor
2019-04-02 11:22 ` Przemyslaw Gaj
2019-04-02 11:32 ` vitor [this message]
2019-04-02 11:53 ` Boris Brezillon
2019-04-02 11:48 ` Boris Brezillon
2019-03-10 13:58 ` [PATCH v4 2/6] i3c: export bus maintenance lock and unlock functions Przemyslaw Gaj
2019-03-10 13:58 ` [PATCH v4 3/6] i3c: Add support for mastership request to I3C subsystem Przemyslaw Gaj
2019-03-30 15:06 ` Boris Brezillon
2019-04-01 18:41 ` vitor
2019-04-01 19:18 ` Boris Brezillon
2019-04-09 14:31 ` Vitor Soares
2019-04-09 15:20 ` Przemyslaw Gaj
2019-04-09 15:46 ` Vitor Soares
2019-04-10 6:53 ` Przemyslaw Gaj
2019-04-10 10:05 ` Vitor Soares
2019-04-10 10:36 ` Boris Brezillon
2019-04-12 14:28 ` Vitor Soares
2019-04-12 14:57 ` Boris Brezillon
2019-04-15 12:02 ` Vitor Soares
2019-04-15 13:08 ` Boris Brezillon
2019-03-10 13:58 ` [PATCH v4 4/6] i3c: master: cdns: add support for mastership request to Cadence I3C master driver Przemyslaw Gaj
2019-03-30 15:44 ` Boris Brezillon
2019-04-29 10:36 ` Przemyslaw Gaj
2019-05-18 7:34 ` Boris Brezillon
2019-03-10 13:58 ` [PATCH v4 5/6] i3c: master: Add module author Przemyslaw Gaj
2019-03-10 13:58 ` [PATCH v4 6/6] MAINTAINERS: add myself as co-maintainer of i3c subsystem Przemyslaw Gaj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b9a810fb-6d92-1d8b-c2e0-35d3617e4e64@synopsys.com \
--to=vitor.soares@synopsys.com \
--cc=agolec@cadence.com \
--cc=bbrezillon@kernel.org \
--cc=boris.brezillon@collabora.com \
--cc=linux-i3c@lists.infradead.org \
--cc=pgaj@cadence.com \
--cc=rafalc@cadence.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).