* 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
* Re: [PATCH v4 7/8] mfd: tps6105x: Add OF device ID table
From: Lee Jones @ 2017-04-11 13:57 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Aaro Koskinen,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Tony Lindgren
In-Reply-To: <20170404153036.6651-8-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On Tue, 04 Apr 2017, 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 a
> OF device ID table if the devices are registered via OF.
>
> Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
>
> ---
>
> Changes in v4: None
> Changes in v3:
> - Add a vendor prefix to the compatible string (Rob Herring).
>
> Changes in v2:
> - Don't use of_match_ptr() to avoid build warning when CONFIG_OF is disabled.
>
> drivers/mfd/tps6105x.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> diff --git a/drivers/mfd/tps6105x.c b/drivers/mfd/tps6105x.c
> index baa12ea666fb..187848c93779 100644
> --- a/drivers/mfd/tps6105x.c
> +++ b/drivers/mfd/tps6105x.c
> @@ -173,9 +173,17 @@ static const struct i2c_device_id tps6105x_id[] = {
> };
> MODULE_DEVICE_TABLE(i2c, tps6105x_id);
>
> +static const struct of_device_id tps6105x_of_match[] = {
> + { .compatible = "ti,tps61050" },
> + { .compatible = "ti,tps61052" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, tps6105x_of_match);
> +
> static struct i2c_driver tps6105x_driver = {
> .driver = {
> .name = "tps6105x",
> + .of_match_table = tps6105x_of_match,
> },
> .probe = tps6105x_probe,
> .remove = tps6105x_remove,
--
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 v4 3/8] mfd: retu: Add OF device ID table
From: Lee Jones @ 2017-04-11 13:56 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Aaro Koskinen,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Tony Lindgren
In-Reply-To: <20170404153036.6651-4-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On Tue, 04 Apr 2017, 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 a
> OF device ID table if the devices are registered via OF.
>
> Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
>
> ---
>
> Changes in v4:
> - Drop -mfd suffix in compatible string (Lee Jones).
>
> Changes in v3:
> - Add a vendor prefix to the compatible string (Rob Herring).
>
> Changes in v2:
> - Don't use of_match_ptr() to avoid build warning when CONFIG_OF is disabled.
>
> drivers/mfd/retu-mfd.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c
> index 53e1d386d2c0..e7d27b7861c1 100644
> --- a/drivers/mfd/retu-mfd.c
> +++ b/drivers/mfd/retu-mfd.c
> @@ -308,9 +308,17 @@ static const struct i2c_device_id retu_id[] = {
> };
> MODULE_DEVICE_TABLE(i2c, retu_id);
>
> +static const struct of_device_id retu_of_match[] = {
> + { .compatible = "nokia,retu" },
> + { .compatible = "nokia,tahvo" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, retu_of_match);
> +
> static struct i2c_driver retu_driver = {
> .driver = {
> .name = "retu-mfd",
> + .of_match_table = retu_of_match,
> },
> .probe = retu_probe,
> .remove = retu_remove,
--
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 v4 2/8] mfd: retu: Drop -mfd suffix from I2C device ID name
From: Lee Jones @ 2017-04-11 13:56 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, Aaro Koskinen, devicetree, Rob Herring,
Tony Lindgren, Benoît Cousson, Mark Rutland, linux-omap,
Russell King, linux-arm-kernel
In-Reply-To: <20170404153036.6651-3-javier@osg.samsung.com>
On Tue, 04 Apr 2017, Javier Martinez Canillas wrote:
> It's not correct to encode the subsystem in the I2C device name, so
> drop the -mfd suffix. To maintain bisect-ability, change driver and
> platform code / DTS users in the same patch.
>
> Suggested-by: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
> arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 4 ++--
> arch/arm/mach-omap1/board-nokia770.c | 4 ++--
> drivers/mfd/retu-mfd.c | 4 ++--
> 3 files changed, 6 insertions(+), 6 deletions(-)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> diff --git a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
> index 7e5ffc583c90..1b06430c8013 100644
> --- a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
> +++ b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
> @@ -15,8 +15,8 @@
> >;
> #address-cells = <1>;
> #size-cells = <0>;
> - retu_mfd: retu@1 {
> - compatible = "retu-mfd";
> + retu: retu@1 {
> + compatible = "retu";
> interrupt-parent = <&gpio4>;
> interrupts = <12 IRQ_TYPE_EDGE_RISING>;
> reg = <0x1>;
> diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c
> index ee8d9f553db4..06243c0b12d2 100644
> --- a/arch/arm/mach-omap1/board-nokia770.c
> +++ b/arch/arm/mach-omap1/board-nokia770.c
> @@ -233,10 +233,10 @@ static struct platform_device nokia770_cbus_device = {
>
> static struct i2c_board_info nokia770_i2c_board_info_2[] __initdata = {
> {
> - I2C_BOARD_INFO("retu-mfd", 0x01),
> + I2C_BOARD_INFO("retu", 0x01),
> },
> {
> - I2C_BOARD_INFO("tahvo-mfd", 0x02),
> + I2C_BOARD_INFO("tahvo", 0x02),
> },
> };
>
> diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c
> index d4c114abeb75..53e1d386d2c0 100644
> --- a/drivers/mfd/retu-mfd.c
> +++ b/drivers/mfd/retu-mfd.c
> @@ -302,8 +302,8 @@ static int retu_remove(struct i2c_client *i2c)
> }
>
> static const struct i2c_device_id retu_id[] = {
> - { "retu-mfd", 0 },
> - { "tahvo-mfd", 0 },
> + { "retu", 0 },
> + { "tahvo", 0 },
> { }
> };
> MODULE_DEVICE_TABLE(i2c, retu_id);
--
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 2/2] devicetree: Document the max31760 device binding.
From: John Muir @ 2017-04-11 13:47 UTC (permalink / raw)
To: Rob Herring
Cc: Jean Delvare, Guenter Roeck, Jonathan Corbet, Pawel Moll,
Ian Campbell, Kumar Gala, devicetree, linux-hwmon, linux-doc,
Anatol Pomazau, Mark Segal
In-Reply-To: <20170410154249.r77b6vf3ctzn4kua@rob-hp-laptop>
> On Apr 10, 2017, at 8:42 AM, Rob Herring <robh@kernel.org> wrote:
>
> On Tue, Apr 04, 2017 at 12:20:34PM -0700, John Muir wrote:
>> +MAX31760 fan controller
>> +-----------------------
>> +
>> +This device supports I2C only. Many properties of this device are configurable
>> +thorugh the hwmon interface. See also Documentation/hwmon/max31760.
>
> I really think we need to describe the fans as separate nodes and
> preferably with a common binding. This is the second fan controller
> binding recently[1].
>
> Features of the "hwmon interface" are not relevant to the binding.
> Bindings describe h/w.
It seems to me that referring to the hwmon interface is only helpful. You are suggesting removing those sentences? If so, can I add a link to the data sheet?
>
>> +Optional node properties:
>> +- maxim,fan1-enabled - 1 to enable, 0 to disable. Default: 1.
>> +- maxim,fan2-enabled - 1 to enable, 0 to disable. Default: 1.
>> +- maxim,fan1-label - String: Hwmon fan1_label.
>> +- maxim,fan2-label - String: Hwmon fan2_label.
>
> Perhaps 2 fan sub nodes. reg for fan number, status for enabled, and
> label for label.
OK.
Right now a fan’s number of pulses and the PWM frequency are configured using the hwmon sysfs interface (which defines standard controls for those), but as those are characteristics of the hardware, should they also be configured via the device tree binding?
>> +- maxim,pwm-zero-fan-can-fail - 0: Fan failure detection disabled when PWM is
>> + ramping to 0%.
>> + 1: Fan failure detection enabled for all PWM
>> + values.
>> + Default: 0.
>
> All these can be boolean…
OK. The only issue I see is when the default is ‘true’ in the device, but I’ll try to avoid that. Sometimes I wish that you could set a boolean to false in DTS files.
>
>> +- maxim,temp1-label - String: Hwmon temp1_label.
>> +- maxim,temp2-label - String: Hwmon temp2_label.
>> +- maxim,temp2-ideality - Set ideality factor for the remote temperature
>> + sensor. Integer with range 0 to 63,
>> + representing a multiplication factor of 0.9844
>> + to 1.0489. Default: 24 (1.0080).
>
> No maxim,temp1-ideality?
No - the device only lets you set the ideality of the ‘external' temperature sensor. I guess if there is an ideality for the internal temperature sensor, it would be hard-wired as a characteristic of the part that was used.
> Not sure what to do with these, but perhaps
> also as sub-nodes. Surely we have some bindings already for devices with
> multiple temp sensors. Don't invent something custom here.
I’ll look into it.
What is the best way to distinguish between ‘fan’ and ‘temp’ sub-nodes? Do I require a ‘compatible’ string?
Thanks!
John.
^ permalink raw reply
* Re: [PATCH v1 3/3] nvmem: dt: document SNVS LPGPR binding
From: Rob Herring @ 2017-04-11 13:35 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Oleksij Rempel, Srinivas Kandagatla, Maxime Ripard, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1e0f8a71-9dca-7aaa-a603-86ed3934da4d-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Mon, Apr 10, 2017 at 11:36 PM, Oleksij Rempel <ore-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> Hi,
>
>
> On 04/10/2017 08:22 PM, Rob Herring wrote:
>>
>> On Thu, Apr 06, 2017 at 09:31:07AM +0200, Oleksij Rempel wrote:
>>>
>>> Documenation bindings for the Low Power General Purpose Registe
>>
>>
>> s/Registe/Register/
>>
>>> available on i.MX6 SoCs in the Secure Non-Volatile Storage.
>>>
>>> Signed-off-by: Oleksij Rempel <o.rempel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>>> Cc: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>> Cc: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> ---
>>> Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt | 15
>>> +++++++++++++++
>>> 1 file changed, 15 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
>>> b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
>>> new file mode 100644
>>> index 000000000000..9a8be1a2d12e
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/nvmem/snvs-lpgpr.txt
>>> @@ -0,0 +1,15 @@
>>> +Device tree bindings for Low Power General Purpose Registe found in
>>> i.MX6Q/D
>>> +Secure Non-Volatile Storage.
>>> +
>>> +Required properties:
>>> +- compatible: should be one of
>>> + "fsl,imx6q-snvs-lpgpr" (i.MX6Q/D/DL/S).
>>> +- offset: Should contain the offset relative to syscon parrent node.
>>
>>
>> typo
>
>
> ok.
>
>> +- regmap: Should contain a phandle pointing to syscon.
>>>
>>> +
>>> +Example:
>>> + snvs_lpgpr: snvs-lpgpr {
>>> + compatible = "fsl,imx6q-snvs-lpgpr";
>>> + regmap = <&snvs>;
>>> + offset = <0x68>;
>>
>>
>> Why does this need to be in DT? Is something going to refer to this
>> node? If not, the &snvs node should be enough information for the OS.
>
>
> Jes, it is refereed by other driver.
What I mean is snvs-lpgpr referenced elsewhere in DT, not by some
driver? You are not using the nvmem binding here so it doesn't seem
like it is. If that's the case, then you don't need this node. The
only information here is the offset which can be part of a driver for
the parent node. To put it another way, we don't want to fill DT with
a node per register.
Rob
--
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
* [PATCH 1/1] ARM: dts: dra7x-evm: Enable dual-role mode for USB1
From: Roger Quadros @ 2017-04-11 13:16 UTC (permalink / raw)
To: tony-4v6yS6AI5VpBDgjK7y7TUQ
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Roger Quadros, Sekhar Nori
In-Reply-To: <1491916575-16023-1-git-send-email-rogerq-l0cyMroinI0@public.gmane.org>
USB1 port is micro-AB type and can function as peripheral
as well as host. Enable dual-role mode for USB1.
We don't want to use the OTG controller block on this
platform as it limits host mode to high-speed. Instead
we rely on extcon framework to give us ID events for
dual-role mode detection.
Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
Signed-off-by: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
---
arch/arm/boot/dts/dra7-evm.dts | 3 ++-
arch/arm/boot/dts/dra72-evm-common.dtsi | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 4bc4b57..c408aaa 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -527,7 +527,8 @@
};
&usb1 {
- dr_mode = "peripheral";
+ dr_mode = "otg";
+ extcon = <&extcon_usb1>;
};
&usb2 {
diff --git a/arch/arm/boot/dts/dra72-evm-common.dtsi b/arch/arm/boot/dts/dra72-evm-common.dtsi
index ad24544..8578054 100644
--- a/arch/arm/boot/dts/dra72-evm-common.dtsi
+++ b/arch/arm/boot/dts/dra72-evm-common.dtsi
@@ -392,7 +392,8 @@
};
&usb1 {
- dr_mode = "peripheral";
+ dr_mode = "otg";
+ extcon = <&extcon_usb1>;
};
&usb2 {
--
2.7.4
--
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 related
* [PATCH 0/1] ARM: dts: dra7x-evm: Enable dual-role mode for USB1
From: Roger Quadros @ 2017-04-11 13:16 UTC (permalink / raw)
To: tony-4v6yS6AI5VpBDgjK7y7TUQ
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Roger Quadros
Hi Tony,
Dual role support for DWC3 is now in usb/next. With this patch we can
utilize dual-role mode on dra7x boards. Please queue for -next. Thanks.
cheers,
-roger
Roger Quadros (1):
ARM: dts: dra7x-evm: Enable dual-role mode for USB1
arch/arm/boot/dts/dra7-evm.dts | 3 ++-
arch/arm/boot/dts/dra72-evm-common.dtsi | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
--
2.7.4
--
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 2/7] dt-bindings: media: Add MAX2175 binding description
From: Laurent Pinchart @ 2017-04-11 12:58 UTC (permalink / raw)
To: Ramesh Shanmugasundaram
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
mchehab-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
crope-X3B1VOXEql0@public.gmane.org, Chris Paterson,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <HK2PR06MB0545F9FBB1B27E91D80F906EC3000-jAC1QCBx2F1Af0bSEaWBKm0DtJ1/0DrXvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
Hi Ramesh,
On Tuesday 11 Apr 2017 12:19:54 Ramesh Shanmugasundaram wrote:
> > On Tuesday 11 Apr 2017 09:57:45 Ramesh Shanmugasundaram wrote:
> >>> On Tuesday 07 Feb 2017 15:02:32 Ramesh Shanmugasundaram wrote:
> >>>> Add device tree binding documentation for MAX2175 Rf to bits tuner
> >>>> device.
> >>>>
> >>>> Signed-off-by: Ramesh Shanmugasundaram
> >>>> <ramesh.shanmugasundaram-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
> >>>> ---
> >>>> .../devicetree/bindings/media/i2c/max2175.txt | 61 +++++++++++++
> >>>> .../devicetree/bindings/property-units.txt | 1 +
> >>>> 2 files changed, 62 insertions(+)
> >>>> create mode 100644
> >>>>
> >>>> Documentation/devicetree/bindings/media/i2c/max2175.txt
> >>>> diff --git
> >>>> a/Documentation/devicetree/bindings/media/i2c/max2175.txt
> >>>> b/Documentation/devicetree/bindings/media/i2c/max2175.txt new file
> >>>> mode 100644 index 0000000..f591ab4
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt
> >
> > [snip]
> >
> >>>> +- maxim,am-hiz : empty property indicates AM Hi-Z filter
> >>>> path is
> >>>> + selected for AM antenna input. By default this
> >>>> + filter path is not used.
> >>>
> >>> Isn't this something that should be selected at runtime through a
> >>> control ? Or does the hardware design dictate whether the filter has
> >>> to be used or must not be used ?
> >>
> >> This is dictated by the h/w design and not selectable at run-time.
> >> I will update these changes in the next patchset.
> >
> > In that case I'm fine with a property, but could we name it in such a way
> > that it describes the hardware instead of instructing the software on how
> > to configure the device ? For instance (and this is a made-up example as I
> > don't know exactly how this works), if the AM Hi-Z filter is required when
> > dealing with AM frequencies and forbidden when dealing with other
> > frequency bands, and *if* boards have to be designed specifically for one
> > frequency band (AM, FM, VHF, L, ...) without any way to accept different
> > bands, then you could instead use
> >
> > maxim,frequency-band = "AM";
> >
> > and enable the filter accordingly in the driver. This would be in my
> > opinion a better system hardware description.
>
> I am not sure. The AM antenna input path has a default filter and AM Hi-Z
> filter. H/W dictates the path to be used for AM input only and this is
> fixed. The device can be configured to use different bands at runtime & not
> AM only. I could edit the description as below:
>
> - maxim,am-hiz : empty property indicates AM Hi-Z filter path
> usage for AM antenna input as dictated by hardware design. By default this
> filter path is not used.
>
> Is it any better? Do you still think the property name should be changed
> please?
I still think this should be renamed, but possibly because I don't understand
all the details of this particular feature :-). The property, as named and
documented above, describes a software features. It requests the driver to
enable the AM Hi-Z filter. DT properties should instead describe the hardware.
You should use a property that describes the hardware design, and use that to
infer, in the driver, whether to enable or disable the filter.
--
Regards,
Laurent Pinchart
--
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: Boris Brezillon @ 2017-04-11 12:51 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: <414dd35931814ce38381a251917ad79f-aBoyCxvc2dBaXkNJqdKpEhSpLNRU/VIH@public.gmane.org>
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.
I think we'll stick to the model name to detect whether on-die ECC is
supported.
Regards,
Boris
--
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 5/7] doc_rst: media: New SDR formats PC16, PC18 & PC20
From: Laurent Pinchart @ 2017-04-11 12:39 UTC (permalink / raw)
To: Ramesh Shanmugasundaram
Cc: robh+dt, mark.rutland, mchehab, hverkuil, sakari.ailus, crope,
chris.paterson2, geert+renesas, linux-media, devicetree,
linux-renesas-soc
In-Reply-To: <1486479757-32128-6-git-send-email-ramesh.shanmugasundaram@bp.renesas.com>
Hi Ramesh,
Thank you for the patch.
On Tuesday 07 Feb 2017 15:02:35 Ramesh Shanmugasundaram wrote:
> This patch adds documentation for the three new SDR formats
>
> V4L2_SDR_FMT_PCU16BE
> V4L2_SDR_FMT_PCU18BE
> V4L2_SDR_FMT_PCU20BE
>
> Signed-off-by: Ramesh Shanmugasundaram
> <ramesh.shanmugasundaram@bp.renesas.com> ---
> .../media/uapi/v4l/pixfmt-sdr-pcu16be.rst | 55 +++++++++++++++++++
> .../media/uapi/v4l/pixfmt-sdr-pcu18be.rst | 55 +++++++++++++++++++
> .../media/uapi/v4l/pixfmt-sdr-pcu20be.rst | 54 +++++++++++++++++++
> Documentation/media/uapi/v4l/sdr-formats.rst | 3 ++
> 4 files changed, 167 insertions(+)
> create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
> create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
> create mode 100644 Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst
>
> diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
> b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst new file mode 100644
> index 0000000..2de1b1a
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
> @@ -0,0 +1,55 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _V4L2-SDR-FMT-PCU16BE:
> +
> +******************************
> +V4L2_SDR_FMT_PCU16BE ('PC16')
> +******************************
> +
> +Planar complex unsigned 16-bit big endian IQ sample
> +
> +Description
> +===========
> +
> +This format contains a sequence of complex number samples. Each complex
> +number consist of two parts called In-phase and Quadrature (IQ). Both I
> +and Q are represented as a 16 bit unsigned big endian number stored in
> +32 bit space. The remaining unused bits within the 32 bit space will be
> +padded with 0. I value starts first and Q value starts at an offset
> +equalling half of the buffer size (i.e.) offset = buffersize/2. Out of
> +the 16 bits, bit 15:2 (14 bit) is data and bit 1:0 (2 bit) can be any
> +value.
This sounds very strange to me. Are the two lower bits always random ? What is
that used for ?
> +**Byte Order.**
> +Each cell is one byte.
> +
> +.. flat-table::
> + :header-rows: 1
> + :stub-columns: 0
> +
> + * - Offset:
> + - Byte B0
> + - Byte B1
> + - Byte B2
> + - Byte B3
> + * - start + 0:
> + - I'\ :sub:`0[13:6]`
> + - I'\ :sub:`0[5:0]; B1[1:0]=pad`
> + - pad
> + - pad
> + * - start + 4:
> + - I'\ :sub:`1[13:6]`
> + - I'\ :sub:`1[5:0]; B1[1:0]=pad`
> + - pad
> + - pad
> + * - ...
> + * - start + offset:
> + - Q'\ :sub:`0[13:6]`
> + - Q'\ :sub:`0[5:0]; B1[1:0]=pad`
> + - pad
> + - pad
> + * - start + offset + 4:
> + - Q'\ :sub:`1[13:6]`
> + - Q'\ :sub:`1[5:0]; B1[1:0]=pad`
> + - pad
> + - pad
> diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
> b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst new file mode 100644
> index 0000000..da8b26b
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
> @@ -0,0 +1,55 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _V4L2-SDR-FMT-PCU18BE:
> +
> +******************************
> +V4L2_SDR_FMT_PCU18BE ('PC18')
> +******************************
> +
> +Planar complex unsigned 18-bit big endian IQ sample
> +
> +Description
> +===========
> +
> +This format contains a sequence of complex number samples. Each complex
> +number consist of two parts called In-phase and Quadrature (IQ). Both I
> +and Q are represented as a 18 bit unsigned big endian number stored in
> +32 bit space. The remaining unused bits within the 32 bit space will be
> +padded with 0. I value starts first and Q value starts at an offset
> +equalling half of the buffer size (i.e.) offset = buffersize/2. Out of
> +the 18 bits, bit 17:2 (16 bit) is data and bit 1:0 (2 bit) can be any
> +value.
> +
> +**Byte Order.**
> +Each cell is one byte.
> +
> +.. flat-table::
> + :header-rows: 1
> + :stub-columns: 0
> +
> + * - Offset:
> + - Byte B0
> + - Byte B1
> + - Byte B2
> + - Byte B3
> + * - start + 0:
> + - I'\ :sub:`0[17:10]`
> + - I'\ :sub:`0[9:2]`
> + - I'\ :sub:`0[1:0]; B2[5:0]=pad`
> + - pad
> + * - start + 4:
> + - I'\ :sub:`1[17:10]`
> + - I'\ :sub:`1[9:2]`
> + - I'\ :sub:`1[1:0]; B2[5:0]=pad`
> + - pad
> + * - ...
> + * - start + offset:
> + - Q'\ :sub:`0[17:10]`
> + - Q'\ :sub:`0[9:2]`
> + - Q'\ :sub:`0[1:0]; B2[5:0]=pad`
> + - pad
> + * - start + offset + 4:
> + - Q'\ :sub:`1[17:10]`
> + - Q'\ :sub:`1[9:2]`
> + - Q'\ :sub:`1[1:0]; B2[5:0]=pad`
> + - pad
> diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst
> b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst new file mode 100644
> index 0000000..5499eed
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst
> @@ -0,0 +1,54 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +.. _V4L2-SDR-FMT-PCU20BE:
> +
> +******************************
> +V4L2_SDR_FMT_PCU20BE ('PC20')
> +******************************
> +
> +Planar complex unsigned 20-bit big endian IQ sample
> +
> +Description
> +===========
> +
> +This format contains a sequence of complex number samples. Each complex
> +number consist of two parts called In-phase and Quadrature (IQ). Both I
> +and Q are represented as a 20 bit unsigned big endian number stored in
> +32 bit space. The remaining unused bits within the 32 bit space will be
> +padded with 0. I value starts first and Q value starts at an offset
> +equalling half of the buffer size (i.e.) offset = buffersize/2. Out of
> +the 20 bits, bit 19:2 (18 bit) is data and bit 1:0 (2 bit) can be any
> +value.
> +
> +**Byte Order.**
> +Each cell is one byte.
> +
> +.. flat-table::
> + :header-rows: 1
> + :stub-columns: 0
> +
> + * - Offset:
> + - Byte B0
> + - Byte B1
> + - Byte B2
> + - Byte B3
> + * - start + 0:
> + - I'\ :sub:`0[19:12]`
> + - I'\ :sub:`0[11:4]`
> + - I'\ :sub:`0[3:0]; B2[3:0]=pad`
> + - pad
> + * - start + 4:
> + - I'\ :sub:`1[19:12]`
> + - I'\ :sub:`1[11:4]`
> + - I'\ :sub:`1[3:0]; B2[3:0]=pad`
> + - pad
> + * - ...
> + * - start + offset:
> + - Q'\ :sub:`0[19:12]`
> + - Q'\ :sub:`0[11:4]`
> + - Q'\ :sub:`0[3:0]; B2[3:0]=pad`
> + - pad
> + * - start + offset + 4:
> + - Q'\ :sub:`1[19:12]`
> + - Q'\ :sub:`1[11:4]`
> + - Q'\ :sub:`1[3:0]; B2[3:0]=pad`
> + - pad
> diff --git a/Documentation/media/uapi/v4l/sdr-formats.rst
> b/Documentation/media/uapi/v4l/sdr-formats.rst index f863c08..2037f5b
> 100644
> --- a/Documentation/media/uapi/v4l/sdr-formats.rst
> +++ b/Documentation/media/uapi/v4l/sdr-formats.rst
> @@ -17,3 +17,6 @@ These formats are used for :ref:`SDR <sdr>` interface
> only. pixfmt-sdr-cs08
> pixfmt-sdr-cs14le
> pixfmt-sdr-ru12le
> + pixfmt-sdr-pcu16be
> + pixfmt-sdr-pcu18be
> + pixfmt-sdr-pcu20be
--
Regards,
Laurent Pinchart
^ permalink raw reply
* RE: [PATCH v3 2/7] dt-bindings: media: Add MAX2175 binding description
From: Ramesh Shanmugasundaram @ 2017-04-11 12:19 UTC (permalink / raw)
To: Laurent Pinchart
Cc: robh+dt@kernel.org, mark.rutland@arm.com, mchehab@kernel.org,
hverkuil@xs4all.nl, sakari.ailus@linux.intel.com, crope@iki.fi,
Chris Paterson, geert+renesas@glider.be,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <6297638.5S79beP3Jj@avalon>
Hi Laurent,
> On Tuesday 11 Apr 2017 09:57:45 Ramesh Shanmugasundaram wrote:
> > > On Tuesday 07 Feb 2017 15:02:32 Ramesh Shanmugasundaram wrote:
> > >> Add device tree binding documentation for MAX2175 Rf to bits tuner
> > >> device.
> > >>
> > >> Signed-off-by: Ramesh Shanmugasundaram
> > >> <ramesh.shanmugasundaram@bp.renesas.com> ---
> > >>
> > >> .../devicetree/bindings/media/i2c/max2175.txt | 61
> +++++++++++++++
> > >> .../devicetree/bindings/property-units.txt | 1 +
> > >> 2 files changed, 62 insertions(+)
> > >> create mode 100644
> > >>
> > >> Documentation/devicetree/bindings/media/i2c/max2175.txt
> > >>
> > >> diff --git
> > >> a/Documentation/devicetree/bindings/media/i2c/max2175.txt
> > >> b/Documentation/devicetree/bindings/media/i2c/max2175.txt new file
> > >> mode 100644 index 0000000..f591ab4
> > >> --- /dev/null
> > >> +++ b/Documentation/devicetree/bindings/media/i2c/max2175.txt
>
> [snip]
>
> > >> +- maxim,am-hiz : empty property indicates AM Hi-Z filter
> path
> > >> is
> > >> + selected for AM antenna input. By default this
> > >> + filter path is not used.
> > >
> > > Isn't this something that should be selected at runtime through a
> > > control ? Or does the hardware design dictate whether the filter has
> > > to be used or must not be used ?
> >
> > This is dictated by the h/w design and not selectable at run-time.
> > I will update these changes in the next patchset.
>
> In that case I'm fine with a property, but could we name it in such a way
> that it describes the hardware instead of instructing the software on how
> to configure the device ? For instance (and this is a made-up example as I
> don't know exactly how this works), if the AM Hi-Z filter is required when
> dealing with AM frequencies and forbidden when dealing with other
> frequency bands, and
> *if* boards have to be designed specifically for one frequency band (AM,
> FM, VHF, L, ...) without any way to accept different bands, then you could
> instead use
>
> maxim,frequency-band = "AM";
>
> and enable the filter accordingly in the driver. This would be in my
> opinion a better system hardware description.
I am not sure. The AM antenna input path has a default filter and AM Hi-Z filter. H/W dictates the path to be used for AM input only and this is fixed. The device can be configured to use different bands at runtime & not AM only. I could edit the description as below:
- maxim,am-hiz : empty property indicates AM Hi-Z filter path usage for AM antenna
input as dictated by hardware design. By default this filter path is not used.
Is it any better? Do you still think the property name should be changed please?
Thanks,
Ramesh
^ 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