* Re: [PATCH v2 1/2] regulator: Add coupled regulator
From: Maxime Ripard @ 2016-11-07 15:47 UTC (permalink / raw)
To: Mark Brown
Cc: Rob Herring, Chen-Yu Tsai, Liam Girdwood,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160205153258.GW4455-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2647 bytes --]
Hi Mark,
On Fri, Feb 05, 2016 at 03:32:58PM +0000, Mark Brown wrote:
> On Fri, Feb 05, 2016 at 03:33:28PM +0100, Maxime Ripard wrote:
> > On Thu, Jan 21, 2016 at 04:28:02PM +0000, Mark Brown wrote:
> > > On Thu, Jan 21, 2016 at 04:46:49PM +0100, Maxime Ripard wrote:
>
> > > > Anyway, I'm fine with both approaches, just let me know what you
> > > > prefer.
>
> > > Without seeing an implementation of the lists it's hard to say.
>
> > Just to make sure we're on the same page: you want to keep the
> > regulator, but instead of giving the parent through vinX-supplies
> > properties, you want to have a single *-supply property, with a list
> > of regulators, right?
>
> Either that or an explicit regulator describing the merge. Rob wants
> the list I think but I really don't care.
So, I'm reviving this old thread after speaking to you about it at
ELCE and trying to code something up, and getting lost..
To put a bit of context, I'm still trying to tackle the issue of
devices that have two regulators powering them on the same pin for
example when each regulator cannot provide enough current alone to
power the device (all the setups like this one I've seen so far were
for WiFi chips, but it might be different).
I guess we already agreed on the fact that the DT binding should just
be to allow a *-supply property to take multiple regulators, and mark
them as "coupled" (or whatever name we see fit) in such a case.
Since regulator_get returns a struct regulator pointer, it felt
logical to try to add the list of parent regulators to it, especially
as this structure is per-consumer, and different consumers might have
different combinations of regulators.
However, this structure embeds a pointer to a struct regulator_dev,
which seems to model the regulator itself, but will also contain
pointer to the struct regulator, probably to model its parent? I guess
my first question would be do we care about nesting? or having a
regulator with multiple parents?
It also contains the constraints on each regulator, which might or
might not be different for each of the coupled regulators, but I'm
guessing the couple might have contraints of its own too I guess. Is
it something that might happen? Should we care about it?
And finally, my real question is, do we want to aggregate them in
struct regulator, at the consumer level, which might make the more
sense, or do we want to create an intermediate regulator internally?
What is your take on this?
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* RE: [PATCH V3 4/9] Documentation: devicetree: mfd: da9062/61 MFD binding
From: Steve Twiss @ 2016-11-07 15:28 UTC (permalink / raw)
To: Lee Jones
Cc: DEVICETREE, LINUX-INPUT, LINUX-KERNEL, Mark Rutland, Rob Herring,
Dmitry Torokhov, Eduardo Valentin, Guenter Roeck, LINUX-PM,
LINUX-WATCHDOG, Liam Girdwood, Mark Brown, Support Opensource,
Wim Van Sebroeck, Zhang Rui
In-Reply-To: <20161102143201.GT13127@dell>
On 02 November 2016 14:32, Lee Jones wrote:
> On Mon, 31 Oct 2016, Steve Twiss wrote:
> > From: Steve Twiss <stwiss.opensource@diasemi.com>
> >
> > [...]
> >
> > +- onkey : See ../input/da9062-onkey.txt
> > +
> > +
> > +- watchdog: See ../watchdog/da9062-watchdog.txt
> > +
> > +
> > +- thermal : See ../thermal/da9062-thermal.txt
>
> Remove all those extra lines in between.
Ok.
> > Example:
> > @@ -64,10 +96,6 @@ Example:
> > compatible = "dlg,da9062-rtc";
> > };
> >
> > - watchdog {
> > - compatible = "dlg,da9062-watchdog";
> > - };
> > -
>
> Why don't you include a sub-node per child device and use
> of_platform_populate() to register the devices?
In this case I'm just moving the binding descriptions into a
different file. I'm not sure I understand what you mean here.
What do you have in mind?
Regards,
Steve
^ permalink raw reply
* Re: [PATCH 1/4] pinctrl: Introduce generic #pinctrl-cells and pinctrl_parse_index_with_args
From: Tony Lindgren @ 2016-11-07 15:26 UTC (permalink / raw)
To: Linus Walleij
Cc: Jon Hunter, Mark Rutland, Rob Herring, Grygorii Strashko,
Nishanth Menon,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-OMAP
In-Reply-To: <CACRpkdaCF4Jc7QY+L44obce=V_W4xgVbPXfuiE7bXJs7ud9q9A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
* Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> [161104 14:50]:
> On Thu, Nov 3, 2016 at 5:35 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
>
> > Introduce #pinctrl-cells helper binding and generic helper functions
> > pinctrl_count_index_with_args() and pinctrl_parse_index_with_args().
> >
> > Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
>
> Ooops applied this v2 version instead of the v1.
No problem, only the pinctrl-single patches needed
reposting.
> * kbuild test robot <lkp-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> [161103 13:29]:
> > In file included from drivers/pinctrl/core.c:36:0:
> > >> drivers/pinctrl/devicetree.h:29:14: warning: 'struct of_phandle_args' declared inside parameter list will not be visible outside of this
> definition or declaratio
>
> > Hmm maybe we should just include of.h in core.c?
>
> Nah. I just did this:
>
> diff --git a/drivers/pinctrl/devicetree.h b/drivers/pinctrl/devicetree.h
> index 7f0a5c4e15ad..c2d1a5505850 100644
> --- a/drivers/pinctrl/devicetree.h
> +++ b/drivers/pinctrl/devicetree.h
> @@ -16,6 +16,8 @@
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> +struct of_phandle_args;
> +
> #ifdef CONFIG_OF
>
> Let's see if it works!
OK so do we know now? It seems there was one more email
about it but it may have been without it.
Thanks,
Tony
--
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/9] mfd: da9061: MFD core support
From: Steve Twiss @ 2016-11-07 15:25 UTC (permalink / raw)
To: Lee Jones
Cc: LINUX-KERNEL, DEVICETREE, Dmitry Torokhov, Eduardo Valentin,
Guenter Roeck, LINUX-INPUT, LINUX-PM, LINUX-WATCHDOG,
Liam Girdwood, Mark Brown, Mark Rutland, Rob Herring,
Support Opensource, Wim Van Sebroeck, Zhang Rui
In-Reply-To: <20161102142854.GS13127@dell>
On 02 November 2016 14:29, Lee Jones wrote:
> On Mon, 31 Oct 2016, Steve Twiss wrote:
> > From: Steve Twiss <stwiss.opensource@diasemi.com>
> >
> > @@ -475,7 +855,25 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
> > return -EINVAL;
> > }
> >
> > - chip->regmap = devm_regmap_init_i2c(i2c, &da9062_regmap_config);
> > + switch (chip->chip_type) {
> > + case(COMPAT_TYPE_DA9061):
> > + cell = da9061_devs;
> > + cell_num = ARRAY_SIZE(da9061_devs);
> > + irq_chip = &da9061_irq_chip;
> > + config = &da9061_regmap_config;
> > + break;
> > + case(COMPAT_TYPE_DA9062):
> > + cell = da9062_devs;
> > + cell_num = ARRAY_SIZE(da9062_devs);
> > + irq_chip = &da9062_irq_chip;
> > + config = &da9062_regmap_config;
> > + break;
> > + default:
> > + dev_err(chip->dev, "Unrecognised chip type\n");
> > + return -ENODEV;
> > + }
>
> I very much dislike when MFD and OF functionality is mixed.
>
> In your case you can use da9062_get_device_type() to dynamically
> interrogate the device and register using the correct MFD cells that
> way.
Hi Lee,
It's the device tree that decides what the chip type is. It's not chip
interrogation in this case. The ordering dictates this I think: to access the
hardware ID register, a regmap definition is needed first. But because the
correct I2C register map requires a knowledge of what chip is being used,
it becomes a circular dependency.
To solve this dependency, I define the chip type (DA9061 or DA9062) in the
device tree and assign the correct regmap first before accessing any registers.
> > + chip->regmap = devm_regmap_init_i2c(i2c, config);
> > if (IS_ERR(chip->regmap)) {
> > ret = PTR_ERR(chip->regmap);
> > dev_err(chip->dev, "Failed to allocate register map: %d\n",
> > @@ -493,7 +891,7 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
> >
> > ret = regmap_add_irq_chip(chip->regmap, i2c->irq,
> > IRQF_TRIGGER_LOW | IRQF_ONESHOT |IRQF_SHARED,
> > - -1, &da9062_irq_chip,
> > + -1, irq_chip,
>
> What is -1?
.. it's a request for an irq_base.
http://lxr.free-electrons.com/source/kernel/irq/irqdesc.c#L477
Is there a reason I shouldn't be doing that?
There doesn't seem to be a #define anywhere, and using -1 seems
to be the standard in the kernel at the moment.
Regards,
Steve
^ permalink raw reply
* Re: [PATCH 6/6] ARM: dts: Extend the S3C RTC node with rtc_src clock
From: Javier Martinez Canillas @ 2016-11-07 15:09 UTC (permalink / raw)
To: Pankaj Dubey, linux-samsung-soc, linux-arm-kernel
Cc: krzk, kgene, thomas.ab, myungjoo.ham, Rob Herring, devicetree
In-Reply-To: <1478513376-14307-7-git-send-email-pankaj.dubey@samsung.com>
Hello Pankaj,
On 11/07/2016 07:09 AM, Pankaj Dubey wrote:
> Extend the S3C RTC node with rtc_src clock so it could be operational.
> The rtc_src clock is provided by MAX8997.
>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: devicetree@vger.kernel.org
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH 4/6] ARM: dts: Add clock provider specific properties to max8997 node
From: Javier Martinez Canillas @ 2016-11-07 15:07 UTC (permalink / raw)
To: Pankaj Dubey, linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: krzk-DgEjT+Ai2ygdnm+yROfE0A, kgene-DgEjT+Ai2ygdnm+yROfE0A,
thomas.ab-Sze3O3UU22JBDgjK7y7TUQ,
myungjoo.ham-Sze3O3UU22JBDgjK7y7TUQ, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1478513376-14307-5-git-send-email-pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Hello Pankaj,
On 11/07/2016 07:09 AM, Pankaj Dubey wrote:
> This patch adds a label and #clock-cells property to device node of
> max8997 PMIC to allow using it as a clock provider.
>
> CC: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> CC: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Pankaj Dubey <pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> arch/arm/boot/dts/exynos4210-origen.dts | 3 ++-
> arch/arm/boot/dts/exynos4210-trats.dts | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4210-origen.dts b/arch/arm/boot/dts/exynos4210-origen.dts
> index cb3a255..6c7ef4e 100644
> --- a/arch/arm/boot/dts/exynos4210-origen.dts
> +++ b/arch/arm/boot/dts/exynos4210-origen.dts
> @@ -147,11 +147,12 @@
> pinctrl-0 = <&i2c0_bus>;
> pinctrl-names = "default";
>
> - max8997_pmic@66 {
> + max8997: max8997_pmic@66 {
The ePAPR says that the node name should be "somewhat generic, reflecting
the function of the device and not its precise programming model". So I
think this should be instead:
max8997: pmic@66 {
[...]
> - max8997_pmic@66 {
> + max8997: max8997_pmic@66 {
Same here.
The rest looks good to me.
Reviewed-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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 1/2] iio: adc: spmi-vadc: Update changes to support reporting of Raw adc code.
From: Phani A, Rama Krishna @ 2016-11-07 15:07 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio, devicetree
Cc: robh, linux-arm-msm, smohanad, mgautam, sivaa, knaack.h, lars,
pmeerw, Julia.Lawall
In-Reply-To: <22dcb3e2-aa00-4e61-eeac-a4f1a9afa0e5@kernel.org>
Hi Jonathan,
On 05-Nov-16 9:29 PM, Jonathan Cameron wrote:
> On 02/11/16 13:12, Phani A, Rama Krishna wrote:
>> Hi Jonathan,
>>
>> On 02-Nov-16 12:00 AM, Jonathan Cameron wrote:
>>> On 31/10/16 08:48, Rama Krishna Phani A wrote:
>>>> Hi Jonathan,
>>>>
>>>> On 30-Oct-16 11:05 PM, Jonathan Cameron wrote:
>>>>> On 26/10/16 15:41, Rama Krishna Phani A wrote:
>>>>>> Logic to convert adc code to voltage is generic across all channels.
>>>>>> Different scaling can be done on the obtained voltage to report in physical
>>>>>> units. Implement separate function for generic conversion logic.
>>>>>> Scaling functionality can be changed per channel. Update changes to support
>>>>>> reporting of Raw adc code.
>>>>> Pleas rewrite this description. Perhaps give examples of the changes
>>>>> it makes to what is read from the various attributes?
>>>> There are several channels in the ADC of PMIC which can be used to
>>>> measure voltage, temperature, current etc., Hardware provides
>>>> readings for all channels in adc code. That adc code needs to be
>>>> converted to voltage. The logic for conversion of adc code to voltage
>>>> is common for all ADC channels(voltage, temperature and current
>>>> .,etc). Once voltage is obtained ., scaling is done on that voltage.
>>>>
>>>> For Ex., Thermal SW wants to know the temperature of thermistor on
>>>> PMIC and it expects the temperature to be reported in millidegC. ADC
>>>> channel is used to read the adc code and convert it to voltage. Once
>>>> the voltage is available based on the thermistor spec that voltage is
>>>> mapped to a temperature and then that value is reported to Thermal
>>>> SW.
>>>>
>>>> Mapping of voltage to temperature is called scaling for that channel
>>>> and scaling function can be different per channel based on how the
>>>> voltage is reported.
>>> Is the thermistor always part of the device? (i.e. in the chip) in which
>>> case this might be fine. If it's external then it needs to be described
>>> by a separate device which acts as a consumer of the IIO channel and
>>> in turn provides the scaled output to thermal.
>>>
>>> The thermistor should really be separately described. This is already
>>> done in drivers/hwmon/ntc_thermistor
>>>
>>> Are any of these scalings characteristics of the chip supported by
>>> this driver, or are they the result of external hardware?
>>
>> All the VADC channels i.e., Voltage, temperature(thermistors and
>> other channels) are part of PMIC chip. The scaling functionalities
>> supported in this driver are for the adc channels which are part of
>> PMIC chip.
>>>>>
>>>>> I haven't immediately followed what this change is actually doing.
>>>>>
>>>>> I 'think' the point here is to not apply the calibration to
>>>>> the raw adc counts when a true raw read is requested?
>>>>>
>>>> When a true raw read is requested .,Scaling is not applied.
>>>>> There are several unconnected looking changes in here...
>>>>>>
>>>>>> Signed-off-by: Rama Krishna Phani A <rphani@codeaurora.org>
>>>>>> ---
>>>>>> drivers/iio/adc/qcom-spmi-vadc.c | 54 +++++++++++++++++++++-------------------
>>>>>> 1 file changed, 28 insertions(+), 26 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/iio/adc/qcom-spmi-vadc.c b/drivers/iio/adc/qcom-spmi-vadc.c
>>>>>> index c2babe5..ff4d549 100644
>>>>>> --- a/drivers/iio/adc/qcom-spmi-vadc.c
>>>>>> +++ b/drivers/iio/adc/qcom-spmi-vadc.c
>>>>>> @@ -1,5 +1,5 @@
>>>>>> /*
>>>>>> - * Copyright (c) 2012-2014, The Linux Foundation. All rights reserved.
>>>>>> + * Copyright (c) 2012-2016, The Linux Foundation. All rights reserved.
>>>>>> *
>>>>>> * This program is free software; you can redistribute it and/or modify
>>>>>> * it under the terms of the GNU General Public License version 2 and
>>>>>> @@ -84,7 +84,7 @@
>>>>>> #define VADC_MAX_ADC_CODE 0xa800
>>>>>>
>>>>>> #define VADC_ABSOLUTE_RANGE_UV 625000
>>>>>> -#define VADC_RATIOMETRIC_RANGE_UV 1800000
>>>>>> +#define VADC_RATIOMETRIC_RANGE 1800
>>>>>>
>>>>>> #define VADC_DEF_PRESCALING 0 /* 1:1 */
>>>>>> #define VADC_DEF_DECIMATION 0 /* 512 */
>>>>>> @@ -418,7 +418,7 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc)
>>>>>> u16 read_1, read_2;
>>>>>> int ret;
>>>>>>
>>>>>> - vadc->graph[VADC_CALIB_RATIOMETRIC].dx = VADC_RATIOMETRIC_RANGE_UV;
>>>>>> + vadc->graph[VADC_CALIB_RATIOMETRIC].dx = VADC_RATIOMETRIC_RANGE;
>>>>>> vadc->graph[VADC_CALIB_ABSOLUTE].dx = VADC_ABSOLUTE_RANGE_UV;
>>>>>>
>>>>>> prop = vadc_get_channel(vadc, VADC_REF_1250MV);
>>>>>> @@ -468,21 +468,30 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc)
>>>>>> return ret;
>>>>>> }
>>>>>>
>>>>>> -static s32 vadc_calibrate(struct vadc_priv *vadc,
>>>>>> - const struct vadc_channel_prop *prop, u16 adc_code)
>>>>>> +static void vadc_scale_calib(struct vadc_priv *vadc, u16 adc_code,
>>>>>> + const struct vadc_channel_prop *prop,
>>>>>> + s64 *scale_voltage)
>>>>>> {
>>>>>> - const struct vadc_prescale_ratio *prescale;
>>>>>> - s64 voltage;
>>>>>> + *scale_voltage = (adc_code -
>>>>>> + vadc->graph[prop->calibration].gnd);
>>>>>> + *scale_voltage *= vadc->graph[prop->calibration].dx;
>>>>>> + *scale_voltage = div64_s64(*scale_voltage,
>>>>>> + vadc->graph[prop->calibration].dy);
>>>>>> + if (prop->calibration == VADC_CALIB_ABSOLUTE)
>>>>>> + *scale_voltage +=
>>>>>> + vadc->graph[prop->calibration].dx;
>>>>>>
>>>>>> - voltage = adc_code - vadc->graph[prop->calibration].gnd;
>>>>>> - voltage *= vadc->graph[prop->calibration].dx;
>>>>>> - voltage = div64_s64(voltage, vadc->graph[prop->calibration].dy);
>>>>>> + if (*scale_voltage < 0)
>>>>>> + *scale_voltage = 0;
>>>>>> +}
>>>>>>
>>>>>> - if (prop->calibration == VADC_CALIB_ABSOLUTE)
>>>>>> - voltage += vadc->graph[prop->calibration].dx;
>>>>>> +static s64 vadc_scale_fn(struct vadc_priv *vadc,
>>>>>> + const struct vadc_channel_prop *prop, u16 adc_code)
>>>>>> +{
>>>>>> + const struct vadc_prescale_ratio *prescale;
>>>>>> + s64 voltage = 0;
>>>>>>
>>>>>> - if (voltage < 0)
>>>>>> - voltage = 0;
>>>>>> + vadc_scale_calib(vadc, adc_code, prop, &voltage);
>>>>>>
>>>>>> prescale = &vadc_prescale_ratios[prop->prescale];
>>>>>>
>>>>>> @@ -552,11 +561,8 @@ static int vadc_read_raw(struct iio_dev *indio_dev,
>>>>>> if (ret)
>>>>>> break;
>>>>>>
>>>>>> - *val = vadc_calibrate(vadc, prop, adc_code);
>>>>>> + *val = vadc_scale_fn(vadc, prop, adc_code);
>>>>>>
>>>>>> - /* 2mV/K, return milli Celsius */
>>>>>> - *val /= 2;
>>>>>> - *val -= KELVINMIL_CELSIUSMIL;
>>>>>> return IIO_VAL_INT;
>>>>>> case IIO_CHAN_INFO_RAW:
>>>>>> prop = &vadc->chan_props[chan->address];
>>>>>> @@ -564,12 +570,8 @@ static int vadc_read_raw(struct iio_dev *indio_dev,
>>>>>> if (ret)
>>>>>> break;
>>>>>>
>>>>>> - *val = vadc_calibrate(vadc, prop, adc_code);
>>>>>> + *val = (int)adc_code;
>>>>>> return IIO_VAL_INT;
>>>>> So this is 'more raw'.
>>>> Yes., its raw value.
>>>>>> - case IIO_CHAN_INFO_SCALE:
>>>>>> - *val = 0;
>>>>>> - *val2 = 1000;
>>>>>> - return IIO_VAL_INT_PLUS_MICRO;
>>>>>> default:
>>>>>> ret = -EINVAL;
>>>>>> break;
>>>>>> @@ -616,8 +618,8 @@ struct vadc_channels {
>>>>>> VADC_CHAN(_dname, IIO_TEMP, BIT(IIO_CHAN_INFO_PROCESSED), _pre) \
>>>>>>
>>>>>> #define VADC_CHAN_VOLT(_dname, _pre) \
>>>>>> - VADC_CHAN(_dname, IIO_VOLTAGE, \
>>>>>> - BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE), \
>>>>>> + VADC_CHAN(_dname, IIO_VOLTAGE, \
>>>>>> + BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_PROCESSED),\
>>>>>> _pre) \
>>>>> It very unusual to report both raw and processed values. Please explain
>>>>> why that is needed here? It may be valid to maintain backwards compatibility
>>>>> of ABI. Which would be fine. However if I read the above correctly you are
>>>>> changing what comes out of reading the raw value so the ABI just changed...
>>>>>
>>>> With the help of IIO sysfs ., we can read the ADC channel readings
>>>> either in RAW format or in processed format. There are two separate
>>>> individual entries to read the ADC channel either in Raw format or in
>>>> processed format. Most of the clients for ADC expect the readings in
>>>> processed format.
>>> If we are talking in kernel, that is worked out by the application of
>>> scale. The IIO in kernel interfaces will do this automatically.
>>>
>>> I we are talking in userspace, then the userspace needs to be
>>> extended to support raw and scale reading.
>>
>> Every channel present in adc has an unique conversion formula for
>> obtained voltage, suggested by Hardware designers.
>>
>> Ex: For die_temp channel., Temp = 2mv/Kelvin Above formula has to be
>> applied on obtained voltage in order for the channel to report the
>> temperature in milldegC.
>>
>> Like wise every channel has unique way of conversion logic suggested
>> by HW folks. That conversion logic is done in ADC driver.
> If it is linear then ideally expose it as a raw channel and offset + scale.
> If non linear then a processed channel with the conversion logic in kernel
> as we have no means of describing it to userspace.
Yes ., these channels are non linear and hence they needs to be processed.
>
>>
>>>>>
>>>
>>>>>> /*
>>>>>> @@ -850,9 +852,9 @@ static int vadc_get_dt_data(struct vadc_priv *vadc, struct device_node *node)
>>>>>>
>>>>>> iio_chan->channel = prop.channel;
>>>>>> iio_chan->datasheet_name = vadc_chan->datasheet_name;
>>>>>> + iio_chan->extend_name = child->name;
>>>>> What's this change?
>>>> We can choose how we want to display our adc channel entries in sysfs. Am using the child node name to be displayed as the sysfs entry rather than channel number for easy interpretation.
>>>>
>>>> For ex: for vcoin(coin battery voltage channel.,) with this change it appears like below in iio adc sysfs
>>>>
>>>> "in_voltage_vcoin_input"
>>> No. This introduces a mass of undocumented (and uncontrolled) ABI.
>>> If there are reasons to add such a label then it should not be done
>>> in the file name.
>>
>> "extended_name" is an existing field in "iio_chan_spec" structure,
>> present in iio.h(include\linux\iio) and has documentation regarding
>> the functionality. Pasting it here for quick reference.>
>> * @extend_name:Allows labeling of channel attributes with an
>> * informative name. Note this has no effect codes etc,
>> * unlike modifiers.
>
>>
>> Am trying to use the existing field here., initializing it with a
>> value which is easy for interpretation of channel attributes.
> OK. I'd misunderstood what was going on here. If and only if these
> channels are internally linked to a particular voltage / temperature
> sensor etc it 'may' make sense.
>
> If they are linked to a hardware monitoring channel then ideally we
> would also be mapping them across to hwmon through the iio_hwmon
> bridge.
>>>>
>>>>>> iio_chan->info_mask_separate = vadc_chan->info_mask;
>>>>>> iio_chan->type = vadc_chan->type;
>>>>>> - iio_chan->indexed = 1;
>>>>> Or for that matter this one...
>>>> reason explained above.
> No they still need to be indexed. If we ever have events etc
> on these channels or want to 'consume' them in other kernel drivers
> they need to be indexed. The strings are not available. They are
> just an convenience in naming of channels (and one I'm kind of
> wishing we had never provided as it leads to uncontrolled ABI
> explosion like here).
>
> Anyhow, the key thing that wasn't clear in this patch description
> and left me confused is that the scaling previously reported was
> simply wrong and this was fixing it!
>
> You do have several overlapping changes here which confused matters
> further. This extend_name stuff for example is a different
> issue. Your big problem is that it is an ABI change and hence
> a non starter at this point. Fixing wrong scaling is one thing
> but changing the naming of sysfs files like this is not going to
> be possible now the driver has been out there for a while.
>
Ok ., will retain the indexed change in next patch.
> Jonathan
>>>>>> iio_chan->address = index++;
>>>>>>
>>>>>> iio_chan++;
>>>>>>
>>>>>
>>>>
>>>> Thanks,
>>>> Ramakrishna
>>>>
>>>> ---
>>>> This email has been checked for viruses by Avast antivirus software.
>>>> https://www.avast.com/antivirus
>>>>
>>>> --
>>>> 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
>>>
>>
>> Thanks,
>> Ramakrishna
>
Thanks,
Ramakrishna
^ permalink raw reply
* Re: [PATCH 3/6] clk: Add driver for Maxim-8997 PMIC clocks
From: Javier Martinez Canillas @ 2016-11-07 15:01 UTC (permalink / raw)
To: Pankaj Dubey, linux-samsung-soc, linux-arm-kernel
Cc: devicetree, thomas.ab, kgene, Michael Turquette, krzk,
Rob Herring, myungjoo.ham, linux-clk
In-Reply-To: <1478513376-14307-4-git-send-email-pankaj.dubey@samsung.com>
Hello Pankaj,
On 11/07/2016 07:09 AM, Pankaj Dubey wrote:
> The MAX8997 PMIC has 32.786kHz crystal oscillator which provides an
> accurate low frequency clock for MAX8997 internal circuit as well as
> external circuit. This patch adds support for these two clocks.
>
> CC: Michael Turquette <mturquette@baylibre.com>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: devicetree@vger.kernel.org
> CC: linux-clk@vger.kernel.org
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
What kernel version are you basing this on? The Maxim common clock code
is going away for v4.9 and instead the clk-max77686 driver supports both
77686 and 77802 clocks. See commit 8ad313fe4e00 ("clk: max77686: Combine
Maxim max77686 and max77802 driver").
Since the 8997 clock IP looks very similar to 77802 AFAICT, you should
also extend the clk-max77686 driver to have 8997 support.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH 1/6] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Radosław Pietrzyk @ 2016-11-07 14:57 UTC (permalink / raw)
To: Gabriel FERNANDEZ
Cc: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Stephen Boyd, Nicolas Pitre,
Arnd Bergmann, Daniel Thompson, Andrea Merello, devicetree,
amelie.delaunay, kernel, olivier.bideau, linux-kernel, linux-clk,
ludovic.barre, linux-arm-kernel
In-Reply-To: <1478523943-23142-2-git-send-email-gabriel.fernandez@st.com>
> +static struct clk_hw *clk_register_pll_div(const char *name,
> + const char *parent_name, unsigned long flags,
> + void __iomem *reg, u8 shift, u8 width,
> + u8 clk_divider_flags, const struct clk_div_table *table,
> + struct clk_hw *pll_hw, spinlock_t *lock)
> +{
> + struct stm32f4_pll_div *pll_div;
> + struct clk_hw *hw;
> + struct clk_init_data init;
> + int ret;
> +
> + /* allocate the divider */
> + pll_div = kzalloc(sizeof(*pll_div), GFP_KERNEL);
> + if (!pll_div)
> + return ERR_PTR(-ENOMEM);
> +
> + init.name = name;
> + init.ops = &stm32f4_pll_div_ops;
> + init.flags = flags;
Maybe it's worth to have CLK_SET_RATE_PARENT here and the VCO clock
should have CLK_SET_RATE_GATE flag and we can get rid of custom
divider ops.
> -static void stm32f4_rcc_register_pll(const char *hse_clk, const char *hsi_clk)
> +
> +static struct clk_hw *stm32f4_rcc_register_pll(const char *pllsrc,
> + const struct stm32f4_pll_data *data, spinlock_t *lock)
> {
> - unsigned long pllcfgr = readl(base + STM32F4_RCC_PLLCFGR);
> + struct stm32f4_pll *pll;
> + struct clk_init_data init = { NULL };
> + void __iomem *reg;
> + struct clk_hw *pll_hw;
> + int ret;
> +
> + pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> + if (!pll)
> + return ERR_PTR(-ENOMEM);
> +
> + init.name = data->vco_name;
> + init.ops = &stm32f4_pll_gate_ops;
> + init.flags = CLK_IGNORE_UNUSED;
CLK_SET_RATE_GATE here
Moreover why not having VCO as a composite clock from gate and mult ?
According to docs SAI VCO (don't know about I2S ) must be within
certain range so clk_set_rate_range should be somewhere.
^ permalink raw reply
* Re: [PATCH 2/6] dt-bindings: clk: max8997: Add DT binding documentation
From: Javier Martinez Canillas @ 2016-11-07 14:47 UTC (permalink / raw)
To: Pankaj Dubey, linux-samsung-soc, linux-arm-kernel
Cc: krzk, kgene, thomas.ab, myungjoo.ham, Michael Turquette,
Rob Herring, devicetree, linux-clk
In-Reply-To: <1478513376-14307-3-git-send-email-pankaj.dubey@samsung.com>
Hello Pankaj,
On 11/07/2016 07:09 AM, Pankaj Dubey wrote:
> Add Device Tree binding documentation for the clocks
> outputs in the Maxim-8997 Power Management IC.
>
> CC: Michael Turquette <mturquette@baylibre.com>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: devicetree@vger.kernel.org
> CC: linux-clk@vger.kernel.org
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH] ARM: tegra: apalis-tk1: Drop leading 0 from unit-address
From: Marcel Ziswiler @ 2016-11-07 14:32 UTC (permalink / raw)
To: thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org, Marcel Ziswiler,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161107134923.5615-1-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, 2016-11-07 at 14:49 +0100, Thierry Reding wrote:
> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org
> >
>
> According to the latest best practices, unit-addresses should be
> represented without any leading zeroes.
Understood, sorry about that.
> Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> ---
> arch/arm/boot/dts/tegra124-apalis.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/tegra124-apalis.dtsi
> b/arch/arm/boot/dts/tegra124-apalis.dtsi
> index e7a73db17613..0819721dda59 100644
> --- a/arch/arm/boot/dts/tegra124-apalis.dtsi
> +++ b/arch/arm/boot/dts/tegra124-apalis.dtsi
> @@ -1595,7 +1595,7 @@
> clock-frequency = <400000>;
>
> /* SGTL5000 audio codec */
> - sgtl5000: codec@0a {
> + sgtl5000: codec@a {
> compatible = "fsl,sgtl5000";
> reg = <0x0a>;
> VDDA-supply = <®_3v3>;
^ permalink raw reply
* Re: [PATCH 4/6] clk: stm32f4: Add I2S clock
From: Daniel Thompson @ 2016-11-07 14:14 UTC (permalink / raw)
To: gabriel.fernandez, Rob Herring, Mark Rutland, Russell King,
Maxime Coquelin, Alexandre Torgue, Michael Turquette,
Stephen Boyd, Nicolas Pitre, Arnd Bergmann, andrea.merello
Cc: devicetree, linux-arm-kernel, linux-kernel, linux-clk, kernel,
ludovic.barre, olivier.bideau, amelie.delaunay
In-Reply-To: <1478523943-23142-5-git-send-email-gabriel.fernandez@st.com>
On 07/11/16 13:05, gabriel.fernandez@st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch introduces I2S clock for stm32f4 soc.
> The I2S clock could be derived from an external clock or from pll-i2s
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> drivers/clk/clk-stm32f4.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
> index 5fa5d51..b7cb359 100644
> --- a/drivers/clk/clk-stm32f4.c
> +++ b/drivers/clk/clk-stm32f4.c
> @@ -216,6 +216,7 @@ enum {
> SYSTICK, FCLK, CLK_LSI, CLK_LSE, CLK_HSE_RTC, CLK_RTC,
> PLL_VCO_I2S, PLL_VCO_SAI,
> CLK_LCD,
> + CLK_I2S,
Sorry, this has just clicked and it applies to most of the other
patches, but adding things to this list effectively extends the clock
bindings (i.e. the list of valid "other" clocks access with a primary
index of 1).
This list if a list of "arbitrary" constants by which DT periphericals
can be linked to specific clocks.
So...
1) If a clock is introduced here we should update the clock binding
documentations.
2) If no peripheral can connect to the clock (because it is internal
to the clock gen logic and peripherals must connect to the gated
version) it should not be included in this enum.
3) I failed to mention this when the four undocumented clocks
(LSI, LSE, HSE_RTC and RTC) were added.
4) I *should* have added a comment explaining the above to the code.
> END_PRIMARY_CLK
> };
>
> @@ -967,6 +968,8 @@ static struct clk_hw *stm32_register_cclk(struct device *dev, const char *name,
>
> static const char *sdmux_parents[2] = { "pll48", "sys" };
>
> +static const char *i2s_parents[2] = { "plli2s-r", NULL };
> +
> struct stm32f4_clk_data {
> const struct stm32f4_gate_data *gates_data;
> const u64 *gates_map;
> @@ -1005,7 +1008,7 @@ struct stm32f4_clk_data {
>
> static void __init stm32f4_rcc_init(struct device_node *np)
> {
> - const char *hse_clk;
> + const char *hse_clk, *i2s_in_clk;
> int n;
> const struct of_device_id *match;
> const struct stm32f4_clk_data *data;
> @@ -1038,6 +1041,7 @@ static void __init stm32f4_rcc_init(struct device_node *np)
> stm32f4_gate_map = data->gates_map;
>
> hse_clk = of_clk_get_parent_name(np, 0);
> + i2s_in_clk = of_clk_get_parent_name(np, 1);
Again this looks like a change to the DT bindings.
Also does the code work if i2s_in_clk is NULL or as you hoping to get
away with a not-backwards compatible change?
Daniel.
>
> clk_register_fixed_rate_with_accuracy(NULL, "hsi", NULL, 0,
> 16000000, 160000);
> @@ -1053,6 +1057,12 @@ static void __init stm32f4_rcc_init(struct device_node *np)
> clks[PLL_VCO_SAI] = stm32f4_rcc_register_pll(pllsrc,
> &data->pll_data[2], &stm32f4_clk_lock);
>
> + i2s_parents[1] = i2s_in_clk;
> +
> + clks[CLK_I2S] = clk_hw_register_mux_table(NULL, "i2s",
> + i2s_parents, ARRAY_SIZE(i2s_parents), 0,
> + base + STM32F4_RCC_CFGR, 23, 1, 0, NULL,
> + &stm32f4_clk_lock);
> sys_parents[1] = hse_clk;
> clk_register_mux_table(
> NULL, "sys", sys_parents, ARRAY_SIZE(sys_parents), 0,
>
^ permalink raw reply
* Re: [PATCH 3/6] clk: stm32f4: Add post divisor for I2S & SAI PLLs and Add lcd-tft clock
From: Gabriel Fernandez @ 2016-11-07 14:14 UTC (permalink / raw)
To: Daniel Thompson, Rob Herring, Mark Rutland, Russell King,
Maxime Coquelin, Alexandre Torgue, Michael Turquette,
Stephen Boyd, Nicolas Pitre, Arnd Bergmann, andrea.merello
Cc: devicetree, linux-arm-kernel, linux-kernel, linux-clk, kernel,
ludovic.barre, olivier.bideau, amelie.delaunay
In-Reply-To: <860ce6a2-066f-2b44-3cf5-2d73720ed588@linaro.org>
Hi Daniel,
On 11/07/2016 02:58 PM, Daniel Thompson wrote:
> On 07/11/16 13:05, gabriel.fernandez@st.com wrote:
>> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>>
>> This patch adds post dividers of I2S & SAI PLLs.
>> These dividers are managed by a dedicated register (RCC_DCKCFGR).
>> The PLL should be off before a set rate.
>> This patch also introduces the lcd-tft clock.
>>
>> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
>> ---
>> drivers/clk/clk-stm32f4.c | 27 +++++++++++++++++++++++++--
>> 1 file changed, 25 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
>> index dda15bc..5fa5d51 100644
>> --- a/drivers/clk/clk-stm32f4.c
>> +++ b/drivers/clk/clk-stm32f4.c
>> @@ -215,6 +215,7 @@ struct stm32f4_gate_data {
>> enum {
>> SYSTICK, FCLK, CLK_LSI, CLK_LSE, CLK_HSE_RTC, CLK_RTC,
>> PLL_VCO_I2S, PLL_VCO_SAI,
>> + CLK_LCD,
>> END_PRIMARY_CLK
>> };
>>
>> @@ -599,6 +600,9 @@ static struct clk_hw *clk_register_pll_div(const
>> char *name,
>> static const struct clk_div_table pll_divp_table[] = {
>> { 0, 2 }, { 1, 4 }, { 2, 6 }, { 3, 8 },
>> };
>> +static const struct clk_div_table pll_lcd_div_table[] = {
>> + { 0, 2 }, { 1, 4 }, { 2, 8 }, { 3, 16 },
>> +};
>>
>> /*
>> * Decode current PLL state and (statically) model the state we
>> inherit from
>> @@ -659,16 +663,35 @@ static struct clk_hw
>> *stm32f4_rcc_register_pll(const char *pllsrc,
>> clk_register_pll_div(data->p_name, data->vco_name, 0, reg,
>> 16, 2, 0, pll_divp_table, pll_hw, lock);
>>
>> - if (data->q_name)
>> + if (data->q_name) {
>> clk_register_pll_div(data->q_name, data->vco_name, 0, reg,
>> 24, 4, CLK_DIVIDER_ONE_BASED, NULL,
>> pll_hw, lock);
>>
>> - if (data->r_name)
>> + if (data->pll_num == PLL_I2S)
>> + clk_register_pll_div("plli2s-q-div", data->q_name,
>> + 0, base + STM32F4_RCC_DCKCFGR,
>> + 0, 5, 0, NULL, pll_hw, &stm32f4_clk_lock);
>> +
>> + if (data->pll_num == PLL_SAI)
>> + clk_register_pll_div("pllsai-q-div", data->q_name,
>> + 0, base + STM32F4_RCC_DCKCFGR,
>> + 8, 5, 0, NULL, pll_hw, &stm32f4_clk_lock);
>> + }
>
> Shouldn't this be in the config structures?
>
> It seems very odd to me to allow the config structures to control
> whether we take the branch or not and then add these hard coded hacks.
>
ok i will put it in the config structure.
BR
Gabriel.
>
> Daniel.
^ permalink raw reply
* Re: [PATCH] ARM: tegra: nyan: Mark all USB ports as host
From: Jon Hunter @ 2016-11-07 14:09 UTC (permalink / raw)
To: Thierry Reding, Paul Kocialkowski
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Alexandre Courbot,
Stephen Warren
In-Reply-To: <20161107132854.GF12559-EkSeR96xj6Pcmrwk2tT4+A@public.gmane.org>
On 07/11/16 13:28, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Sun, Sep 18, 2016 at 12:28:52PM +0200, Paul Kocialkowski wrote:
>> Nyan boards only have host USB ports (2 external, 1 internal), there is
>> no OTG-enabled connector.
>>
>> Signed-off-by: Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org>
>> ---
>> arch/arm/boot/dts/tegra124-nyan.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Where is this information coming from? I don't have one of the Nyans
> myself, but one of the Tegra132 devices I have, which I think was
> derived from one of the Nyans uses one of the external host ports as
> forced recovery port, for which it would need OTG.
>
> I suspect that the way to get U-Boot onto the Nyans is via tegrarcm?
> In that case I think one of the ports must be OTG.
It is true that the port on the back on the nyan-big can be used with
recovery mode. I was thinking that this is not a true OTG port as it is
just a 4-pin type A socket and does not have an ID pin. Thinking some
more about this the USB spec does include a "Host Negotiation Protocol
(HNP)" that allows a host and device to swap roles and so keeping it as
OTG seems valid afterall.
Cheers
Jon
--
nvpublic
--
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 2/6] clk: stm32f4: SDIO & 48Mhz clock management for STM32F469 board
From: Gabriel Fernandez @ 2016-11-07 14:06 UTC (permalink / raw)
To: Daniel Thompson, Rob Herring, Mark Rutland, Russell King,
Maxime Coquelin, Alexandre Torgue, Michael Turquette,
Stephen Boyd, Nicolas Pitre, Arnd Bergmann, andrea.merello
Cc: devicetree, linux-arm-kernel, linux-kernel, linux-clk, kernel,
ludovic.barre, olivier.bideau, amelie.delaunay
In-Reply-To: <45a332b6-5170-9ae3-8d5e-c5f827c3edea@linaro.org>
Hi Daniel,
On 11/07/2016 02:55 PM, Daniel Thompson wrote:
> On 07/11/16 13:05, gabriel.fernandez@st.com wrote:
>> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>>
>> In the stm32f469 soc, the 48Mhz clock could be derived from pll-q or
>> from pll-sai-p.
>>
>> The SDIO clock could be also derived from 48Mhz or from sys clock.
>>
>> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
>> ---
>> drivers/clk/clk-stm32f4.c | 18 +++++++++++++++++-
>> 1 file changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
>> index 7641acd..dda15bc 100644
>> --- a/drivers/clk/clk-stm32f4.c
>> +++ b/drivers/clk/clk-stm32f4.c
>> @@ -199,7 +199,7 @@ struct stm32f4_gate_data {
>> { STM32F4_RCC_APB2ENR, 8, "adc1", "apb2_div" },
>> { STM32F4_RCC_APB2ENR, 9, "adc2", "apb2_div" },
>> { STM32F4_RCC_APB2ENR, 10, "adc3", "apb2_div" },
>> - { STM32F4_RCC_APB2ENR, 11, "sdio", "pll48" },
>> + { STM32F4_RCC_APB2ENR, 11, "sdio", "sdmux" },
>
> I'm confused. How do the "sdmux" clock come to exist on STM32F429?
>
"sdmux" only exist on STM32F469 (struct stm32f4_gate_data stm32f469_gates[])
BR
Gabriel
>
>> { STM32F4_RCC_APB2ENR, 12, "spi1", "apb2_div" },
>> { STM32F4_RCC_APB2ENR, 13, "spi4", "apb2_div" },
>> { STM32F4_RCC_APB2ENR, 14, "syscfg", "apb2_div" },
>> @@ -940,6 +940,10 @@ static struct clk_hw *stm32_register_cclk(struct
>> device *dev, const char *name,
>> "no-clock", "lse", "lsi", "hse-rtc"
>> };
>>
>> +static const char *pll48_parents[2] = { "pll-q", "pllsai-p" };
>> +
>> +static const char *sdmux_parents[2] = { "pll48", "sys" };
>> +
>> struct stm32f4_clk_data {
>> const struct stm32f4_gate_data *gates_data;
>> const u64 *gates_map;
>> @@ -1109,6 +1113,18 @@ static void __init stm32f4_rcc_init(struct
>> device_node *np)
>> goto fail;
>> }
>>
>> + if (of_device_is_compatible(np, "st,stm32f469-rcc")) {
>> + clk_hw_register_mux_table(NULL, "pll48",
>> + pll48_parents, ARRAY_SIZE(pll48_parents), 0,
>> + base + STM32F4_RCC_DCKCFGR, 27, 1, 0, NULL,
>> + &stm32f4_clk_lock);
>> +
>> + clk_hw_register_mux_table(NULL, "sdmux",
>> + sdmux_parents, ARRAY_SIZE(sdmux_parents), 0,
>> + base + STM32F4_RCC_DCKCFGR, 28, 1, 0, NULL,
>> + &stm32f4_clk_lock);
>> + }
>> +
>> of_clk_add_hw_provider(np, stm32f4_rcc_lookup_clk, NULL);
>> return;
>> fail:
>>
>
^ permalink raw reply
* Re: [PATCH 1/6] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Gabriel Fernandez @ 2016-11-07 14:05 UTC (permalink / raw)
To: Daniel Thompson, Rob Herring, Mark Rutland, Russell King,
Maxime Coquelin, Alexandre Torgue, Michael Turquette,
Stephen Boyd, Nicolas Pitre, Arnd Bergmann, andrea.merello
Cc: devicetree, linux-arm-kernel, linux-kernel, linux-clk, kernel,
ludovic.barre, olivier.bideau, amelie.delaunay
In-Reply-To: <d60df94d-8f42-12eb-af55-2fc839c126bc@linaro.org>
Hi Daniel,
Thanks for reviewing.
On 11/07/2016 02:53 PM, Daniel Thompson wrote:
> On 07/11/16 13:05, gabriel.fernandez@st.com wrote:
>> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>>
>> This patch introduces PLL_I2S and PLL_SAI.
>> Vco clock of these PLLs can be modify by DT (only n multiplicator,
>> m divider is still fixed by the boot-loader).
>> Each PLL has 3 dividers. PLL should be off when we modify the rate.
>>
>> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
>> ---
>> drivers/clk/clk-stm32f4.c | 371
>> ++++++++++++++++++++++++++++++++++++++++++++--
>> 1 file changed, 359 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
>> index c2661e2..7641acd 100644
>> --- a/drivers/clk/clk-stm32f4.c
>> +++ b/drivers/clk/clk-stm32f4.c
>> @@ -28,6 +28,7 @@
> > ...
>> +static const struct clk_div_table pll_divp_table[] = {
>> + { 0, 2 }, { 1, 4 }, { 2, 6 }, { 3, 8 },
>> +};
>> +
>> /*
>> * Decode current PLL state and (statically) model the state we
>> inherit from
>> * the bootloader.
>> */
>
> This comment isn't right. For a start the model is no longer static.
>
you're right, i will suppress it.
>
>> @@ -615,18 +944,24 @@ struct stm32f4_clk_data {
>> const struct stm32f4_gate_data *gates_data;
>> const u64 *gates_map;
>> int gates_num;
>> + const struct stm32f4_pll_data *pll_data;
>> + int pll_num;
>
> pll_num is unused.
>
ok
BR
Gabriel
>
> Daniel.
^ permalink raw reply
* Re: [PATCH 3/6] clk: stm32f4: Add post divisor for I2S & SAI PLLs and Add lcd-tft clock
From: Daniel Thompson @ 2016-11-07 13:58 UTC (permalink / raw)
To: gabriel.fernandez, Rob Herring, Mark Rutland, Russell King,
Maxime Coquelin, Alexandre Torgue, Michael Turquette,
Stephen Boyd, Nicolas Pitre, Arnd Bergmann, andrea.merello
Cc: devicetree, linux-arm-kernel, linux-kernel, linux-clk, kernel,
ludovic.barre, olivier.bideau, amelie.delaunay
In-Reply-To: <1478523943-23142-4-git-send-email-gabriel.fernandez@st.com>
On 07/11/16 13:05, gabriel.fernandez@st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch adds post dividers of I2S & SAI PLLs.
> These dividers are managed by a dedicated register (RCC_DCKCFGR).
> The PLL should be off before a set rate.
> This patch also introduces the lcd-tft clock.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> drivers/clk/clk-stm32f4.c | 27 +++++++++++++++++++++++++--
> 1 file changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
> index dda15bc..5fa5d51 100644
> --- a/drivers/clk/clk-stm32f4.c
> +++ b/drivers/clk/clk-stm32f4.c
> @@ -215,6 +215,7 @@ struct stm32f4_gate_data {
> enum {
> SYSTICK, FCLK, CLK_LSI, CLK_LSE, CLK_HSE_RTC, CLK_RTC,
> PLL_VCO_I2S, PLL_VCO_SAI,
> + CLK_LCD,
> END_PRIMARY_CLK
> };
>
> @@ -599,6 +600,9 @@ static struct clk_hw *clk_register_pll_div(const char *name,
> static const struct clk_div_table pll_divp_table[] = {
> { 0, 2 }, { 1, 4 }, { 2, 6 }, { 3, 8 },
> };
> +static const struct clk_div_table pll_lcd_div_table[] = {
> + { 0, 2 }, { 1, 4 }, { 2, 8 }, { 3, 16 },
> +};
>
> /*
> * Decode current PLL state and (statically) model the state we inherit from
> @@ -659,16 +663,35 @@ static struct clk_hw *stm32f4_rcc_register_pll(const char *pllsrc,
> clk_register_pll_div(data->p_name, data->vco_name, 0, reg,
> 16, 2, 0, pll_divp_table, pll_hw, lock);
>
> - if (data->q_name)
> + if (data->q_name) {
> clk_register_pll_div(data->q_name, data->vco_name, 0, reg,
> 24, 4, CLK_DIVIDER_ONE_BASED, NULL,
> pll_hw, lock);
>
> - if (data->r_name)
> + if (data->pll_num == PLL_I2S)
> + clk_register_pll_div("plli2s-q-div", data->q_name,
> + 0, base + STM32F4_RCC_DCKCFGR,
> + 0, 5, 0, NULL, pll_hw, &stm32f4_clk_lock);
> +
> + if (data->pll_num == PLL_SAI)
> + clk_register_pll_div("pllsai-q-div", data->q_name,
> + 0, base + STM32F4_RCC_DCKCFGR,
> + 8, 5, 0, NULL, pll_hw, &stm32f4_clk_lock);
> + }
Shouldn't this be in the config structures?
It seems very odd to me to allow the config structures to control
whether we take the branch or not and then add these hard coded hacks.
Daniel.
^ permalink raw reply
* Re: [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver
From: Peter Griffin @ 2016-11-07 13:57 UTC (permalink / raw)
To: Bjorn Andersson
Cc: ohad, devicetree, kernel, vinod.koul, linux-remoteproc,
patrice.chotard, linux-kernel, dmaengine, lee.jones,
linux-arm-kernel
In-Reply-To: <20161103213703.GA15449@tuxbot>
Hi Bjorn,
On Thu, 03 Nov 2016, Bjorn Andersson wrote:
> On Tue 18 Oct 02:39 PDT 2016, Peter Griffin wrote:
>
> > slim core is used as a basis for many IPs in the STi
> > chipsets such as fdma and demux. To avoid duplicating
> > the elf loading code in each device driver a slim
> > rproc driver has been created.
> >
> > This driver is designed to be used by other device drivers
> > such as fdma, or demux whose IP is based around a slim core.
> > The device driver can call slim_rproc_alloc() to allocate
> > a slim rproc and slim_rproc_put() when finished.
> >
> > This driver takes care of ioremapping the slim
> > registers (dmem, imem, slimcore, peripherals), whose offsets
> > and sizes can change between IP's. It also obtains and enables
> > any clocks used by the device. This approach avoids having
> > a double mapping of the registers as slim_rproc does not register
> > its own platform device. It also maps well to device tree
> > abstraction as it allows us to have one dt node for the whole
> > device.
> >
> > All of the generic rproc elf loading code can be reused, and
> > we provide start() stop() hooks to start and stop the slim
> > core once the firmware has been loaded. This has been tested
> > successfully with fdma driver.
> >
> > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> > ---
> > drivers/remoteproc/Kconfig | 7 +-
> > drivers/remoteproc/Makefile | 1 +
> > drivers/remoteproc/st_slim_rproc.c | 364 +++++++++++++++++++++++++++++++
> > include/linux/remoteproc/st_slim_rproc.h | 58 +++++
> > 4 files changed, 428 insertions(+), 2 deletions(-)
> > create mode 100644 drivers/remoteproc/st_slim_rproc.c
> > create mode 100644 include/linux/remoteproc/st_slim_rproc.h
> >
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index f396bfe..9270c8e 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -58,7 +58,6 @@ config DA8XX_REMOTEPROC
> > tristate "DA8xx/OMAP-L13x remoteproc support"
> > depends on ARCH_DAVINCI_DA8XX
> > select CMA if MMU
> > - select REMOTEPROC
>
> No, this is an unrelated change to this patch.
Sorry that crept in as part of the rebase. Will fix.
>
> > select RPMSG_VIRTIO
> > help
> > Say y here to support DA8xx/OMAP-L13x remote processors via the
> > @@ -99,10 +98,10 @@ config QCOM_WCNSS_PIL
> > tristate "Qualcomm WCNSS Peripheral Image Loader"
> > depends on OF && ARCH_QCOM
> > depends on QCOM_SMEM
> > + depends on REMOTEPROC
> > select QCOM_MDT_LOADER
> > select QCOM_SCM
> > select QCOM_WCNSS_IRIS
> > - select REMOTEPROC
>
> Dito.
Will fix.
>
>
> As you now make changes to the entire remoteproc Kconfig file, rather
> than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> without providing Linus with a messy merge conflict.
>
> So the remoteproc parts now has to go through my tree.
OK, I think the best approach is for Vinod to create an immutable
branch with the entire fdma series on, and then both of you merge that branch into
your respective trees.
That way there won't be any conflicts and you can both accept further changes
for v4.9 release. Trying to take half the series via rproc, and half via dma trees won't work
because they have dependencies on each other.
I will send a v11 series in a moment which includes the feedback in this email
and also include the additional fixes which Vinod has applied since the driver
has been in linux-next.
>
> > help
> > Say y here to support the Peripheral Image Loader for the Qualcomm
> > Wireless Connectivity Subsystem.
> > @@ -116,4 +115,8 @@ config ST_REMOTEPROC
> > processor framework.
> > This can be either built-in or a loadable module.
> >
> > +config ST_SLIM_REMOTEPROC
> > + tristate
> > + select REMOTEPROC
> > +
> > endmenu
> [..]
> > diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
> [..]
> > +struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
> > + char *fw_name)
> > +{
> [..]
> > + rproc = rproc_alloc(dev, np->name, &slim_rproc_ops,
> > + fw_name, sizeof(*slim_rproc));
> [..]
> > + rproc_put(rproc);
>
> As of v4.9 you need to rproc_free() rather than rproc_put() to undo
> rproc_alloc().
Will fix.
regards,
Peter.
^ permalink raw reply
* Re: [PATCH 2/6] clk: stm32f4: SDIO & 48Mhz clock management for STM32F469 board
From: Daniel Thompson @ 2016-11-07 13:55 UTC (permalink / raw)
To: gabriel.fernandez-qxv4g6HH51o, Rob Herring, Mark Rutland,
Russell King, Maxime Coquelin, Alexandre Torgue,
Michael Turquette, Stephen Boyd, Nicolas Pitre, Arnd Bergmann,
andrea.merello-Re5JQEeQqe8AvxtiuMwx3w
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA, kernel-F5mvAk5X5gdBDgjK7y7TUQ,
ludovic.barre-qxv4g6HH51o, olivier.bideau-qxv4g6HH51o,
amelie.delaunay-qxv4g6HH51o
In-Reply-To: <1478523943-23142-3-git-send-email-gabriel.fernandez-qxv4g6HH51o@public.gmane.org>
On 07/11/16 13:05, gabriel.fernandez-qxv4g6HH51o@public.gmane.org wrote:
> From: Gabriel Fernandez <gabriel.fernandez-qxv4g6HH51o@public.gmane.org>
>
> In the stm32f469 soc, the 48Mhz clock could be derived from pll-q or
> from pll-sai-p.
>
> The SDIO clock could be also derived from 48Mhz or from sys clock.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez-qxv4g6HH51o@public.gmane.org>
> ---
> drivers/clk/clk-stm32f4.c | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
> index 7641acd..dda15bc 100644
> --- a/drivers/clk/clk-stm32f4.c
> +++ b/drivers/clk/clk-stm32f4.c
> @@ -199,7 +199,7 @@ struct stm32f4_gate_data {
> { STM32F4_RCC_APB2ENR, 8, "adc1", "apb2_div" },
> { STM32F4_RCC_APB2ENR, 9, "adc2", "apb2_div" },
> { STM32F4_RCC_APB2ENR, 10, "adc3", "apb2_div" },
> - { STM32F4_RCC_APB2ENR, 11, "sdio", "pll48" },
> + { STM32F4_RCC_APB2ENR, 11, "sdio", "sdmux" },
I'm confused. How do the "sdmux" clock come to exist on STM32F429?
> { STM32F4_RCC_APB2ENR, 12, "spi1", "apb2_div" },
> { STM32F4_RCC_APB2ENR, 13, "spi4", "apb2_div" },
> { STM32F4_RCC_APB2ENR, 14, "syscfg", "apb2_div" },
> @@ -940,6 +940,10 @@ static struct clk_hw *stm32_register_cclk(struct device *dev, const char *name,
> "no-clock", "lse", "lsi", "hse-rtc"
> };
>
> +static const char *pll48_parents[2] = { "pll-q", "pllsai-p" };
> +
> +static const char *sdmux_parents[2] = { "pll48", "sys" };
> +
> struct stm32f4_clk_data {
> const struct stm32f4_gate_data *gates_data;
> const u64 *gates_map;
> @@ -1109,6 +1113,18 @@ static void __init stm32f4_rcc_init(struct device_node *np)
> goto fail;
> }
>
> + if (of_device_is_compatible(np, "st,stm32f469-rcc")) {
> + clk_hw_register_mux_table(NULL, "pll48",
> + pll48_parents, ARRAY_SIZE(pll48_parents), 0,
> + base + STM32F4_RCC_DCKCFGR, 27, 1, 0, NULL,
> + &stm32f4_clk_lock);
> +
> + clk_hw_register_mux_table(NULL, "sdmux",
> + sdmux_parents, ARRAY_SIZE(sdmux_parents), 0,
> + base + STM32F4_RCC_DCKCFGR, 28, 1, 0, NULL,
> + &stm32f4_clk_lock);
> + }
> +
> of_clk_add_hw_provider(np, stm32f4_rcc_lookup_clk, NULL);
> return;
> fail:
>
--
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 1/6] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Daniel Thompson @ 2016-11-07 13:53 UTC (permalink / raw)
To: gabriel.fernandez, Rob Herring, Mark Rutland, Russell King,
Maxime Coquelin, Alexandre Torgue, Michael Turquette,
Stephen Boyd, Nicolas Pitre, Arnd Bergmann, andrea.merello
Cc: devicetree, amelie.delaunay, kernel, olivier.bideau, linux-kernel,
linux-arm-kernel, linux-clk, ludovic.barre
In-Reply-To: <1478523943-23142-2-git-send-email-gabriel.fernandez@st.com>
On 07/11/16 13:05, gabriel.fernandez@st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch introduces PLL_I2S and PLL_SAI.
> Vco clock of these PLLs can be modify by DT (only n multiplicator,
> m divider is still fixed by the boot-loader).
> Each PLL has 3 dividers. PLL should be off when we modify the rate.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> drivers/clk/clk-stm32f4.c | 371 ++++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 359 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
> index c2661e2..7641acd 100644
> --- a/drivers/clk/clk-stm32f4.c
> +++ b/drivers/clk/clk-stm32f4.c
> @@ -28,6 +28,7 @@
> ...
> +static const struct clk_div_table pll_divp_table[] = {
> + { 0, 2 }, { 1, 4 }, { 2, 6 }, { 3, 8 },
> +};
> +
> /*
> * Decode current PLL state and (statically) model the state we inherit from
> * the bootloader.
> */
This comment isn't right. For a start the model is no longer static.
> @@ -615,18 +944,24 @@ struct stm32f4_clk_data {
> const struct stm32f4_gate_data *gates_data;
> const u64 *gates_map;
> int gates_num;
> + const struct stm32f4_pll_data *pll_data;
> + int pll_num;
pll_num is unused.
Daniel.
^ permalink raw reply
* [PATCH] clk: qcom: fix semicolon.cocci warnings
From: kbuild test robot @ 2016-11-07 13:51 UTC (permalink / raw)
To: Ritesh Harjani
Cc: kbuild-all, ulf.hansson, linux-mmc, adrian.hunter, shawn.lin,
sboyd, devicetree, linux-clk, david.brown, andy.gross,
linux-arm-msm, georgi.djakov, alex.lemberg, mateusz.nowak,
Yuliy.Izrailov, asutoshd, kdorfman, david.griego, stummala,
venkatg, rnayak, pramod.gurav
In-Reply-To: <1478517877-23733-3-git-send-email-riteshh@codeaurora.org>
drivers/clk/qcom/clk-rcg2.c:306:2-3: Unneeded semicolon
drivers/clk/qcom/clk-rcg2.c:201:2-3: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Rajendra Nayak <rnayak@codeaurora.org>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
clk-rcg2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -198,7 +198,7 @@ static int _freq_tbl_determine_rate(stru
break;
default:
return -EINVAL;
- };
+ }
if (!f)
return -EINVAL;
@@ -303,7 +303,7 @@ static int __clk_rcg2_set_rate(struct cl
break;
default:
return -EINVAL;
- };
+ }
if (!f)
return -EINVAL;
^ permalink raw reply
* Re: [PATCH v6 02/14] clk: qcom: Add rcg ops to return floor value closest to the requested rate
From: kbuild test robot @ 2016-11-07 13:51 UTC (permalink / raw)
To: Ritesh Harjani
Cc: kbuild-all-JC7UmRfGjtg, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
adrian.hunter-ral2JQCrhuEAvxtiuMwx3w,
shawn.lin-TNX95d0MmH7DzftRWevZcw, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
david.brown-QSEj5FYQhm4dnm+yROfE0A,
andy.gross-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A,
alex.lemberg-XdAiOPVOjttBDgjK7y7TUQ,
mateusz.nowak-ral2JQCrhuEAvxtiuMwx3w,
Yuliy.Izrailov-XdAiOPVOjttBDgjK7y7TUQ,
asutoshd-sgV2jX0FEOL9JmXXK+q4OQ, kdorfman-sgV2jX0FEOL9JmXXK+q4OQ,
david.griego-QSEj5FYQhm4dnm+yROfE0A,
stummala-sgV2jX0FEOL9JmXXK+q4OQ, venkatg-sgV2jX0FEOL9JmXXK+q4OQ,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ,
pramod.gurav-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1478517877-23733-3-git-send-email-riteshh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4963 bytes --]
Hi Rajendra,
[auto build test WARNING on ulf.hansson-mmc/next]
[also build test WARNING on v4.9-rc4 next-20161028]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ritesh-Harjani/mmc-sdhci-msm-Add-clk-rates-DDR-HS400-support/20161107-203031
base: https://git.linaro.org/people/ulf.hansson/mmc next
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/clk/qcom/clk-rcg2.c: In function '_freq_tbl_determine_rate':
>> drivers/clk/qcom/clk-rcg2.c:192:2: warning: switch condition has boolean value [-Wswitch-bool]
switch (match) {
^~~~~~
drivers/clk/qcom/clk-rcg2.c: In function '__clk_rcg2_set_rate':
drivers/clk/qcom/clk-rcg2.c:297:2: warning: switch condition has boolean value [-Wswitch-bool]
switch (match) {
^~~~~~
coccinelle warnings: (new ones prefixed by >>)
>> drivers/clk/qcom/clk-rcg2.c:306:2-3: Unneeded semicolon
drivers/clk/qcom/clk-rcg2.c:201:2-3: Unneeded semicolon
Please review and possibly fold the followup patch.
vim +192 drivers/clk/qcom/clk-rcg2.c
186 {
187 unsigned long clk_flags, rate = req->rate;
188 struct clk_hw *p;
189 struct clk_rcg2 *rcg = to_clk_rcg2(hw);
190 int index;
191
> 192 switch (match) {
193 case FLOOR:
194 f = qcom_find_freq_floor(f, rate);
195 break;
196 case CEIL:
197 f = qcom_find_freq(f, rate);
198 break;
199 default:
200 return -EINVAL;
201 };
202
203 if (!f)
204 return -EINVAL;
205
206 index = qcom_find_src_index(hw, rcg->parent_map, f->src);
207 if (index < 0)
208 return index;
209
210 clk_flags = clk_hw_get_flags(hw);
211 p = clk_hw_get_parent_by_index(hw, index);
212 if (clk_flags & CLK_SET_RATE_PARENT) {
213 if (f->pre_div) {
214 rate /= 2;
215 rate *= f->pre_div + 1;
216 }
217
218 if (f->n) {
219 u64 tmp = rate;
220 tmp = tmp * f->n;
221 do_div(tmp, f->m);
222 rate = tmp;
223 }
224 } else {
225 rate = clk_hw_get_rate(p);
226 }
227 req->best_parent_hw = p;
228 req->best_parent_rate = rate;
229 req->rate = f->freq;
230
231 return 0;
232 }
233
234 static int clk_rcg2_determine_rate(struct clk_hw *hw,
235 struct clk_rate_request *req)
236 {
237 struct clk_rcg2 *rcg = to_clk_rcg2(hw);
238
239 return _freq_tbl_determine_rate(hw, rcg->freq_tbl, req, CEIL);
240 }
241
242 static int clk_rcg2_determine_floor_rate(struct clk_hw *hw,
243 struct clk_rate_request *req)
244 {
245 struct clk_rcg2 *rcg = to_clk_rcg2(hw);
246
247 return _freq_tbl_determine_rate(hw, rcg->freq_tbl, req, FLOOR);
248 }
249
250 static int clk_rcg2_configure(struct clk_rcg2 *rcg, const struct freq_tbl *f)
251 {
252 u32 cfg, mask;
253 struct clk_hw *hw = &rcg->clkr.hw;
254 int ret, index = qcom_find_src_index(hw, rcg->parent_map, f->src);
255
256 if (index < 0)
257 return index;
258
259 if (rcg->mnd_width && f->n) {
260 mask = BIT(rcg->mnd_width) - 1;
261 ret = regmap_update_bits(rcg->clkr.regmap,
262 rcg->cmd_rcgr + M_REG, mask, f->m);
263 if (ret)
264 return ret;
265
266 ret = regmap_update_bits(rcg->clkr.regmap,
267 rcg->cmd_rcgr + N_REG, mask, ~(f->n - f->m));
268 if (ret)
269 return ret;
270
271 ret = regmap_update_bits(rcg->clkr.regmap,
272 rcg->cmd_rcgr + D_REG, mask, ~f->n);
273 if (ret)
274 return ret;
275 }
276
277 mask = BIT(rcg->hid_width) - 1;
278 mask |= CFG_SRC_SEL_MASK | CFG_MODE_MASK;
279 cfg = f->pre_div << CFG_SRC_DIV_SHIFT;
280 cfg |= rcg->parent_map[index].cfg << CFG_SRC_SEL_SHIFT;
281 if (rcg->mnd_width && f->n && (f->m != f->n))
282 cfg |= CFG_MODE_DUAL_EDGE;
283 ret = regmap_update_bits(rcg->clkr.regmap,
284 rcg->cmd_rcgr + CFG_REG, mask, cfg);
285 if (ret)
286 return ret;
287
288 return update_config(rcg);
289 }
290
291 static int __clk_rcg2_set_rate(struct clk_hw *hw, unsigned long rate,
292 bool match)
293 {
294 struct clk_rcg2 *rcg = to_clk_rcg2(hw);
295 const struct freq_tbl *f;
296
297 switch (match) {
298 case FLOOR:
299 f = qcom_find_freq_floor(rcg->freq_tbl, rate);
300 break;
301 case CEIL:
302 f = qcom_find_freq(rcg->freq_tbl, rate);
303 break;
304 default:
305 return -EINVAL;
> 306 };
307
308 if (!f)
309 return -EINVAL;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56829 bytes --]
^ permalink raw reply
* [PATCH] ARM: tegra: apalis-tk1: Drop leading 0 from unit-address
From: Thierry Reding @ 2016-11-07 13:49 UTC (permalink / raw)
To: Thierry Reding
Cc: Rob Herring, Mark Rutland, Marcel Ziswiler,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
According to the latest best practices, unit-addresses should be
represented without any leading zeroes.
Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
arch/arm/boot/dts/tegra124-apalis.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra124-apalis.dtsi b/arch/arm/boot/dts/tegra124-apalis.dtsi
index e7a73db17613..0819721dda59 100644
--- a/arch/arm/boot/dts/tegra124-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra124-apalis.dtsi
@@ -1595,7 +1595,7 @@
clock-frequency = <400000>;
/* SGTL5000 audio codec */
- sgtl5000: codec@0a {
+ sgtl5000: codec@a {
compatible = "fsl,sgtl5000";
reg = <0x0a>;
VDDA-supply = <®_3v3>;
--
2.10.2
^ permalink raw reply related
* Re: [PATCH 3/6] clk: stm32f4: Add post divisor for I2S & SAI PLLs and Add lcd-tft clock
From: Radosław Pietrzyk @ 2016-11-07 13:48 UTC (permalink / raw)
To: Gabriel FERNANDEZ
Cc: Rob Herring, Mark Rutland, Russell King, Maxime Coquelin,
Alexandre Torgue, Michael Turquette, Stephen Boyd, Nicolas Pitre,
Arnd Bergmann, Daniel Thompson, Andrea Merello, devicetree,
amelie.delaunay, kernel, olivier.bideau, linux-kernel, linux-clk,
ludovic.barre, linux-arm-kernel
In-Reply-To: <1478523943-23142-4-git-send-email-gabriel.fernandez@st.com>
[-- Attachment #1: Type: text/plain, Size: 3387 bytes --]
Wouldn't it be good to connect ltdc gate clock with lcd-tft clock to enable
the whole LCD clock chain in once ?
2016-11-07 14:05 GMT+01:00 <gabriel.fernandez@st.com>:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch adds post dividers of I2S & SAI PLLs.
> These dividers are managed by a dedicated register (RCC_DCKCFGR).
> The PLL should be off before a set rate.
> This patch also introduces the lcd-tft clock.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> drivers/clk/clk-stm32f4.c | 27 +++++++++++++++++++++++++--
> 1 file changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
> index dda15bc..5fa5d51 100644
> --- a/drivers/clk/clk-stm32f4.c
> +++ b/drivers/clk/clk-stm32f4.c
> @@ -215,6 +215,7 @@ struct stm32f4_gate_data {
> enum {
> SYSTICK, FCLK, CLK_LSI, CLK_LSE, CLK_HSE_RTC, CLK_RTC,
> PLL_VCO_I2S, PLL_VCO_SAI,
> + CLK_LCD,
> END_PRIMARY_CLK
> };
>
> @@ -599,6 +600,9 @@ static struct clk_hw *clk_register_pll_div(const char
> *name,
> static const struct clk_div_table pll_divp_table[] = {
> { 0, 2 }, { 1, 4 }, { 2, 6 }, { 3, 8 },
> };
> +static const struct clk_div_table pll_lcd_div_table[] = {
> + { 0, 2 }, { 1, 4 }, { 2, 8 }, { 3, 16 },
> +};
>
> /*
> * Decode current PLL state and (statically) model the state we inherit
> from
> @@ -659,16 +663,35 @@ static struct clk_hw *stm32f4_rcc_register_pll(const
> char *pllsrc,
> clk_register_pll_div(data->p_name, data->vco_name, 0, reg,
> 16, 2, 0, pll_divp_table, pll_hw, lock);
>
> - if (data->q_name)
> + if (data->q_name) {
> clk_register_pll_div(data->q_name, data->vco_name, 0, reg,
> 24, 4, CLK_DIVIDER_ONE_BASED, NULL,
> pll_hw, lock);
>
> - if (data->r_name)
> + if (data->pll_num == PLL_I2S)
> + clk_register_pll_div("plli2s-q-div", data->q_name,
> + 0, base + STM32F4_RCC_DCKCFGR,
> + 0, 5, 0, NULL, pll_hw, &stm32f4_clk_lock);
> +
> + if (data->pll_num == PLL_SAI)
> + clk_register_pll_div("pllsai-q-div", data->q_name,
> + 0, base + STM32F4_RCC_DCKCFGR,
> + 8, 5, 0, NULL, pll_hw, &stm32f4_clk_lock);
> + }
> +
> + if (data->r_name) {
> clk_register_pll_div(data->r_name, data->vco_name, 0, reg,
> 28, 3, CLK_DIVIDER_ONE_BASED, NULL,
> pll_hw,
> lock);
>
> + if (data->pll_num == PLL_SAI)
> + clks[CLK_LCD] = clk_register_pll_div("lcd-tft",
> + data->r_name, CLK_SET_RATE_PARENT,
> + base + STM32F4_RCC_DCKCFGR, 16, 2,
> 0,
> + pll_lcd_div_table, pll_hw,
> + &stm32f4_clk_lock);
> + }
> +
> return pll_hw;
> }
>
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
[-- Attachment #2: Type: text/html, Size: 4779 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/3] ASoC/ARM: tegra: apalis t30/tk1/colibri t30: sgtl5000 audio
From: Thierry Reding @ 2016-11-07 13:42 UTC (permalink / raw)
To: Marcel Ziswiler
Cc: linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, devicetree@vger.kernel.org,
linux@armlinux.org.uk, gnurou@gmail.com, broonie@kernel.org,
mark.rutland@arm.com, prarit@redhat.com,
akpm@linux-foundation.org, tiwai@suse.com, lgirdwood@gmail.com,
ttynkkynen@nvidia.com, linux-arm-kernel@lists.infradead.org,
perex@perex.cz, alsa-devel
In-Reply-To: <1471355726.4197.6.camel@toradex.com>
[-- Attachment #1: Type: text/plain, Size: 2297 bytes --]
On Tue, Aug 16, 2016 at 01:55:28PM +0000, Marcel Ziswiler wrote:
> On Sun, 2016-06-19 at 02:59 +0200, Marcel Ziswiler wrote:
> > This series adds/integrates Freescale SGTL5000 analogue audio codec
> > support.
> >
> > Changes in v4:
> > - simple-audio-card does still not allow for more advanced use cases
> > like Tegra SoCs
> > - further platform drivers have been accepted since my last attempt
> > (e.g. rt5677 one)
> > - relevance for one further board the new Toradex Apalis TK1
> > - drop unused sound/jack.h include
> > - in tegra_sgtl5000_driver_remove() pass return value of
> > snd_soc_unregister_card() on to caller
> > - no longer set owner property in platform_driver to THIS_MODULE
> > - re-based/resend
> >
> > Changes in v3:
> > - revert to not using simple-audio-card being incompatible with tegra
> > - rebased to for-next
> >
> > Changes in v2:
> > - using simple-audio-card as suggested by Fabio
> >
> > Marcel Ziswiler (3):
> > ASoC: tegra: add tegra sgtl5000 machine driver
> > ARM: tegra: apalis/colibri t30: integrate audio
> > ARM: tegra: enable sgtl5000 audio
> >
> > .../bindings/sound/nvidia,tegra-audio-sgtl5000.txt | 42 ++++
> > arch/arm/boot/dts/tegra30-apalis.dtsi | 49 +++++
> > arch/arm/boot/dts/tegra30-colibri.dtsi | 49 +++++
> > arch/arm/configs/tegra_defconfig | 1 +
> > sound/soc/tegra/Kconfig | 11 ++
> > sound/soc/tegra/Makefile | 2 +
> > sound/soc/tegra/tegra_sgtl5000.c | 212
> > +++++++++++++++++++++
> > 7 files changed, 366 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/sound/nvidia,tegra-audio-
> > sgtl5000.txt
> > create mode 100644 sound/soc/tegra/tegra_sgtl5000.c
>
> With Mark finally having pulled the first patch of this series (https:/
> /lkml.org/lkml/2016/8/15/297) I'm wondering whether the second and
> third patch are now being pulled via tegra tree? Or should I rather re-
> submit those as a new v5 patch set?
Both patches applied now, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ 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