From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
linux-samsung-soc@vger.kernel.org, b.zolnierkie@samsung.com,
Mark Brown <broonie@kernel.org>,
dri-devel@lists.freedesktop.org,
Maciej Purski <m.purski@samsung.com>,
robh+dt@kernel.org, krzk@kernel.org
Subject: Re: [PATCH 1/2] drm/bridge: add Silicon Image SiI9234 driver
Date: Fri, 11 Aug 2017 12:00:43 +0300 [thread overview]
Message-ID: <35788498.IS2VIdUVsa@avalon> (raw)
In-Reply-To: <4d5ac06c-d396-b489-65d0-a975edf6db61@samsung.com>
Hi Marek,
(now CC'ing Mark Brown with his correct e-mail address)
On Friday 11 Aug 2017 09:00:00 Marek Szyprowski wrote:
> On 2017-08-10 16:51, Laurent Pinchart wrote:
> > On Friday 04 Aug 2017 08:55:55 Marek Szyprowski wrote:
> >> Hi Laurent,
> >>
> >> Thanks for your detailed comments. Maciej resurrected some orphaned code,
> >> which is still useful today (Tomasz has left Samsung a few years ago).
> >> I'm not sure we will be able to answer all your questions without deep
> >> investigation, especially about the driver operation details, but we
> >> will try.
> >
> > Thank you.
> >
> >> On 2017-08-03 12:24, Laurent Pinchart wrote:
> >>> On Thursday 03 Aug 2017 09:45:22 Maciej Purski wrote:
> >>>> SiI9234 transmitter converts eTMDS/HDMI signal to MHL 1.0.
> >>>> It is controlled via I2C bus. Its interaction with other
> >>>> devices in video pipeline is performed mainly on HW level.
> >>>> The only interaction it does on device driver level is
> >>>> filtering-out unsupported video modes, it exposes drm_bridge
> >>>> interface to perform this operation.
> >>>>
> >>>> This patch is based on the code refactored by Tomasz Stanislawski
> >>>> <t.stanislaws@samsung.com>, which was initially developed by:
> >>>> Adam Hampson <ahampson@sta.samsung.com>
> >>>> Erik Gilling <konkers@android.com>
> >>>> Shankar Bandal <shankar.b@samsung.com>
> >>>> Dharam Kumar <dharam.kr@samsung.com>
> >>>>
> >>>> Signed-off-by: Maciej Purski <m.purski@samsung.com>
> >>>> ---
> >>>>
> >>>> .../devicetree/bindings/display/bridge/sii9234.txt | 20 +
> >>>> drivers/gpu/drm/bridge/Kconfig | 8 +
> >>>> drivers/gpu/drm/bridge/Makefile | 1 +
> >>>> drivers/gpu/drm/bridge/sii9234.c | 1019 ++++++++++
> >>>> 4 files changed, 1048 insertions(+)
> >>>> create mode 100644
> >>>>
> >>>> Documentation/devicetree/bindings/display/bridge/sii9234.txt create
> >>>> mode
> >>>> 100644 drivers/gpu/drm/bridge/sii9234.c
> >>>>
> >>>> diff --git
> >>>> a/Documentation/devicetree/bindings/display/bridge/sii9234.txt
> >>>> b/Documentation/devicetree/bindings/display/bridge/sii9234.txt new file
> >>>> mode 100644
> >>>> index 0000000..2cdf286
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/display/bridge/sii9234.txt
> >>>
> >>> DT reviewers might ask you to submit DT bindings as a separate patch.
> >>>
> >>>> @@ -0,0 +1,20 @@
> >>>> +SiI9234 Mobile HD Link Transmitter
> >>>> +
> >>>> +Required properties:
> >>>> +- compatible : "sil,sii9234".
> >>>> +- reg : I2C address for TPI interface, use 0x39
> >>>> +- vcc-supply : regulator that supplies the chip
> >>>
> >>> Is there a single power supply only ? Transceivers usually have at least
> >>> one digital and one analog power supply.
> >>
> >> Acording to the schematic there are four power supplies used for SII9234
> >> MHL chip in Trats2 board: VSIL_1.2A, VSIL_1.2C, VCC_3.3V_MHL and
> >> VCC_1.8V_MHL. First two are derived directly from VSIL_1.2 signal, which
> >> is modeled as a fixed regulator. The latter two are derived directly from
> >> VBAT using some level converter, which is controlled by the same GPIO pin
> >> as VSIL fixed regulator. Any idea how this should be represented better
> >> in device tree instead of having single vcc-supply?
> >
> > Without access to the documentation I can only guess, but it looks like
> > VSIL_1.2A and VSIL_1.2C are supposed to be powered from the same power
> > supply rail, possibly with different filters. I think they can be grouped
> > together from a DT binding point of view. The last two supplies seem
> > independent. We should thus probably model this as three separate
> > supplies.
>
> Okay, I see no problem adding support for all those three supplies, but
> I was wondering how to model them in the device tree, because from the
> software perspective ALL power supplies needed by this chip are enabled by a
> single GPIO line switch.
>
> I see 3 possible solutions:
> 1. Keep only single vcc supply for now and use fixed gpio regulator for it
> as a provider. Add a comment that it fact it provides 3 different power
> signals.
> 2. Extend fixed gpio regulator driver and bindings so it will be possible to
> have more than one fixed regulator controlled by the same gpio pin.
> 3. Model VCC_3.3V_MHL and VCC_1.8V_MHL providers as "vctrl-regulator" and
> use this VSIL_1.2 as control voltage for them.
>
> Which one do you prefer?
2 would be best I think, but that's more work. Mark, what do you think ?
> > It would be useful to check in the SII9234 datasheet what power sequence
> > the chip expects. Is there any chance you could find that document ?
>
> We have access only to the parts of the SII9234 documentation now and
> there is no
> such information there.
>
> >>>> +- interrupts, interrupt-parent: interrupt specifier of INT pin
> >>>> +- reset-gpios: gpio specifier of RESET pin
> >>>
> >>> Is this mandatory to connect the reset pin to the SoC ?
> >>
> >> IMHO yes, the chip has to be reset during the initialization procedure
> >> and doesn't work properly without reset.
> >
> > OK, I have no issue making the property mandatory then.
>
> Best regards
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-08-11 9:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20170803074535eucas1p107414859fa54647d1f623c73d0fc17f2@eucas1p1.samsung.com>
2017-08-03 7:45 ` [PATCH 0/2] add Silicon Image SiI9234 driver Maciej Purski
[not found] ` <CGME20170803074538eucas1p1fec88e4f2c3ebc00054fd362a504c03e@eucas1p1.samsung.com>
2017-08-03 7:45 ` [PATCH 1/2] drm/bridge: " Maciej Purski
2017-08-03 10:24 ` Laurent Pinchart
2017-08-04 6:55 ` Marek Szyprowski
2017-08-10 14:51 ` Laurent Pinchart
2017-08-11 7:00 ` Marek Szyprowski
2017-08-11 8:59 ` Laurent Pinchart
2017-08-11 9:00 ` Laurent Pinchart [this message]
2017-08-14 16:35 ` Mark Brown
2017-08-03 19:36 ` kbuild test robot
[not found] ` <1501746323-5254-2-git-send-email-m.purski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2017-08-03 19:36 ` [PATCH] drm/bridge: fix platform_no_drv_owner.cocci warnings kbuild test robot
2017-08-12 22:43 ` [PATCH 1/2] drm/bridge: add Silicon Image SiI9234 driver kbuild test robot
[not found] ` <CGME20170803074541eucas1p2b054d4853a98819fc42f19f7cae7f419@eucas1p2.samsung.com>
2017-08-03 7:45 ` [PATCH 2/2] ARM: dts: exynos: Add HDMI and Sil9234 to Trats2 board Maciej Purski
2017-08-03 19:20 ` Krzysztof Kozlowski
2017-08-04 6:32 ` Marek Szyprowski
2017-08-04 6:44 ` Krzysztof Kozlowski
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=35788498.IS2VIdUVsa@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=b.zolnierkie@samsung.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=krzk@kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.purski@samsung.com \
--cc=m.szyprowski@samsung.com \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
/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).