* 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] 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 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 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] 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 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 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 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 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 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 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 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 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 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 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
* [PATCH 0/3] arm64: dts: hisi: hip06 SAS device tree fixes
From: John Garry @ 2016-11-07 16:44 UTC (permalink / raw)
To: xuwei5
Cc: robh+dt, mark.rutland, will.deacon, catalin.marinas,
linux-arm-kernel, devicetree, linux-kernel, linuxarm, John Garry
This patchset resolves some hip06 SAS device tree issues.
John Garry (3):
arm64: dts: hisi: fix hip06 sas am-max-trans quirk
arm64: dts: hisi: disable sas0 and sas2 for d03
arm64: dts: hisi: add refclk node to hip06 dts files for SAS
arch/arm64/boot/dts/hisilicon/hip06-d03.dts | 8 --------
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 11 ++++++++++-
2 files changed, 10 insertions(+), 9 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/3] arm64: dts: hisi: fix hip06 sas am-max-trans quirk
From: John Garry @ 2016-11-07 16:44 UTC (permalink / raw)
To: xuwei5-C8/M+/jPZTeaMJb+Lgu22Q
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linuxarm-hv44wF8Li93QT0dZR+AlfA, John Garry
In-Reply-To: <1478537065-169286-1-git-send-email-john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
The string for the am max transmissions quirk property
is not correct -> fix it.
Signed-off-by: John Garry <john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Reviewed-by: Xiang Chen <chenxiang66-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
---
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index b548763..5330abb 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -590,7 +590,7 @@
reg = <0 0xa2000000 0 0x10000>;
sas-addr = [50 01 88 20 16 00 00 00];
hisilicon,sas-syscon = <&pcie_subctl>;
- am-max-trans;
+ hip06-sas-v2-quirk-amt;
ctrl-reset-reg = <0xa18>;
ctrl-reset-sts-reg = <0x5a0c>;
ctrl-clock-ena-reg = <0x318>;
--
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 2/3] arm64: dts: hisi: disable sas0 and sas2 for d03
From: John Garry @ 2016-11-07 16:44 UTC (permalink / raw)
To: xuwei5
Cc: robh+dt, mark.rutland, will.deacon, catalin.marinas,
linux-arm-kernel, devicetree, linux-kernel, linuxarm, John Garry
In-Reply-To: <1478537065-169286-1-git-send-email-john.garry@huawei.com>
The SAS nodes sas0 and sas2 are not available on d03, so
disable them.
Signed-off-by: John Garry <john.garry@huawei.com>
Acked-by: Xu Wei <xuwei5@hisilicon.com>
---
arch/arm64/boot/dts/hisilicon/hip06-d03.dts | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hip06-d03.dts b/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
index f54b283..7c4114a 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
+++ b/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
@@ -41,18 +41,10 @@
status = "ok";
};
-&sas0 {
- status = "ok";
-};
-
&sas1 {
status = "ok";
};
-&sas2 {
- status = "ok";
-};
-
&usb_ohci {
status = "ok";
};
--
1.9.1
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: hisi: add refclk node to hip06 dts files for SAS
From: John Garry @ 2016-11-07 16:44 UTC (permalink / raw)
To: xuwei5-C8/M+/jPZTeaMJb+Lgu22Q
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linuxarm-hv44wF8Li93QT0dZR+AlfA, John Garry
In-Reply-To: <1478537065-169286-1-git-send-email-john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
We will only maintain 1 dts for D03 and there are 50MHz
and 66MHz versions of D03: so we expect UEFI to update
refclk rate in the fdt at boot time.
Signed-off-by: John Garry <john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Reviewed-by: Xiang Chen <chenxiang66-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
---
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index 5330abb..7b40dce 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -318,6 +318,12 @@
#size-cells = <2>;
ranges;
+ refclk: refclk {
+ compatible = "fixed-clock";
+ clock-frequency = <50000000>;
+ #clock-cells = <0>;
+ };
+
usb_ohci: ohci@a7030000 {
compatible = "generic-ohci";
reg = <0x0 0xa7030000 0x0 0x10000>;
@@ -552,6 +558,7 @@
ctrl-reset-reg = <0xa60>;
ctrl-reset-sts-reg = <0x5a30>;
ctrl-clock-ena-reg = <0x338>;
+ clocks = <&refclk 0>;
queue-count = <16>;
phy-count = <8>;
dma-coherent;
@@ -594,6 +601,7 @@
ctrl-reset-reg = <0xa18>;
ctrl-reset-sts-reg = <0x5a0c>;
ctrl-clock-ena-reg = <0x318>;
+ clocks = <&refclk 0>;
queue-count = <16>;
phy-count = <8>;
dma-coherent;
@@ -635,6 +643,7 @@
ctrl-reset-reg = <0xae0>;
ctrl-reset-sts-reg = <0x5a70>;
ctrl-clock-ena-reg = <0x3a8>;
+ clocks = <&refclk 0>;
queue-count = <16>;
phy-count = <9>;
dma-coherent;
--
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
* Re: [PATCH v3 1/8] iio:core: add a callback to allow drivers to provide _available attributes
From: Slawomir Stepien @ 2016-11-07 16:46 UTC (permalink / raw)
To: Peter Rosin
Cc: Daniel Baluta, Linux Kernel Mailing List, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Rob Herring, Mark Rutland, linux-iio@vger.kernel.org,
Devicetree List
In-Reply-To: <62f150ba-abc0-8e45-1355-8a61354ee3e1@axentia.se>
On Nov 07, 2016 12:57, Peter Rosin wrote:
> On 2016-11-07 12:37, Daniel Baluta wrote:
> > On Mon, Oct 24, 2016 at 1:39 AM, Peter Rosin <peda@axentia.se> wrote:
> >> From: Jonathan Cameron <jic23@kernel.org>
> >>
> >> A large number of attributes can only take a limited range of values.
> >> Currently in IIO this is handled by directly registering additional
> >> *_available attributes thus providing this information to userspace.
> >>
> >> It is desirable to provide this information via the core for much the same
> >> reason this was done for the actual channel information attributes in the
> >> first place. If it isn't there, then it can only really be accessed from
> >> userspace. Other in kernel IIO consumers have no access to what valid
> >> parameters are.
> >>
> >> Two forms are currently supported:
> >> * list of values in one particular IIO_VAL_* format.
> >> e.g. 1.300000 1.500000 1.730000
> >> * range specification with a step size:
> >> e.g. [1.000000 0.500000 2.500000]
> >> equivalent to 1.000000 1.5000000 2.000000 2.500000
> >
> > Is there any driver using this format? :)
>
> Yes, soon. Hopefully. See patch 3/8
> iio: mcp4531: provide range of available raw values
> https://patchwork.kernel.org/patch/9391283/
I would also like to add this to mcp4131.c and ds1803.c.
--
Slawomir Stepien
^ permalink raw reply
* Re: [v17 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
From: Matthias Brugger @ 2016-11-07 16:53 UTC (permalink / raw)
To: Daniel Kurtz
Cc: Enric Balletbo Serra, Jitao Shi, David Airlie, Thierry Reding,
Mark Rutland, stonea168-9Onoh4P/yGk, dri-devel, Andy Yan,
Ajay Kumar, Vincent Palatin, cawa cheng,
Bibby Hsieh (謝濟遠),
CK Hu (胡俊光), Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Sascha Hauer,
Pawel Moll, Ian Campbell
In-Reply-To: <CAGS+omDmFdqzuFqcCe9gFGemZc88Yt0_3_o2KwOgW=GN_kCakQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 05/11/16 00:21, Daniel Kurtz wrote:
> On Tue, Oct 25, 2016 at 6:23 AM, Matthias Brugger
> <matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>> On 10/18/2016 04:37 PM, Enric Balletbo Serra wrote:
>> [...]
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
>> [...]
>>>>
>>>> +
>>>> +/* Firmware */
>>>> +#define PS_FW_NAME "ps864x_fw.bin"
>>>> +
>>>
>>> From where I can download this firmware image?
>>
>> I suppose this FW bits have to be added to linux-firmware repository first, before this patch can be accepted.
>
> All PS8640 devices should already ship with working firmware.
> The firmware update procedure is only used in the unlikely event where
> one wants to update the bridge to a different firmware provided by
> Parade.
>
> Why must the lack of firmware really block landing this driver?
>
> If this is really so, can we just land the functional part of the
> driver first, and add the firmware update in a follow-up patch.
>
After checking other users of request_firmware and check them against
linux-firmware I think we don't need the FW in linux-firmware to get the
driver merged. Especially as there already is a working FW stored on the
device.
Regards,
Matthias
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: Add Broadcom Northstar2 device tree entries for PDC driver.
From: Florian Fainelli @ 2016-11-07 17:06 UTC (permalink / raw)
To: Rob Rice, Jassi Brar, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Ray Jui, Scott Branden,
Jon Mason, Florian Fainelli, Anup Patel, Catalin Marinas,
Will Deacon, Rob Rice
In-Reply-To: <1467316764-19686-4-git-send-email-rob.rice-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On 06/30/2016 12:59 PM, Rob Rice wrote:
> From: Rob Rice <rrice-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>
> Add Broadcom Northstar2 SoC device tree entries for PDC driver.
>
> Signed-off-by: Rob Rice <rob.rice-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Ray Jui <ray.jui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Applied, thanks Rob!
--
Florian
--
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: [REGRESSION] "console: don't prefer first registered if DT specifies stdout-path" breaks console on video outputs of various ARM boards
From: Paul Burton @ 2016-11-07 17:16 UTC (permalink / raw)
To: Hans de Goede
Cc: Linus Torvalds, Andrew Morton, Rob Herring, Frank Rowand,
Thorsten Leemhuis, Greg Kroah-Hartman, Tejun Heo, devicetree,
linux-kernel
In-Reply-To: <cf275db8-6d2b-c891-9280-f141c6f10733@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2849 bytes --]
Hi Hans,
On Sunday, 6 November 2016 11:54:35 GMT Hans de Goede wrote:
> > What I see in my systems, and what 05fd007e4629 ("console: don't prefer
> > first registered if DT specifies stdout-path") addressed, is that if
> > there are for example 2 UARTs uart0 & uart1 that are probed in that order
> > and stdout-path indicates that we should use uart1 we wind up essentially
> > ignoring it because>
> > the ordering of the relevant calls goes:
> > - of_console_check() for uart0
> > - add_preferred_console() for uart0
> > - register_console() for uart0
> > - of_console_check() for uart1
> > - add_preferred_console() for uart1
> > - register_console() for uart1
> >
> > Since of_check_console() doesn't get called for uart1 until after uart0
> > has
> > been probed, we don't add an entry for it to the console_cmdline array
> > until after register_console() has already decided to enable uart0
> > because preferred_console == -1.
> >
> > I'm not the only one seeing this oddity either, for example see the
> > discussion on this patch:
> >
> > https://patchwork.kernel.org/patch/9263753/
> >
> > By simply reverting my patch you restore us to a position where so far as
> > I
> > can see we simply do not honor stdout-path for the real kernel console.
>
> As said before, we do still honor it, but in your probe example we also get
> a (second) serial console on uart0, where as you only want one on uart1.
...but don't we only support one console per type of device? That's what
Documentation/serial-console.txt says anyway, which means having a console on
both uart0 & uart1 does not work. I could live with having console output on
an extra UART, but that's not what I was seeing when I wrote this patch.
> So I see a few possible solutions here:
>
> 1) Do a new version of your patch which changes the "&&
> !of_specified_console" check to "&& (newcon == tty0 ||
> !of_specified_console)", then we would still always register tty0 (as long
> as it gets registered first, just like now) and we would not register uart0
> in your above example, note the "newcon == tty0" check in my example is
> pseudo-code. I would be happy to try out such a patch
>
> 2) Add a new dt property to enable the new behavior you seek
>
> I'm myself tending towards 1 as a better solution: treat tty0 special,
> because some existing setups rely on it always being registered as a
> console even if stdout-path is specified and otherwise always honor
> stdout-path.
>
> Regards,
>
> Hans
That does feel a little hack-ish to me though... I don't like the reliance on
probe ordering, nor special casing tty0 in general.
In any case I don't think I have the time to unpick all this at the moment, so
I suggest we go ahead with your revert for now & I'll revisit the system I was
working on when I find the time.
Thanks,
Paul
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 3/6] clk: Add driver for Maxim-8997 PMIC clocks
From: Pankaj Dubey @ 2016-11-07 17:20 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-samsung-soc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA,
thomas.ab-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org, Kukjin Kim,
Michael Turquette, Krzysztof Kozlowski, Rob Herring,
myungjoo.ham-Sze3O3UU22JBDgjK7y7TUQ,
linux-clk-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <63750c2f-35cb-91ab-276b-c788f51081cb-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
Hi Javier,
On 7 November 2016 at 20:31, Javier Martinez Canillas
<javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
> 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-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> CC: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> CC: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> CC: linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Signed-off-by: Pankaj Dubey <pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>> ---
>
> What kernel version are you basing this on? The Maxim common clock code
This patch series, I have prepared on Krzysztof's for-next which is 4.9-rc1,
> 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.
>
I was not aware of this change. I will check this and if I can
reuse/extend max77686 for 8997 I will do it.
Thanks,
Pankaj Dubey
> Best regards,
> --
> Javier Martinez Canillas
> Open Source Group
> Samsung Research America
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 v2 0/3] Venus remoteproc driver
From: Stanimir Varbanov @ 2016-11-07 17:30 UTC (permalink / raw)
To: Ohad Ben-Cohen, Bjorn Andersson, Stephen Boyd, Andy Gross,
Rob Herring, Mark Rutland
Cc: Srinivas Kandagatla, linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Stanimir Varbanov
Hi,
here is v2 of the Venus remoteproc driver, the changes are:
- removed page table size and page table init SCM calls.
regards,
Stan
Stanimir Varbanov (3):
firmware: qcom: scm: add a video command for state setting
dt-binding: remoteproc: venus rproc dt binding document
remoteproc: qcom: add Venus video core firmware loader driver
.../devicetree/bindings/remoteproc/qcom,venus.txt | 33 ++++
drivers/firmware/qcom_scm-32.c | 18 ++
drivers/firmware/qcom_scm-64.c | 16 ++
drivers/firmware/qcom_scm.c | 16 ++
drivers/firmware/qcom_scm.h | 2 +
drivers/remoteproc/Kconfig | 12 ++
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/qcom_venus_pil.c | 213 +++++++++++++++++++++
include/linux/qcom_scm.h | 2 +
9 files changed, 313 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
create mode 100644 drivers/remoteproc/qcom_venus_pil.c
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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