linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: "Ivan T. Ivanov" <iivanov@mm-sol.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Gilad Avidov <gavidov@codeaurora.org>,
	Sagar Dharia <sdharia@codeaurora.org>
Subject: Re: [PATCH] spmi-pmic-arb: support configurable number of peripherals
Date: Wed, 14 Oct 2015 15:43:56 -0700	[thread overview]
Message-ID: <561EDAAC.6060800@codeaurora.org> (raw)
In-Reply-To: <20150915182728.GA11715@codeaurora.org>

On 09/15/2015 11:27 AM, Stephen Boyd wrote:
> On 09/15, Ivan T. Ivanov wrote:
>> On Mon, 2015-09-14 at 18:28 -0700, Stephen Boyd wrote:
>>> On 09/14/2015 02:54 PM, Stephen Boyd wrote:
>>>> The current driver implementation supports only 128 peripherals.
>>>> Add support for more than 128 peripherals by taking a lazy
>>>> caching approach to the mapping tables. Instead of reading the
>>>> tables at boot given some fixed size, read them on an as needed
>>>> basis and cache the results. We still assume a max number of 512
>>>> peripherals, trading off some space for simplicity.
>>>>
>>>> Based on a patch by Gilad Avidov <gavidov@codeaurora.org> and
>>>> Sagar Dharia <sdharia@codeaurora.org>.
>>>>
>>>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>>>> ---
>>> Hi Ivan,
>>>
>>> This patch causes 8916 to crash, because there isn't a mapping for ppid
>>> 257 in the ppid to channel table. It seems that we're reading the revid
>>> from the slave id 1 pmic by going through channel 0, which seems to be
>>> setup for ppid 9 (slave id 0 and the peripheral starting at 0x900). Can
>>> we stop reading the revid registers from non-zero slave id pmic devices?
>>> That would be one solution to fix this problem. Or maybe we need to
>>> special case this in the pmic arbiter code to fold ppid 0xN01 (slave id
>>> N and address 0x100) onto channel 0 all the time?
>>>
>> Yes, we can. We are not using this information at the moment.
>> Right now, revision read is more or less for debug purposes.
>>
>> Would following patch work for you? Of course it will be difficult
> Yes the patch works fine. Feel free to add a
>
> Tested-by: Stephen Boyd <sboyd@codeaurora.org>
>
>

I have to take this back. I missed the part where some pmics are on
slave id 2 or slave id 4, so this check isn't going to work. I've
adjusted it to use sid % 2 instead and I'll resend these two patches,
but I imagine to be more robust we're going to need to add a revid node
to the DT under the SID that actually has it. Then we can search the
child nodes for a revid compatible node and do the rev probing stuff.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

  reply	other threads:[~2015-10-14 22:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-14 21:54 [PATCH] spmi-pmic-arb: support configurable number of peripherals Stephen Boyd
2015-09-15  1:28 ` Stephen Boyd
2015-09-15 11:20   ` Ivan T. Ivanov
2015-09-15 18:27     ` Stephen Boyd
2015-10-14 22:43       ` Stephen Boyd [this message]
2015-10-15  9:23         ` Ivan T. Ivanov
2015-10-15 18:24           ` Stephen Boyd
  -- strict thread matches above, loose matches on Subject: below --
2015-09-03 23:20 Gilad Avidov
2015-09-04  0:16 ` Stephen Boyd
     [not found]   ` <20150904001630.GJ15099-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-09-04 18:04     ` Gilad Avidov
2015-09-05  0:50       ` Stephen Boyd
2015-09-09 23:32         ` Gilad Avidov
2015-09-10  0:30           ` Stephen Boyd

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=561EDAAC.6060800@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=gavidov@codeaurora.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=iivanov@mm-sol.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sdharia@codeaurora.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).