* Re: [PATCHv3] power: supply: cpcap-charger: Add minimal CPCAP PMIC battery charger
From: Tony Lindgren @ 2017-04-11 15:31 UTC (permalink / raw)
To: Sebastian Reichel
Cc: linux-pm, linux-omap, devicetree, Marcel Partap, Michael Scott
In-Reply-To: <20170411152829.padtau2mqtn6gxdg@earth>
* Sebastian Reichel <sre@kernel.org> [170411 08:31]:
> > +Required properties:
> > +- compatible: Shall be "motorola,cpcap-charger" or
> > + "motorola,mapphone-cpcap-charger"
>
> I queued this with "motorola,cpcap-charger" also dropped from the
> binding document.
Oh OK sorry for missing that.
Thanks,
Tony
^ permalink raw reply
* Re: [PATCH 4/5] mtd: nand: add support for Micron on-die ECC
From: Boris Brezillon @ 2017-04-11 15:30 UTC (permalink / raw)
To: Bean Huo (beanhuo)
Cc: Thomas Petazzoni,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
pawel.moll-5wv7dgnIgG8@public.gmane.org, Campbell,
richard-/L3Ra7n9ekc@public.gmane.org, Mark Rutland,
marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Rob Herring,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, Cyrille Pitchen,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <90300f14cd2a4ae6967d8be0f7dff4e9-aBoyCxvc2dBaXkNJqdKpEhSpLNRU/VIH@public.gmane.org>
On Tue, 11 Apr 2017 15:02:22 +0000
"Bean Huo (beanhuo)" <beanhuo-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org> wrote:
> Hi, Boris and Thomas
> Let me do some explanation.
>
> >> if (NAND == SLC ) { // on-die ECC only exists in SLC //check device ID
> >> byte 4
> >> if ((ID.byte4 & 0x02) == 0x02) {// internal ECC level ==10b
> >
> >So here the MT29F1G08ABADAWP datasheet says 0x2 <=> 4bit/512bytes ECC.
> >
>
> If the NAND supports on-die ECC, here should be 10b, not matter it is 8bit or 4bit,
> You are correct, MT29F1G08ABADAWP is 0x2, its explanation is 4bit/512bytes ECC.
> But for the 70s, it is 8bit on-die ECC, but it is still 10b.
> So that why here using these two bits to determine if exist on-die ECC.
> What's more, for some old products, they don't support on-die ECC,
> Sometimes, here is still 01b, so still need following codes to do further
> determinations.
Okay, then here is the differentiator. Did you check that on SLC NANDs
there's no collision on ID[4].bits[1:0]. I've seen NAND vendors
changing their ID scheme in incompatible ways (old fields were
replaced by new ones with completely different meanings).
I'd really like to make sure we're not mis-interpreting READ_ID
information, so maybe we should restrict the test on ONFI NANDs if all
NANDs supporting on-die ECC are ONFI compliant. We should probably also
check that chip->id.len >= 5.
>
> >> if (ID.byte4 & 0x80) {//on-Die ECC enabled
> >
> >Did you read my last reply?
> >Thomas discovered that ID[4].bit7 is actually reflecting the ECC engine state (1 if
> >the engine is enabled, 0 if it's disabled), not whether the NAND supports on-die
> >ECC or not, so no this test is not reliable.
> >
> For the on-die ECC, it is not always default enabled. It depends on requirement from costumers.
> If on-die ECC is not enabled, bit7 is 0. It can be switched through "Feature Operations".
So this check is not needed, right?
BTW, do you have NANDs where the on-die ECC is always enabled, and if
this is the case, what happens when you call
SET_FEATURE(disable/enable-ECC) on these NANDs?
>
> >> if (ONFI.byte112 == 4)
> >> 60s SLC NAND with on-die ECC
> >> else if (ONFI.byte112 == 8)
> >> 70s SLC NAND with on-die ECC
> >
> >This is completely fucked up! Now the ONFI param page says the NAND requires
> >8bits/512bytes, while the ID bytes advertised an on-die ECC providing
> >4bits/512bytes correctability.
>
> I think, my previous answers can answer this confusion.
Yep. BTW, sorry for being so harsh in my previous reply.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 4/5] mtd: nand: add support for Micron on-die ECC
From: Bean Huo (beanhuo) @ 2017-04-11 15:28 UTC (permalink / raw)
To: Boris Brezillon
Cc: Thomas Petazzoni,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
pawel.moll-5wv7dgnIgG8@public.gmane.org, Campbell,
richard-/L3Ra7n9ekc@public.gmane.org, Mark Rutland,
marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Rob Herring,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, Cyrille Pitchen,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <20170411171003.7b14b8a6@bbrezillon>
Hi, Boris
>> Maybe I was wrong about your 'if ((ID.byte4 & 0x02) == 0x02)' test,
>> because you apparently only mask bit 1 and not bits 0 and 1.
Sorry, here is my wrong, it should be masked with 0x3, not 0x02.
>> Anyway, I can't tell if this is valid because I don't have access to
>> the M79A datasheets you're referring to.
>
>Okay, I managed to download the MT29F2G08ABAGAWP datasheet (from the
>MT79A family), and it seems that the test should be
>
> if ((ID.byte4 & 0x03) == 0x02)
This is correct, should be 0x03, not 0x02.
>
>and not
>
> if ((ID.byte4 & 0x02) == 0x02)
>
>Also, this field named "Internal ECC level" clearly does not reflect the on-die ECC
>strength because it's set to the same value on both parts (0x2) while
>MT29F2G08ABAGAWP provides 8bits/512bytes and MT29F1G08ABADAWP
>4bits/512bytes.
>
>See why I say we can't rely on READ_ID information. It's changing all the time,
>and nothing clearly say how to differentiate the scheme used in a specific NAND
>part.
Correct, so far there is no standard to define ID.byte4, every vendor with their own definition.
Even with the same vendor, for the different products, this is also changing.
Maintain one table in MTD, it is a simple and convenient way to differentiate, but, in my opinion,
This is not linux trend. We have method to automatically detect, why still maintain an additional table.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv3] power: supply: cpcap-charger: Add minimal CPCAP PMIC battery charger
From: Sebastian Reichel @ 2017-04-11 15:28 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marcel Partap, Michael Scott
In-Reply-To: <20170327032513.22890-1-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2340 bytes --]
Hi Tony,
On Sun, Mar 26, 2017 at 08:25:13PM -0700, Tony Lindgren wrote:
> The custom CPCAP PMIC used on Motorola phones such as Droid 4 has a
> USB battery charger. It can optionally also have a companion chip that
> is used for wireless charging.
>
> The charger on CPCAP also can feed VBUS for the USB host mode. This
> can be handled by the existing kernel phy_companion interface.
>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Marcel Partap <mpartap-hi6Y0CQ0nG0@public.gmane.org>
> Cc: Michael Scott <michael.scott-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> ---
>
> Changes since v2:
>
> - Update binding based on comments by Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> - Drop "motorola,cpcap-charger" compatible for now as this seems specific
> to the motorola-mapphone
>
> - Update Kconfig for "depends on IIO" and "default MFD_CPCAP"
>
> Changes since v1:
>
> - Fix scaling of IIO values as pointed out by Sebastian Reichel
> <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> - Use iio_read_channel_processed() instead of iio_read_channel_scaled()
> as changed in the v2 of the ADC driver
>
> - Add GPL v2 license header
>
> ---
> .../bindings/power/supply/cpcap-charger.txt | 38 ++
> drivers/power/supply/Kconfig | 8 +
> drivers/power/supply/Makefile | 1 +
> drivers/power/supply/cpcap-charger.c | 681 +++++++++++++++++++++
> 4 files changed, 728 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/supply/cpcap-charger.txt
> create mode 100644 drivers/power/supply/cpcap-charger.c
>
> diff --git a/Documentation/devicetree/bindings/power/supply/cpcap-charger.txt b/Documentation/devicetree/bindings/power/supply/cpcap-charger.txt
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/cpcap-charger.txt
> @@ -0,0 +1,38 @@
> +Motorola CPCAP PMIC battery charger binding
> +
> +Required properties:
> +- compatible: Shall be "motorola,cpcap-charger" or
> + "motorola,mapphone-cpcap-charger"
I queued this with "motorola,cpcap-charger" also dropped from the
binding document.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 4/5] mtd: nand: add support for Micron on-die ECC
From: Boris Brezillon @ 2017-04-11 15:10 UTC (permalink / raw)
To: Bean Huo (beanhuo)
Cc: Thomas Petazzoni,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
pawel.moll-5wv7dgnIgG8@public.gmane.org, Campbell,
richard-/L3Ra7n9ekc@public.gmane.org, Mark Rutland,
marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Rob Herring,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, Cyrille Pitchen,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <20170411164952.52357b4f@bbrezillon>
On Tue, 11 Apr 2017 16:49:52 +0200
Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On Tue, 11 Apr 2017 14:26:02 +0000
> "Bean Huo (beanhuo)" <beanhuo-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org> wrote:
>
> > >
> > >Hi Bean,
> > >
> > >On Mon, 3 Apr 2017 11:31:05 +0000
> > >"Bean Huo (beanhuo)" <beanhuo-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org> wrote:
> > >
> > >> Hi, Boris and Thomas
> > >>
> > >> >>
> > >> >> Ok, but I recommend that 70s should be the first choice on this
> > >> >> single solution, it doesn't need to read twice to detect its bitflips count.
> > >> >
> > >> >That's exactly why we need to differentiate the 2 chips.
> > >>
> > >> Sorry for later this response.
> > >> Below is the pseudo codes about how to differentiate these 2 series
> > >> parallel NAND with on-die ECC:
> > >>
> > >> if (NAND == SLC ) { // on-die ECC only exists in SLC //check device ID
> > >> byte 4
> > >> if ((ID.byte4 & 0x02) == 0x02) {// internal ECC level ==10b
> > >
> > >So here the MT29F1G08ABADAWP datasheet says 0x2 <=> 4bit/512bytes ECC.
> > >
> > >> if (ID.byte4 & 0x80) {//on-Die ECC enabled
> > >
> > >Did you read my last reply?
> > >Thomas discovered that ID[4].bit7 is actually reflecting the ECC engine state (1 if
> > >the engine is enabled, 0 if it's disabled), not whether the NAND supports on-die
> > >ECC or not, so no this test is not reliable.
> > >
> > >> if (ONFI.byte112 == 4)
> > >> 60s SLC NAND with on-die ECC
> > >> else if (ONFI.byte112 == 8)
> > >> 70s SLC NAND with on-die ECC
> > >
> > >This is completely fucked up! Now the ONFI param page says the NAND requires
> > >8bits/512bytes, while the ID bytes advertised an on-die ECC providing
> > >4bits/512bytes correctability.
> > >So either your algorithm is wrong, or the ID and ONFI param page are contracting
> > >(not sure what solution I'd prefer...).
> > >
> > >> else
> > >> Doesn't support on-die ECC
> > >
> > >Sorry to say that, but I find it worrisome that even someone from Micron is not
> > >able to get it right.
> > >
> >
> > Sorry, would you please specify which one is wrong or confuse you?
>
> The initial 'if (ID.byte4 & 0x80)' is wrong, because this bit is only
> set when someone enabled the ECC engine using the SET_FEATURE command
> (this has been verified by Thomas who tried to disable the feature in
> the bootloader and noticed that on-die ECC was reported as
> 'unsupported' by the kernel).
>
> Maybe I was wrong about your 'if ((ID.byte4 & 0x02) == 0x02)' test,
> because you apparently only mask bit 1 and not bits 0 and 1.
> Anyway, I can't tell if this is valid because I don't have access to
> the M79A datasheets you're referring to.
Okay, I managed to download the MT29F2G08ABAGAWP datasheet (from the
MT79A family), and it seems that the test should be
if ((ID.byte4 & 0x03) == 0x02)
and not
if ((ID.byte4 & 0x02) == 0x02)
Also, this field named "Internal ECC level" clearly does not reflect
the on-die ECC strength because it's set to the same value on both
parts (0x2) while MT29F2G08ABAGAWP provides 8bits/512bytes and
MT29F1G08ABADAWP 4bits/512bytes.
See why I say we can't rely on READ_ID information. It's changing all
the time, and nothing clearly say how to differentiate the scheme used
in a specific NAND part.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Re: [PATCH v2 03/11] dt-bindings: add device tree binding for X-Powers AXP803 PMIC
From: Chen-Yu Tsai @ 2017-04-11 15:02 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Lee Jones, devicetree, linux-kernel, linux-sunxi, Liam Girdwood,
Chen-Yu Tsai, Rob Herring, Maxime Ripard, linux-arm-kernel
In-Reply-To: <alpine.LNX.2.20.1704112237290.39759@x220i>
Hi,
On Tue, Apr 11, 2017 at 11:00 PM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>
>
> On Tue, 11 Apr 2017, Lee Jones wrote:
>
>> On Sat, 08 Apr 2017, Icenowy Zheng wrote:
>>
>>> AXP803 is a PMIC produced by Shenzhen X-Powers, with either I2C or RSB
>>> bus.
>>>
>>> Add a compatible for it.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>>> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
>>> ---
>>> Changes in v2:
>>> - Place AXP803 before AXP806/809.
>>> - Added Chen-Yu's ACK.
>>>
>>> Documentation/devicetree/bindings/mfd/axp20x.txt | 5 +++--
>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>>
>> For my own reference:
>> Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
>
> Excuse me... Who will apply this patch?
>
> I think this patch should be applied by you as it's in bindings/mfd
> directory, however, if I'm wrong, please point out ;-)
We need the DT maintainers to ack it first. :)
ChenYu
^ permalink raw reply
* RE: [PATCH 4/5] mtd: nand: add support for Micron on-die ECC
From: Bean Huo (beanhuo) @ 2017-04-11 15:02 UTC (permalink / raw)
To: Boris Brezillon
Cc: Thomas Petazzoni,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
pawel.moll-5wv7dgnIgG8@public.gmane.org, Campbell,
richard-/L3Ra7n9ekc@public.gmane.org, Mark Rutland,
marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Rob Herring,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, Cyrille Pitchen,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <20170411145102.563fa388@bbrezillon>
Hi, Boris and Thomas
Let me do some explanation.
>> if (NAND == SLC ) { // on-die ECC only exists in SLC //check device ID
>> byte 4
>> if ((ID.byte4 & 0x02) == 0x02) {// internal ECC level ==10b
>
>So here the MT29F1G08ABADAWP datasheet says 0x2 <=> 4bit/512bytes ECC.
>
If the NAND supports on-die ECC, here should be 10b, not matter it is 8bit or 4bit,
You are correct, MT29F1G08ABADAWP is 0x2, its explanation is 4bit/512bytes ECC.
But for the 70s, it is 8bit on-die ECC, but it is still 10b.
So that why here using these two bits to determine if exist on-die ECC.
What's more, for some old products, they don't support on-die ECC,
Sometimes, here is still 01b, so still need following codes to do further
determinations.
>> if (ID.byte4 & 0x80) {//on-Die ECC enabled
>
>Did you read my last reply?
>Thomas discovered that ID[4].bit7 is actually reflecting the ECC engine state (1 if
>the engine is enabled, 0 if it's disabled), not whether the NAND supports on-die
>ECC or not, so no this test is not reliable.
>
For the on-die ECC, it is not always default enabled. It depends on requirement from costumers.
If on-die ECC is not enabled, bit7 is 0. It can be switched through "Feature Operations".
>> if (ONFI.byte112 == 4)
>> 60s SLC NAND with on-die ECC
>> else if (ONFI.byte112 == 8)
>> 70s SLC NAND with on-die ECC
>
>This is completely fucked up! Now the ONFI param page says the NAND requires
>8bits/512bytes, while the ID bytes advertised an on-die ECC providing
>4bits/512bytes correctability.
I think, my previous answers can answer this confusion.
>So either your algorithm is wrong, or the ID and ONFI param page are contracting
>(not sure what solution I'd prefer...).
>
>> else
>> Doesn't support on-die ECC
>
>Sorry to say that, but I find it worrisome that even someone from Micron is not
>able to get it right.
>
I am ashamed. I have been in Micron for two years, for some old products, I am also not very clear.
But I checked all the SLC-NAND datasheet with on-die ECC with our AE, and had this final pseudo code.
>I think we'll stick to the model name to detect whether on-die ECC is supported.
>
>Regards,
>
>Boris
beanhuo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 03/11] dt-bindings: add device tree binding for X-Powers AXP803 PMIC
From: Icenowy Zheng @ 2017-04-11 15:00 UTC (permalink / raw)
To: Lee Jones
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Liam Girdwood, Chen-Yu Tsai,
Rob Herring, Maxime Ripard,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170411140427.doq5atxk6ptjrp36@dell>
[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]
On Tue, 11 Apr 2017, Lee Jones wrote:
> On Sat, 08 Apr 2017, Icenowy Zheng wrote:
>
>> AXP803 is a PMIC produced by Shenzhen X-Powers, with either I2C or RSB
>> bus.
>>
>> Add a compatible for it.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
>> ---
>> Changes in v2:
>> - Place AXP803 before AXP806/809.
>> - Added Chen-Yu's ACK.
>>
>> Documentation/devicetree/bindings/mfd/axp20x.txt | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> For my own reference:
> Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Excuse me... Who will apply this patch?
I think this patch should be applied by you as it's in bindings/mfd
directory, however, if I'm wrong, please point out ;-)
>
>> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
>> index b41d2601c6ba..334fb19ce605 100644
>> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
>> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
>> @@ -6,12 +6,13 @@ axp202 (X-Powers)
>> axp209 (X-Powers)
>> axp221 (X-Powers)
>> axp223 (X-Powers)
>> +axp803 (X-Powers)
>> axp809 (X-Powers)
>>
>> Required properties:
>> - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
>> - "x-powers,axp221", "x-powers,axp223", "x-powers,axp806",
>> - "x-powers,axp809"
>> + "x-powers,axp221", "x-powers,axp223", "x-powers,axp803",
>> + "x-powers,axp806", "x-powers,axp809"
>> - reg: The I2C slave address or RSB hardware address for the AXP chip
>> - interrupt-parent: The parent interrupt controller
>> - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/5] mtd: nand: add support for Micron on-die ECC
From: Boris Brezillon @ 2017-04-11 14:49 UTC (permalink / raw)
To: Bean Huo (beanhuo)
Cc: Thomas Petazzoni,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
pawel.moll-5wv7dgnIgG8@public.gmane.org, Campbell,
richard-/L3Ra7n9ekc@public.gmane.org, Mark Rutland,
marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Rob Herring,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, Cyrille Pitchen,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <106593e04c494120b323836b8bc54f7f-aBoyCxvc2dBaXkNJqdKpEhSpLNRU/VIH@public.gmane.org>
On Tue, 11 Apr 2017 14:26:02 +0000
"Bean Huo (beanhuo)" <beanhuo-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org> wrote:
> >
> >Hi Bean,
> >
> >On Mon, 3 Apr 2017 11:31:05 +0000
> >"Bean Huo (beanhuo)" <beanhuo-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org> wrote:
> >
> >> Hi, Boris and Thomas
> >>
> >> >>
> >> >> Ok, but I recommend that 70s should be the first choice on this
> >> >> single solution, it doesn't need to read twice to detect its bitflips count.
> >> >
> >> >That's exactly why we need to differentiate the 2 chips.
> >>
> >> Sorry for later this response.
> >> Below is the pseudo codes about how to differentiate these 2 series
> >> parallel NAND with on-die ECC:
> >>
> >> if (NAND == SLC ) { // on-die ECC only exists in SLC //check device ID
> >> byte 4
> >> if ((ID.byte4 & 0x02) == 0x02) {// internal ECC level ==10b
> >
> >So here the MT29F1G08ABADAWP datasheet says 0x2 <=> 4bit/512bytes ECC.
> >
> >> if (ID.byte4 & 0x80) {//on-Die ECC enabled
> >
> >Did you read my last reply?
> >Thomas discovered that ID[4].bit7 is actually reflecting the ECC engine state (1 if
> >the engine is enabled, 0 if it's disabled), not whether the NAND supports on-die
> >ECC or not, so no this test is not reliable.
> >
> >> if (ONFI.byte112 == 4)
> >> 60s SLC NAND with on-die ECC
> >> else if (ONFI.byte112 == 8)
> >> 70s SLC NAND with on-die ECC
> >
> >This is completely fucked up! Now the ONFI param page says the NAND requires
> >8bits/512bytes, while the ID bytes advertised an on-die ECC providing
> >4bits/512bytes correctability.
> >So either your algorithm is wrong, or the ID and ONFI param page are contracting
> >(not sure what solution I'd prefer...).
> >
> >> else
> >> Doesn't support on-die ECC
> >
> >Sorry to say that, but I find it worrisome that even someone from Micron is not
> >able to get it right.
> >
>
> Sorry, would you please specify which one is wrong or confuse you?
The initial 'if (ID.byte4 & 0x80)' is wrong, because this bit is only
set when someone enabled the ECC engine using the SET_FEATURE command
(this has been verified by Thomas who tried to disable the feature in
the bootloader and noticed that on-die ECC was reported as
'unsupported' by the kernel).
Maybe I was wrong about your 'if ((ID.byte4 & 0x02) == 0x02)' test,
because you apparently only mask bit 1 and not bits 0 and 1.
Anyway, I can't tell if this is valid because I don't have access to
the M79A datasheets you're referring to.
>
> >I think we'll stick to the model name to detect whether on-die ECC is supported.
> >
> You want one solution that can clearly differentiate two serial SLC NAND, but NAND ONFI table
> and device Id are always changing. It is easy to draw a perfect solution to do that.
> OK, if you like maintain a huge/ugly table in MTD, please do that.
I'm not happy with the big ID table either, but unless I'm missing
something, what you propose does not work for the MT29F1G08ABADAWP, so
I prefer to rely on something I can trust.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 4/4] net: dsa: LAN9303: add MDIO managed mode support
From: Andrew Lunn @ 2017-04-11 14:34 UTC (permalink / raw)
To: Juergen Borleis
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, devicetree-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
In-Reply-To: <20170411072259.15356-5-jbe-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Tue, Apr 11, 2017 at 09:22:59AM +0200, Juergen Borleis wrote:
> When the LAN9303 device is in MDIO manged mode, all register accesses must
> be done via MDIO.
>
> Please note: this code is compile time tested only due to the absence of such
> configured hardware. It is based on a patch from Stefan Roese from 2014.
>
> Signed-off-by: Juergen Borleis <jbe-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 3/4] net: dsa: LAN9303: add I2C managed mode support
From: Andrew Lunn @ 2017-04-11 14:32 UTC (permalink / raw)
To: Juergen Borleis
Cc: netdev, linux-kernel, f.fainelli, kernel, vivien.didelot, davem,
devicetree, robh+dt, mark.rutland
In-Reply-To: <20170411072259.15356-4-jbe@pengutronix.de>
On Tue, Apr 11, 2017 at 09:22:58AM +0200, Juergen Borleis wrote:
> In this mode the switch device and the internal phys will be managed via
> I2C interface. The MDIO interface is still supported, but for the
> (emulated) CPU port only.
>
> Signed-off-by: Juergen Borleis <jbe@pengutronix.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: Document STM32 I2S bindings
From: Mark Brown @ 2017-04-11 14:32 UTC (permalink / raw)
To: Rob Herring
Cc: olivier moysan, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w,
alexandre.torgue-qxv4g6HH51o, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
arnaud.pouliquen-qxv4g6HH51o, benjamin.gaignard-qxv4g6HH51o
In-Reply-To: <20170410194832.iivnkyejtywbe2c7@rob-hp-laptop>
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
On Mon, Apr 10, 2017 at 02:48:32PM -0500, Rob Herring wrote:
> On Thu, Apr 06, 2017 at 05:40:35PM +0200, olivier moysan wrote:
> > +Required properties:
> > + - compatible: Must be "st,stm32h7-i2s"
> > + - #sound-dai-cells: Must be 1. (one parameter)
> > + This parameter allows to specify CPU DAI index in soundcard CPU dai link.
> > + index 0: playback DAI
> > + index 1: capture DAI
> > + index 2: full duplex DAI
> Is this still needed for graph-card?
The graph card is blocked on your review... I'm also not clear how
without something like this we'd be able to identify a specific DAI
within a device if we don't have a way of identifying them.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 2/2] power: supply: ltc2941-battery-gauge: Add OF device ID table
From: Sebastian Reichel @ 2017-04-11 14:29 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, devicetree, Mark Rutland, Rob Herring, linux-pm
In-Reply-To: <20170329160057.8298-2-javier@osg.samsung.com>
[-- Attachment #1: Type: text/plain, Size: 632 bytes --]
Hi,
On Wed, Mar 29, 2017 at 12:00:57PM -0400, Javier Martinez Canillas wrote:
> The driver doesn't have a struct of_device_id table but supported devices
> are registered via Device Trees. This is working on the assumption that a
> I2C device registered via OF will always match a legacy I2C device ID and
> that the MODALIAS reported will always be of the form i2c:<device>.
>
> But this could change in the future so the correct approach is to have an
> OF device ID table if the devices are registered via OF.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Thanks, queued.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 1/2] power: supply: ltc2941-battery-gauge: Add vendor to compatibles in binding
From: Sebastian Reichel @ 2017-04-11 14:28 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland, Rob Herring,
linux-pm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170329160057.8298-1-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 601 bytes --]
Hi,
On Wed, Mar 29, 2017 at 12:00:56PM -0400, Javier Martinez Canillas wrote:
> The DT binding document for LTC2941 and LTC2943 battery gauges did not use
> a vendor prefix in the listed compatible strings. The driver says that the
> manufacturer is Linear Technology which is "lltc" in vendor-prefixes.txt.
>
> There isn't an upstream Device Tree source file that has nodes defined for
> these devices, so there's no need to keep the old compatible strings.
>
> Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
Thanks, queued.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* RE: [PATCH 4/5] mtd: nand: add support for Micron on-die ECC
From: Bean Huo (beanhuo) @ 2017-04-11 14:26 UTC (permalink / raw)
To: Boris Brezillon
Cc: Thomas Petazzoni, devicetree@vger.kernel.org, pawel.moll@arm.com,
Campbell, richard@nod.at, marek.vasut@gmail.com, Rob Herring,
linux-mtd@lists.infradead.org, galak@codeaurora.org, Mark Rutland,
computersforpeace@gmail.com, Cyrille Pitchen
In-Reply-To: <20170411145102.563fa388@bbrezillon>
>
>Hi Bean,
>
>On Mon, 3 Apr 2017 11:31:05 +0000
>"Bean Huo (beanhuo)" <beanhuo@micron.com> wrote:
>
>> Hi, Boris and Thomas
>>
>> >>
>> >> Ok, but I recommend that 70s should be the first choice on this
>> >> single solution, it doesn't need to read twice to detect its bitflips count.
>> >
>> >That's exactly why we need to differentiate the 2 chips.
>>
>> Sorry for later this response.
>> Below is the pseudo codes about how to differentiate these 2 series
>> parallel NAND with on-die ECC:
>>
>> if (NAND == SLC ) { // on-die ECC only exists in SLC //check device ID
>> byte 4
>> if ((ID.byte4 & 0x02) == 0x02) {// internal ECC level ==10b
>
>So here the MT29F1G08ABADAWP datasheet says 0x2 <=> 4bit/512bytes ECC.
>
>> if (ID.byte4 & 0x80) {//on-Die ECC enabled
>
>Did you read my last reply?
>Thomas discovered that ID[4].bit7 is actually reflecting the ECC engine state (1 if
>the engine is enabled, 0 if it's disabled), not whether the NAND supports on-die
>ECC or not, so no this test is not reliable.
>
>> if (ONFI.byte112 == 4)
>> 60s SLC NAND with on-die ECC
>> else if (ONFI.byte112 == 8)
>> 70s SLC NAND with on-die ECC
>
>This is completely fucked up! Now the ONFI param page says the NAND requires
>8bits/512bytes, while the ID bytes advertised an on-die ECC providing
>4bits/512bytes correctability.
>So either your algorithm is wrong, or the ID and ONFI param page are contracting
>(not sure what solution I'd prefer...).
>
>> else
>> Doesn't support on-die ECC
>
>Sorry to say that, but I find it worrisome that even someone from Micron is not
>able to get it right.
>
Sorry, would you please specify which one is wrong or confuse you?
>I think we'll stick to the model name to detect whether on-die ECC is supported.
>
You want one solution that can clearly differentiate two serial SLC NAND, but NAND ONFI table
and device Id are always changing. It is easy to draw a perfect solution to do that.
OK, if you like maintain a huge/ugly table in MTD, please do that.
>Regards,
>
>Boris
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCHv5] mfd: cpcap: implement irq sense helper
From: Lee Jones @ 2017-04-11 14:21 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Tony Lindgren, Dmitry Torokhov, Rob Herring, Mark Rutland,
linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170410142748.jxqd65jrcz2ijp47@earth>
On Mon, 10 Apr 2017, Sebastian Reichel wrote:
> On Mon, Apr 03, 2017 at 11:26:15AM +0100, Lee Jones wrote:
> > On Wed, 29 Mar 2017, Sebastian Reichel wrote:
> >
> > > CPCAP can sense if IRQ is currently set or not. This
> > > functionality is required for a few subdevices, such
> > > as the power button and usb phy modules.
> > >
> > > Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> > > Signed-off-by: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > > ---
> > > Changes since PATCHv3:
> > > - add extern to function definition
> > > - use BIT macro for mask variable
> > > - avoid magic numbers
> > > Changes since PATCHv4:
> > > - rename base to irq_base
> > > ---
> > > drivers/mfd/motorola-cpcap.c | 28 ++++++++++++++++++++++++++++
> > > include/linux/mfd/motorola-cpcap.h | 2 ++
> > > 2 files changed, 30 insertions(+)
> >
> > Applied, thanks.
>
> Thanks, will you also pick up the input patch?
>
> https://patchwork.kernel.org/patch/9637807/
Done, and pull-request sent.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [GIT PULL] Immutable branch between MFD and Input due for the v4.12 merge window
From: Lee Jones @ 2017-04-11 14:21 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Tony Lindgren, Dmitry Torokhov, Rob Herring, Mark Rutland,
linux-input, devicetree, linux-kernel
In-Reply-To: <20170321225042.28057-1-sre@kernel.org>
Dmitry,
Enjoy!
The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-input-v4.12
for you to fetch changes up to 6d99971842f6b0779738d8c168d9ed92ef1ff5fc:
input: cpcap-pwrbutton: New driver (2017-04-11 15:18:09 +0100)
----------------------------------------------------------------
Immutable branch between MFD and Input due for the v4.12 merge window
----------------------------------------------------------------
Sebastian Reichel (2):
mfd: cpcap: Implement IRQ sense helper
input: cpcap-pwrbutton: New driver
.../devicetree/bindings/input/cpcap-pwrbutton.txt | 20 ++++
drivers/input/misc/Kconfig | 10 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/cpcap-pwrbutton.c | 117 +++++++++++++++++++++
drivers/mfd/motorola-cpcap.c | 28 +++++
include/linux/mfd/motorola-cpcap.h | 2 +
6 files changed, 178 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
create mode 100644 drivers/input/misc/cpcap-pwrbutton.c
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCHv3 00/10] Nokia H4+ support
From: Greg Kroah-Hartman @ 2017-04-11 14:06 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Sebastian Reichel, Gustavo F. Padovan, Johan Hedberg,
Samuel Thibault, Pavel Machek, Tony Lindgren, Jiri Slaby,
Mark Rutland, open list:BLUETOOTH DRIVERS,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David S. Miller, Rob Herring
In-Reply-To: <4FEFA1D8-BE23-40FB-BAA3-3EC910FE9F96-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
On Tue, Apr 11, 2017 at 01:36:44PM +0200, Marcel Holtmann wrote:
> Hi Sebastian,
>
> >>>>>> Here is PATCHv3 for the Nokia bluetooth patchset. I addressed all comments from
> >>>>>> Rob and Pavel regarding the serdev patches and dropped the *.dts patches, since
> >>>>>> they were queued by Tony. I also changed the patch order, so that the serdev
> >>>>>> patches come first. All of them have Acked-by from Rob, so I think it makes
> >>>>>> sense to merge them to serdev subsystem (now) and provide an immutable branch
> >>>>>> for the bluetooth subsystem.
> >>>>>
> >>>>> Greg doesn't read cover letters generally and since the serdev patches
> >>>>> are Cc rather than To him, he's probably not planning to pick them up.
> >>>>
> >>>> I wonder actually if we should merge all of these via bluetooth-next
> >>>> tree with proper Ack from Greg. However it would be good to also get
> >>>> buy in from Dave for merging this ultimately through net-next.
> >>>
> >>> I don't really care where it goes. I can take the whole thing in my
> >>> tty/serial tree now if no one objects and I get an ack from the relevant
> >>> maintainers {hint...}
> >>
> >> I think it is better if it goes thru BT tree. I have another driver
> >> converted that is dependent on this series. There's a couple other
> >> serdev changes on the list too, but this shouldn't depend on them.
> >
> > Is this waiting for something, or could it be queued to
> > bluetooth-next then? It would be nice to finally have
> > this in 4.12 :)
>
> I would prefer if we can get an ACK from Greg. Then I merge it through the bluetooth-next tree.
Sorry thought this was coming through mine:
Acked-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
Merge away!
greg k-h
^ permalink raw reply
* Re: [PATCH V2] clk: hi6220: Add the hi655x's pmic clock
From: Lee Jones @ 2017-04-11 14:06 UTC (permalink / raw)
To: Daniel Lezcano
Cc: sboyd, mturquette, xuwei5, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
In-Reply-To: <1491683412-12237-1-git-send-email-daniel.lezcano@linaro.org>
On Sat, 08 Apr 2017, Daniel Lezcano wrote:
> The hi655x multi function device is a PMIC providing regulators.
>
> The PMIC also provides a clock for the WiFi and the Bluetooth, let's implement
> this clock in order to add it in the hi655x MFD and allow proper wireless
> initialization.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
>
> Changelog:
>
> V2:
> - Added COMPILE_TEST option, compiled on x86
> - Removed useless parenthesis
> - Used of_clk_hw_simple_get() instead of deref dance
> - Do bailout if the clock-names is not specified
> - Rollback on error
> - Folded mfd line change and binding
Why did you do that?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v2 03/11] dt-bindings: add device tree binding for X-Powers AXP803 PMIC
From: Lee Jones @ 2017-04-11 14:04 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Maxime Ripard, Liam Girdwood,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170407183441.58750-4-icenowy-h8G6r0blFSE@public.gmane.org>
On Sat, 08 Apr 2017, Icenowy Zheng wrote:
> AXP803 is a PMIC produced by Shenzhen X-Powers, with either I2C or RSB
> bus.
>
> Add a compatible for it.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> ---
> Changes in v2:
> - Place AXP803 before AXP806/809.
> - Added Chen-Yu's ACK.
>
> Documentation/devicetree/bindings/mfd/axp20x.txt | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index b41d2601c6ba..334fb19ce605 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -6,12 +6,13 @@ axp202 (X-Powers)
> axp209 (X-Powers)
> axp221 (X-Powers)
> axp223 (X-Powers)
> +axp803 (X-Powers)
> axp809 (X-Powers)
>
> Required properties:
> - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
> - "x-powers,axp221", "x-powers,axp223", "x-powers,axp806",
> - "x-powers,axp809"
> + "x-powers,axp221", "x-powers,axp223", "x-powers,axp803",
> + "x-powers,axp806", "x-powers,axp809"
> - reg: The I2C slave address or RSB hardware address for the AXP chip
> - interrupt-parent: The parent interrupt controller
> - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 04/11] mfd: axp20x: support AXP803 variant
From: Lee Jones @ 2017-04-11 14:04 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Maxime Ripard, Liam Girdwood,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170407183441.58750-5-icenowy-h8G6r0blFSE@public.gmane.org>
On Sat, 08 Apr 2017, Icenowy Zheng wrote:
> AXP803 is a new PMIC chip produced by X-Powers, usually paired with A64
> via RSB bus. The PMIC itself is like AXP288, but with RSB support and
> dedicated VBUS and ACIN.
>
> Add support for it in the axp20x mfd driver.
>
> Currently only power key function is supported.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> Changes in v2:
> - Share regmap configs with AXP288.
> - Place AXP803 bits before AXP806/809.
>
> drivers/mfd/axp20x-rsb.c | 1 +
> drivers/mfd/axp20x.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/axp20x.h | 40 ++++++++++++++++++++++-
> 3 files changed, 119 insertions(+), 1 deletion(-)
Applied, thanks.
> diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
> index a732cb50bcff..fd5c7267b136 100644
> --- a/drivers/mfd/axp20x-rsb.c
> +++ b/drivers/mfd/axp20x-rsb.c
> @@ -61,6 +61,7 @@ static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
>
> static const struct of_device_id axp20x_rsb_of_match[] = {
> { .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
> + { .compatible = "x-powers,axp803", .data = (void *)AXP803_ID },
> { .compatible = "x-powers,axp806", .data = (void *)AXP806_ID },
> { .compatible = "x-powers,axp809", .data = (void *)AXP809_ID },
> { },
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 5ba3b04cc9b1..2268a6a9aa2c 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -41,6 +41,7 @@ static const char * const axp20x_model_names[] = {
> "AXP221",
> "AXP223",
> "AXP288",
> + "AXP803",
> "AXP806",
> "AXP809",
> };
> @@ -117,6 +118,7 @@ static const struct regmap_access_table axp22x_volatile_table = {
> .n_yes_ranges = ARRAY_SIZE(axp22x_volatile_ranges),
> };
>
> +/* AXP288 ranges are shared with the AXP803, as they cover the same range */
> static const struct regmap_range axp288_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ6_STATE),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP288_FG_TUNE5),
> @@ -264,6 +266,20 @@ static struct resource axp288_fuel_gauge_resources[] = {
> },
> };
>
> +static struct resource axp803_pek_resources[] = {
> + {
> + .name = "PEK_DBR",
> + .start = AXP803_IRQ_PEK_RIS_EDGE,
> + .end = AXP803_IRQ_PEK_RIS_EDGE,
> + .flags = IORESOURCE_IRQ,
> + }, {
> + .name = "PEK_DBF",
> + .start = AXP803_IRQ_PEK_FAL_EDGE,
> + .end = AXP803_IRQ_PEK_FAL_EDGE,
> + .flags = IORESOURCE_IRQ,
> + },
> +};
> +
> static struct resource axp809_pek_resources[] = {
> {
> .name = "PEK_DBR",
> @@ -457,6 +473,43 @@ static const struct regmap_irq axp288_regmap_irqs[] = {
> INIT_REGMAP_IRQ(AXP288, BC_USB_CHNG, 5, 1),
> };
>
> +static const struct regmap_irq axp803_regmap_irqs[] = {
> + INIT_REGMAP_IRQ(AXP803, ACIN_OVER_V, 0, 7),
> + INIT_REGMAP_IRQ(AXP803, ACIN_PLUGIN, 0, 6),
> + INIT_REGMAP_IRQ(AXP803, ACIN_REMOVAL, 0, 5),
> + INIT_REGMAP_IRQ(AXP803, VBUS_OVER_V, 0, 4),
> + INIT_REGMAP_IRQ(AXP803, VBUS_PLUGIN, 0, 3),
> + INIT_REGMAP_IRQ(AXP803, VBUS_REMOVAL, 0, 2),
> + INIT_REGMAP_IRQ(AXP803, BATT_PLUGIN, 1, 7),
> + INIT_REGMAP_IRQ(AXP803, BATT_REMOVAL, 1, 6),
> + INIT_REGMAP_IRQ(AXP803, BATT_ENT_ACT_MODE, 1, 5),
> + INIT_REGMAP_IRQ(AXP803, BATT_EXIT_ACT_MODE, 1, 4),
> + INIT_REGMAP_IRQ(AXP803, CHARG, 1, 3),
> + INIT_REGMAP_IRQ(AXP803, CHARG_DONE, 1, 2),
> + INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_HIGH, 2, 7),
> + INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_HIGH_END, 2, 6),
> + INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_LOW, 2, 5),
> + INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_LOW_END, 2, 4),
> + INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_HIGH, 2, 3),
> + INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_HIGH_END, 2, 2),
> + INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_LOW, 2, 1),
> + INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_LOW_END, 2, 0),
> + INIT_REGMAP_IRQ(AXP803, DIE_TEMP_HIGH, 3, 7),
> + INIT_REGMAP_IRQ(AXP803, GPADC, 3, 2),
> + INIT_REGMAP_IRQ(AXP803, LOW_PWR_LVL1, 3, 1),
> + INIT_REGMAP_IRQ(AXP803, LOW_PWR_LVL2, 3, 0),
> + INIT_REGMAP_IRQ(AXP803, TIMER, 4, 7),
> + INIT_REGMAP_IRQ(AXP803, PEK_RIS_EDGE, 4, 6),
> + INIT_REGMAP_IRQ(AXP803, PEK_FAL_EDGE, 4, 5),
> + INIT_REGMAP_IRQ(AXP803, PEK_SHORT, 4, 4),
> + INIT_REGMAP_IRQ(AXP803, PEK_LONG, 4, 3),
> + INIT_REGMAP_IRQ(AXP803, PEK_OVER_OFF, 4, 2),
> + INIT_REGMAP_IRQ(AXP803, GPIO1_INPUT, 4, 1),
> + INIT_REGMAP_IRQ(AXP803, GPIO0_INPUT, 4, 0),
> + INIT_REGMAP_IRQ(AXP803, BC_USB_CHNG, 5, 1),
> + INIT_REGMAP_IRQ(AXP803, MV_CHNG, 5, 0),
> +};
> +
> static const struct regmap_irq axp806_regmap_irqs[] = {
> INIT_REGMAP_IRQ(AXP806, DIE_TEMP_HIGH_LV1, 0, 0),
> INIT_REGMAP_IRQ(AXP806, DIE_TEMP_HIGH_LV2, 0, 1),
> @@ -557,6 +610,18 @@ static const struct regmap_irq_chip axp288_regmap_irq_chip = {
>
> };
>
> +static const struct regmap_irq_chip axp803_regmap_irq_chip = {
> + .name = "axp803",
> + .status_base = AXP20X_IRQ1_STATE,
> + .ack_base = AXP20X_IRQ1_STATE,
> + .mask_base = AXP20X_IRQ1_EN,
> + .mask_invert = true,
> + .init_ack_masked = true,
> + .irqs = axp803_regmap_irqs,
> + .num_irqs = ARRAY_SIZE(axp803_regmap_irqs),
> + .num_regs = 6,
> +};
> +
> static const struct regmap_irq_chip axp806_regmap_irq_chip = {
> .name = "axp806",
> .status_base = AXP20X_IRQ1_STATE,
> @@ -769,6 +834,14 @@ static struct mfd_cell axp288_cells[] = {
> },
> };
>
> +static struct mfd_cell axp803_cells[] = {
> + {
> + .name = "axp20x-pek",
> + .num_resources = ARRAY_SIZE(axp803_pek_resources),
> + .resources = axp803_pek_resources,
> + }
> +};
> +
> static struct mfd_cell axp806_cells[] = {
> {
> .id = 2,
> @@ -855,6 +928,12 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
> axp20x->regmap_irq_chip = &axp288_regmap_irq_chip;
> axp20x->irq_flags = IRQF_TRIGGER_LOW;
> break;
> + case AXP803_ID:
> + axp20x->nr_cells = ARRAY_SIZE(axp803_cells);
> + axp20x->cells = axp803_cells;
> + axp20x->regmap_cfg = &axp288_regmap_config;
> + axp20x->regmap_irq_chip = &axp803_regmap_irq_chip;
> + break;
> case AXP806_ID:
> axp20x->nr_cells = ARRAY_SIZE(axp806_cells);
> axp20x->cells = axp806_cells;
> diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
> index dc8798cf2a24..cde56cfe8446 100644
> --- a/include/linux/mfd/axp20x.h
> +++ b/include/linux/mfd/axp20x.h
> @@ -20,6 +20,7 @@ enum axp20x_variants {
> AXP221_ID,
> AXP223_ID,
> AXP288_ID,
> + AXP803_ID,
> AXP806_ID,
> AXP809_ID,
> NR_AXP20X_VARIANTS,
> @@ -234,7 +235,7 @@ enum axp20x_variants {
> #define AXP22X_TS_ADC_L 0x59
> #define AXP22X_BATLOW_THRES1 0xe6
>
> -/* AXP288 specific registers */
> +/* AXP288/AXP803 specific registers */
> #define AXP288_POWER_REASON 0x02
> #define AXP288_BC_GLOBAL 0x2c
> #define AXP288_BC_VBUS_CNTL 0x2d
> @@ -475,6 +476,43 @@ enum axp288_irqs {
> AXP288_IRQ_BC_USB_CHNG,
> };
>
> +enum axp803_irqs {
> + AXP803_IRQ_ACIN_OVER_V = 1,
> + AXP803_IRQ_ACIN_PLUGIN,
> + AXP803_IRQ_ACIN_REMOVAL,
> + AXP803_IRQ_VBUS_OVER_V,
> + AXP803_IRQ_VBUS_PLUGIN,
> + AXP803_IRQ_VBUS_REMOVAL,
> + AXP803_IRQ_BATT_PLUGIN,
> + AXP803_IRQ_BATT_REMOVAL,
> + AXP803_IRQ_BATT_ENT_ACT_MODE,
> + AXP803_IRQ_BATT_EXIT_ACT_MODE,
> + AXP803_IRQ_CHARG,
> + AXP803_IRQ_CHARG_DONE,
> + AXP803_IRQ_BATT_CHG_TEMP_HIGH,
> + AXP803_IRQ_BATT_CHG_TEMP_HIGH_END,
> + AXP803_IRQ_BATT_CHG_TEMP_LOW,
> + AXP803_IRQ_BATT_CHG_TEMP_LOW_END,
> + AXP803_IRQ_BATT_ACT_TEMP_HIGH,
> + AXP803_IRQ_BATT_ACT_TEMP_HIGH_END,
> + AXP803_IRQ_BATT_ACT_TEMP_LOW,
> + AXP803_IRQ_BATT_ACT_TEMP_LOW_END,
> + AXP803_IRQ_DIE_TEMP_HIGH,
> + AXP803_IRQ_GPADC,
> + AXP803_IRQ_LOW_PWR_LVL1,
> + AXP803_IRQ_LOW_PWR_LVL2,
> + AXP803_IRQ_TIMER,
> + AXP803_IRQ_PEK_RIS_EDGE,
> + AXP803_IRQ_PEK_FAL_EDGE,
> + AXP803_IRQ_PEK_SHORT,
> + AXP803_IRQ_PEK_LONG,
> + AXP803_IRQ_PEK_OVER_OFF,
> + AXP803_IRQ_GPIO1_INPUT,
> + AXP803_IRQ_GPIO0_INPUT,
> + AXP803_IRQ_BC_USB_CHNG,
> + AXP803_IRQ_MV_CHNG,
> +};
> +
> enum axp806_irqs {
> AXP806_IRQ_DIE_TEMP_HIGH_LV1,
> AXP806_IRQ_DIE_TEMP_HIGH_LV2,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v2 06/11] dt-bindings: add AXP803's regulator info
From: Lee Jones @ 2017-04-11 14:03 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Maxime Ripard, Liam Girdwood,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170407183441.58750-7-icenowy-h8G6r0blFSE@public.gmane.org>
On Sat, 08 Apr 2017, Icenowy Zheng wrote:
> AXP803 have the most regulators in currently supported AXP PMICs.
>
> Add info for the regulators in the dt-bindings document.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> Changes in v2:
> - Place AXP803 regulators before AXP806/809 ones.
>
> Documentation/devicetree/bindings/mfd/axp20x.txt | 27 ++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index 334fb19ce605..50e381cdbf44 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -90,6 +90,33 @@ LDO_IO1 : LDO : ips-supply : GPIO 1
> RTC_LDO : LDO : ips-supply : always on
> DRIVEVBUS : Enable output : drivevbus-supply : external regulator
>
> +AXP803 regulators, type, and corresponding input supply names:
> +
> +Regulator Type Supply Name Notes
> +--------- ---- ----------- -----
> +DCDC1 : DC-DC buck : vin1-supply
> +DCDC2 : DC-DC buck : vin2-supply : poly-phase capable
> +DCDC3 : DC-DC buck : vin3-supply : poly-phase capable
> +DCDC4 : DC-DC buck : vin4-supply
> +DCDC5 : DC-DC buck : vin5-supply : poly-phase capable
> +DCDC6 : DC-DC buck : vin6-supply : poly-phase capable
> +DC1SW : On/Off Switch : : DCDC1 secondary output
> +ALDO1 : LDO : aldoin-supply : shared supply
> +ALDO2 : LDO : aldoin-supply : shared supply
> +ALDO3 : LDO : aldoin-supply : shared supply
> +DLDO1 : LDO : dldoin-supply : shared supply
> +DLDO2 : LDO : dldoin-supply : shared supply
> +DLDO3 : LDO : dldoin-supply : shared supply
> +DLDO4 : LDO : dldoin-supply : shared supply
> +ELDO1 : LDO : eldoin-supply : shared supply
> +ELDO2 : LDO : eldoin-supply : shared supply
> +ELDO3 : LDO : eldoin-supply : shared supply
> +FLDO1 : LDO : fldoin-supply : shared supply
> +FLDO2 : LDO : fldoin-supply : shared supply
> +LDO_IO0 : LDO : ips-supply : GPIO 0
> +LDO_IO1 : LDO : ips-supply : GPIO 1
> +RTC_LDO : LDO : ips-supply : always on
> +
> AXP806 regulators, type, and corresponding input supply names:
>
> Regulator Type Supply Name Notes
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v2 07/11] regulator: axp20x-regulator: add support for AXP803
From: Lee Jones @ 2017-04-11 14:03 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Maxime Ripard, Liam Girdwood,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170407183441.58750-8-icenowy-h8G6r0blFSE@public.gmane.org>
On Sat, 08 Apr 2017, Icenowy Zheng wrote:
> AXP803 PMIC also have a series of regulators (DCDCs and LDOs)
> controllable via I2C/RSB bus.
>
> Add support for them.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> Changes in v2:
> - Place AXP803 codes before AXP806/809 ones.
> - Fixed some errors in regulator description.
> - Reuse AXP803 DLDO2 range for AXP806 CLDO2 & AXP809 DLDO1.
>
> drivers/regulator/axp20x-regulator.c | 153 ++++++++++++++++++++++++++++++-----
> include/linux/mfd/axp20x.h | 37 +++++++++
> 2 files changed, 168 insertions(+), 22 deletions(-)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
> index 0b9d4e3e52c7..2ed15e4a7a82 100644
> --- a/drivers/regulator/axp20x-regulator.c
> +++ b/drivers/regulator/axp20x-regulator.c
> @@ -244,6 +244,82 @@ static const struct regulator_desc axp22x_drivevbus_regulator = {
> .ops = &axp20x_ops_sw,
> };
>
> +static const struct regulator_linear_range axp803_dcdc234_ranges[] = {
> + REGULATOR_LINEAR_RANGE(500000, 0x0, 0x46, 10000),
> + REGULATOR_LINEAR_RANGE(1220000, 0x47, 0x4b, 20000),
> +};
> +
> +static const struct regulator_linear_range axp803_dcdc5_ranges[] = {
> + REGULATOR_LINEAR_RANGE(800000, 0x0, 0x20, 10000),
> + REGULATOR_LINEAR_RANGE(1140000, 0x21, 0x44, 20000),
> +};
> +
> +static const struct regulator_linear_range axp803_dcdc6_ranges[] = {
> + REGULATOR_LINEAR_RANGE(600000, 0x0, 0x32, 10000),
> + REGULATOR_LINEAR_RANGE(1120000, 0x33, 0x47, 20000),
> +};
> +
> +/* AXP806's CLDO2 and AXP809's DLDO1 shares the same range */
> +static const struct regulator_linear_range axp803_dldo2_ranges[] = {
> + REGULATOR_LINEAR_RANGE(700000, 0x0, 0x1a, 100000),
> + REGULATOR_LINEAR_RANGE(3400000, 0x1b, 0x1f, 200000),
> +};
> +
> +static const struct regulator_desc axp803_regulators[] = {
> + AXP_DESC(AXP803, DCDC1, "dcdc1", "vin1", 1600, 3400, 100,
> + AXP803_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(0)),
> + AXP_DESC_RANGES(AXP803, DCDC2, "dcdc2", "vin2", axp803_dcdc234_ranges,
> + 76, AXP803_DCDC2_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
> + BIT(1)),
> + AXP_DESC_RANGES(AXP803, DCDC3, "dcdc3", "vin3", axp803_dcdc234_ranges,
> + 76, AXP803_DCDC3_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
> + BIT(2)),
> + AXP_DESC_RANGES(AXP803, DCDC4, "dcdc4", "vin4", axp803_dcdc234_ranges,
> + 76, AXP803_DCDC4_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
> + BIT(3)),
> + AXP_DESC_RANGES(AXP803, DCDC5, "dcdc5", "vin5", axp803_dcdc5_ranges,
> + 68, AXP803_DCDC5_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
> + BIT(4)),
> + AXP_DESC_RANGES(AXP803, DCDC6, "dcdc6", "vin6", axp803_dcdc6_ranges,
> + 72, AXP803_DCDC6_V_OUT, 0x7f, AXP22X_PWR_OUT_CTRL1,
> + BIT(5)),
> + /* secondary switchable output of DCDC1 */
> + AXP_DESC_SW(AXP803, DC1SW, "dc1sw", NULL, AXP22X_PWR_OUT_CTRL2,
> + BIT(7)),
> + AXP_DESC(AXP803, ALDO1, "aldo1", "aldoin", 700, 3300, 100,
> + AXP22X_ALDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(5)),
> + AXP_DESC(AXP803, ALDO2, "aldo2", "aldoin", 700, 3300, 100,
> + AXP22X_ALDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(6)),
> + AXP_DESC(AXP803, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
> + AXP22X_ALDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL3, BIT(7)),
> + AXP_DESC(AXP803, DLDO1, "dldo1", "dldoin", 700, 3300, 100,
> + AXP22X_DLDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(3)),
> + AXP_DESC_RANGES(AXP803, DLDO2, "dldo2", "dldoin", axp803_dldo2_ranges,
> + 32, AXP22X_DLDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2,
> + BIT(4)),
> + AXP_DESC(AXP803, DLDO3, "dldo3", "dldoin", 700, 3300, 100,
> + AXP22X_DLDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(5)),
> + AXP_DESC(AXP803, DLDO4, "dldo4", "dldoin", 700, 3300, 100,
> + AXP22X_DLDO4_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(6)),
> + AXP_DESC(AXP803, ELDO1, "eldo1", "eldoin", 700, 1900, 50,
> + AXP22X_ELDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(0)),
> + AXP_DESC(AXP803, ELDO2, "eldo2", "eldoin", 700, 1900, 50,
> + AXP22X_ELDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(1)),
> + AXP_DESC(AXP803, ELDO3, "eldo3", "eldoin", 700, 1900, 50,
> + AXP22X_ELDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(2)),
> + AXP_DESC(AXP803, FLDO1, "fldo1", "fldoin", 700, 1450, 50,
> + AXP803_FLDO1_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(2)),
> + AXP_DESC(AXP803, FLDO2, "fldo2", "fldoin", 700, 1450, 50,
> + AXP803_FLDO2_V_OUT, 0x0f, AXP22X_PWR_OUT_CTRL3, BIT(3)),
> + AXP_DESC_IO(AXP803, LDO_IO0, "ldo_io0", "ips", 700, 3300, 100,
> + AXP22X_LDO_IO0_V_OUT, 0x1f, AXP20X_GPIO0_CTRL, 0x07,
> + AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
> + AXP_DESC_IO(AXP803, LDO_IO1, "ldo_io1", "ips", 700, 3300, 100,
> + AXP22X_LDO_IO1_V_OUT, 0x1f, AXP20X_GPIO1_CTRL, 0x07,
> + AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
> + AXP_DESC_FIXED(AXP803, RTC_LDO, "rtc_ldo", "ips", 3000),
> +};
> +
> static const struct regulator_linear_range axp806_dcdca_ranges[] = {
> REGULATOR_LINEAR_RANGE(600000, 0x0, 0x32, 10000),
> REGULATOR_LINEAR_RANGE(1120000, 0x33, 0x47, 20000),
> @@ -254,11 +330,6 @@ static const struct regulator_linear_range axp806_dcdcd_ranges[] = {
> REGULATOR_LINEAR_RANGE(1600000, 0x2e, 0x3f, 100000),
> };
>
> -static const struct regulator_linear_range axp806_cldo2_ranges[] = {
> - REGULATOR_LINEAR_RANGE(700000, 0x0, 0x1a, 100000),
> - REGULATOR_LINEAR_RANGE(3400000, 0x1b, 0x1f, 200000),
> -};
> -
> static const struct regulator_desc axp806_regulators[] = {
> AXP_DESC_RANGES(AXP806, DCDCA, "dcdca", "vina", axp806_dcdca_ranges,
> 72, AXP806_DCDCA_V_CTRL, 0x7f, AXP806_PWR_OUT_CTRL1,
> @@ -289,7 +360,7 @@ static const struct regulator_desc axp806_regulators[] = {
> AXP806_BLDO4_V_CTRL, 0x0f, AXP806_PWR_OUT_CTRL2, BIT(3)),
> AXP_DESC(AXP806, CLDO1, "cldo1", "cldoin", 700, 3300, 100,
> AXP806_CLDO1_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL2, BIT(4)),
> - AXP_DESC_RANGES(AXP806, CLDO2, "cldo2", "cldoin", axp806_cldo2_ranges,
> + AXP_DESC_RANGES(AXP806, CLDO2, "cldo2", "cldoin", axp803_dldo2_ranges,
> 32, AXP806_CLDO2_V_CTRL, 0x1f, AXP806_PWR_OUT_CTRL2,
> BIT(5)),
> AXP_DESC(AXP806, CLDO3, "cldo3", "cldoin", 700, 3300, 100,
> @@ -326,7 +397,7 @@ static const struct regulator_desc axp809_regulators[] = {
> AXP22X_ALDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(7)),
> AXP_DESC(AXP809, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
> AXP22X_ALDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(5)),
> - AXP_DESC_RANGES(AXP809, DLDO1, "dldo1", "dldoin", axp806_cldo2_ranges,
> + AXP_DESC_RANGES(AXP809, DLDO1, "dldo1", "dldoin", axp803_dldo2_ranges,
> 32, AXP22X_DLDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2,
> BIT(3)),
> AXP_DESC(AXP809, DLDO2, "dldo2", "dldoin", 700, 3300, 100,
> @@ -369,14 +440,21 @@ static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
> def = 1500;
> step = 75;
> break;
> - case AXP806_ID:
> + case AXP803_ID:
> /*
> - * AXP806 DCDC work frequency setting has the same range and
> + * AXP803 DCDC work frequency setting has the same range and
> * step as AXP22X, but at a different register.
> * Fall through to the check below.
> * (See include/linux/mfd/axp20x.h)
> */
> - reg = AXP806_DCDC_FREQ_CTRL;
> + reg = AXP803_DCDC_FREQ_CTRL;
> + case AXP806_ID:
> + /*
> + * AXP806 also have DCDC work frequency setting register at a
> + * different position.
> + */
> + if (axp20x->variant == AXP806_ID)
> + reg = AXP806_DCDC_FREQ_CTRL;
> case AXP221_ID:
> case AXP223_ID:
> case AXP809_ID:
> @@ -475,6 +553,14 @@ static int axp20x_set_dcdc_workmode(struct regulator_dev *rdev, int id, u32 work
> workmode <<= id - AXP22X_DCDC1;
> break;
>
> + case AXP803_ID:
> + if (id < AXP803_DCDC1 || id > AXP803_DCDC6)
> + return -EINVAL;
> +
> + mask = AXP22X_WORKMODE_DCDCX_MASK(id - AXP803_DCDC1);
> + workmode <<= id - AXP803_DCDC1;
> + break;
> +
> default:
> /* should not happen */
> WARN_ON(1);
> @@ -492,20 +578,38 @@ static bool axp20x_is_polyphase_slave(struct axp20x_dev *axp20x, int id)
> {
> u32 reg = 0;
>
> - /* Only AXP806 has poly-phase outputs */
> - if (axp20x->variant != AXP806_ID)
> - return false;
> + /*
> + * Currently in our supported AXP variants, only AXP806 and AXP803
> + * have polyphase regulators.
> + */
> + switch (axp20x->variant) {
> + case AXP803_ID:
> + regmap_read(axp20x->regmap, AXP803_POLYPHASE_CTRL, ®);
> +
> + switch (id) {
> + case AXP803_DCDC3:
> + return !!(reg & BIT(6));
> + case AXP803_DCDC6:
> + return !!(reg & BIT(7));
> + }
> + break;
>
> - regmap_read(axp20x->regmap, AXP806_DCDC_MODE_CTRL2, ®);
> + case AXP806_ID:
> + regmap_read(axp20x->regmap, AXP806_DCDC_MODE_CTRL2, ®);
> +
> + switch (id) {
> + case AXP806_DCDCB:
> + return (((reg & GENMASK(7, 6)) == BIT(6)) ||
> + ((reg & GENMASK(7, 6)) == BIT(7)));
> + case AXP806_DCDCC:
> + return ((reg & GENMASK(7, 6)) == BIT(7));
> + case AXP806_DCDCE:
> + return !!(reg & BIT(5));
> + }
> + break;
>
> - switch (id) {
> - case AXP806_DCDCB:
> - return (((reg & GENMASK(7, 6)) == BIT(6)) ||
> - ((reg & GENMASK(7, 6)) == BIT(7)));
> - case AXP806_DCDCC:
> - return ((reg & GENMASK(7, 6)) == BIT(7));
> - case AXP806_DCDCE:
> - return !!(reg & BIT(5));
> + default:
> + return false;
> }
>
> return false;
> @@ -540,6 +644,10 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
> drivevbus = of_property_read_bool(pdev->dev.parent->of_node,
> "x-powers,drive-vbus-en");
> break;
> + case AXP803_ID:
> + regulators = axp803_regulators;
> + nregulators = AXP803_REG_ID_MAX;
> + break;
> case AXP806_ID:
> regulators = axp806_regulators;
> nregulators = AXP806_REG_ID_MAX;
> @@ -579,6 +687,7 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
> * name.
> */
> if ((regulators == axp22x_regulators && i == AXP22X_DC1SW) ||
> + (regulators == axp803_regulators && i == AXP803_DC1SW) ||
> (regulators == axp809_regulators && i == AXP809_DC1SW)) {
> new_desc = devm_kzalloc(&pdev->dev, sizeof(*desc),
> GFP_KERNEL);
> diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
> index cde56cfe8446..965b027e31b3 100644
> --- a/include/linux/mfd/axp20x.h
> +++ b/include/linux/mfd/axp20x.h
> @@ -119,6 +119,17 @@ enum axp20x_variants {
> #define AXP806_BUS_ADDR_EXT 0xfe
> #define AXP806_REG_ADDR_EXT 0xff
>
> +#define AXP803_POLYPHASE_CTRL 0x14
> +#define AXP803_FLDO1_V_OUT 0x1c
> +#define AXP803_FLDO2_V_OUT 0x1d
> +#define AXP803_DCDC1_V_OUT 0x20
> +#define AXP803_DCDC2_V_OUT 0x21
> +#define AXP803_DCDC3_V_OUT 0x22
> +#define AXP803_DCDC4_V_OUT 0x23
> +#define AXP803_DCDC5_V_OUT 0x24
> +#define AXP803_DCDC6_V_OUT 0x25
> +#define AXP803_DCDC_FREQ_CTRL 0x3b
> +
> /* Interrupt */
> #define AXP152_IRQ1_EN 0x40
> #define AXP152_IRQ2_EN 0x41
> @@ -350,6 +361,32 @@ enum {
> AXP809_REG_ID_MAX,
> };
>
> +enum {
> + AXP803_DCDC1 = 0,
> + AXP803_DCDC2,
> + AXP803_DCDC3,
> + AXP803_DCDC4,
> + AXP803_DCDC5,
> + AXP803_DCDC6,
> + AXP803_DC1SW,
> + AXP803_ALDO1,
> + AXP803_ALDO2,
> + AXP803_ALDO3,
> + AXP803_DLDO1,
> + AXP803_DLDO2,
> + AXP803_DLDO3,
> + AXP803_DLDO4,
> + AXP803_ELDO1,
> + AXP803_ELDO2,
> + AXP803_ELDO3,
> + AXP803_FLDO1,
> + AXP803_FLDO2,
> + AXP803_RTC_LDO,
> + AXP803_LDO_IO0,
> + AXP803_LDO_IO1,
> + AXP803_REG_ID_MAX,
> +};
> +
> /* IRQs */
> enum {
> AXP152_IRQ_LDO0IN_CONNECT = 1,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v2 08/11] mfd: axp20x: add axp20x-regulator cell for AXP803
From: Lee Jones @ 2017-04-11 14:03 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Maxime Ripard, Liam Girdwood,
devicetree, linux-sunxi, linux-kernel, linux-arm-kernel
In-Reply-To: <20170407183441.58750-9-icenowy@aosc.io>
On Sat, 08 Apr 2017, Icenowy Zheng wrote:
> As axp20x-regulator now supports AXP803, add a cell for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> drivers/mfd/axp20x.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 2268a6a9aa2c..08b9bbd5bd71 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -839,6 +839,8 @@ static struct mfd_cell axp803_cells[] = {
> .name = "axp20x-pek",
> .num_resources = ARRAY_SIZE(axp803_pek_resources),
> .resources = axp803_pek_resources,
> + }, {
> + .name = "axp20x-regulator",
I'd prefer it if you placed single lined entries on one line.
Like this:
{ .name = "axp20x-regulator" }
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v4 1/8] dt-bindings: mfd: Add retu/tahvo ASIC chips bindings
From: Lee Jones @ 2017-04-11 13:57 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, Aaro Koskinen, devicetree, Rob Herring,
Tony Lindgren, Mark Rutland
In-Reply-To: <20170404153036.6651-2-javier@osg.samsung.com>
On Tue, 04 Apr 2017, Javier Martinez Canillas wrote:
> There are Device Tree source files defining a device node for the
> retu/tahvo I2C chip, but there isn't a DT binding document for it.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
> ---
>
> Changes in v4:
> - Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
> - Add information about what functions the device serve (Lee Jones).
> - Avoid using MFD in Device Tree (Lee Jones).
>
> Changes in v3: None
> Changes in v2: None
>
> Documentation/devicetree/bindings/mfd/retu.txt | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/retu.txt
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> diff --git a/Documentation/devicetree/bindings/mfd/retu.txt b/Documentation/devicetree/bindings/mfd/retu.txt
> new file mode 100644
> index 000000000000..7df21a2b28ea
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/retu.txt
> @@ -0,0 +1,21 @@
> +* Device tree bindings for Nokia Retu and Tahvo multi-function device
> +
> +Retu and Tahvo are a multi-function devices found on Nokia Internet
> +Tablets (770, N800 and N810). The Retu chip provides watchdog timer
> +and power button control functionalities while Tahvo chip provides
> +USB transceiver functionality.
> +
> +Required properties:
> +- compatible: "nokia,retu" or "nokia,tahvo"
> +- reg: Specifies the I2C slave address of the ASIC chip
> +
> +Example:
> +
> +i2c0 {
> + retu: retu@1 {
> + compatible = "nokia,retu";
> + interrupt-parent = <&gpio4>;
> + interrupts = <12 IRQ_TYPE_EDGE_RISING>;
> + reg = <0x1>;
> + };
> +};
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox