public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: flora.fu@mediatek.com (Flora Fu)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/8] soc: mediatek: Add PMIC wrapper for MT8135 and MT6397 SoC
Date: Thu, 11 Dec 2014 18:04:15 +0800	[thread overview]
Message-ID: <1418292255.2315.12.camel@mtksdaap41> (raw)
In-Reply-To: <3015972.tvmzP0zTdv@wuerfel>

Hi,

On Tue, 2014-12-09 at 12:20 +0100, Arnd Bergmann wrote:
> On Tuesday 09 December 2014 11:30:15 Matthias Brugger wrote:
> > 2014-12-09 11:13 GMT+01:00 Sascha Hauer <s.hauer@pengutronix.de>:
> > > On Tue, Dec 09, 2014 at 09:23:18AM +0100, Arnd Bergmann wrote:
> > >>
> > >> I think we have had a similar case recently where a controller wasn't
> > >> actually using I2C, but the sofware protocol was close enough so we decided
> > >> to make it appear as i2c in Linux.
> > >>
> > >> Would that work for you, i.e. register the pmic wrapper as a fake spi
> > >> master driver in drivers/spi/ and register the rtc/regulator/codec
> > >> as SPI clients from DT?
> > >
> > > I don't think that's appropriate. I mean technically that could even
> > > work, but in software you really don't see anything from the underlying
> > > SPI bus. The SoC and the PMIC are really tightly coupled via the PMIC
> > > wrapper. This goes to the point where pins of the SoCs internal I2C and
> > > keypad controllers are routed over the SPI bus out of the PMIC. In
> > > software you do this by setting a bit in the I2C controller. If it's
> > > set, the signals are routed out of the PMIC instead of the main die.
> > > As said, technically we probably could create a fake SPI master, but
> > > that wouldn't really fit to this situation.
> 
> Ok, I see.
> 
> > I agree with Sascha. Although from the hardware point of view, the
> > communication between the PMIC and the SOC is done through SPI from
> > the point of view of the software everything looks like I2C commands
> > which will be "transalted" into SPI messages by the PMIC wrapper.
> 
> If it looks like i2c messages, would it be more appropriate to make
> it appear as an i2c controller then?


Although the message looks like I2C command, it is not I2C.
Form source code, the software does not touch any I2C i/o or protocols.
It depends SoC and has specific initial flow, read and write transfer
state. It is not able to an i2c controller.
That's why we consider its a proprietary hardware with specific
protocols. How about let it appear in driver/soc?

Thanks,
Flora

  reply	other threads:[~2014-12-11 10:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-05  4:07 [PATCH v3 0/8] Add Support for MediaTek PMIC MT6397 MFD Core and Regulator Flora Fu
2014-12-05  4:07 ` [PATCH v3 1/8] soc: mediatek: Add PMIC wrapper for MT8135 and MT6397 SoC Flora Fu
2014-12-05 10:13   ` Arnd Bergmann
2014-12-09  2:15     ` Flora Fu
2014-12-09  8:23       ` Arnd Bergmann
2014-12-09 10:13         ` Sascha Hauer
2014-12-09 10:30           ` Matthias Brugger
2014-12-09 11:20             ` Arnd Bergmann
2014-12-11 10:04               ` Flora Fu [this message]
2014-12-14 20:18                 ` Arnd Bergmann
2014-12-15 17:22                 ` Mark Brown
2014-12-05  4:07 ` [PATCH v3 2/8] mfd: MT6397: Add support for PMIC MT6397 MFD Flora Fu
2014-12-08  8:46   ` Lee Jones
2014-12-05  4:07 ` [PATCH v3 3/8] regulator: MT6397: Add support for MT6397 regulator Flora Fu
2014-12-24 12:41   ` Mark Brown
2014-12-05  4:07 ` [PATCH v3 4/8] dt-bindings:: Add document for MT8135 PMIC Wrapper Flora Fu
2014-12-05  4:07 ` [PATCH v3 5/8] dt-bindings: Add document for MT6397 MFD Flora Fu
2014-12-05  4:07 ` [PATCH v3 6/8] dt-bindings: Add document for MT6397 regulator Flora Fu
2014-12-24 12:41   ` Mark Brown
2014-12-05  4:07 ` [PATCH v3 7/8] ARM: dts: mt8135: Add support for MT8135 PMIC wrapper Flora Fu
2014-12-05  4:07 ` [PATCH v3 8/8] ARM: dts: mt8135: Add support for MT6397 MFD and regulator Flora Fu

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=1418292255.2315.12.camel@mtksdaap41 \
    --to=flora.fu@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.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