Hi Philipp,
On 09/16/2016 06:21 PM, Philipp Zabel wrote:
Hi Vladimir,
Am Mittwoch, den 14.09.2016, 21:46 +0300 schrieb Vladimir Zapolskiy:
Hi Philipp,
On 08/29/2016 06:50 PM, Rob Herring wrote:
On Wed, Aug 24, 2016 at 08:46:37AM +0300, Vladimir Zapolskiy wrote:
The change adds support of internal HDMI I2C master controller, this
subdevice is used by default, if "ddc-i2c-bus" DT property is omitted.
The main purpose of this functionality is to support reading EDID from
an HDMI monitor on boards, which don't have an I2C bus connected to
DDC pins.
The current implementation does not support "I2C Master Interface
Extended Read Mode" to read data addressed by non-zero segment
pointer, this means that if EDID has more than 1 extension blocks,
EDID reading operation won't succeed, in my practice all tested HDMI
monitors have at maximum one extension block.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@xxxxxxxxxx>
---
The change is based on top of v4.8.0-rc1 and a fix in DW HDMI driver
https://patchwork.kernel.org/patch/9284717/
Changes from v5 to v6:
* rebased on top of v4.8.0-rc1
* fixed one improper resource deallocation on error path of dw_hdmi_bind()
* added a comment describing a mutex asked by checkpatch.pl --strict
Link to version v5: https://patchwork.kernel.org/patch/7279831/
Changes from v4 to v5:
* do I2C bus controller initialization only once in bind() as it was done
in v1-v3 of the change.
Changes from v3 to v4, thanks to Doug and Philipp for review:
* set speed mode after software reset in dw_hdmi_i2c_init()
* by default set standard speed mode instead of fast speed mode, on iMX6Q
this configures SCL to 100 KHz, which is compliant with HDMI 1.3a spec
* do I2C bus controller reinitialization on every data transfer,
this change hopefully solves some observed problems on RK3288 platform
* added short functional change description to dw_hdmi.txt
v3 of the change was
Tested-by: Philipp Zabel <p.zabel@xxxxxxxxxxxxxx>
Changes from v2 to v3, thanks to Russell:
* moved register field value definitions to dw_hdmi.h
* made completions uninterruptible to avoid transfer retries if interrupted
* use one completion for both read and write transfers as in v1,
operation_reg is removed
* redundant i2c->stat = 0 is removed from dw_hdmi_i2c_read/write()
* struct i2c_algorithm dw_hdmi_algorithm is qualified as const
* dw_hdmi_i2c_adapter() does not modify struct dw_hdmi on error path
* dw_hdmi_i2c_irq() does not modify hdmi->i2c->stat, if interrupt is
not for I2CM
* spin lock is removed from dw_hdmi_i2c_irq()
* removed spin lock from dw_hdmi_i2c_xfer() around write to
HDMI_IH_MUTE_I2CM_STAT0 register
* split loop over message array in dw_hdmi_i2c_xfer() to validation
and transfer parts
* added a mutex to serialize I2C transfer requests, i2c->lock is
completely removed
* removed if(len) check from dw_hdmi_i2c_write(), hardware supports
only len>0 transfers
* described extension blocks <= 1 limitation in the commit message
* a number of minor clean ups
Changes from v1 to v2:
* fixed a devm_kfree() signature
* split completions for read and write operations
.../devicetree/bindings/display/bridge/dw_hdmi.txt | 4 +-
Acked-by: Rob Herring <robh@xxxxxxxxxx>
drivers/gpu/drm/bridge/dw-hdmi.c | 265 ++++++++++++++++++++-
drivers/gpu/drm/bridge/dw-hdmi.h | 19 ++
3 files changed, 281 insertions(+), 7 deletions(-)
as far as I know David accepts pull requests from you, can you please
create and send a pull request for v4.9 containing these changes?
https://patchwork.kernel.org/patch/9284717/ -- with Russell's ack
Is that a forward looking statement? I don't see Russell's ack.
Here it is: http://www.spinics.net/lists/dri-devel/msg115880.html
Please don't bother about two other commits from that series, at least
there are official maintainers for the changes. And by the way please
consider to add youself as a maintainer of DW HDMI.
https://patchwork.kernel.org/patch/9296883/ -- with Rob's ack and yours tested-by
Some users anticipate this change, for example see https://lkml.org/lkml/2016/9/14/55
Those I see. I can re-test and prepare a pull request.
Thank you in advance!
--
With best wishes,
Vladimir
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
