Received: by 10.223.176.5 with SMTP id f5csp768600wra; Wed, 7 Feb 2018 07:15:41 -0800 (PST) X-Google-Smtp-Source: AH8x227XBsM6sGN/kYo5mdSk2fMlmuGEuGzolWljj1Ig6QYwFDJLCeQbudG7qLcYlzxg9vpq/pNT X-Received: by 10.98.137.213 with SMTP id n82mr6324539pfk.175.1518016541240; Wed, 07 Feb 2018 07:15:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518016541; cv=none; d=google.com; s=arc-20160816; b=0KP1hUqsCOc/LTdxPRxXzgezsaKqGqcEC0zdAtUZl6Eg73y8b6fClhYw5+Cuv02DOX BWElSEPBI7pq1bjI9OXVbIRdXXYm+VI0Pj5PqS1xQ9IlvSx4sbP995D2svqKzrLeEeis 2jVNRpMhXTzboXPERL6WH7ESLu6DjxTISHeD1SSzcZHyivDNSJ04tfOhddQ4YxXqdFi3 PCRQtetx5wwcf6hsf2SF7Uyb5ibu6tHEyZPInMv92STNgmXPaNPQe1t6mSDveIjcJZYN D+rHe83Bwm53K5fhfUhWR+6DlbPokLeHf0R3tsEFP0LPjzSjWdZdi924rdGHewwh3NNl 20pQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject :dkim-signature:arc-authentication-results; bh=a/Nn7XzptG8GQv7P4YS6w2GmCcDtfV4KInoMmzD8YwY=; b=yHXwKPsG7ihxUcxfIAQJOqzucyr5GlKFMoTQLYG90iC/ngLdCpfPRTUIvv1C0anlnp 0y4vgMIltB/HuRr1S7zi3HiD43oPwkg0gwDcK9w+9CegnKqv+h5QLGEDM9Go9rGJq9HI 8wAwqSikHDTgYM/tR4E2I5JLkmM/dM1DPBV9eO0GxsQzuJ7nX2uKWyiWJf/Xcue5ZdNI EVt7Ae+E6ao2oBgg3a2ITV9c/79wRw+eFtlGfxip8v9U8tY028pYov4ddObmzlLSlYAP ISAROpv6i43IHvWhvbxTP2s/7zRoneOCPlXXXWkQJ1X3L/mgbyOFudeHukzo6llMFDQN lIpQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=l77XHHeg; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b18-v6si1210572pls.191.2018.02.07.07.15.26; Wed, 07 Feb 2018 07:15:41 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=l77XHHeg; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754382AbeBGPOQ (ORCPT + 99 others); Wed, 7 Feb 2018 10:14:16 -0500 Received: from galahad.ideasonboard.com ([185.26.127.97]:38246 "EHLO galahad.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754115AbeBGPOO (ORCPT ); Wed, 7 Feb 2018 10:14:14 -0500 Received: from [192.168.0.20] (cpc89242-aztw30-2-0-cust488.18-1.cable.virginm.net [86.31.129.233]) by galahad.ideasonboard.com (Postfix) with ESMTPSA id BD4BE200AD; Wed, 7 Feb 2018 16:12:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1518016370; bh=OLhR9feFr61HM86PSjIjywc2jFm4e1aEo7gNAYHhf8Q=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=l77XHHegzpc6F6kn5JF5mQK+DVR1f59n7DhiYolZ+zuB6DIeirv/WLRkEGsew5iO7 ra4QNQ8QQLcK3Fm2DAeAxDP2qhquE8LK75mBH7YQHiJHnyLN6KFwWOwQAaX2c0mpIj 3akhLUbBAhf3FkU1WzMNExQVFalA2qHhj/w+mxbM= Subject: Re: [PATCH 2/2] drm: adv7511: Add support for i2c_new_secondary_device To: Laurent Pinchart Cc: linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Jean-Michel Hautbois , David Airlie , Rob Herring , Mark Rutland , Archit Taneja , Andrzej Hajda , John Stultz , Mark Brown , Hans Verkuil , Lars-Peter Clausen , Daniel Vetter , Bhumika Goyal , Inki Dae , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Sergei Shtylyov References: <1516625389-6362-1-git-send-email-kieran.bingham@ideasonboard.com> <1516625389-6362-3-git-send-email-kieran.bingham@ideasonboard.com> <1650729.pzuqXiNcLL@avalon> From: Kieran Bingham Organization: Ideas on Board Message-ID: <22aa9d42-e7df-cbe7-4044-3b120cd242c3@ideasonboard.com> Date: Wed, 7 Feb 2018 15:14:09 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1650729.pzuqXiNcLL@avalon> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Laurent, On 29/01/18 10:26, Laurent Pinchart wrote: > Hi Kieran, > > Thank you for the patch. Thanks for your review, > 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 >> --- >> .../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. 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. > 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>; >> 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 >> #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); >> + adv->i2c_cec = i2c_new_secondary_device(adv->i2c_main, "cec", >> + ADV7511_REG_CEC_I2C_ADDR_DEFAULT); >> 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; >> 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); >> - 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; > > I wonder if this is the right error code. Maybe -EINVAL ? In most cases errors > will be caused by invalid addresses (out of memory and device_register() > failures can happen too but should be less common). It's arbitrary, as multiple error paths simply return NULL, but I think you are right - the 'most common' fault here is likely to be an in use address. -ENOMEM was chosen here to mirror the equivalent code returned from the adv7604 driver. Either way - -EINVAL does feel better at the moment. Although when mirrored back to the ADV7604 that becomes a distinct change there. I don't think that matters though - so I'll apply this fix to both patches. > > It would be nice if i2c_new_secondary_device() returned an ERR_PTR, but that's > out of scope. I was about to say - well I'll add this, but the reality is it might require updating all users of i2c_new_device, and i2c_new_dummy. Updating i2c_new_secondary_device() on it's own seems a bit pointless otherwise. And that is definitely out of scope for the amount of time I currently have :D >> 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; >> } >