| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <5890b343-e908-688b-ba03-84c1f76411f3@ideasonboard.com>
Date: Wed, 7 Feb 2018 12:33:51 +0000
From: Kieran Bingham <kieran.bingham@...asonboard.com>
To: Archit Taneja <architt@...eaurora.org>,
linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org,
linux-kernel@...r.kernel.org, linux-renesas-soc@...r.kernel.org
Cc: Jean-Michel Hautbois <jean-michel.hautbois@...alys.com>,
David Airlie <airlied@...ux.ie>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Andrzej Hajda <a.hajda@...sung.com>,
Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
John Stultz <john.stultz@...aro.org>,
Mark Brown <broonie@...nel.org>,
Hans Verkuil <hans.verkuil@...co.com>,
Lars-Peter Clausen <lars@...afoo.de>,
Daniel Vetter <daniel.vetter@...ll.ch>,
Bhumika Goyal <bhumirks@...il.com>,
Inki Dae <inki.dae@...sung.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
Subject: Re: [PATCH 2/2] drm: adv7511: Add support for
i2c_new_secondary_device
Hi Archit,
Thank you for your review,
On 29/01/18 04:11, Archit Taneja wrote:
> Hi,
>
> On 01/22/2018 06:20 PM, 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@...asonboard.com>
>> ---
>> .../bindings/display/bridge/adi,adv7511.txt | 10 +++++-
>> 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"
>> 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>;
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> b/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> index d034b2cb5eee..7d81ce3808e0 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> @@ -53,8 +53,10 @@
>> #define ADV7511_REG_POWER 0x41
>> #define ADV7511_REG_STATUS 0x42
>> #define ADV7511_REG_EDID_I2C_ADDR 0x43
>> +#define ADV7511_REG_EDID_I2C_ADDR_DEFAULT 0x3f
>> #define ADV7511_REG_PACKET_ENABLE1 0x44
>> #define ADV7511_REG_PACKET_I2C_ADDR 0x45
>> +#define ADV7511_REG_PACKET_I2C_ADDR_DEFAULT 0x38
>> #define ADV7511_REG_DSD_ENABLE 0x46
>> #define ADV7511_REG_VIDEO_INPUT_CFG2 0x48
>> #define ADV7511_REG_INFOFRAME_UPDATE 0x4a
>> @@ -89,6 +91,7 @@
>> #define ADV7511_REG_TMDS_CLOCK_INV 0xde
>> #define ADV7511_REG_ARC_CTRL 0xdf
>> #define ADV7511_REG_CEC_I2C_ADDR 0xe1
>> +#define ADV7511_REG_CEC_I2C_ADDR_DEFAULT 0x3c
>
> Minor comment: The defines above make look like new register
> defines. It would be nice to remove the "REG_" from them, and
> place them somewhere after the register definitions.
Sure.
>> #define ADV7511_REG_CEC_CTRL 0xe2
>> #define ADV7511_REG_CHIP_ID_HIGH 0xf5
>> #define ADV7511_REG_CHIP_ID_LOW 0xf6
>> @@ -322,6 +325,7 @@ struct adv7511 {
>> struct i2c_client *i2c_main;
>> struct i2c_client *i2c_edid;
>> struct i2c_client *i2c_cec;
>> + struct i2c_client *i2c_packet;
>> struct regmap *regmap;
>> struct regmap *regmap_cec;
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> index efa29db5fc2b..7ec33837752b 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> @@ -969,8 +969,8 @@ static int adv7511_init_cec_regmap(struct adv7511 *adv)
>> {
>> int ret;
>> - adv->i2c_cec = i2c_new_dummy(adv->i2c_main->adapter,
>> - adv->i2c_main->addr - 1);
>
> This patch avoids deriving the CEC/EDID map addresses from the main map. I think
> this would break what the original patch tried to do:
That was intentional.
The ADV7511 data-sheet defines default addresses for these maps.
(or rather the hardware does)
>
> d25a4cbba4b9da7c2d674b2f8ecf84af1b24988e
> "drm/bridge: adv7511: add support for the 2nd chip"
>
> Maybe the default macros can be a function of the main address?
I'm loathed to do that, because then intrinsic knowledge must be known that if I
define a device at address X ... it will also use magic offset A B and C.
IMO - the driver should define the defaults to match the hardware.
Anything else is an override ...
<Welcoming comments, and arguments here>
>> + adv->i2c_cec = i2c_new_secondary_device(adv->i2c_main, "cec",
>> + ADV7511_REG_CEC_I2C_ADDR_DEFAULT);
>
> Also, I'm a bit unclear on the default address values. For example, previously,
> the CEC
> address was calculated as "adv->i2c_main->addr - 1", which is 0x38. The new
> CEC_I2C_ADDR_DEFAULT
> define sets it to 0x3c.
The registers defined in the programming guide [0] define default addresses
which is set by the hardware (and noteworthy, reset to; at low power mode!)
Page : Register : Default : Purpose
165 : 0x43 : 0x3f << 1 : EDID Memory Address
166 : 0x45 : 0x38 << 1 : Packet Memory I2C Map Address
181 : 0xE1 : 0x3c << 1 : CEC ID
Actually - I've just seen there's a good table at page 16 :D
The ADV7511 main register map can appear at either 0x39 or 0x3D depending on the
input to a pull-up/down pin.
Thus - that implies that perhaps Sergei must have been working on a device
located at 0x3D, to determine the offset of -1 ... but we have two values for
computing the offset depending on whether you start at 0x39 or 0x3D.
And also - I can't even be sure that I can infer the starting address, as the
offsets for the EDID and Packet do not correlate here.
[0]
http://www.analog.com/media/en/technical-documentation/user-guides/ADV7511_Programming_Guide.pdf
> Thanks,
> Archit
>
>> if (!adv->i2c_cec)
>> return -ENOMEM;
>> i2c_set_clientdata(adv->i2c_cec, adv);
>> @@ -1082,8 +1082,6 @@ static int adv7511_probe(struct i2c_client *i2c, const
>> struct i2c_device_id *id)
>> struct adv7511_link_config link_config;
>> struct adv7511 *adv7511;
>> struct device *dev = &i2c->dev;
>> - unsigned int main_i2c_addr = i2c->addr << 1;
>> - unsigned int edid_i2c_addr = main_i2c_addr + 4;
This computation doesn't correspond to anything except a random (perhaps
platform specific) offset.
>> unsigned int val;
>> int ret;
>> @@ -1153,24 +1151,35 @@ static int adv7511_probe(struct i2c_client *i2c,
>> const struct i2c_device_id *id)
>> if (ret)
>> goto uninit_regulators;
>> - regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR, edid_i2c_addr);
>> - regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
>> - main_i2c_addr - 0xa);
Packet address here is written as an offset of -0x0a, which gives 0x2f or 0x33 ... ?
I think these current offsets are platform specific to a specific platform :)
--
Regards
Kieran
>> - regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR,
>> - main_i2c_addr - 2);
>> -
>> adv7511_packet_disable(adv7511, 0xffff);
>> - adv7511->i2c_edid = i2c_new_dummy(i2c->adapter, edid_i2c_addr >> 1);
>> + adv7511->i2c_edid = i2c_new_secondary_device(i2c, "edid",
>> + ADV7511_REG_EDID_I2C_ADDR_DEFAULT);
>> if (!adv7511->i2c_edid) {
>> ret = -ENOMEM;
>> goto uninit_regulators;
>> }
>> + regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR,
>> + adv7511->i2c_edid->addr << 1);
>> +
>> ret = adv7511_init_cec_regmap(adv7511);
>> if (ret)
>> goto err_i2c_unregister_edid;
>> + regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR,
>> + adv7511->i2c_cec->addr << 1);
>> +
>> + adv7511->i2c_packet = i2c_new_secondary_device(i2c, "packet",
>> + ADV7511_REG_PACKET_I2C_ADDR_DEFAULT);
>> + if (!adv7511->i2c_packet) {
>> + ret = -ENOMEM;
>> + goto err_unregister_cec;
>> + }
>> +
>> + regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
>> + adv7511->i2c_packet->addr << 1);
>> +
>> INIT_WORK(&adv7511->hpd_work, adv7511_hpd_work);
>> if (i2c->irq) {
>> @@ -1181,7 +1190,7 @@ static int adv7511_probe(struct i2c_client *i2c, const
>> struct i2c_device_id *id)
>> IRQF_ONESHOT, dev_name(dev),
>> adv7511);
>> if (ret)
>> - goto err_unregister_cec;
>> + goto err_unregister_packet;
>> }
>> adv7511_power_off(adv7511);
>> @@ -1203,6 +1212,8 @@ static int adv7511_probe(struct i2c_client *i2c, const
>> struct i2c_device_id *id)
>> adv7511_audio_init(dev, adv7511);
>> return 0;
>> +err_unregister_packet:
>> + i2c_unregister_device(adv7511->i2c_packet);
>> err_unregister_cec:
>> i2c_unregister_device(adv7511->i2c_cec);
>> if (adv7511->cec_clk)
>> @@ -1234,6 +1245,7 @@ static int adv7511_remove(struct i2c_client *i2c)
>> cec_unregister_adapter(adv7511->cec_adap);
>> i2c_unregister_device(adv7511->i2c_edid);
>> + i2c_unregister_device(adv7511->i2c_packet);
>> return 0;
>> }
>>
>
Powered by blists - more mailing lists