From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Kieran Bingham <kieran.bingham@ideasonboard.com>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Jean-Michel Hautbois <jean-michel.hautbois@vodalys.com>,
David Airlie <airlied@linux.ie>, Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Archit Taneja <architt@codeaurora.org>,
Andrzej Hajda <a.hajda@samsung.com>,
John Stultz <john.stultz@linaro.org>,
Mark Brown <broonie@kernel.org>,
Hans Verkuil <hans.verkuil@cisco.com>,
Lars-Peter Clausen <lars@metafoo.de>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Bhumika Goyal <bhumirks@gmail.com>,
Inki Dae <inki.dae@samsung.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>
Subject: Re: [PATCH 2/2] drm: adv7511: Add support for i2c_new_secondary_device
Date: Thu, 08 Feb 2018 23:51:31 +0200 [thread overview]
Message-ID: <3477719.9Iy5Zezpfg@avalon> (raw)
In-Reply-To: <5e144334-a747-7abf-4a8c-8f6f9134143b@ideasonboard.com>
Hi Kieran,
On Thursday, 8 February 2018 01:30:43 EET Kieran Bingham wrote:
> On 07/02/18 21:59, Laurent Pinchart wrote:
> > On Wednesday, 7 February 2018 17:14:09 EET Kieran Bingham wrote:
> >> On 29/01/18 10:26, Laurent Pinchart wrote:
> >>> On Monday, 22 January 2018 14:50:00 EET Kieran Bingham wrote:
> >>>> The ADV7511 has four 256-byte maps that can be accessed via the main
> >>>> I²C ports. Each map has it own I²C address and acts as a standard slave
> >>>> device on the I²C bus.
> >>>>
> >>>> Allow a device tree node to override the default addresses so that
> >>>> address conflicts with other devices on the same bus may be resolved at
> >>>> the board description level.
> >>>>
> >>>> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> >>>> ---
> >>>>
> >>>> .../bindings/display/bridge/adi,adv7511.txt | 10 +++++-
> >>>
> >>> I don't mind personally, but device tree maintainers usually ask for DT
> >>> bindings changes to be split to a separate patch.
> >>>
> >>>> drivers/gpu/drm/bridge/adv7511/adv7511.h | 4 +++
> >>>> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 36++++++++++-----
> >>>> 3 files changed, 37 insertions(+), 13 deletions(-)
> >>>>
> >>>> diff --git
> >>>> a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> >>>> b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> >>>> index 0047b1394c70..f6bb9f6d3f48 100644
> >>>> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> >>>> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> >>>>
> >>>> @@ -70,6 +70,9 @@ Optional properties:
> >>>> rather than generate its own timings for HDMI output.
> >>>> - clocks: from common clock binding: reference to the CEC clock.
> >>>> - clock-names: from common clock binding: must be "cec".
> >>>> +- reg-names : Names of maps with programmable addresses.
> >>>> + It can contain any map needing a non-default address.
> >>>> + Possible maps names are : "main", "edid", "cec", "packet"
> >>>
> >>> Is the reg-names property (and the additional maps) mandatory or
> >>> optional ? If mandatory you should also update the existing DT sources
> >>> that use those bindings.
> >>
> >> They are currently optional. I do prefer it that way - but perhaps due to
> >> an issue mentioned below we might need to make this driver mandatory ?>>
> >>
> >>> If optional you should define which I2C addresses will be used when
> >>> the maps are not specified (and in that case I think we should go for
> >>> the addresses listed as default in the datasheet, which correspond to
> >>> the current driver implementation when the main address is 0x3d/0x7a).
> >>
> >> The current addresses do not correspond to the datasheet, even when the
> >> implementation main address is set to 0x3d.
> >
> > Don't they ? The driver currently uses the following (8-bit) I2C
> > addresses:
> >
> > EDID: main + 4 = 0x7e (0x3f)
> > Packet: main - 10 = 0x70 (0x38)
> > CEC: main - 2 = 0x78 (0x3c)
> >
> > Those are the default addresses according to section 4.1 of the ADV7511W
> > programming guide (rev. B), and they match the ones you set in this patch.
>
> Sorry - I was clearly subtracting 8bit values from a 7bit address in my
> failed assertion, to both you and Archit.
No worries.
> >> Thus, in my opinion - they are currently 'wrong' - but perhaps changing
> >> them is considered breakage too.
> >>
> >> A particular issue will arise here too - as on this device - when the
> >> device is in low-power mode (after probe, before use) - the maps will
> >> respond on their *hardware default* addresses (the ones implemented in
> >> this patch), and thus consume that address on the I2C bus regardless of
> >> their settings in the driver.
> >
> > We've discussed this previously and I share you concern. Just to make sure
> > I remember correctly, did all the secondary maps reset to their default
> > addresses, or just the EDID map ?
>
> The following responds on the bus when programmed at alternative addresses,
> and in low power mode. The responses are all 0, but that's still going to
> conflict with other hardware if it tries to use the 'un-used' addresses.
>
> Packet (0x38),
> Main (0x39),
> Fixed (set to 0 by software, but shows up at 0x3e)
> and EDID (0x3f).
>
> So actually it's only the CEC which don't respond when in "low-power-mode".
>
> As far as I can see, (git grep -B3 adi,adv75) - The r8a7792-wheat.dts is
> the only instance of a device using 0x3d, which means that Sergei's patch
> changed the behaviour of all the existing devices before that.
>
> Thus - this patch could be seen to be a 'correction' back to the original
> behaviour for all devices except the Wheat, and possibly devices added after
> Sergei's patch went in.
>
> However - by my understanding, - any device which has only one ADV75(3,1)+
> should use the hardware defined addresses (the hardware defaults will be
> conflicting on the bus anyway, thus should be assigned to the ADV7511)
>
> Any platform which uses *two* ADV7511 devices on the same bus should
> actually set *both* devices to use entirely separate addresses - or they
> will still conflict with each other.
Agreed. No access should be made to the default addresses for the secondary
I2C clients, otherwise there's a risk of conflict.
When only one ADV7511 is present, but conflicts with another device, we could
reprogram the other device only (assuming it doesn't lose its configuration in
low-power mode), or reprogram both.
> Now - if my understanding is correct - then I believe - that means that all
> existing devices except Wheat *should* be using the default addresses as
> this patch updates them to.
>
> The Wheat - has an invalid configuration - and thus should be updated
> anyway.
I agree.
> >>> You should also update the definition of the reg property that currently
> >>> just states
> >>>
> >>> - reg: I2C slave address
> >>>
> >>> And finally you might want to define the term "map" in this context.
> >>> Here's a proposal (if we make all maps mandatory).
> >>>
> >>> The ADV7511 internal registers are split into four pages exposed through
> >>> different I2C addresses, creating four register maps. The I2C addresses
> >>> of all four maps shall be specified by the reg and reg-names property.
> >>>
> >>> - reg: I2C slave addresses, one per reg-names entry
> >>> - reg-names: map names, shall be "main", "edid", "cec", "packet"
> >>>
> >>>> Required nodes:
> >>>> @@ -88,7 +91,12 @@ Example
> >>>>
> >>>> adv7511w: hdmi@39 {
> >>>> compatible = "adi,adv7511w";
> >>>>
> >>>> - reg = <39>;
> >>>> + /*
> >>>> + * The EDID page will be accessible on address 0x66 on the i2c
> >>>> + * bus. All other maps continue to use their default addresses.
> >>>> + */
> >>>> + reg = <0x39 0x66>;
> >>>> + reg-names = "main", "edid";
> >>>> interrupt-parent = <&gpio3>;
> >>>> interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
> >>>> clocks = <&cec_clock>;
[snip]
--
Regards,
Laurent Pinchart
WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Kieran Bingham <kieran.bingham@ideasonboard.com>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Jean-Michel Hautbois <jean-michel.hautbois@vodalys.com>,
David Airlie <airlied@linux.ie>, Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Archit Taneja <architt@codeaurora.org>,
Andrzej Hajda <a.hajda@samsung.com>,
John Stultz <john.stultz@linaro.org>,
Mark Brown <broonie@kernel.org>,
Hans Verkuil <hans.verkuil@cisco.com>,
Lars-Peter Clausen <lars@metafoo.de>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Bhumika Goyal <bhumirks@gmail.com>,
Inki Dae <inki.dae@samsung.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kerne>
Subject: Re: [PATCH 2/2] drm: adv7511: Add support for i2c_new_secondary_device
Date: Thu, 08 Feb 2018 23:51:31 +0200 [thread overview]
Message-ID: <3477719.9Iy5Zezpfg@avalon> (raw)
In-Reply-To: <5e144334-a747-7abf-4a8c-8f6f9134143b@ideasonboard.com>
Hi Kieran,
On Thursday, 8 February 2018 01:30:43 EET Kieran Bingham wrote:
> On 07/02/18 21:59, Laurent Pinchart wrote:
> > On Wednesday, 7 February 2018 17:14:09 EET Kieran Bingham wrote:
> >> On 29/01/18 10:26, Laurent Pinchart wrote:
> >>> On Monday, 22 January 2018 14:50:00 EET Kieran Bingham wrote:
> >>>> The ADV7511 has four 256-byte maps that can be accessed via the main
> >>>> I²C ports. Each map has it own I²C address and acts as a standard slave
> >>>> device on the I²C bus.
> >>>>
> >>>> Allow a device tree node to override the default addresses so that
> >>>> address conflicts with other devices on the same bus may be resolved at
> >>>> the board description level.
> >>>>
> >>>> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> >>>> ---
> >>>>
> >>>> .../bindings/display/bridge/adi,adv7511.txt | 10 +++++-
> >>>
> >>> I don't mind personally, but device tree maintainers usually ask for DT
> >>> bindings changes to be split to a separate patch.
> >>>
> >>>> drivers/gpu/drm/bridge/adv7511/adv7511.h | 4 +++
> >>>> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 36++++++++++-----
> >>>> 3 files changed, 37 insertions(+), 13 deletions(-)
> >>>>
> >>>> diff --git
> >>>> a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> >>>> b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> >>>> index 0047b1394c70..f6bb9f6d3f48 100644
> >>>> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> >>>> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> >>>>
> >>>> @@ -70,6 +70,9 @@ Optional properties:
> >>>> rather than generate its own timings for HDMI output.
> >>>> - clocks: from common clock binding: reference to the CEC clock.
> >>>> - clock-names: from common clock binding: must be "cec".
> >>>> +- reg-names : Names of maps with programmable addresses.
> >>>> + It can contain any map needing a non-default address.
> >>>> + Possible maps names are : "main", "edid", "cec", "packet"
> >>>
> >>> Is the reg-names property (and the additional maps) mandatory or
> >>> optional ? If mandatory you should also update the existing DT sources
> >>> that use those bindings.
> >>
> >> They are currently optional. I do prefer it that way - but perhaps due to
> >> an issue mentioned below we might need to make this driver mandatory ?>>
> >>
> >>> If optional you should define which I2C addresses will be used when
> >>> the maps are not specified (and in that case I think we should go for
> >>> the addresses listed as default in the datasheet, which correspond to
> >>> the current driver implementation when the main address is 0x3d/0x7a).
> >>
> >> The current addresses do not correspond to the datasheet, even when the
> >> implementation main address is set to 0x3d.
> >
> > Don't they ? The driver currently uses the following (8-bit) I2C
> > addresses:
> >
> > EDID: main + 4 = 0x7e (0x3f)
> > Packet: main - 10 = 0x70 (0x38)
> > CEC: main - 2 = 0x78 (0x3c)
> >
> > Those are the default addresses according to section 4.1 of the ADV7511W
> > programming guide (rev. B), and they match the ones you set in this patch.
>
> Sorry - I was clearly subtracting 8bit values from a 7bit address in my
> failed assertion, to both you and Archit.
No worries.
> >> Thus, in my opinion - they are currently 'wrong' - but perhaps changing
> >> them is considered breakage too.
> >>
> >> A particular issue will arise here too - as on this device - when the
> >> device is in low-power mode (after probe, before use) - the maps will
> >> respond on their *hardware default* addresses (the ones implemented in
> >> this patch), and thus consume that address on the I2C bus regardless of
> >> their settings in the driver.
> >
> > We've discussed this previously and I share you concern. Just to make sure
> > I remember correctly, did all the secondary maps reset to their default
> > addresses, or just the EDID map ?
>
> The following responds on the bus when programmed at alternative addresses,
> and in low power mode. The responses are all 0, but that's still going to
> conflict with other hardware if it tries to use the 'un-used' addresses.
>
> Packet (0x38),
> Main (0x39),
> Fixed (set to 0 by software, but shows up at 0x3e)
> and EDID (0x3f).
>
> So actually it's only the CEC which don't respond when in "low-power-mode".
>
> As far as I can see, (git grep -B3 adi,adv75) - The r8a7792-wheat.dts is
> the only instance of a device using 0x3d, which means that Sergei's patch
> changed the behaviour of all the existing devices before that.
>
> Thus - this patch could be seen to be a 'correction' back to the original
> behaviour for all devices except the Wheat, and possibly devices added after
> Sergei's patch went in.
>
> However - by my understanding, - any device which has only one ADV75(3,1)+
> should use the hardware defined addresses (the hardware defaults will be
> conflicting on the bus anyway, thus should be assigned to the ADV7511)
>
> Any platform which uses *two* ADV7511 devices on the same bus should
> actually set *both* devices to use entirely separate addresses - or they
> will still conflict with each other.
Agreed. No access should be made to the default addresses for the secondary
I2C clients, otherwise there's a risk of conflict.
When only one ADV7511 is present, but conflicts with another device, we could
reprogram the other device only (assuming it doesn't lose its configuration in
low-power mode), or reprogram both.
> Now - if my understanding is correct - then I believe - that means that all
> existing devices except Wheat *should* be using the default addresses as
> this patch updates them to.
>
> The Wheat - has an invalid configuration - and thus should be updated
> anyway.
I agree.
> >>> You should also update the definition of the reg property that currently
> >>> just states
> >>>
> >>> - reg: I2C slave address
> >>>
> >>> And finally you might want to define the term "map" in this context.
> >>> Here's a proposal (if we make all maps mandatory).
> >>>
> >>> The ADV7511 internal registers are split into four pages exposed through
> >>> different I2C addresses, creating four register maps. The I2C addresses
> >>> of all four maps shall be specified by the reg and reg-names property.
> >>>
> >>> - reg: I2C slave addresses, one per reg-names entry
> >>> - reg-names: map names, shall be "main", "edid", "cec", "packet"
> >>>
> >>>> Required nodes:
> >>>> @@ -88,7 +91,12 @@ Example
> >>>>
> >>>> adv7511w: hdmi@39 {
> >>>> compatible = "adi,adv7511w";
> >>>>
> >>>> - reg = <39>;
> >>>> + /*
> >>>> + * The EDID page will be accessible on address 0x66 on the i2c
> >>>> + * bus. All other maps continue to use their default addresses.
> >>>> + */
> >>>> + reg = <0x39 0x66>;
> >>>> + reg-names = "main", "edid";
> >>>> interrupt-parent = <&gpio3>;
> >>>> interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
> >>>> clocks = <&cec_clock>;
[snip]
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2018-02-08 21:51 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-22 12:49 [PATCH 0/2] Add support for i2c_new_secondary_device Kieran Bingham
2018-01-22 12:49 ` Kieran Bingham
2018-01-22 12:49 ` [PATCH 1/2] media: adv7604: " Kieran Bingham
2018-01-22 12:49 ` Kieran Bingham
2018-01-22 12:49 ` Kieran Bingham
2018-01-22 12:49 ` Kieran Bingham
2018-01-29 20:08 ` Rob Herring
2018-01-29 20:08 ` Rob Herring
2018-01-29 20:08 ` Rob Herring
2018-02-07 15:54 ` Kieran Bingham
2018-02-07 15:54 ` Kieran Bingham
2018-01-22 12:49 ` [PATCH 2/2] drm: adv7511: " Kieran Bingham
2018-01-22 12:50 ` Kieran Bingham
2018-01-22 12:50 ` Kieran Bingham
2018-01-22 12:49 ` Kieran Bingham
2018-01-22 13:00 ` Lars-Peter Clausen
2018-01-23 7:54 ` Kieran Bingham
2018-01-29 4:11 ` Archit Taneja
2018-01-29 4:11 ` Archit Taneja
2018-02-07 12:33 ` Kieran Bingham
2018-02-07 12:33 ` Kieran Bingham
2018-02-07 23:40 ` Kieran Bingham
2018-02-07 23:40 ` Kieran Bingham
2018-01-29 10:26 ` Laurent Pinchart
2018-01-29 10:26 ` Laurent Pinchart
2018-01-29 20:12 ` Rob Herring
2018-01-29 20:12 ` Rob Herring
2018-01-29 20:12 ` Rob Herring
2018-02-07 15:14 ` Kieran Bingham
2018-02-07 15:14 ` Kieran Bingham
2018-02-07 21:59 ` Laurent Pinchart
2018-02-07 21:59 ` Laurent Pinchart
2018-02-07 23:30 ` Kieran Bingham
2018-02-08 21:51 ` Laurent Pinchart [this message]
2018-02-08 21:51 ` Laurent Pinchart
2018-01-29 20:09 ` Rob Herring
2018-01-29 20:09 ` Rob Herring
2018-01-29 20:09 ` Rob Herring
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=3477719.9Iy5Zezpfg@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=a.hajda@samsung.com \
--cc=airlied@linux.ie \
--cc=architt@codeaurora.org \
--cc=bhumirks@gmail.com \
--cc=broonie@kernel.org \
--cc=daniel.vetter@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=hans.verkuil@cisco.com \
--cc=inki.dae@samsung.com \
--cc=jean-michel.hautbois@vodalys.com \
--cc=john.stultz@linaro.org \
--cc=kieran.bingham@ideasonboard.com \
--cc=lars@metafoo.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=sergei.shtylyov@cogentembedded.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.