* Re: [PATCH 5/8] power: supply: axp20x_battery: add support for AXP813
From: Jonathan Cameron @ 2017-12-10 16:49 UTC (permalink / raw)
To: Quentin Schulz
Cc: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA, icenowy-h8G6r0blFSE,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
In-Reply-To: <545d3aa6339c9e33060d651c42d652d0b848c06b.1512396054.git-series.quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Mon, 4 Dec 2017 15:12:51 +0100
Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> The X-Powers AXP813 PMIC has got some slight differences from
> AXP20X/AXP22X PMICs:
> - the maximum voltage supplied by the PMIC is 4.35 instead of 4.36/4.24
> for AXP20X/AXP22X,
> - the constant charge current formula is different,
>
> It also has a bit to tell whether the battery percentage returned by the
> PMIC is valid.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
I'd use switch statements when matching the IDs as that'll be more elegant
as you perhaps add further devices going forward...
Other than that, looks good to me.
Jonathan
> ---
> drivers/power/supply/axp20x_battery.c | 44 +++++++++++++++++++++++++++-
> 1 file changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/power/supply/axp20x_battery.c b/drivers/power/supply/axp20x_battery.c
> index 7494f0f..cb30302 100644
> --- a/drivers/power/supply/axp20x_battery.c
> +++ b/drivers/power/supply/axp20x_battery.c
> @@ -46,6 +46,8 @@
> #define AXP20X_CHRG_CTRL1_TGT_4_2V (2 << 5)
> #define AXP20X_CHRG_CTRL1_TGT_4_36V (3 << 5)
>
> +#define AXP813_CHRG_CTRL1_TGT_4_35V (3 << 5)
> +
> #define AXP22X_CHRG_CTRL1_TGT_4_22V (1 << 5)
> #define AXP22X_CHRG_CTRL1_TGT_4_24V (3 << 5)
>
> @@ -123,10 +125,41 @@ static int axp22x_battery_get_max_voltage(struct axp20x_batt_ps *axp20x_batt,
> return 0;
> }
>
> +static int axp813_battery_get_max_voltage(struct axp20x_batt_ps *axp20x_batt,
> + int *val)
> +{
> + int ret, reg;
> +
> + ret = regmap_read(axp20x_batt->regmap, AXP20X_CHRG_CTRL1, ®);
> + if (ret)
> + return ret;
> +
> + switch (reg & AXP20X_CHRG_CTRL1_TGT_VOLT) {
You could do a lookup based from a table instead which might
be ever so slightly more elegant..
> + case AXP20X_CHRG_CTRL1_TGT_4_1V:
> + *val = 4100000;
> + break;
> + case AXP20X_CHRG_CTRL1_TGT_4_15V:
> + *val = 4150000;
> + break;
> + case AXP20X_CHRG_CTRL1_TGT_4_2V:
> + *val = 4200000;
> + break;
> + case AXP813_CHRG_CTRL1_TGT_4_35V:
> + *val = 4350000;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> static void raw_to_constant_charge_current(struct axp20x_batt_ps *axp, int *val)
> {
> if (axp->axp_id == AXP209_ID)
> *val = *val * 100000 + 300000;
> + else if (axp->axp_id == AXP813_ID)
> + *val = *val * 200000 + 200000;
> else
> *val = *val * 150000 + 300000;
Switch?
> }
> @@ -135,6 +168,8 @@ static void constant_charge_current_to_raw(struct axp20x_batt_ps *axp, int *val)
> {
> if (axp->axp_id == AXP209_ID)
> *val = (*val - 300000) / 100000;
> + else if (axp->axp_id == AXP813_ID)
> + *val = (*val - 200000) / 200000;
> else
> *val = (*val - 300000) / 150000;
> }
> @@ -269,7 +304,8 @@ static int axp20x_battery_get_prop(struct power_supply *psy,
> if (ret)
> return ret;
>
> - if (axp20x_batt->axp_id == AXP221_ID &&
> + if ((axp20x_batt->axp_id == AXP221_ID ||
> + axp20x_batt->axp_id == AXP813_ID) &&
> !(reg & AXP22X_FG_VALID))
> return -EINVAL;
>
> @@ -284,6 +320,9 @@ static int axp20x_battery_get_prop(struct power_supply *psy,
> if (axp20x_batt->axp_id == AXP209_ID)
> return axp20x_battery_get_max_voltage(axp20x_batt,
> &val->intval);
> + else if (axp20x_batt->axp_id == AXP813_ID)
> + return axp813_battery_get_max_voltage(axp20x_batt,
> + &val->intval);
> return axp22x_battery_get_max_voltage(axp20x_batt,
> &val->intval);
Worth converting to a switch statement to make it more elegant for future
devices?
>
> @@ -467,6 +506,9 @@ static const struct of_device_id axp20x_battery_ps_id[] = {
> }, {
> .compatible = "x-powers,axp221-battery-power-supply",
> .data = (void *)AXP221_ID,
> + }, {
> + .compatible = "x-powers,axp813-battery-power-supply",
> + .data = (void *)AXP813_ID,
> }, { /* sentinel */ },
> };
> MODULE_DEVICE_TABLE(of, axp20x_battery_ps_id);
^ permalink raw reply
* Re: [PATCH 4/8] dt-bindings: power: supply: axp20x: add AXP813 battery DT binding
From: Jonathan Cameron @ 2017-12-10 16:44 UTC (permalink / raw)
To: Quentin Schulz
Cc: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA, icenowy-h8G6r0blFSE,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
In-Reply-To: <bf3682e87c75532884881d7b08840c61678cbce1.1512396054.git-series.quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Mon, 4 Dec 2017 15:12:50 +0100
Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> The AXP813 can have a battery as power supply, so let's add it to the
> list of compatibles.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> Documentation/devicetree/bindings/power/supply/axp20x_battery.txt | 8 +++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
> index c248866..4614c8e 100644
> --- a/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
> +++ b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
> @@ -4,12 +4,12 @@ Required Properties:
> - compatible, one of:
> "x-powers,axp209-battery-power-supply"
> "x-powers,axp221-battery-power-supply"
> + "x-powers,axp813-battery-power-supply"
>
> -This node is a subnode of the axp20x/axp22x PMIC.
> +This node is a subnode of the axp20x/axp22x/axp81x PMIC.
>
> -The AXP20X and AXP22X can read the battery voltage, charge and discharge
> -currents of the battery by reading ADC channels from the AXP20X/AXP22X
> -ADC.
> +The AXP20X, AXP22X and AXP81X can read the battery voltage, charge and
> +discharge currents of the battery by reading ADC channels from the ADC.
Might just be me, but this looks like a recipe for unneeded churn in future.
The supported devices can read...
Maybe also
This node is a subnode of the PMIC with the same part number. ?
I don't really care though!
>
> Example:
>
^ permalink raw reply
* Re: [PATCH 3/8] mfd: axp20x: probe axp20x_adc driver for AXP813
From: Jonathan Cameron @ 2017-12-10 16:40 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Quentin Schulz, Maxime Ripard, Sebastian Reichel, Rob Herring,
Mark Rutland, Russell King, Lee Jones, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, open list:THERMAL,
devicetree, linux-kernel, linux-arm-kernel, linux-iio,
Icenowy Zheng, linux-sunxi, Thomas Petazzoni
In-Reply-To: <CAGb2v66esOimRhDHL6QgYU3iWg2a6JiQm__0ivv3SdnQv=SGQg@mail.gmail.com>
On Thu, 7 Dec 2017 17:14:30 +0800
Chen-Yu Tsai <wens@csie.org> wrote:
> On Thu, Dec 7, 2017 at 5:03 PM, Quentin Schulz
> <quentin.schulz@free-electrons.com> wrote:
> > Hi Chen-Yu,
> >
> > On 07/12/2017 09:54, Chen-Yu Tsai wrote:
> >> On Thu, Dec 7, 2017 at 4:51 PM, Quentin Schulz
> >> <quentin.schulz@free-electrons.com> wrote:
> >>> Hi Maxime,
> >>>
> >>> On 05/12/2017 09:08, Maxime Ripard wrote:
> >>>> On Mon, Dec 04, 2017 at 03:12:49PM +0100, Quentin Schulz wrote:
> >>>>> This makes the axp20x_adc driver probe with platform device id
> >>>>> "axp813-adc".
> >>>>>
> >>>>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> >>>>> ---
> >>>>> drivers/mfd/axp20x.c | 4 +++-
> >>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> >>>>> index 2468b43..42e54d1 100644
> >>>>> --- a/drivers/mfd/axp20x.c
> >>>>> +++ b/drivers/mfd/axp20x.c
> >>>>> @@ -878,7 +878,9 @@ static struct mfd_cell axp813_cells[] = {
> >>>>> .resources = axp803_pek_resources,
> >>>>> }, {
> >>>>> .name = "axp20x-regulator",
> >>>>> - }
> >>>>> + }, {
> >>>>> + .name = "axp813-adc",
> >>>>> + },
> >>>>
> >>>> Any particular reason you're not adding it to the DT?
> >>>>
> >>>
> >>> No, no particular reason. It's just the way it is currently for AXP209
> >>> and AXP22x so did the same for AXP813.
> >>>
> >>> I'll add DT "support" in next version for all AXPs supported by this
> >>> driver. Or is it worthy of a small separate patch series?
> >>
> >> IIRC there's no DT support because there's no need to reference
> >> it in the device tree.
> >>
> >
> > No current need but that does not mean there won't be a need later for
> > drivers to map IIO channels from the ADC driver (i.e. some components
> > wired to GPIOs of the PMIC for example).
>
> Hmm... Why would you map the IIO channels from the ADC? I thought those
> were all accessible from userspace?
There is a reasonably fully featured consumer interface for IIO channels
as well. Here it's being used internal to the hardware, but yes if
you want to do the mappings to other devices, it will need to 'exist'
in the device tree.
I'm guessing that you have something in mind that needs this. If not I'd
leave it until there is a real user.
>
> However, proper muxing of the GPIO pin to the ADC function makes sense.
>
Agreed.
Jonathan
> ChenYu
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V7 0/7] dmaengine: qcom_hidma: add support for bugfixed HW
From: Vinod Koul @ 2017-12-10 16:39 UTC (permalink / raw)
To: Sinan Kaya
Cc: Rafael J. Wysocki, dmaengine, Timur Tabi,
devicetree@vger.kernel.org, ACPI Devel Maling List, Sakari Ailus,
linux-arm-msm, linux-arm-kernel@lists.infradead.org
In-Reply-To: <bad52be7-4ff8-4f06-4bd0-83e97701f495@codeaurora.org>
On Fri, Dec 08, 2017 at 09:44:46AM -0500, Sinan Kaya wrote:
> On 12/8/2017 8:48 AM, Rafael J. Wysocki wrote:
> > The series is fine by me, by how do you want to route it?
>
> Probably through the DMA engine route as it has pieces that didn't get any
> review from Vinod yet.
>
> Vinod,
>
> Do you have any preference?
Yeah sure sounds okay to me as DMA parts are dependent on these.
Rafael if you need an immutable tag to pull this, let me know.
Thanks
--
~Vinod
^ permalink raw reply
* Re: [linux-sunxi] [PATCH 1/8] iio: adc: axp20x_adc: put ADC rate setting in a per-variant function
From: Jonathan Cameron @ 2017-12-10 16:37 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Quentin Schulz, Sebastian Reichel, Rob Herring, Mark Rutland,
Russell King, Maxime Ripard, Lee Jones, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, open list:THERMAL,
devicetree, linux-kernel, linux-arm-kernel,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Icenowy Zheng, linux-sunxi,
Thomas Petazzoni
In-Reply-To: <CAGb2v64er1xMXCFDfNKqGjGN-TysQyjK+vfHdx0t+kaCchQfCg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 5 Dec 2017 11:35:49 +0800
Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> On Mon, Dec 4, 2017 at 10:12 PM, Quentin Schulz
> <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > To prepare for a new comer that set a different register with different
> > values, move rate setting in a function that is specific to each AXP
> > variant.
> >
> > Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > ---
> > drivers/iio/adc/axp20x_adc.c | 17 ++++++++++-------
> > 1 file changed, 10 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/iio/adc/axp20x_adc.c b/drivers/iio/adc/axp20x_adc.c
> > index a30a972..7274f4f 100644
> > --- a/drivers/iio/adc/axp20x_adc.c
> > +++ b/drivers/iio/adc/axp20x_adc.c
> > @@ -470,14 +470,18 @@ static const struct iio_info axp22x_adc_iio_info = {
> > .read_raw = axp22x_read_raw,
> > };
> >
> > -static int axp20x_adc_rate(int rate)
> > +static int axp20x_adc_rate(struct axp20x_adc_iio *info, int rate)
> > {
> > - return AXP20X_ADC_RATE_HZ(rate);
> > + return regmap_update_bits(info->regmap, AXP20X_ADC_RATE,
> > + AXP20X_ADC_RATE_MASK,
> > + AXP20X_ADC_RATE_HZ(rate));
> > }
> >
> > -static int axp22x_adc_rate(int rate)
> > +static int axp22x_adc_rate(struct axp20x_adc_iio *info, int rate)
> > {
> > - return AXP22X_ADC_RATE_HZ(rate);
> > + return regmap_update_bits(info->regmap, AXP20X_ADC_RATE,
> > + AXP20X_ADC_RATE_MASK,
> > + AXP22X_ADC_RATE_HZ(rate));
> > }
> >
> > struct axp_data {
> > @@ -485,7 +489,7 @@ struct axp_data {
> > int num_channels;
> > struct iio_chan_spec const *channels;
> > unsigned long adc_en1_mask;
> > - int (*adc_rate)(int rate);
> > + int (*adc_rate)(struct axp20x_adc_iio *info, int rate);
>
> Could you also change the name of the callback, to say, adc_set_rate?
> This would make it much clearer what the callback does. Previously
> it was just a conversion helper.
>
Agreed.
With that change you can add my
Acked-by: Jonathan Cameron <Jonathan.Cameron-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Thanks,
Jonathan
> ChenYu
>
> > bool adc_en2;
> > struct iio_map *maps;
> > };
> > @@ -554,8 +558,7 @@ static int axp20x_probe(struct platform_device *pdev)
> > AXP20X_ADC_EN2_MASK, AXP20X_ADC_EN2_MASK);
> >
> > /* Configure ADCs rate */
> > - regmap_update_bits(info->regmap, AXP20X_ADC_RATE, AXP20X_ADC_RATE_MASK,
> > - info->data->adc_rate(100));
> > + info->data->adc_rate(info, 100);
> >
> > ret = iio_map_array_register(indio_dev, info->data->maps);
> > if (ret < 0) {
> > --
> > git-series 0.9.1
> >
> > --
> > 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.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" 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 2/8] iio: adc: axp20x_adc: add support for AXP813 ADC
From: Jonathan Cameron @ 2017-12-10 16:36 UTC (permalink / raw)
To: Quentin Schulz
Cc: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, knaack.h-Mmb7MZpHnFY,
lars-Qo5EllUWu/uELgA04lAiVw, pmeerw-jW+XmwGofnusTnJN9+BGXg,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA, icenowy-h8G6r0blFSE,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
In-Reply-To: <ef830ce470a4f0f4be6040a776b6928bf89c0143.1512396054.git-series.quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Mon, 4 Dec 2017 15:12:48 +0100
Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> The X-Powers AXP813 PMIC is really close to what is already done for
> AXP20X/AXP22X.
>
> There are two pairs of bits to set the rate (one for Voltage and Current
> measurements and one for TS/GPIO0 voltage measurements) instead of one.
This would normally imply we need to split the device into two logical
IIO devices. However, that only becomes relevant if we are using
buffered output which this driver doesn't support.
It'll be nasty to deal with this if we add that support down the line
though. Up to you though as it's more likely to be your problem than
anyone else's :)
For now you could elect to support the different sampling frequencies
if you wanted to but just providing controls for each channel.
Given the driver doesn't currently expose these at all (I think)
this is all rather immaterial ;)
>
> The register to set the ADC rates is different from the one for
> AXP20X/AXP22X.
>
> GPIO0 can be used as an ADC (measuring Volts) unlike for AXP22X.
>
> The scales to apply to the different inputs are unlike the ones from
> AXP20X and AXP22X.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Looks good to me.
Acked-by: Jonathan Cameron <Jonathan.Cameron-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
I'm assuming these will probably go via MFD..
Jonathan
> ---
> drivers/iio/adc/axp20x_adc.c | 122 ++++++++++++++++++++++++++++++++++++-
> include/linux/mfd/axp20x.h | 2 +-
> 2 files changed, 124 insertions(+)
>
> diff --git a/drivers/iio/adc/axp20x_adc.c b/drivers/iio/adc/axp20x_adc.c
> index 7274f4f..03d489b 100644
> --- a/drivers/iio/adc/axp20x_adc.c
> +++ b/drivers/iio/adc/axp20x_adc.c
> @@ -35,8 +35,13 @@
> #define AXP20X_GPIO10_IN_RANGE_GPIO1_VAL(x) (((x) & BIT(0)) << 1)
>
> #define AXP20X_ADC_RATE_MASK GENMASK(7, 6)
> +#define AXP813_V_I_ADC_RATE_MASK GENMASK(5, 4)
> +#define AXP813_ADC_RATE_MASK (AXP20X_ADC_RATE_MASK | AXP813_V_I_ADC_RATE_MASK)
> #define AXP20X_ADC_RATE_HZ(x) ((ilog2((x) / 25) << 6) & AXP20X_ADC_RATE_MASK)
> #define AXP22X_ADC_RATE_HZ(x) ((ilog2((x) / 100) << 6) & AXP20X_ADC_RATE_MASK)
> +#define AXP813_TS_GPIO0_ADC_RATE_HZ(x) AXP20X_ADC_RATE_HZ(x)
> +#define AXP813_V_I_ADC_RATE_HZ(x) ((ilog2((x) / 100) << 4) & AXP813_V_I_ADC_RATE_MASK)
> +#define AXP813_ADC_RATE_HZ(x) (AXP20X_ADC_RATE_HZ(x) | AXP813_V_I_ADC_RATE_HZ(x))
>
> #define AXP20X_ADC_CHANNEL(_channel, _name, _type, _reg) \
> { \
> @@ -95,6 +100,12 @@ enum axp22x_adc_channel_i {
> AXP22X_BATT_DISCHRG_I,
> };
>
> +enum axp813_adc_channel_v {
> + AXP813_TS_IN = 0,
> + AXP813_GPIO0_V,
> + AXP813_BATT_V,
> +};
> +
> static struct iio_map axp20x_maps[] = {
> {
> .consumer_dev_name = "axp20x-usb-power-supply",
> @@ -197,6 +208,25 @@ static const struct iio_chan_spec axp22x_adc_channels[] = {
> AXP20X_BATT_DISCHRG_I_H),
> };
>
> +static const struct iio_chan_spec axp813_adc_channels[] = {
> + {
> + .type = IIO_TEMP,
> + .address = AXP22X_PMIC_TEMP_H,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> + BIT(IIO_CHAN_INFO_SCALE) |
> + BIT(IIO_CHAN_INFO_OFFSET),
> + .datasheet_name = "pmic_temp",
> + },
> + AXP20X_ADC_CHANNEL(AXP813_GPIO0_V, "gpio0_v", IIO_VOLTAGE,
> + AXP288_GP_ADC_H),
> + AXP20X_ADC_CHANNEL(AXP813_BATT_V, "batt_v", IIO_VOLTAGE,
> + AXP20X_BATT_V_H),
> + AXP20X_ADC_CHANNEL(AXP22X_BATT_CHRG_I, "batt_chrg_i", IIO_CURRENT,
> + AXP20X_BATT_CHRG_I_H),
> + AXP20X_ADC_CHANNEL(AXP22X_BATT_DISCHRG_I, "batt_dischrg_i", IIO_CURRENT,
> + AXP20X_BATT_DISCHRG_I_H),
> +};
> +
> static int axp20x_adc_raw(struct iio_dev *indio_dev,
> struct iio_chan_spec const *chan, int *val)
> {
> @@ -243,6 +273,18 @@ static int axp22x_adc_raw(struct iio_dev *indio_dev,
> return IIO_VAL_INT;
> }
>
> +static int axp813_adc_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int *val)
> +{
> + struct axp20x_adc_iio *info = iio_priv(indio_dev);
> +
> + *val = axp20x_read_variable_width(info->regmap, chan->address, 12);
> + if (*val < 0)
> + return *val;
> +
> + return IIO_VAL_INT;
> +}
> +
> static int axp20x_adc_scale_voltage(int channel, int *val, int *val2)
> {
> switch (channel) {
> @@ -273,6 +315,24 @@ static int axp20x_adc_scale_voltage(int channel, int *val, int *val2)
> }
> }
>
> +static int axp813_adc_scale_voltage(int channel, int *val, int *val2)
> +{
> + switch (channel) {
> + case AXP813_GPIO0_V:
> + *val = 0;
> + *val2 = 800000;
> + return IIO_VAL_INT_PLUS_MICRO;
> +
> + case AXP813_BATT_V:
> + *val = 1;
> + *val2 = 100000;
> + return IIO_VAL_INT_PLUS_MICRO;
> +
> + default:
> + return -EINVAL;
> + }
> +}
> +
> static int axp20x_adc_scale_current(int channel, int *val, int *val2)
> {
> switch (channel) {
> @@ -342,6 +402,26 @@ static int axp22x_adc_scale(struct iio_chan_spec const *chan, int *val,
> }
> }
>
> +static int axp813_adc_scale(struct iio_chan_spec const *chan, int *val,
> + int *val2)
> +{
> + switch (chan->type) {
> + case IIO_VOLTAGE:
> + return axp813_adc_scale_voltage(chan->channel, val, val2);
> +
> + case IIO_CURRENT:
> + *val = 1;
> + return IIO_VAL_INT;
> +
> + case IIO_TEMP:
> + *val = 100;
> + return IIO_VAL_INT;
> +
> + default:
> + return -EINVAL;
> + }
> +}
> +
> static int axp20x_adc_offset_voltage(struct iio_dev *indio_dev, int channel,
> int *val)
> {
> @@ -425,6 +505,26 @@ static int axp22x_read_raw(struct iio_dev *indio_dev,
> }
> }
>
> +static int axp813_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int *val,
> + int *val2, long mask)
> +{
> + switch (mask) {
> + case IIO_CHAN_INFO_OFFSET:
> + *val = -2667;
> + return IIO_VAL_INT;
> +
> + case IIO_CHAN_INFO_SCALE:
> + return axp813_adc_scale(chan, val, val2);
> +
> + case IIO_CHAN_INFO_RAW:
> + return axp813_adc_raw(indio_dev, chan, val);
> +
> + default:
> + return -EINVAL;
> + }
> +}
> +
> static int axp20x_write_raw(struct iio_dev *indio_dev,
> struct iio_chan_spec const *chan, int val, int val2,
> long mask)
> @@ -470,6 +570,10 @@ static const struct iio_info axp22x_adc_iio_info = {
> .read_raw = axp22x_read_raw,
> };
>
> +static const struct iio_info axp813_adc_iio_info = {
> + .read_raw = axp813_read_raw,
> +};
> +
> static int axp20x_adc_rate(struct axp20x_adc_iio *info, int rate)
> {
> return regmap_update_bits(info->regmap, AXP20X_ADC_RATE,
> @@ -484,6 +588,13 @@ static int axp22x_adc_rate(struct axp20x_adc_iio *info, int rate)
> AXP22X_ADC_RATE_HZ(rate));
> }
>
> +static int axp813_adc_rate(struct axp20x_adc_iio *info, int rate)
> +{
> + return regmap_update_bits(info->regmap, AXP813_ADC_RATE,
> + AXP813_ADC_RATE_MASK,
> + AXP813_ADC_RATE_HZ(rate));
> +}
> +
> struct axp_data {
> const struct iio_info *iio_info;
> int num_channels;
> @@ -514,9 +625,20 @@ static const struct axp_data axp22x_data = {
> .maps = axp22x_maps,
> };
>
> +static const struct axp_data axp813_data = {
> + .iio_info = &axp813_adc_iio_info,
> + .num_channels = ARRAY_SIZE(axp813_adc_channels),
> + .channels = axp813_adc_channels,
> + .adc_en1_mask = AXP22X_ADC_EN1_MASK,
> + .adc_rate = axp813_adc_rate,
> + .adc_en2 = false,
> + .maps = axp22x_maps,
> +};
> +
> static const struct platform_device_id axp20x_adc_id_match[] = {
> { .name = "axp20x-adc", .driver_data = (kernel_ulong_t)&axp20x_data, },
> { .name = "axp22x-adc", .driver_data = (kernel_ulong_t)&axp22x_data, },
> + { .name = "axp813-adc", .driver_data = (kernel_ulong_t)&axp813_data, },
> { /* sentinel */ },
> };
> MODULE_DEVICE_TABLE(platform, axp20x_adc_id_match);
> diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
> index 78dc853..ff95414 100644
> --- a/include/linux/mfd/axp20x.h
> +++ b/include/linux/mfd/axp20x.h
> @@ -266,6 +266,8 @@ enum axp20x_variants {
> #define AXP288_RT_BATT_V_H 0xa0
> #define AXP288_RT_BATT_V_L 0xa1
>
> +#define AXP813_ADC_RATE 0x85
> +
> /* Fuel Gauge */
> #define AXP288_FG_RDC1_REG 0xba
> #define AXP288_FG_RDC0_REG 0xbb
^ permalink raw reply
* Re: [PATCH] iio: accel: bmc150: Add OF device ID table
From: Jonathan Cameron @ 2017-12-10 16:12 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Jonathan Cameron, Hans de Goede,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Hartmut Knaack,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Lars-Peter Clausen,
Peter Meerwald-Stadler, devicetree-u79uwXL29TY76Z2rM5mHXA,
Wolfram Sang
In-Reply-To: <337e54d5-7248-9eb2-e0c0-3a8b5443723d-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Mon, 4 Dec 2017 11:24:40 +0100
Javier Martinez Canillas <javierm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> Hello Jonathan,
>
> On 12/04/2017 10:44 AM, Jonathan Cameron wrote:
> > On Mon, 4 Dec 2017 09:29:38 +0100
> > Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> >
> >> Hi,
> >>
> >> On 01-12-17 12:10, 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.
> >>>
> >>> The I2C device ID table entries have the .driver_data field set, but they
> >>> are not used in the driver so weren't set in the OF device table entries.
> >>>
> >>> Signed-off-by: Javier Martinez Canillas <javierm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >>> ---
> >>>
> >>> drivers/iio/accel/bmc150-accel-i2c.c | 12 ++++++++++++
> >>> 1 file changed, 12 insertions(+)
> >>>
> >>> diff --git a/drivers/iio/accel/bmc150-accel-i2c.c b/drivers/iio/accel/bmc150-accel-i2c.c
> >>> index f85014fbaa12..8ffc308d5fd0 100644
> >>> --- a/drivers/iio/accel/bmc150-accel-i2c.c
> >>> +++ b/drivers/iio/accel/bmc150-accel-i2c.c
> >>> @@ -81,9 +81,21 @@ static const struct i2c_device_id bmc150_accel_id[] = {
> >>>
> >>> MODULE_DEVICE_TABLE(i2c, bmc150_accel_id);
> >>>
> >>> +static const struct of_device_id bmc150_accel_of_match[] = {
> >>> + { .compatible = "bosch,bmc150_accel" },
> >>> + { .compatible = "bosch,bmi055_accel" },
> >>
> >> These look a bit weird, there is no reason to mirror the i2c_device_ids
> >
> > There has been a steady move for a long time to add these IDs with the plan
> > that we would stop automatically matching against the manufacturer free
> > i2c IDs. Mostly on the basis that was a hack that brought a lot
>
> Matching using OF IDs have been working for some time (since v4.10 AFAICT)
> after the following commit:
>
> da10c06a044b ("i2c: Make I2C ID tables non-mandatory for DT'ed devices").
>
> The only remaining problem is with module auto-loading.
>
> > of effectively unreviewed device tree bindings. As I understand it the
> > eventual plan is to be able to get rid of that old path entirely...
> > +CC Wolfram to see what his view is on this.
> >
>
> I don't think we can get rid of the old path entirely since are valid use cases
> for it. For example when the I2C devices are registered with the i2c_new_device
> interface where the bus and address are declared in a struct i2c_board_info (ie:
> old platforms that still use board files or devices with an embedded I2C chip).
Agreed. I only meant the use of that path when matching device tree IDs.
There are still reasons to use it otherwise - including the ones you mention
and indeed manually adding the device - commonly done with various sensors
supported by lm-sensors on x86 boards. These are often not described in
any way at all.
>
> What I think though is that drivers should only be required to define the device
> table for the firmware interface used to instantiate them. For example, a driver
> for a device that's DT-only should only have an OF device ID table just like a
> driver for an ACPI-only device only requires to have an ACPI ID table.
>
> Conversely, a driver for a device that's only instantiated using platform data
> should only have an I2C device ID table.
>
A lot of drivers are used on both ACPI and DT platforms. For newer cases we
perhaps don't need the i2c table.
> If a driver supports both DT and legacy platforms, then it's OK to have both ID
> tables defined. What is not correct is to require OF-only drivers to have an I2C
> device ID table just as a workaround to have their modules auto-loading working.
Absolutely agree.
Jonathan
>
> Best regards,
--
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 v1 6/6] ARM: dts: imx7s: add usb hsic phy domain
From: Fabio Estevam @ 2017-12-10 15:23 UTC (permalink / raw)
To: tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf
Cc: Shawn Guo, Sascha Hauer,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel,
Fabio Estevam
In-Reply-To: <20171205222707.11302-7-tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
On Tue, Dec 5, 2017 at 8:27 PM, <tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org> wrote:
> From: Tyler Baker <tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
>
> The GPCv2 driver should control the MIPI, PCIe,
> and USB HSIC PHY regulators. Add the USB HSIC
> power domain to the GPC node.
>
> Signed-off-by: Tyler Baker <tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
Looks good. I am assuming you tested USB HSIC operation on the mx7
compulab board, right?
Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
--
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 v1 5/6] ARM: dts: imx7d-sbc-iot: enable PCIe peripheral
From: Fabio Estevam @ 2017-12-10 15:20 UTC (permalink / raw)
To: tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf
Cc: Shawn Guo, Sascha Hauer,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel,
Fabio Estevam
In-Reply-To: <20171205222707.11302-6-tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
On Tue, Dec 5, 2017 at 8:27 PM, <tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org> wrote:
> From: Tyler Baker <tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
>
> Add a PCIe device tree node to enable PCIe support.
>
> Signed-off-by: Tyler Baker <tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
--
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 v1 4/6] ARM: dts: imx7s: add node and supplies for vdd1p2
From: Fabio Estevam @ 2017-12-10 15:20 UTC (permalink / raw)
To: tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf
Cc: Shawn Guo, Sascha Hauer,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel,
Fabio Estevam
In-Reply-To: <20171205222707.11302-5-tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
On Tue, Dec 5, 2017 at 8:27 PM, <tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org> wrote:
> From: Tyler Baker <tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
>
> Add the regulator nodes and supplies for vdd1p2. This regulator is
> used to power the GPC and USB HSIC PHY.
>
> Signed-off-by: Tyler Baker <tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
> ---
> arch/arm/boot/dts/imx7s.dtsi | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index 7b85659..151ab34 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -522,6 +522,20 @@
> anatop-max-voltage = <1200000>;
> anatop-enable-bit = <0>;
> };
> +
> + reg_1p2: regulator-vdd1p2@220 {
Using a unit address without a corresponding reg would give you a
warning with W=1.
Please see the patch I sent with Subject:
ARM: dts: imx7s: Add unit address and reg for the anatop nodes
--
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 v1 3/6] ARM: dts: imx7s: add dma support
From: Fabio Estevam @ 2017-12-10 15:15 UTC (permalink / raw)
To: tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf
Cc: Shawn Guo, Sascha Hauer,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel,
Fabio Estevam
In-Reply-To: <20171205222707.11302-4-tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
On Tue, Dec 5, 2017 at 8:27 PM, <tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org> wrote:
> From: Tyler Baker <tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
>
> Enable dma on all SPI interfaces.
>
> Signed-off-by: Tyler Baker <tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
--
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 v1 2/6] ARM: dts: imx7d-cl-som: add nodes for usbh, and usbotg2
From: Fabio Estevam @ 2017-12-10 15:14 UTC (permalink / raw)
To: tyler
Cc: Shawn Guo, Sascha Hauer, robh+dt@kernel.org, Mark Rutland,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel, Fabio Estevam
In-Reply-To: <20171205222707.11302-3-tyler@opensourcefoundries.com>
On Tue, Dec 5, 2017 at 8:27 PM, <tyler@opensourcefoundries.com> wrote:
> From: Tyler Baker <tyler@opensourcefoundries.com>
>
> Add device tree nodes for the USB hub, and USB OTG. i2c2 on this
> platform supports low state retention power state so lets use it.
Looks like the I2C2 fix should be a separate patch.
^ permalink raw reply
* Re: [PATCH v1 1/6] ARM: dts: imx7d-sbc-iot: add initial iot gateway dts
From: Fabio Estevam @ 2017-12-10 15:10 UTC (permalink / raw)
To: tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf
Cc: Shawn Guo, Sascha Hauer,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel,
Fabio Estevam, Ilya Ledvich
In-Reply-To: <20171205222707.11302-2-tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org>
On Tue, Dec 5, 2017 at 8:27 PM, <tyler-yzvPICuk2AAEdKtRPRuaE5USO3DlRtUf@public.gmane.org> wrote:
> +&usdhc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc1>;
> + cd-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
> + wp-gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
> + enable-sdio-wakeup;
This is a deprecated property.
Please use wakeup-source as stated in
Documentation/devicetree/bindings/mmc/mmc.txt
--
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 00/12] Marvell NAND controller rework with ->exec_op()
From: Ezequiel Garcia @ 2017-12-09 23:27 UTC (permalink / raw)
To: Miquel Raynal
Cc: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Russell King, Daniel Mack, Haojian Zhuang, Robert Jarzmik,
Eric Miao, Catalin Marinas
In-Reply-To: <20171207201814.30411-1-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Miquel,
On 7 December 2017 at 17:18, Miquel Raynal
<miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hi,
>
> After the addition of the NAND framework ->exec_op() interface (see [1]
> for the series preparing it and [2] for the last version of the
> core-side implementation of ->exec_op() itself), this series replaces
> the current Marvell NAND controller driver pxa3xx_nand.c with a rework
> called marvell_nand.c.
>
Nice to see this effort!
Unfortunately, I don't much time to spend reviewing this, but I'm super
happy to see a new driver fixing all the nasty issues the current one has.
Cheers,
--
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
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/2] dt-bindings: Add Infineon TLV493D-A1B6
From: Andreas Färber @ 2017-12-09 23:25 UTC (permalink / raw)
To: linux-iio-u79uwXL29TY76Z2rM5mHXA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andreas Färber,
Marius Tarcatu, Rob Herring, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20171209232507.18594-1-afaerber-l3A5Bk7waGM@public.gmane.org>
The Infineon TLV493D-A1B6 is an I2C-based 3D Magnetic Sensor.
Cc: Marius Tarcatu <marius.tarcatu-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org>
Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
---
Documentation/devicetree/bindings/trivial-devices.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/trivial-devices.txt b/Documentation/devicetree/bindings/trivial-devices.txt
index 5f3143f97098..7ad1939cb0d6 100644
--- a/Documentation/devicetree/bindings/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/trivial-devices.txt
@@ -63,6 +63,7 @@ fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec
gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire Interface
infineon,slb9635tt Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz)
infineon,slb9645tt Infineon SLB9645 I2C TPM (new protocol, max 400khz)
+infineon,tlv493d-a1b6 Infineon TLV493D-A1B6 I2C 3D Magnetic Sensor
isil,isl1208 Intersil ISL1208 Low Power RTC with Battery Backed SRAM
isil,isl1218 Intersil ISL1218 Low Power RTC with Battery Backed SRAM
isil,isl12022 Intersil ISL12022 Real-time Clock
--
2.13.6
^ permalink raw reply related
* [PATCH 0/2] iio: magnetometer: Infineon TLV493D-A1B6 support
From: Andreas Färber @ 2017-12-09 23:25 UTC (permalink / raw)
To: linux-iio-u79uwXL29TY76Z2rM5mHXA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andreas Färber,
Marius Tarcatu, devicetree-u79uwXL29TY76Z2rM5mHXA
Hello,
This mini-series adds initial support for the Infineon TLV493D-A1B6 3D Magnetic
Sensor found on the Infineon 3D Magnetic Sensor 2Go Kit.
Tested on a Raspberry Pi 3 with a DT Overlay.
https://github.com/afaerber/dt-overlays/blob/master/bcm2837-rpi-3-b%2Btlv493d-a1b6.dts
Have a lot of fun!
Cheers,
Andreas
Cc: Marius Tarcatu <marius.tarcatu-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Andreas Färber (2):
dt-bindings: Add Infineon TLV493D-A1B6
iio: magnetometer: Add Infineon TLV493D-A1B6
.../devicetree/bindings/trivial-devices.txt | 1 +
drivers/iio/magnetometer/Kconfig | 9 +
drivers/iio/magnetometer/Makefile | 2 +
drivers/iio/magnetometer/tlv493d.c | 328 +++++++++++++++++++++
4 files changed, 340 insertions(+)
create mode 100644 drivers/iio/magnetometer/tlv493d.c
--
2.13.6
^ permalink raw reply
* Re: [PATCH v8 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver
From: Jacek Anaszewski @ 2017-12-09 21:21 UTC (permalink / raw)
To: Dan Murphy, Rob Herring
Cc: mark.rutland, rpurdie, pavel, devicetree, linux-kernel,
linux-leds
In-Reply-To: <c354b66d-f501-99bc-5928-efcfe33dbd06@ti.com>
On 12/08/2017 12:04 AM, Dan Murphy wrote:
> Rob
>
>
> On 12/07/2017 04:49 PM, Rob Herring wrote:
>> On Tue, Dec 05, 2017 at 02:46:29PM -0600, Dan Murphy wrote:
>>> This adds the devicetree bindings for the LM3692x
>>> I2C LED string driver.
>>>
>>> Acked-by: Pavel Machek <pavel@ucw.cz>
>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>>> ---
>>>
>>> v8 - Added address-cells and size-cells as well as child node reg - https://patchwork.kernel.org/patch/10091259/
>>> v7 - No changes - https://patchwork.kernel.org/patch/10087475/
>>> v6 - No changes -https://patchwork.kernel.org/patch/10085567/
>>> v5 - No Changes - https://patchwork.kernel.org/patch/10081071/
>>> v4 - Fix example node, added trigger entry, removed ambiguous x for compatible and
>>> added common.txt pointer for label - https://patchwork.kernel.org/patch/10060107
>>> v3 - No changes
>>> v2 - No changes - https://patchwork.kernel.org/patch/10056677/
>>>
>>> .../devicetree/bindings/leds/leds-lm3692x.txt | 47 ++++++++++++++++++++++
>>> 1 file changed, 47 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3692x.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/leds/leds-lm3692x.txt b/Documentation/devicetree/bindings/leds/leds-lm3692x.txt
>>> new file mode 100644
>>> index 000000000000..84f69342d879
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/leds/leds-lm3692x.txt
>>> @@ -0,0 +1,47 @@
>>> +* Texas Instruments - LM3692x Highly Efficient White LED Driver
>>> +
>>> +The LM3692x is an ultra-compact, highly efficient,
>>> +white-LED driver designed for LCD display backlighting.
>>> +
>>> +The main difference between the LM36922 and LM36923 is the number of
>>> +LED strings it supports. The LM36922 supports two strings while the LM36923
>>> +supports three strings.
>>> +
>>> +Required properties:
>>> + - compatible:
>>> + "ti,lm36922"
>>> + "ti,lm36923"
>>> + - reg : I2C slave address
>>> + - #address-cells : 1
>>> + - #size-cells : 0
>>> +
>>> +Optional properties:
>>> + - label : see Documentation/devicetree/bindings/leds/common.txt
>>
>> Should be a child prop.
>
> Thanks I forgot to move this to Optional Child Properties.
>
>>
>>> + - enable-gpios : gpio pin to enable/disable the device.
>>> + - vled-supply : LED supply
>>> + - linux,default-trigger : (optional)
>>> + see Documentation/devicetree/bindings/leds/common.txt
>>
>> Ditto.
>
> Ack
>
>>
>>> +
>>> +Required child properties:
>>> + - reg : 0
>>> +
>>> +Example:
>>> +
>>> +lm3692x@36 {
>>
>> leds@36
>
> Rob why does this need to be leds? Is this because it would be a child of an I2C node?
>
> Jacek
> Would this not cause and issue for your proposal to take the parent node name as part of the LED label?
Yes, it would.
Rob, does something prevent us from adding a requirement that
LED controller DT node has to contain the chip name (besides the
unit address)? Many current LED controller nodes apply this pattern.
Also, I would appreciate if you could express your opinion on
the patch [0].
[0] https://patchwork.kernel.org/patch/10089047/
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* [PATCH] dt-bindings: mailbox: ti,message-manager: Fix interrupt name error
From: Nishanth Menon @ 2017-12-09 19:35 UTC (permalink / raw)
To: Nishanth Menon, Marco Franchi, Mark Rutland, Rob Herring,
Jassi Brar
Cc: linux-kernel, devicetree
Message Manager's mailbox interrupts are queue based and not proxy
specific. The interrupt names are wrong in the binding, however
correctly reflected in the example provided. Remove the relation
to proxy ID in the documentation of binding. Existing device tree
descriptions follow the correct conventions already and documentation
update has been missed.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Documentation/devicetree/bindings/mailbox/ti,message-manager.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
index c3b55b3ede8a..ebf0e3710cee 100644
--- a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
+++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
@@ -20,9 +20,9 @@ Required properties:
order referring to the transfer path.
- interrupt-names: Contains interrupt names matching the rx transfer path
for a given SoC. Receive interrupts shall be of the
- format: "rx_<QID>_<PID>".
+ format: "rx_<QID>".
For ti,k2g-message-manager, this shall contain:
- "rx_005_002", "rx_057_002"
+ "rx_005", "rx_057"
- interrupts: Contains the interrupt information corresponding to
interrupt-names property.
--
2.14.1
^ permalink raw reply related
* [PATCH] dt-bindings: chosen: Document linux,initrd-{start,end}
From: Jonathan Neuschäfer @ 2017-12-09 15:33 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Jonathan Neuschäfer, Rob Herring, Mark Rutland,
AKASHI Takahiro, Ard Biesheuvel, Kees Cook, James Morse,
Frank Rowand, linux-kernel-u79uwXL29TY76Z2rM5mHXA
These properties have been in use for a very long time (at least since
2005), but were never documented in chosen.txt.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer-hi6Y0CQ0nG0@public.gmane.org>
---
Documentation/devicetree/bindings/chosen.txt | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
index e3b13ea7d2ae..45e79172a646 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -120,3 +120,18 @@ e.g.
While this property does not represent a real hardware, the address
and the size are expressed in #address-cells and #size-cells,
respectively, of the root node.
+
+linux,initrd-start and linux,initrd-end
+---------------------------------------
+
+These properties hold the physical start and end address of an initrd that's
+loaded by the bootloader. Note that linux,initrd-start is inclusive, but
+linux,initrd-end is exclusive.
+e.g.
+
+/ {
+ chosen {
+ linux,initrd-start = <0x82000000>;
+ linux,initrd-end = <0x82800000>;
+ };
+};
--
2.15.0
--
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
* Re: [PATCH v1 2/2] drm/tinydrm: add driver for ST7735R panels
From: Noralf Trønnes @ 2017-12-09 12:21 UTC (permalink / raw)
To: David Lechner, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: limor-6aDhHjTmHzzR7s880joybQ, Rob Herring, Mark Rutland,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1511924469-11448-3-git-send-email-david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
Den 29.11.2017 04.01, skrev David Lechner:
> This adds a new driver for Sitronix ST7735R display panels.
>
> This has been tested using an Adafruit 1.8" TFT.
>
> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
> ---
<snip>
> diff --git a/drivers/gpu/drm/tinydrm/st7735r.c b/drivers/gpu/drm/tinydrm/st7735r.c
<snip>
> +static struct drm_driver st7735r_driver = {
> + .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
> + DRIVER_ATOMIC,
> + .fops = &st7735r_fops,
> + TINYDRM_GEM_DRIVER_OPS,
> + .lastclose = tinydrm_lastclose,
I was reminded of this since it would have made it easy to turn off the
panel and see if it turned white. Adding this makes it possible to send
commands from userspace for testing:
.debugfs_init = mipi_dbi_debugfs_init,
If you do that you have to set this to NULL since it's not possible to
read from the controller in this panel:
mipi->read_commands = NULL;
Noralf.
--
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 0/2] of: overlay: Crash fix and improvement
From: Geert Uytterhoeven @ 2017-12-09 9:04 UTC (permalink / raw)
To: Frank Rowand
Cc: Geert Uytterhoeven, Pantelis Antoniou, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <f78620d2-7a6d-b90e-d773-9e3cc3d0cb6a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Frank,
On Sat, Dec 9, 2017 at 7:01 AM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 12/08/17 05:13, Geert Uytterhoeven wrote:
>> This patch series fixes memory corruption when applying overlays.
>> I first noticed this when using OF configfs. After lots of failed
>> debugging attempts, I bisected it to "of: overlay: add per overlay sysfs
>> attributes", which is not upstream. But that was a red herring: that
>> commit enlarged struct fragment to exactly 64-bytes, which just made it
>> more likely to cause random corruption when writing beyond the end of an
>> array of fragment structures. With the smaller structure size before,
>> such writes usually ended up in the unused holes between allocated
>> blocks, causing no harm.
>>
>> The first patch is the real fix, and applies to both v4.15-rc2 and Rob's
>> for-next branch.
>> The second patch is a small improvement, and applies to Rob's for-next
>> branch only.
>
> Overlay FDT files should not have invalid contents. But they inevitably
> will, so the code has to handle those cases. Thanks for finding this
> problem and making the code better!
Sure, people can throw anything at it ;-)
In my case, I'm wondering if the dtbo was actually invalid?
Simplification of the decompiled dtbo:
/dts-v1/;
/ {
fragment-name {
target-path = [2f 00];
__overlay__ {
node-name {
compatible = "foo,bar";
gpios = <0xffffffff 0x0 0x0>;
};
};
};
__fixups__ {
bank0 = "/fragment-name/__overlay__/node-name:gpios:0";
};
};
So it has __fixup__, but no __symbols__, which looks totally valid to me.
> For the full series:
>
> Reviewed-by: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 7/7] arm64: dts: mt8173: add uwk node and remove unused usb property
From: Chunfeng Yun @ 2017-12-09 8:45 UTC (permalink / raw)
To: Rob Herring, Felipe Balbi, Matthias Brugger, Mathias Nyman
Cc: Mark Rutland, Greg Kroah-Hartman, Catalin Marinas, Will Deacon,
Chunfeng Yun, Jean Delvare, Sean Wang, devicetree, linux-kernel,
linux-usb, linux-arm-kernel, linux-mediatek
In-Reply-To: <1512809136-2779-1-git-send-email-chunfeng.yun@mediatek.com>
Add uwk node for new way of usb remote wakeup instead of old one,
and modify some usb properties according binding documents
of mediatek,mtu3.txt and mediatek,mtk-xhci.txt
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 28 ++++++++++++++++++----------
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 16 +++++-----------
2 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 1c3634f..08a323b 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -14,6 +14,7 @@
/dts-v1/;
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/soc/mediatek,usb-wakeup.h>
#include "mt8173.dtsi"
/ {
@@ -68,6 +69,20 @@
gpio = <&pio 9 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+ usb_wakeup: uwk@0 {
+ compatible = "mediatek,mt8173-uwk","mediatek,usb-wk-v1";
+ mediatek,wkc = <&pericfg>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ status = "okay";
+
+ usb_wk0: uwk@400 {
+ reg = <0x400 0x8>;
+ #mediatek,uwk-cells = <1>;
+ status = "okay";
+ };
+ };
};
&cec {
@@ -268,12 +283,6 @@
};
};
- usb_id_pins_ground: usb_iddig_pull_down {
- pins_iddig {
- pinmux = <MT8173_PIN_16_IDDIG__FUNC_IDDIG>;
- bias-pull-down;
- };
- };
};
&pwm0 {
@@ -501,15 +510,14 @@
};
&ssusb {
+ mediatek,uwks = <&usb_wk0 MTU_WK_IP_SLEEP>;
vusb33-supply = <&mt6397_vusb_reg>;
vbus-supply = <&usb_p0_vbus>;
extcon = <&extcon_usb>;
dr_mode = "otg";
- mediatek,enable-wakeup;
- pinctrl-names = "default", "id_float", "id_ground";
+ wakeup-source;
+ pinctrl-names = "default";
pinctrl-0 = <&usb_id_pins_float>;
- pinctrl-1 = <&usb_id_pins_float>;
- pinctrl-2 = <&usb_id_pins_ground>;
status = "okay";
};
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 26396ef..818ead7 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -722,7 +722,7 @@
};
ssusb: usb@11271000 {
- compatible = "mediatek,mt8173-mtu3";
+ compatible = "mediatek,mt8173-mtu3", "mediatek,mtu3";
reg = <0 0x11271000 0 0x3000>,
<0 0x11280700 0 0x0100>;
reg-names = "mac", "ippc";
@@ -731,22 +731,16 @@
<&u3port0 PHY_TYPE_USB3>,
<&u2port1 PHY_TYPE_USB2>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
- clocks = <&topckgen CLK_TOP_USB30_SEL>,
- <&clk26m>,
- <&pericfg CLK_PERI_USB0>,
- <&pericfg CLK_PERI_USB1>;
- clock-names = "sys_ck",
- "ref_ck",
- "wakeup_deb_p0",
- "wakeup_deb_p1";
- mediatek,syscon-wakeup = <&pericfg>;
+ clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>;
+ clock-names = "sys_ck", "ref_ck";
#address-cells = <2>;
#size-cells = <2>;
ranges;
status = "disabled";
usb_host: xhci@11270000 {
- compatible = "mediatek,mt8173-xhci";
+ compatible = "mediatek,mt8173-xhci",
+ "mediatek,mtk-xhci";
reg = <0 0x11270000 0 0x1000>;
reg-names = "mac";
interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_LOW>;
--
1.9.1
^ permalink raw reply related
* [PATCH 6/7] dt-bindings: usb: mtu3: add USB wakeup properties
From: Chunfeng Yun @ 2017-12-09 8:45 UTC (permalink / raw)
To: Rob Herring, Felipe Balbi, Matthias Brugger, Mathias Nyman
Cc: Mark Rutland, Greg Kroah-Hartman, Catalin Marinas, Will Deacon,
Chunfeng Yun, Jean Delvare, Sean Wang,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1512809136-2779-1-git-send-email-chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Modify the properties of usb wakeup, and use the new way of mtu_wakeup
which is extracted from SSUSB controller dirver as a new driver.
Signed-off-by: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
Documentation/devicetree/bindings/usb/mediatek,mtu3.txt | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
index b2271d8..2ed546d 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
@@ -42,9 +42,17 @@ Optional properties:
- enable-manual-drd : supports manual dual-role switch via debugfs; usually
used when receptacle is TYPE-A and also wants to support dual-role
mode.
- - mediatek,enable-wakeup : supports ip sleep wakeup used by host mode
- - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
- control register, it depends on "mediatek,enable-wakeup".
+ - mediatek,uwks : a phandle to USB-Wakeup node to control the type of wakeup,
+ it's used to replace the old way which is realized by the property of
+ "mediatek,wakeup-wakeup" and "mediatek,syscon-wakeup",
+ see: Documentation/devicetree/bindings/soc/mediatek/usb-wakeup.txt
+ - wakeup-source : Decides if the new way of USB wakeup is supported or
+ not, it depends on "mediatek,uwks" property.
+ - mediatek,enable-wakeup : (deprecated) supports ip sleep wakeup used by
+ host mode, only supports mt8173 platform, use the property of
+ "mediatek,uwks" instead on other SoCs.
+ - mediatek,syscon-wakeup : (deprecated) phandle to syscon used to access
+ USB wakeup control register, it depends on "mediatek,enable-wakeup".
- mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
bit1 for u3port1, ... etc;
--
1.9.1
--
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 5/7] dt-bindings: usb: mtk-xhci: add USB wakeup properties
From: Chunfeng Yun @ 2017-12-09 8:45 UTC (permalink / raw)
To: Rob Herring, Felipe Balbi, Matthias Brugger, Mathias Nyman
Cc: Mark Rutland, Greg Kroah-Hartman, Catalin Marinas, Will Deacon,
Chunfeng Yun, Jean Delvare, Sean Wang, devicetree, linux-kernel,
linux-usb, linux-arm-kernel, linux-mediatek
In-Reply-To: <1512809136-2779-1-git-send-email-chunfeng.yun@mediatek.com>
Modify the properties of usb wakeup, and use the new way of mtu_wakeup
which is extracted from SSUSB controller dirver as a new one.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
.../devicetree/bindings/usb/mediatek,mtk-xhci.txt | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
index 3059596..88984d8 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
@@ -35,10 +35,17 @@ Required properties:
- phys : a list of phandle + phy specifier pairs
Optional properties:
- - mediatek,wakeup-src : 1: ip sleep wakeup mode; 2: line state wakeup
- mode;
- - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
- control register, it depends on "mediatek,wakeup-src".
+ - mediatek,uwks : a phandle to USB-Wakeup node to control the type of
+ wakeup, it's used to replace the old way which is realized by the
+ property of "mediatek,wakeup-src" and "mediatek,syscon-wakeup",
+ see: Documentation/devicetree/bindings/soc/mediatek/usb-wakeup.txt
+ - wakeup-source : Decides if the new way of USB wakeup is supported or
+ not, it depends on "mediatek,uwks" property.
+ - mediatek,wakeup-src : (deprecated) 1: ip sleep wakeup mode; 2: line
+ state wakeup mode; only supports mt8173 platform, use the property
+ of "mediatek,uwks" instead on other SoCs.
+ - mediatek,syscon-wakeup : (deprecated) phandle to syscon used to access
+ USB wakeup control register, depends on "mediatek,wakeup-src".
- mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
bit1 for u3port1, ... etc;
- vbus-supply : reference to the VBUS regulator;
--
1.9.1
^ permalink raw reply related
* [PATCH 4/7] usb: mtu3: use APIs of mtu_wakeup to support remote wakeup
From: Chunfeng Yun @ 2017-12-09 8:45 UTC (permalink / raw)
To: Rob Herring, Felipe Balbi, Matthias Brugger, Mathias Nyman
Cc: Mark Rutland, Greg Kroah-Hartman, Catalin Marinas, Will Deacon,
Chunfeng Yun, Jean Delvare, Sean Wang, devicetree, linux-kernel,
linux-usb, linux-arm-kernel, linux-mediatek
In-Reply-To: <1512809136-2779-1-git-send-email-chunfeng.yun@mediatek.com>
On some platforms, there are two SSUSB IPs, but the old way of
usb wakeup doesn't support it, so use the new APIs of mtu_wakeup
to support it.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/mtu3.h | 2 ++
drivers/usb/mtu3/mtu3_host.c | 39 +++++++++++++++++++++++----------------
2 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
index 3c888d9..9f3eb79 100644
--- a/drivers/usb/mtu3/mtu3.h
+++ b/drivers/usb/mtu3/mtu3.h
@@ -255,6 +255,8 @@ struct ssusb_mtk {
/* usb wakeup for host mode */
bool wakeup_en;
struct regmap *pericfg;
+ struct mtu_wakeup *uwk;
+ bool new_wakeup;
};
/**
diff --git a/drivers/usb/mtu3/mtu3_host.c b/drivers/usb/mtu3/mtu3_host.c
index 7e948c0..f769b65 100644
--- a/drivers/usb/mtu3/mtu3_host.c
+++ b/drivers/usb/mtu3/mtu3_host.c
@@ -14,6 +14,7 @@
#include <linux/mfd/syscon.h>
#include <linux/of_device.h>
#include <linux/regmap.h>
+#include <linux/soc/mediatek/usb-wakeup.h>
#include "mtu3.h"
#include "mtu3_dr.h"
@@ -56,24 +57,26 @@ static void ssusb_wakeup_ip_sleep_dis(struct ssusb_mtk *ssusb)
int ssusb_wakeup_of_property_parse(struct ssusb_mtk *ssusb,
struct device_node *dn)
{
- struct device *dev = ssusb->dev;
+ /* try the new way first */
+ ssusb->new_wakeup = of_property_read_bool(dn, "wakeup-source");
+ if (ssusb->new_wakeup) {
+ ssusb->uwk = devm_of_uwk_get_by_index(ssusb->dev, dn, 0);
+ if (IS_ERR(ssusb->uwk))
+ dev_err(ssusb->dev, "fail to get mtu_wakeup\n");
+
+ return PTR_ERR_OR_ZERO(ssusb->uwk);
+ }
- /*
- * Wakeup function is optional, so it is not an error if this property
- * does not exist, and in such case, no need to get relative
- * properties anymore.
- */
+ /* Wakeup function is optional. (deprecated, use the new way instead) */
ssusb->wakeup_en = of_property_read_bool(dn, "mediatek,enable-wakeup");
- if (!ssusb->wakeup_en)
- return 0;
-
- ssusb->pericfg = syscon_regmap_lookup_by_phandle(dn,
+ if (ssusb->wakeup_en) {
+ ssusb->pericfg = syscon_regmap_lookup_by_phandle(dn,
"mediatek,syscon-wakeup");
- if (IS_ERR(ssusb->pericfg)) {
- dev_err(dev, "fail to get pericfg regs\n");
- return PTR_ERR(ssusb->pericfg);
+ if (IS_ERR(ssusb->pericfg)) {
+ dev_err(ssusb->dev, "fail to get pericfg regs\n");
+ return PTR_ERR(ssusb->pericfg);
+ }
}
-
return 0;
}
@@ -235,7 +238,9 @@ void ssusb_host_exit(struct ssusb_mtk *ssusb)
int ssusb_wakeup_enable(struct ssusb_mtk *ssusb)
{
- if (ssusb->wakeup_en)
+ if (ssusb->new_wakeup)
+ mtu_wakeup_enable(ssusb->uwk);
+ else if (ssusb->wakeup_en)
ssusb_wakeup_ip_sleep_en(ssusb);
return 0;
@@ -243,6 +248,8 @@ int ssusb_wakeup_enable(struct ssusb_mtk *ssusb)
void ssusb_wakeup_disable(struct ssusb_mtk *ssusb)
{
- if (ssusb->wakeup_en)
+ if (ssusb->new_wakeup)
+ mtu_wakeup_disable(ssusb->uwk);
+ else if (ssusb->wakeup_en)
ssusb_wakeup_ip_sleep_dis(ssusb);
}
--
1.9.1
^ permalink raw reply related
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