All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Lartey <ian@slimlogic.co.uk>
To: Laxman Dewangan <ldewangan@nvidia.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"broonie@opensource.wolfsonmicro.com" 
	<broonie@opensource.wolfsonmicro.com>, "lrg@ti.com" <lrg@ti.com>,
	"sameo@linux.intel.com" <sameo@linux.intel.com>,
	Graeme Gregory <gg@slimlogic.co.uk>
Subject: Re: [PATCH 2/2] mfd: palmas add variant and OTP detection
Date: Fri, 22 Feb 2013 15:52:36 +0000	[thread overview]
Message-ID: <51279444.7060308@slimlogic.co.uk> (raw)
In-Reply-To: <512748DF.8080401@nvidia.com>

On 22/02/13 10:30, Laxman Dewangan wrote:
> On Friday 22 February 2013 06:22 AM, Ian Lartey wrote:
>> From: Graeme Gregory <gg@slimlogic.co.uk>
>>
>> Read the chip varient and the OTP information from the chip and display
>> this on probe to aid in debugging of issues.
>>
>
>> +    /* Read varient info from the device */
>> +    slave = PALMAS_BASE_TO_SLAVE(PALMAS_ID_BASE);
>> +    addr = PALMAS_BASE_TO_REG(PALMAS_ID_BASE, PALMAS_PRODUCT_ID_LSB);
>> +    ret = regmap_read(palmas->regmap[slave], addr, &reg);
>> +    if (ret < 0) {
>> +        dev_err(palmas->dev, "Unable to read ID err: %d\n", ret);
>> +        goto err;
>> +    }
>> +
>
> Can you please use the api palmas_* for reading register which I added
> recently. This will reduce the calc of slave and addr and done in single
> call?
> Same of following code also.

Will do.
>
>
> Also can we move all these new code to one function where we read id and
> diaplay. To keep probe() smaller.

Yes, I'll do that too.
>
>
>> +    palmas->id = reg;
>> +
>> +    slave = PALMAS_BASE_TO_SLAVE(PALMAS_ID_BASE);
>> +    addr = PALMAS_BASE_TO_REG(PALMAS_ID_BASE, PALMAS_PRODUCT_ID_MSB);
>> +    ret = regmap_read(palmas->regmap[slave], addr, &reg);
>> +    if (ret < 0) {
>> +        dev_err(palmas->dev, "Unable to read ID err: %d\n", ret);
>> +        goto err;
>> +    }
>> +
>> +    palmas->id |= reg << 8;
>
> Is it possible to change variable name id to product_id and then update
> to have more meaningful name?
> We can add for vendor_id also if require.

The rename of id to product_id is fine, if this what you mean by
"update to have a more meaningful name" then I agree.
Though if you wish for a additional change, I am not sure what the 
additional change is.

>
>> +
>> +    dev_info(palmas->dev, "Product ID %x\n", palmas->id);
>> +
>> +    slave = PALMAS_BASE_TO_SLAVE(PALMAS_DESIGNREV_BASE);
>> +    addr = PALMAS_BASE_TO_REG(PALMAS_DESIGNREV_BASE, PALMAS_DESIGNREV);
>> +    ret = regmap_read(palmas->regmap[slave], addr, &reg);
>> +    if (ret < 0) {
>> +        dev_err(palmas->dev, "Unable to read DESIGNREV err: %d\n", ret);
>> +        goto err;
>> +    }
>> +
>> +    palmas->designrev = reg & PALMAS_DESIGNREV_DESIGNREV_MASK;
>> +
>> +    dev_info(palmas->dev, "Product Design Rev %x\n", palmas->designrev);
>> +
>> +    slave = PALMAS_BASE_TO_SLAVE(PALMAS_PMU_CONTROL_BASE);
>> +    addr = PALMAS_BASE_TO_REG(PALMAS_PMU_CONTROL_BASE,
>> PALMAS_SW_REVISION);
>> +    ret = regmap_read(palmas->regmap[slave], addr, &reg);
>> +    if (ret < 0) {
>> +        dev_err(palmas->dev, "Unable to read SW_REVISION err: %d\n",
>> +                ret);
>> +        goto err;
>> +    }
>> +
>> +    palmas->sw_revision = reg;
>> +
>> +    dev_info(palmas->dev, "Product SW Rev %x\n", palmas->sw_revision);
>> +
>
>
> Here designrev also says the ES version and sw revision says the OTP SW
> revision.
> TI has make the design revision as ES1.0, ES2.0, ES2.1, ES2.2 like this
> and other technical names are 0xA0, 0xB0, 0xB1, 0xB2 etc.
>
> Probably I will add this in follow on patch becasue we have some errata
> which we need to implement based on the version number.

OK, I'll not make this change in favour of your later patch.
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


  reply	other threads:[~2013-02-22 15:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-22  0:52 [PATCH 1/2] regulator: palmas fix SMPS no voltages Ian Lartey
2013-02-22  0:52 ` [PATCH 2/2] mfd: palmas add variant and OTP detection Ian Lartey
2013-02-22 10:30   ` Laxman Dewangan
2013-02-22 15:52     ` Ian Lartey [this message]
2013-02-22 10:41 ` [PATCH 1/2] regulator: palmas fix SMPS no voltages Laxman Dewangan

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=51279444.7060308@slimlogic.co.uk \
    --to=ian@slimlogic.co.uk \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=gg@slimlogic.co.uk \
    --cc=ldewangan@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@ti.com \
    --cc=sameo@linux.intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.