From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
To: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Caesar Wang <wxt@rock-chips.com>,
heiko@sntech.de, mark.rutland@arm.com,
devicetree@vger.kernel.org, linux@arm.linux.org.uk,
pawel.moll@arm.com, ijc+devicetree@hellion.org.uk,
linus.walleij@linaro.org, linux-kernel@vger.kernel.org,
linux-rockchip@lists.infradead.org, robh+dt@kernel.org,
galak@codeaurora.org, matthias.bgg@gmail.com,
jay.xu@rock-chips.com, linux-arm-kernel@lists.infradead.org,
Maxime Ripard <maxime.ripard@free-electrons.com>
Subject: Re: [PATCH v2 0/3] Add the efuse driver on rockchip platform
Date: Thu, 18 Jun 2015 09:29:31 +0100 [thread overview]
Message-ID: <5582816B.5020208@linaro.org> (raw)
In-Reply-To: <55826D9D.2060106@i2se.com>
On 18/06/15 08:05, Stefan Wahren wrote:
> Hi Srinivas,
>
> Am 16.06.2015 um 12:54 schrieb Srinivas Kandagatla:
>>
>>
>> On 16/06/15 11:06, Caesar Wang wrote:
>>> Hi Srinivas,
>>>
>>> 在 2015年06月16日 17:21, Srinivas Kandagatla 写道:
>>>> Hi Stefan,
>>>>
>>>>
>>>> On 16/06/15 09:52, Stefan Wahren wrote:
>>>>> Hi Caesar,
>>>>>
>>>>> [add Maxime and Srinivas]
>>>>>
>>>>> Am 16.06.2015 um 09:27 schrieb Caesar Wang:
>>>>>> The original driver is uploaded by Jianqun.
>>>>>> Here is his patchs:
>>>>>> https://patchwork.kernel.org/patch/5410341/
>>>>>> https://patchwork.kernel.org/patch/5410351/
>>>>>>
>>>>>> Jianqun, nevermind!
>>>>>> I check-pick it and re-upload the driver for the upstream.
>>>>>> e.g.:
>>>>>> Tested by on minnie board.(kernel-4.1-rc8)
>>>>>> cd /sys/devices/platform/ffb40000.efuse
>>>>>> localhost ffb40000.efuse # cat cpu_leakage_show
>>>>>> cpu_version_show
>>>>>> The results:
>>>>>> 19
>>>>>> 2
>>>>>>
>>>>>> Changes in v2:
>>>>>> - Change the document decription.
>>>>>> - Move the efuse driver into driver/soc/vendor.
>>>>>> - update the efuse driver.
>>>>>> - Add the dts node on RK3288.
>>>>>>
>>>>>>
>>>>>
>>>>> i want to mention that there is a upcoming new framework suitable for
>>>>> efuse drivers:
>>>>>
>>>>> https://lkml.org/lkml/2015/5/21/643
>>>>>
>>>>> Unfortunately i don't know the current development state.
>>>>>
>>>>
>>>> Currently this framework is used by atleast 3 drivers(qcom-tsens,
>>>> qcom-cpr, begel-bone-cape manager) which are still floating in the
>>>> mailing list.
>>>>
>>>> I was hoping that these 3 users would getback with tested-by.. which
>>>> did not happen for last 3-4 weeks.
>>>>
>>>> I would appreciate, If you could try framework too, and let me know.
>>>
>
> yes i work on OCOTP driver for MXS platform and i will try ...
>
>>
>> int rockchip_efuse_reg_read(void *context, unsigned int reg, unsigned
>> int *val)
>> {
>> /* efuse specific read sequence */
>> ...
>> }
>
> I will need a specific read sequence too.
You can have a look at
https://git.linaro.org/people/srinivas.kandagatla/linux.git/blob/b4c3ad253747767511233687436f20144e850d67:/drivers/nvmem/rockchip-efuse.c
I did modify the rockchip driver, which I guess should be very much
similar to what OCOTP driver would need.
>
> Sorry for these newbie questions:
>
> What data structure does context points to for this reg_read opteration?
>
> Do we need range checking of reg or is it handled by the framework?
>
We already have that in place.
> Are there any limitation for reg_read regarding sleeping or locking
> operations?
There are no limitaions as such from nvmem framework, regmap might have
limitations w.r.t to sleeping and fast_io, as fast_io would take
spinlocks, AFAIK the providers would not have fast_io, as they not IO
devices.
>
> In case of a read only driver, is everything handle by devicetree or do
> we need an empty write operation?
Yes, if you pass read-only flag in the provider, the framework would not
attempt to even write.
You will find answers to most of your question in the rochip-efuse.c file.
--srini
>
> Best regards
> Stefan
>
WARNING: multiple messages have this Message-ID (diff)
From: srinivas.kandagatla@linaro.org (Srinivas Kandagatla)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/3] Add the efuse driver on rockchip platform
Date: Thu, 18 Jun 2015 09:29:31 +0100 [thread overview]
Message-ID: <5582816B.5020208@linaro.org> (raw)
In-Reply-To: <55826D9D.2060106@i2se.com>
On 18/06/15 08:05, Stefan Wahren wrote:
> Hi Srinivas,
>
> Am 16.06.2015 um 12:54 schrieb Srinivas Kandagatla:
>>
>>
>> On 16/06/15 11:06, Caesar Wang wrote:
>>> Hi Srinivas,
>>>
>>> ? 2015?06?16? 17:21, Srinivas Kandagatla ??:
>>>> Hi Stefan,
>>>>
>>>>
>>>> On 16/06/15 09:52, Stefan Wahren wrote:
>>>>> Hi Caesar,
>>>>>
>>>>> [add Maxime and Srinivas]
>>>>>
>>>>> Am 16.06.2015 um 09:27 schrieb Caesar Wang:
>>>>>> The original driver is uploaded by Jianqun.
>>>>>> Here is his patchs:
>>>>>> https://patchwork.kernel.org/patch/5410341/
>>>>>> https://patchwork.kernel.org/patch/5410351/
>>>>>>
>>>>>> Jianqun, nevermind!
>>>>>> I check-pick it and re-upload the driver for the upstream.
>>>>>> e.g.:
>>>>>> Tested by on minnie board.(kernel-4.1-rc8)
>>>>>> cd /sys/devices/platform/ffb40000.efuse
>>>>>> localhost ffb40000.efuse # cat cpu_leakage_show
>>>>>> cpu_version_show
>>>>>> The results:
>>>>>> 19
>>>>>> 2
>>>>>>
>>>>>> Changes in v2:
>>>>>> - Change the document decription.
>>>>>> - Move the efuse driver into driver/soc/vendor.
>>>>>> - update the efuse driver.
>>>>>> - Add the dts node on RK3288.
>>>>>>
>>>>>>
>>>>>
>>>>> i want to mention that there is a upcoming new framework suitable for
>>>>> efuse drivers:
>>>>>
>>>>> https://lkml.org/lkml/2015/5/21/643
>>>>>
>>>>> Unfortunately i don't know the current development state.
>>>>>
>>>>
>>>> Currently this framework is used by atleast 3 drivers(qcom-tsens,
>>>> qcom-cpr, begel-bone-cape manager) which are still floating in the
>>>> mailing list.
>>>>
>>>> I was hoping that these 3 users would getback with tested-by.. which
>>>> did not happen for last 3-4 weeks.
>>>>
>>>> I would appreciate, If you could try framework too, and let me know.
>>>
>
> yes i work on OCOTP driver for MXS platform and i will try ...
>
>>
>> int rockchip_efuse_reg_read(void *context, unsigned int reg, unsigned
>> int *val)
>> {
>> /* efuse specific read sequence */
>> ...
>> }
>
> I will need a specific read sequence too.
You can have a look at
https://git.linaro.org/people/srinivas.kandagatla/linux.git/blob/b4c3ad253747767511233687436f20144e850d67:/drivers/nvmem/rockchip-efuse.c
I did modify the rockchip driver, which I guess should be very much
similar to what OCOTP driver would need.
>
> Sorry for these newbie questions:
>
> What data structure does context points to for this reg_read opteration?
>
> Do we need range checking of reg or is it handled by the framework?
>
We already have that in place.
> Are there any limitation for reg_read regarding sleeping or locking
> operations?
There are no limitaions as such from nvmem framework, regmap might have
limitations w.r.t to sleeping and fast_io, as fast_io would take
spinlocks, AFAIK the providers would not have fast_io, as they not IO
devices.
>
> In case of a read only driver, is everything handle by devicetree or do
> we need an empty write operation?
Yes, if you pass read-only flag in the provider, the framework would not
attempt to even write.
You will find answers to most of your question in the rochip-efuse.c file.
--srini
>
> Best regards
> Stefan
>
next prev parent reply other threads:[~2015-06-18 8:29 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-16 7:27 [PATCH v2 0/3] Add the efuse driver on rockchip platform Caesar Wang
2015-06-16 7:27 ` Caesar Wang
2015-06-16 7:27 ` Caesar Wang
2015-06-16 7:27 ` [PATCH v2 1/3] soc/rockchip: Add efuse bindings for Rockchip SoC efuse driver Caesar Wang
2015-06-16 7:27 ` Caesar Wang
2015-06-16 7:27 ` [PATCH v2 2/3] soc/rockchip: efuse: Add Rockchip SoC efuse support Caesar Wang
2015-06-16 7:27 ` Caesar Wang
2015-06-16 7:27 ` [PATCH v2 3/3] ARM: dts: Add RK3288 efuse node Caesar Wang
2015-06-16 7:27 ` Caesar Wang
2015-06-16 8:52 ` [PATCH v2 0/3] Add the efuse driver on rockchip platform Stefan Wahren
2015-06-16 8:52 ` Stefan Wahren
2015-06-16 9:21 ` Srinivas Kandagatla
2015-06-16 9:21 ` Srinivas Kandagatla
2015-06-16 10:06 ` Caesar Wang
2015-06-16 10:06 ` Caesar Wang
[not found] ` <557FF50C.10809-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2015-06-16 10:54 ` Srinivas Kandagatla
2015-06-16 10:54 ` Srinivas Kandagatla
2015-06-16 10:54 ` Srinivas Kandagatla
[not found] ` <55800070.5030509-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-06-18 7:05 ` Stefan Wahren
2015-06-18 7:05 ` Stefan Wahren
2015-06-18 7:05 ` Stefan Wahren
2015-06-18 8:29 ` Srinivas Kandagatla [this message]
2015-06-18 8:29 ` Srinivas Kandagatla
[not found] ` <5582816B.5020208-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-06-18 9:08 ` Caesar Wang
2015-06-18 9:08 ` Caesar Wang
2015-06-18 9:08 ` Caesar Wang
2015-07-31 9:27 ` Shunqian Zheng
2015-07-31 9:27 ` Shunqian Zheng
2015-08-04 16:11 ` Srinivas Kandagatla
2015-08-04 16:11 ` Srinivas Kandagatla
2015-08-06 1:10 ` Shunqian Zheng
2015-08-06 1:10 ` Shunqian Zheng
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=5582816B.5020208@linaro.org \
--to=srinivas.kandagatla@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=heiko@sntech.de \
--cc=ijc+devicetree@hellion.org.uk \
--cc=jay.xu@rock-chips.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux@arm.linux.org.uk \
--cc=mark.rutland@arm.com \
--cc=matthias.bgg@gmail.com \
--cc=maxime.ripard@free-electrons.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=stefan.wahren@i2se.com \
--cc=wxt@rock-chips.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.