* Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output
From: Florian Vaussard @ 2014-02-25 7:54 UTC (permalink / raw)
To: Javier Martinez Canillas, Russell King - ARM Linux,
Tomi Valkeinen
Cc: Benoît Cousson, Tony Lindgren, devicetree@vger.kernel.org,
linux-omap@vger.kernel.org, Ash Charles,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CABxcv=kKxidVJWcMrueB+edW=g_6gcucvi6=7p=EZ_WooCpbMA@mail.gmail.com>
Hi Russell, Javier,
On 02/24/2014 09:22 PM, Javier Martinez Canillas wrote:
> Hi Russell,
>
> On Mon, Feb 24, 2014 at 3:03 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Mon, Feb 24, 2014 at 06:07:49PM +0100, Florian Vaussard wrote:
>>> + hdmi0: connector@0 {
>>> + compatible = "hdmi-connector";
>>
>> This looks way to generic a compatible string. Are you sure it's
>> correct?
>>
>
> That compatible string is correct according to the latest series
> posted by Tomi Valkeinen to add DT bindings for the OMAP Display
> SubSystem (DSS) [0].
>
Indeed, this compatible string comes from the DSS series.
> The property is added on this patch [1] and as far as I understood the
> idea is that it could be a generic DT binding that can be used by
> platform specific HDMI connectors like the omap dss HDMI connector
> [2].
>
On the other side, looking at
drivers/video/omap2/displays-new/connector-hdmi.c from the DSS series
[1], the compatible string is "omapdss,hdmi-connector", which makes me
wonder which one should be used :) BTW, "omapdss" seems a strange
prefix, isn't it?
Tomi, any inputs?
Regards,
Florian
[1]
https://git.kernel.org/cgit/linux/kernel/git/tomba/linux.git/tree/drivers/video/omap2/displays-new/connector-hdmi.c?h=work/dss-dt-review-3
^ permalink raw reply
* Re: [PATCH 1/2] clk: ti: am335x: remove unecessary cpu0 clk node
From: Mike Turquette @ 2014-02-25 8:24 UTC (permalink / raw)
To: Benoît Cousson, Tony Lindgren
Cc: Tero Kristo, linux-omap, devicetree, linux-arm-kernel,
linux-kernel, Nishanth Menon
In-Reply-To: <1391019557-22313-2-git-send-email-nm@ti.com>
Quoting Nishanth Menon (2014-01-29 10:19:16)
> cpu0 clock node has no functionality, since cpufreq-cpu0 is already
> capable of picking up the clock from dts.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
Taken into clk-next!
Regards,
Mike
> ---
> drivers/clk/ti/clk-33xx.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/clk/ti/clk-33xx.c b/drivers/clk/ti/clk-33xx.c
> index 776ee45..028b337 100644
> --- a/drivers/clk/ti/clk-33xx.c
> +++ b/drivers/clk/ti/clk-33xx.c
> @@ -34,7 +34,6 @@ static struct ti_dt_clk am33xx_clks[] = {
> DT_CLK(NULL, "dpll_core_m5_ck", "dpll_core_m5_ck"),
> DT_CLK(NULL, "dpll_core_m6_ck", "dpll_core_m6_ck"),
> DT_CLK(NULL, "dpll_mpu_ck", "dpll_mpu_ck"),
> - DT_CLK("cpu0", NULL, "dpll_mpu_ck"),
> DT_CLK(NULL, "dpll_mpu_m2_ck", "dpll_mpu_m2_ck"),
> DT_CLK(NULL, "dpll_ddr_ck", "dpll_ddr_ck"),
> DT_CLK(NULL, "dpll_ddr_m2_ck", "dpll_ddr_m2_ck"),
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [PATCH v8 06/14] CLK: TI: OMAP3: Get rid of unused USB Host dummy clocks
From: Mike Turquette @ 2014-02-25 8:43 UTC (permalink / raw)
To: tony, bcousson, lee.jones
Cc: balbi, nm, khilman, linux-omap, linux-arm-kernel, linux-kernel,
devicetree, linux-usb, Roger Quadros, Tero Kristo
In-Reply-To: <1392896409-5101-7-git-send-email-rogerq@ti.com>
Quoting Roger Quadros (2014-02-20 03:40:01)
> The OMAP USB Host MFD driver no longer expects these non-existing
> clocks from the OMAP3 platform, so get rid of them.
Looks good to me.
Regards,
Mike
>
> CC: Tero Kristo <t-kristo@ti.com>
> CC: Mike Turquette <mturquette@linaro.org>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
> arch/arm/mach-omap2/cclock3xxx_data.c | 4 ----
> drivers/clk/ti/clk-3xxx.c | 4 ----
> 2 files changed, 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
> index 3b05aea..4299a55 100644
> --- a/arch/arm/mach-omap2/cclock3xxx_data.c
> +++ b/arch/arm/mach-omap2/cclock3xxx_data.c
> @@ -3495,10 +3495,6 @@ static struct omap_clk omap3xxx_clks[] = {
> CLK(NULL, "dss_tv_fck", &dss_tv_fck),
> CLK(NULL, "dss_96m_fck", &dss_96m_fck),
> CLK(NULL, "dss2_alwon_fck", &dss2_alwon_fck),
> - CLK(NULL, "utmi_p1_gfclk", &dummy_ck),
> - CLK(NULL, "utmi_p2_gfclk", &dummy_ck),
> - CLK(NULL, "xclk60mhsp1_ck", &dummy_ck),
> - CLK(NULL, "xclk60mhsp2_ck", &dummy_ck),
> CLK(NULL, "init_60m_fclk", &dummy_ck),
> CLK(NULL, "gpt1_fck", &gpt1_fck),
> CLK(NULL, "aes2_ick", &aes2_ick),
> diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
> index d323023..0d1750a 100644
> --- a/drivers/clk/ti/clk-3xxx.c
> +++ b/drivers/clk/ti/clk-3xxx.c
> @@ -130,10 +130,6 @@ static struct ti_dt_clk omap3xxx_clks[] = {
> DT_CLK(NULL, "dss_tv_fck", "dss_tv_fck"),
> DT_CLK(NULL, "dss_96m_fck", "dss_96m_fck"),
> DT_CLK(NULL, "dss2_alwon_fck", "dss2_alwon_fck"),
> - DT_CLK(NULL, "utmi_p1_gfclk", "dummy_ck"),
> - DT_CLK(NULL, "utmi_p2_gfclk", "dummy_ck"),
> - DT_CLK(NULL, "xclk60mhsp1_ck", "dummy_ck"),
> - DT_CLK(NULL, "xclk60mhsp2_ck", "dummy_ck"),
> DT_CLK(NULL, "init_60m_fclk", "dummy_ck"),
> DT_CLK(NULL, "gpt1_fck", "gpt1_fck"),
> DT_CLK(NULL, "aes2_ick", "aes2_ick"),
> --
> 1.8.3.2
>
^ permalink raw reply
* Re: [PATCH] pinctrl: add pinctrl driver for imx6sx
From: Linus Walleij @ 2014-02-25 8:43 UTC (permalink / raw)
To: Anson.Huang@freescale.com
Cc: Shawn Guo, kernel@pengutronix.de, dong.aisheng@linaro.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <dda7bce900ca4b358d1ed6f167f60940@BY2PR03MB315.namprd03.prod.outlook.com>
On Wed, Feb 19, 2014 at 9:43 AM, Anson.Huang@freescale.com
<Anson.Huang@freescale.com> wrote:
> Hi, Shawn
>
> OK, I will hold on these patches until Freescale announce this SOC, please ignore the dts patches as well.
OK just don't hold back stuff for too long, usually this kind of infrastructure
needs to go in as early as possible (with clocks and regulators...)
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v8 03/14] mfd: omap-usb-host: Use clock names as per function for reference clocks
From: Lee Jones @ 2014-02-25 8:52 UTC (permalink / raw)
To: Roger Quadros
Cc: tony, bcousson, balbi, nm, khilman, linux-omap, linux-arm-kernel,
linux-kernel, devicetree, linux-usb, Samuel Ortiz
In-Reply-To: <1392896409-5101-4-git-send-email-rogerq@ti.com>
> Use a meaningful name for the reference clocks so that it indicates the function.
>
> CC: Lee Jones <lee.jones@linaro.org>
> CC: Samuel Ortiz <sameo@linux.intel.com>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
> drivers/mfd/omap-usb-host.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> index 865c276..651e249 100644
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -718,24 +718,24 @@ static int usbhs_omap_probe(struct platform_device *pdev)
> goto err_mem;
> }
>
> - omap->xclk60mhsp1_ck = devm_clk_get(dev, "xclk60mhsp1_ck");
> + omap->xclk60mhsp1_ck = devm_clk_get(dev, "refclk_60m_ext_p1");
> if (IS_ERR(omap->xclk60mhsp1_ck)) {
> ret = PTR_ERR(omap->xclk60mhsp1_ck);
> - dev_err(dev, "xclk60mhsp1_ck failed error:%d\n", ret);
> + dev_err(dev, "refclk_60m_ext_p1 failed error:%d\n", ret);
> goto err_mem;
> }
Will anything break if I were to apply the MFD patches seperately?
> - omap->xclk60mhsp2_ck = devm_clk_get(dev, "xclk60mhsp2_ck");
> + omap->xclk60mhsp2_ck = devm_clk_get(dev, "refclk_60m_ext_p2");
> if (IS_ERR(omap->xclk60mhsp2_ck)) {
> ret = PTR_ERR(omap->xclk60mhsp2_ck);
> - dev_err(dev, "xclk60mhsp2_ck failed error:%d\n", ret);
> + dev_err(dev, "refclk_60m_ext_p2 failed error:%d\n", ret);
> goto err_mem;
> }
>
> - omap->init_60m_fclk = devm_clk_get(dev, "init_60m_fclk");
> + omap->init_60m_fclk = devm_clk_get(dev, "refclk_60m_int");
> if (IS_ERR(omap->init_60m_fclk)) {
> ret = PTR_ERR(omap->init_60m_fclk);
> - dev_err(dev, "init_60m_fclk failed error:%d\n", ret);
> + dev_err(dev, "refclk_60m_int failed error:%d\n", ret);
> goto err_mem;
> }
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v8 03/14] mfd: omap-usb-host: Use clock names as per function for reference clocks
From: Roger Quadros @ 2014-02-25 9:02 UTC (permalink / raw)
To: Lee Jones, tony, bcousson
Cc: nm, devicetree, khilman, Samuel Ortiz, linux-usb, linux-kernel,
balbi, linux-omap, linux-arm-kernel
In-Reply-To: <20140225085234.GB19099@lee--X1>
Hi,
On 02/25/2014 10:52 AM, Lee Jones wrote:
>> Use a meaningful name for the reference clocks so that it indicates the function.
>>
>> CC: Lee Jones <lee.jones@linaro.org>
>> CC: Samuel Ortiz <sameo@linux.intel.com>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>> drivers/mfd/omap-usb-host.c | 12 ++++++------
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index 865c276..651e249 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -718,24 +718,24 @@ static int usbhs_omap_probe(struct platform_device *pdev)
>> goto err_mem;
>> }
>>
>> - omap->xclk60mhsp1_ck = devm_clk_get(dev, "xclk60mhsp1_ck");
>> + omap->xclk60mhsp1_ck = devm_clk_get(dev, "refclk_60m_ext_p1");
>> if (IS_ERR(omap->xclk60mhsp1_ck)) {
>> ret = PTR_ERR(omap->xclk60mhsp1_ck);
>> - dev_err(dev, "xclk60mhsp1_ck failed error:%d\n", ret);
>> + dev_err(dev, "refclk_60m_ext_p1 failed error:%d\n", ret);
>> goto err_mem;
>> }
>
> Will anything break if I were to apply the MFD patches seperately?
>
Nothing will break for OMAP3, but OMAP4 USB host will break (e.g. Panda board).
OMAP5 USB host was never working so it doesn't matter there.
To make sure nothing breaks, we need at least these 2 patches to go in together with mfd changes.
[PATCH v8 08/14] ARM: dts: omap4: Update omap-usb-host node
[PATCH v8 09/14] ARM: dts: omap5: Update omap-usb-host node
Any suggestions about how we can proceed?
cheers,
-roger
>> - omap->xclk60mhsp2_ck = devm_clk_get(dev, "xclk60mhsp2_ck");
>> + omap->xclk60mhsp2_ck = devm_clk_get(dev, "refclk_60m_ext_p2");
>> if (IS_ERR(omap->xclk60mhsp2_ck)) {
>> ret = PTR_ERR(omap->xclk60mhsp2_ck);
>> - dev_err(dev, "xclk60mhsp2_ck failed error:%d\n", ret);
>> + dev_err(dev, "refclk_60m_ext_p2 failed error:%d\n", ret);
>> goto err_mem;
>> }
>>
>> - omap->init_60m_fclk = devm_clk_get(dev, "init_60m_fclk");
>> + omap->init_60m_fclk = devm_clk_get(dev, "refclk_60m_int");
>> if (IS_ERR(omap->init_60m_fclk)) {
>> ret = PTR_ERR(omap->init_60m_fclk);
>> - dev_err(dev, "init_60m_fclk failed error:%d\n", ret);
>> + dev_err(dev, "refclk_60m_int failed error:%d\n", ret);
>> goto err_mem;
>> }
>>
>
^ permalink raw reply
* Re: [PATCH v2 0/6] ARM: STi reset controller support
From: srinivas kandagatla @ 2014-02-25 9:08 UTC (permalink / raw)
To: Philipp Zabel
Cc: Maxime Coquelin, Mark Rutland, devicetree, Russell King, kernel,
Pawel Moll, Ian Campbell, Olof Johansson, linux-doc, linux-kernel,
stephen.gallimore, Rob Herring, Arnd Bergmann, Rob Landley,
Kumar Gala, Grant Likely, linux-arm-kernel
In-Reply-To: <1393254982.3091.44.camel@pizza.hi.pengutronix.de>
On 24/02/14 15:16, Philipp Zabel wrote:
> Hi Srinivas,
>
> Am Montag, den 24.02.2014, 14:03 +0000 schrieb srinivas kandagatla:
>> Thanks Philipp for your comments,
>>
>> On 24/02/14 10:33, Philipp Zabel wrote:
>>>>> Did Srini's explanations convinced you?
>>>>>
>>>>> If so, could you queue the series for v3.15?
>>> to be honest, I'm not comfortable with this explanation. If the
>>> "powerdown" bits only gate the clocks to those modules, calling it a
>>> reset control is clearly the wrong abstraction. If that is the case,
>>> couldn't you handle those bits via the clock framework?
>> I just had a re-look at the IPs specs for more information on where
>> these power-down signals are actually terminating on the IP side.
>>
>> For example: ST-Synopsis Ethernet GMAC IP has two pins
>> power_down_req[IN] and power_down_ack[OUT]. power_down_req is used by
>> the software to either put the IP in powerdown or bring it out of
>> powerdown state.
>
> Now I'm a bit confused. There is no mention of GMAC in your patches,
> and for ETH[01] they contain only the SOFTRESET bits. I have no issue
> with the SOFTRESETs.
Yes, GMAC was a bad example indeed. However this same logic applies to
the USB IP as well.
GMAC power-down-reset can be added to the power-down-reset list for
consistency.
We did not define the power-down-reset for GMAC because the reset state
of GMAC will not be in power down. softreset should be enough to bring
the IP in to a usable state. So the software never drives the power
down-request but instead uses softreset in this particular case.
>
>> The IP itself drives power_down_ack to indicate when the power down
>> request is successfully finished. For power_down/power_up request the IP
>> will change the internal state accordingly including powering up/down
>> its internal blocks and/or clock gating.
>>
>>> If on the other hand these powerdown bits also trigger reset machinery,
>>> such that asserting and deasserting that bit will change the module's
>>> internal state, I could be convinced to queue them like this.
>> This is true with ST IPs, these lines change the state of the IP as
>> described above. Reset framework seems to fits in very well with this
>> behavior rather than power-domains or clock framework.
>
> If you put the IP in power down when it is idle, and then power it up
> again, will the IP registers have kept their previous state?
No, the context is lost, the IP needs re-initialization.
Thanks,
srini
>
> regards
> Philipp
>
>
>
^ permalink raw reply
* Re: [PATCH 2/4] net: rfkill: gpio: remove gpio names
From: Linus Walleij @ 2014-02-25 9:13 UTC (permalink / raw)
To: Stephen Warren, Alexandre Courbot, Grant Likely,
devicetree@vger.kernel.org
Cc: Chen-Yu Tsai, Heikki Krogerus, Johannes Berg, David S. Miller,
Rhyland Klein, linux-wireless, netdev, linux-kernel,
Arnd Bergmann, Mark Gross
In-Reply-To: <5306E599.7020605@wwwdotorg.org>
On Fri, Feb 21, 2014 at 6:35 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 02/20/2014 06:55 PM, Chen-Yu Tsai wrote:
>> That's correct. However using con_id to pass this results in different
>> behavior across DT and ACPI. A better way is to export the labeling
>> function so consumers can set meaningful labels themselves.
>
> But this code is the consumer of those GPIOs. IF the parameter to
> devm_gpiod_get_index() isn't intended to be used, why does it exist?
Kerneldoc says:
/**
* gpiod_get_index - obtain a GPIO from a multi-index GPIO function
* @dev: GPIO consumer, can be NULL for system-global GPIOs
* @con_id: function within the GPIO consumer
* @idx: index of the GPIO to obtain in the consumer
*
Basically it is just exposing the fact that of_find_gpio() and
acpi_find_gpio() both take a con_id as argument.
If we drill into this, we find that it is used to conjure the
arbitrary string before the gpios in the DT case, like:
foo-gpios = <...>;
As in tegra30-beaver.dts...
sdhci@78000000 {
status = "okay";
cd-gpios = <&gpio TEGRA_GPIO(I, 5) GPIO_ACTIVE_LOW>;
wp-gpios = <&gpio TEGRA_GPIO(T, 3) GPIO_ACTIVE_HIGH>;
power-gpios = <&gpio TEGRA_GPIO(D, 7) GPIO_ACTIVE_HIGH>;
bus-width = <4>;
};
Instead of passing the GPIOs as index 0,1,2 they are named
and I do admit this has a nice "things are under control" aspect
to it.
In the ACPI case the con_id is not used for anything.
So it is basically there to satisfy the habit in some device
tree bindings to name gpio arrays instead of just passing gpios = <...>;
(The latter should be encouraged going forward.)
As DT is ABI we need to keep this forever, and driver may need to
look for foo-gpios=<> and gpios=<> alike for backward compatibility
if we'd change it, sweet isn't it? :-)
I don't quite like this, as it is adding stupid nonsens arguments for
ACPI GPIO producers (which only take an index AFAICT), but it is a
first sacrifice on the altar of trying to mask the differences between DT
and ACPI probe paths about which I have mixed feelings.
Yours,
LInus Walleij
^ permalink raw reply
* Re: [PATCH v8 03/14] mfd: omap-usb-host: Use clock names as per function for reference clocks
From: Lee Jones @ 2014-02-25 9:18 UTC (permalink / raw)
To: Roger Quadros
Cc: tony, bcousson, balbi, nm, khilman, linux-omap, linux-arm-kernel,
linux-kernel, devicetree, linux-usb, Samuel Ortiz
In-Reply-To: <530C5C29.1090503@ti.com>
> >> Use a meaningful name for the reference clocks so that it indicates the function.
> >>
> >> CC: Lee Jones <lee.jones@linaro.org>
> >> CC: Samuel Ortiz <sameo@linux.intel.com>
> >> Signed-off-by: Roger Quadros <rogerq@ti.com>
> >> ---
> >> drivers/mfd/omap-usb-host.c | 12 ++++++------
> >> 1 file changed, 6 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> >> index 865c276..651e249 100644
> >> --- a/drivers/mfd/omap-usb-host.c
> >> +++ b/drivers/mfd/omap-usb-host.c
> >> @@ -718,24 +718,24 @@ static int usbhs_omap_probe(struct platform_device *pdev)
> >> goto err_mem;
> >> }
> >>
> >> - omap->xclk60mhsp1_ck = devm_clk_get(dev, "xclk60mhsp1_ck");
> >> + omap->xclk60mhsp1_ck = devm_clk_get(dev, "refclk_60m_ext_p1");
> >> if (IS_ERR(omap->xclk60mhsp1_ck)) {
> >> ret = PTR_ERR(omap->xclk60mhsp1_ck);
> >> - dev_err(dev, "xclk60mhsp1_ck failed error:%d\n", ret);
> >> + dev_err(dev, "refclk_60m_ext_p1 failed error:%d\n", ret);
> >> goto err_mem;
> >> }
> >
> > Will anything break if I were to apply the MFD patches seperately?
> >
>
> Nothing will break for OMAP3, but OMAP4 USB host will break (e.g. Panda board).
> OMAP5 USB host was never working so it doesn't matter there.
>
> To make sure nothing breaks, we need at least these 2 patches to go in together with mfd changes.
>
> [PATCH v8 08/14] ARM: dts: omap4: Update omap-usb-host node
> [PATCH v8 09/14] ARM: dts: omap5: Update omap-usb-host node
>
> Any suggestions about how we can proceed?
Yes, unfortunately you have to squash each of the patches into one
patch. Applying a patch which breaks a build, then applying another one
immediately after which subsequently fixes the break is not an acceptable
way of working I'm afraid. What would happen if we were to fall into
the middle of the two patches when bisecting?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] mfd: palmas: support IRQ inversion at the board level
From: Lee Jones @ 2014-02-25 9:20 UTC (permalink / raw)
To: Stephen Warren
Cc: Samuel Ortiz, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, J Keerthy, Ian Lartey,
Stefan Agner, josephl-DDmLM1+adcrQT0dZR+AlfA,
ldewangan-DDmLM1+adcrQT0dZR+AlfA, Stephen Warren
In-Reply-To: <1392415108-4365-1-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Mark,
> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> Some boards or SoCs have an inverter between the PMIC IRQ output pin and
> the IRQ controller input signal.
>
> The IRQ specifier in DT is meant to represent the IRQ flags at the input
> to the IRQ controller.
>
> The Palmas HW's IRQ output has configurable polarity. The driver
> currently selects the output polarity by querying the input polarity at
> the IRQ controller. This works fine if the IRQ signal is routed directly
> from the PMIC to the IRQ controller with no intervening logic. However,
> if the signal is inverted between the two, this automatic polarity
> selection gets the wrong answer.
>
> Add an additional optional DT and platform data parameter which indicates
> that such an inversion occurs. If this option is enabled, the Palmas
> driver will configure its IRQ output to the opposite polarity of the IRQ
> controller's input.
>
> An alternative would have been to add a new non-optional DT parameter to
> indicate the exact desired output polarity. However, this would have been
> an incompatible change to the DT binding.
>
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> If this patch could be applied to its own branch (w/ signed tag) in the
> MFD tree, that would great; then I can pull patch 1/2 into the Tegra tree
> so that I can apply patch 2/2 to the Tegra tree. Thanks.
> ---
> Documentation/devicetree/bindings/mfd/palmas.txt | 6 ++++++
Would you care to review this for Stephen please?
> drivers/mfd/palmas.c | 4 ++++
> include/linux/mfd/palmas.h | 1 +
> 3 files changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt b/Documentation/devicetree/bindings/mfd/palmas.txt
> index e5f0f8303461..76ec509d5f87 100644
> --- a/Documentation/devicetree/bindings/mfd/palmas.txt
> +++ b/Documentation/devicetree/bindings/mfd/palmas.txt
> @@ -18,6 +18,12 @@ Required properties:
> ti,tps659038
> and also the generic series names
> ti,palmas
> +- interrupts : Should contain a single entry for the IRQ output.
> +- ti,irq-externally-inverted : If missing, the polarity of the Palmas IRQ
> + output should be set to the opposite of the polarity indicated by the IRQ
> + specifier in the interrupts property. If absent, the polarity should be
> + configured to match. This allows the representation of an inverter between
> + the Palmas IRQ output and the interrupt parent's IRQ input.
> - interrupt-controller : palmas has its own internal IRQs
> - #interrupt-cells : should be set to 2 for IRQ number and flags
> The first cell is the IRQ number.
> diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
> index d280d789e55a..f4ea932adf8d 100644
> --- a/drivers/mfd/palmas.c
> +++ b/drivers/mfd/palmas.c
> @@ -293,6 +293,8 @@ static int palmas_set_pdata_irq_flag(struct i2c_client *i2c,
> }
>
> pdata->irq_flags = irqd_get_trigger_type(irq_data);
> + pdata->irq_external_inversion = of_property_read_bool(i2c->dev.of_node,
> + "ti,irq-externally-inverted");
> dev_info(&i2c->dev, "Irq flag is 0x%08x\n", pdata->irq_flags);
> return 0;
> }
> @@ -447,6 +449,8 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
> reg = PALMAS_POLARITY_CTRL_INT_POLARITY;
> else
> reg = 0;
> + if (pdata->irq_external_inversion)
> + reg ^= PALMAS_POLARITY_CTRL_INT_POLARITY;
> ret = palmas_update_bits(palmas, PALMAS_PU_PD_OD_BASE,
> PALMAS_POLARITY_CTRL, PALMAS_POLARITY_CTRL_INT_POLARITY,
> reg);
> diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
> index 9974e387e483..2fdf08c50a48 100644
> --- a/include/linux/mfd/palmas.h
> +++ b/include/linux/mfd/palmas.h
> @@ -292,6 +292,7 @@ struct palmas_clk_platform_data {
>
> struct palmas_platform_data {
> int irq_flags;
> + bool irq_external_inversion;
> int gpio_base;
>
> /* bit value to be loaded to the POWER_CTRL register */
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v8 03/14] mfd: omap-usb-host: Use clock names as per function for reference clocks
From: Roger Quadros @ 2014-02-25 9:25 UTC (permalink / raw)
To: Lee Jones
Cc: tony, bcousson, balbi, nm, khilman, linux-omap, linux-arm-kernel,
linux-kernel, devicetree, linux-usb, Samuel Ortiz
In-Reply-To: <20140225091839.GE19099@lee--X1>
On 02/25/2014 11:18 AM, Lee Jones wrote:
>>>> Use a meaningful name for the reference clocks so that it indicates the function.
>>>>
>>>> CC: Lee Jones <lee.jones@linaro.org>
>>>> CC: Samuel Ortiz <sameo@linux.intel.com>
>>>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>>>> ---
>>>> drivers/mfd/omap-usb-host.c | 12 ++++++------
>>>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>>>> index 865c276..651e249 100644
>>>> --- a/drivers/mfd/omap-usb-host.c
>>>> +++ b/drivers/mfd/omap-usb-host.c
>>>> @@ -718,24 +718,24 @@ static int usbhs_omap_probe(struct platform_device *pdev)
>>>> goto err_mem;
>>>> }
>>>>
>>>> - omap->xclk60mhsp1_ck = devm_clk_get(dev, "xclk60mhsp1_ck");
>>>> + omap->xclk60mhsp1_ck = devm_clk_get(dev, "refclk_60m_ext_p1");
>>>> if (IS_ERR(omap->xclk60mhsp1_ck)) {
>>>> ret = PTR_ERR(omap->xclk60mhsp1_ck);
>>>> - dev_err(dev, "xclk60mhsp1_ck failed error:%d\n", ret);
>>>> + dev_err(dev, "refclk_60m_ext_p1 failed error:%d\n", ret);
>>>> goto err_mem;
>>>> }
>>>
>>> Will anything break if I were to apply the MFD patches seperately?
>>>
>>
>> Nothing will break for OMAP3, but OMAP4 USB host will break (e.g. Panda board).
>> OMAP5 USB host was never working so it doesn't matter there.
>>
>> To make sure nothing breaks, we need at least these 2 patches to go in together with mfd changes.
>>
>> [PATCH v8 08/14] ARM: dts: omap4: Update omap-usb-host node
>> [PATCH v8 09/14] ARM: dts: omap5: Update omap-usb-host node
>>
>> Any suggestions about how we can proceed?
>
> Yes, unfortunately you have to squash each of the patches into one
> patch. Applying a patch which breaks a build, then applying another one
> immediately after which subsequently fixes the break is not an acceptable
> way of working I'm afraid. What would happen if we were to fall into
> the middle of the two patches when bisecting?
>
OK, I'll squash patches 8 and 9 into patch 3.
cheers,
-roger
^ permalink raw reply
* Re: [PATCH v8 06/14] CLK: TI: OMAP3: Get rid of unused USB Host dummy clocks
From: Roger Quadros @ 2014-02-25 9:32 UTC (permalink / raw)
To: Mike Turquette, tony-4v6yS6AI5VpBDgjK7y7TUQ,
bcousson-rdvid1DuHRBWk0Htik3J/w, lee.jones-QSEj5FYQhm4dnm+yROfE0A
Cc: balbi-l0cyMroinI0, nm-l0cyMroinI0, khilman-QSEj5FYQhm4dnm+yROfE0A,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Tero Kristo
In-Reply-To: <20140225084327.22529.86075@quantum>
Hi Mike,
On 02/25/2014 10:43 AM, Mike Turquette wrote:
> Quoting Roger Quadros (2014-02-20 03:40:01)
>> The OMAP USB Host MFD driver no longer expects these non-existing
>> clocks from the OMAP3 platform, so get rid of them.
>
> Looks good to me.
Is it OK if I squash this patch with [1] and take it through the MFD tree?
Keeping them separate could break functionality if both don't go in together.
[1] - http://article.gmane.org/gmane.linux.ports.arm.kernel/303266
cheers,
-roger
>
>>
>> CC: Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org>
>> CC: Mike Turquette <mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
>> ---
>> arch/arm/mach-omap2/cclock3xxx_data.c | 4 ----
>> drivers/clk/ti/clk-3xxx.c | 4 ----
>> 2 files changed, 8 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
>> index 3b05aea..4299a55 100644
>> --- a/arch/arm/mach-omap2/cclock3xxx_data.c
>> +++ b/arch/arm/mach-omap2/cclock3xxx_data.c
>> @@ -3495,10 +3495,6 @@ static struct omap_clk omap3xxx_clks[] = {
>> CLK(NULL, "dss_tv_fck", &dss_tv_fck),
>> CLK(NULL, "dss_96m_fck", &dss_96m_fck),
>> CLK(NULL, "dss2_alwon_fck", &dss2_alwon_fck),
>> - CLK(NULL, "utmi_p1_gfclk", &dummy_ck),
>> - CLK(NULL, "utmi_p2_gfclk", &dummy_ck),
>> - CLK(NULL, "xclk60mhsp1_ck", &dummy_ck),
>> - CLK(NULL, "xclk60mhsp2_ck", &dummy_ck),
>> CLK(NULL, "init_60m_fclk", &dummy_ck),
>> CLK(NULL, "gpt1_fck", &gpt1_fck),
>> CLK(NULL, "aes2_ick", &aes2_ick),
>> diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
>> index d323023..0d1750a 100644
>> --- a/drivers/clk/ti/clk-3xxx.c
>> +++ b/drivers/clk/ti/clk-3xxx.c
>> @@ -130,10 +130,6 @@ static struct ti_dt_clk omap3xxx_clks[] = {
>> DT_CLK(NULL, "dss_tv_fck", "dss_tv_fck"),
>> DT_CLK(NULL, "dss_96m_fck", "dss_96m_fck"),
>> DT_CLK(NULL, "dss2_alwon_fck", "dss2_alwon_fck"),
>> - DT_CLK(NULL, "utmi_p1_gfclk", "dummy_ck"),
>> - DT_CLK(NULL, "utmi_p2_gfclk", "dummy_ck"),
>> - DT_CLK(NULL, "xclk60mhsp1_ck", "dummy_ck"),
>> - DT_CLK(NULL, "xclk60mhsp2_ck", "dummy_ck"),
>> DT_CLK(NULL, "init_60m_fclk", "dummy_ck"),
>> DT_CLK(NULL, "gpt1_fck", "gpt1_fck"),
>> DT_CLK(NULL, "aes2_ick", "aes2_ick"),
>> --
>> 1.8.3.2
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 00/10] pinctrl: mvebu: remove hard-coded addresses from Dove pinctrl
From: Linus Walleij @ 2014-02-25 9:36 UTC (permalink / raw)
To: Jason Cooper
Cc: Sebastian Hesselbarth, Mark Rutland, Andrew Lunn, Russell King,
Pawel Moll, Ian Campbell,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Rob Landley, Kumar Gala, Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20140224181023.GA1010-u4khhh1J0LxI1Ri9qeTfzeTW4wlIGRCZ@public.gmane.org>
On Mon, Feb 24, 2014 at 7:10 PM, Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org> wrote:
> Sebastian, Linus,
>
> I've now created mvebu/pinctrl-dove for this series. It's based on
> v3.14-rc1, and depends on mvebu/pinctrl (which depends on
> mvebu/pinctrl-3xx).
>
> I've kept this series in a separate branch in case we encounter an
> unforeseen problem with something in here. Then this branch can be
> dropped, and /pinctrl-3xx and /pinctrl will still make it in.
>
> So, all patches except 3 and 4 are in mvebu/pinctrl-dove. 3 and 4 are
> in mvebu/dt.
OK so what should I be pulling in first now?
Yours,
Linus Walleij
--
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 v8 01/14] mfd: omap-usb-host: Get clocks based on hardware revision
From: Lee Jones @ 2014-02-25 9:37 UTC (permalink / raw)
To: Roger Quadros
Cc: nm, devicetree, khilman, Samuel Ortiz, tony, linux-usb,
linux-kernel, balbi, bcousson, linux-omap, linux-arm-kernel
In-Reply-To: <1392896409-5101-2-git-send-email-rogerq@ti.com>
> Not all revisions have all the clocks so get the necessary clocks
> based on hardware revision.
>
> This should avoid un-necessary clk_get failure messages that were
> observed earlier.
>
> CC: Lee Jones <lee.jones@linaro.org>
> CC: Samuel Ortiz <sameo@linux.intel.com>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
> drivers/mfd/omap-usb-host.c | 43 ++++++++++++++++++++++++++++++++-----------
> 1 file changed, 32 insertions(+), 11 deletions(-)
What about patches 1 and 2. Are these safe to go in alone?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 01/14] mfd: omap-usb-host: Get clocks based on hardware revision
From: Roger Quadros @ 2014-02-25 9:40 UTC (permalink / raw)
To: Lee Jones
Cc: tony, bcousson, balbi, nm, khilman, linux-omap, linux-arm-kernel,
linux-kernel, devicetree, linux-usb, Samuel Ortiz
In-Reply-To: <20140225093759.GA22755@lee--X1>
On 02/25/2014 11:37 AM, Lee Jones wrote:
>> Not all revisions have all the clocks so get the necessary clocks
>> based on hardware revision.
>>
>> This should avoid un-necessary clk_get failure messages that were
>> observed earlier.
>>
>> CC: Lee Jones <lee.jones@linaro.org>
>> CC: Samuel Ortiz <sameo@linux.intel.com>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>> drivers/mfd/omap-usb-host.c | 43 ++++++++++++++++++++++++++++++++-----------
>> 1 file changed, 32 insertions(+), 11 deletions(-)
>
> What about patches 1 and 2. Are these safe to go in alone?
>
patch 6 must not go in without 1. I've just asked Mike if we can squash it into 1.
patch 2 can go alone.
cheers,
-roger
^ permalink raw reply
* Re: [PATCH v5 04/10] V4L: Add driver for s5k6a3 image sensor
From: Sylwester Nawrocki @ 2014-02-25 9:46 UTC (permalink / raw)
To: Baruch Siach
Cc: linux-media, devicetree, mark.rutland, linux-samsung-soc, a.hajda,
kyungmin.park, robh+dt, galak, kgene.kim, linux-arm-kernel
In-Reply-To: <20140224193838.GL4869@tarshish>
Hi Baruch,
On 24/02/14 20:38, Baruch Siach wrote:
> On Mon, Feb 24, 2014 at 06:35:16PM +0100, Sylwester Nawrocki wrote:
>> > This patch adds subdev driver for Samsung S5K6A3 raw image sensor.
>> > As it is intended at the moment to be used only with the Exynos
>> > FIMC-IS (camera ISP) subsystem it is pretty minimal subdev driver.
>> > It doesn't do any I2C communication since the sensor is controlled
>> > by the ISP and its own firmware.
>> > This driver, if needed, can be updated in future into a regular
>> > subdev driver where the main CPU communicates with the sensor
>> > directly.
>> >
>> > Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>> > Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>
> [...]
>
>> > +static int s5k6a3_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
>> > +{
>> > + struct v4l2_mbus_framefmt *format = v4l2_subdev_get_try_format(fh, 0);
>> > +
>> > + *format = s5k6a3_formats[0];
>> > + format->width = S5K6A3_DEFAULT_WIDTH;
>> > + format->height = S5K6A3_DEFAULT_HEIGHT;
>> > +
>> > + return 0;
>> > +}
>> > +
>> > +static const struct v4l2_subdev_internal_ops s5k6a3_sd_internal_ops = {
>> > + .open = s5k6a3_open,
>> > +};
>
> Where is this used?
This will be called when user process opens the corresponding /dev/v4l-subdev*
device node. More details on the v4l2 sub-device interface can be found at [1],
[2]. The device node is created by an aggregate media device driver, once all
required sub-devices are registered to it.
The above v4l2_subdev_internal_ops::open() implementation is pretty simple,
it just sets V4L2_SUBDEV_FORMAT_TRY format to some initial default value.
That's a per file handle value, so each process opening a set of sub-devices
can try pipeline configuration independently.
[1] http://linuxtv.org/downloads/v4l-dvb-apis/subdev.html
[2] http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-subdev-g-fmt.html
Regards,
Sylwester
^ permalink raw reply
* Re: [PATCH v2 0/6] ARM: STi reset controller support
From: Philipp Zabel @ 2014-02-25 9:47 UTC (permalink / raw)
To: srinivas kandagatla
Cc: Maxime Coquelin, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
Russell King, kernel-F5mvAk5X5gdBDgjK7y7TUQ, Pawel Moll,
Ian Campbell, Olof Johansson, linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
stephen.gallimore-qxv4g6HH51o, Rob Herring, Arnd Bergmann,
Rob Landley, Kumar Gala, Grant Likely,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <530C5D8C.1080809-qxv4g6HH51o@public.gmane.org>
Hi Srinivas,
Am Dienstag, den 25.02.2014, 09:08 +0000 schrieb srinivas kandagatla:
> On 24/02/14 15:16, Philipp Zabel wrote:
> > Hi Srinivas,
> >
> > Am Montag, den 24.02.2014, 14:03 +0000 schrieb srinivas kandagatla:
> >> Thanks Philipp for your comments,
> >>
> >> On 24/02/14 10:33, Philipp Zabel wrote:
> >>>>> Did Srini's explanations convinced you?
> >>>>>
> >>>>> If so, could you queue the series for v3.15?
> >>> to be honest, I'm not comfortable with this explanation. If the
> >>> "powerdown" bits only gate the clocks to those modules, calling it a
> >>> reset control is clearly the wrong abstraction. If that is the case,
> >>> couldn't you handle those bits via the clock framework?
> >> I just had a re-look at the IPs specs for more information on where
> >> these power-down signals are actually terminating on the IP side.
> >>
> >> For example: ST-Synopsis Ethernet GMAC IP has two pins
> >> power_down_req[IN] and power_down_ack[OUT]. power_down_req is used by
> >> the software to either put the IP in powerdown or bring it out of
> >> powerdown state.
> >
> > Now I'm a bit confused. There is no mention of GMAC in your patches,
> > and for ETH[01] they contain only the SOFTRESET bits. I have no issue
> > with the SOFTRESETs.
> Yes, GMAC was a bad example indeed. However this same logic applies to
> the USB IP as well.
>
> GMAC power-down-reset can be added to the power-down-reset list for
> consistency.
>
> We did not define the power-down-reset for GMAC because the reset state
> of GMAC will not be in power down. softreset should be enough to bring
> the IP in to a usable state. So the software never drives the power
> down-request but instead uses softreset in this particular case.
>
> >
> >> The IP itself drives power_down_ack to indicate when the power down
> >> request is successfully finished. For power_down/power_up request the IP
> >> will change the internal state accordingly including powering up/down
> >> its internal blocks and/or clock gating.
> >>
> >>> If on the other hand these powerdown bits also trigger reset machinery,
> >>> such that asserting and deasserting that bit will change the module's
> >>> internal state, I could be convinced to queue them like this.
> >> This is true with ST IPs, these lines change the state of the IP as
> >> described above. Reset framework seems to fits in very well with this
> >> behavior rather than power-domains or clock framework.
> >
> > If you put the IP in power down when it is idle, and then power it up
> > again, will the IP registers have kept their previous state?
> No, the context is lost, the IP needs re-initialization.
alright then, I'll add them to the queue.
thanks
Philipp
--
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] ARM: tegra: add device tree for SHIELD
From: Arend van Spriel @ 2014-02-25 9:52 UTC (permalink / raw)
To: Alexandre Courbot, Stephen Warren, Thierry Reding, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <530BFC58.6020003-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 02/25/2014 03:13 AM, Alexandre Courbot wrote:
>>
>>> + /* Wifi */
>>> + sdhci@78000000 {
>>> + status = "okay";
>>> + bus-width = <4>;
>>> + broken-cd;
>>> + keep-power-in-suspend;
>>> + cap-sdio-irq;
>>
>> Is non-removable better than broken-cd, or are they entirely unrelated?
>
> They are unrelated actually. With non-removable the driver expects the
> device to always be there since boot, and does not check for the card to
> be removed/added after boot. broken-cd indicates there is no CD line and
> the device should be polled regularly.
>
> For the Wifi chip, non-removable would be the correct setting
> hardware-wise, but there is a trap: the chip has its reset line asserted
> at boot-time, and you need to set GPIO 229 to de-assert it. Only after
> that will the device be detected on the SDIO bus. Since it lacks a CD
> line, it must be polled, hence the broken-cd property.
>
> This also raises another, redundant problem with DT bindings: AFAIK we
> currently have no way to let the system know the device will only appear
> after a given GPIO is set. It would also be nice to be able to give some
> parameters to the Wifi driver through the DT (like the OOB interrupt).
> Right now the Wifi chip is brought up by exporting the GPIO and writing
> to it from user-space, and the OOB interrupt is not used.
Hi Alexandre,
I recently posted a proposal for brcmfmac DT binding [1]. I did receive
some comments, but it would be great if you (and/or others involved) had
a look at it as well and give me some feedback. DT work still needs to
grow on me.
> Otherwise, Wifi works great with the brcmfmac driver and NVRAM file
> extracted from Android.
With in-band interrupts, indeed. The HOST_WAKE signal is the OOB
interrupt which would need to be provided in the device-tree.
Regards,
Arend
[1] http://mid.gmane.org/1392059868-8782-1-git-send-email-arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org
^ permalink raw reply
* Re: [PATCH v5 04/10] V4L: Add driver for s5k6a3 image sensor
From: Baruch Siach @ 2014-02-25 9:55 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: linux-media, devicetree, mark.rutland, linux-samsung-soc, a.hajda,
kyungmin.park, robh+dt, galak, kgene.kim, linux-arm-kernel
In-Reply-To: <530C6692.6090307@samsung.com>
Hi Sylwester,
On Tue, Feb 25, 2014 at 10:46:58AM +0100, Sylwester Nawrocki wrote:
> On 24/02/14 20:38, Baruch Siach wrote:
> > On Mon, Feb 24, 2014 at 06:35:16PM +0100, Sylwester Nawrocki wrote:
> >> > This patch adds subdev driver for Samsung S5K6A3 raw image sensor.
> >> > As it is intended at the moment to be used only with the Exynos
> >> > FIMC-IS (camera ISP) subsystem it is pretty minimal subdev driver.
> >> > It doesn't do any I2C communication since the sensor is controlled
> >> > by the ISP and its own firmware.
> >> > This driver, if needed, can be updated in future into a regular
> >> > subdev driver where the main CPU communicates with the sensor
> >> > directly.
> >> >
> >> > Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> >> > Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> >
> > [...]
> >
> >> > +static int s5k6a3_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
> >> > +{
> >> > + struct v4l2_mbus_framefmt *format = v4l2_subdev_get_try_format(fh, 0);
> >> > +
> >> > + *format = s5k6a3_formats[0];
> >> > + format->width = S5K6A3_DEFAULT_WIDTH;
> >> > + format->height = S5K6A3_DEFAULT_HEIGHT;
> >> > +
> >> > + return 0;
> >> > +}
> >> > +
> >> > +static const struct v4l2_subdev_internal_ops s5k6a3_sd_internal_ops = {
> >> > + .open = s5k6a3_open,
> >> > +};
> >
> > Where is this used?
>
> This will be called when user process opens the corresponding /dev/v4l-subdev*
> device node. More details on the v4l2 sub-device interface can be found at [1],
> [2]. The device node is created by an aggregate media device driver, once all
> required sub-devices are registered to it.
> The above v4l2_subdev_internal_ops::open() implementation is pretty simple,
> it just sets V4L2_SUBDEV_FORMAT_TRY format to some initial default value.
> That's a per file handle value, so each process opening a set of sub-devices
> can try pipeline configuration independently.
>
> [1] http://linuxtv.org/downloads/v4l-dvb-apis/subdev.html
> [2] http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-subdev-g-fmt.html
Thanks for the explanation. However, I've found no reference to the
s5k6a3_sd_internal_ops struct in the driver code. There surly has to be at
least one reference for the upper layer to access these ops.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* Re: [PATCH v8 02/14] mfd: omap-usb-host: Always fail on clk_get() error
From: Lee Jones @ 2014-02-25 9:59 UTC (permalink / raw)
To: Roger Quadros
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ, bcousson-rdvid1DuHRBWk0Htik3J/w,
balbi-l0cyMroinI0, nm-l0cyMroinI0, khilman-QSEj5FYQhm4dnm+yROfE0A,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Samuel Ortiz
In-Reply-To: <1392896409-5101-3-git-send-email-rogerq-l0cyMroinI0@public.gmane.org>
> Be more strict and always fail on clk_get() error.
>
> For OMAP3 platforms, get the 120MHz EHCI clock by its proper name
> 'usbhost_120m_fck' instead of its alias 'ehci_logic_fck'.
>
> CC: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> CC: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
> ---
> drivers/mfd/omap-usb-host.c | 65 +++++++++++++++++++++++++++++----------------
> 1 file changed, 42 insertions(+), 23 deletions(-)
Appied, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 1/6] spi: sh-msiof: Improve bindings
From: Geert Uytterhoeven @ 2014-02-25 10:21 UTC (permalink / raw)
To: Mark Brown
Cc: Takashi Yoshii, Magnus Damm, linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-sh-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1393323673-2751-1-git-send-email-geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
From: Geert Uytterhoeven <geert+renesas-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
Documentation:
- Add missing "interrupt-parent", "#address-cells", "#size-cells", and
"clocks" properties,
- Add missing default values for "num-cs", "renesas,tx-fifo-size" and
"renesas,rx-fifo-size",
- Add a reference to the pinctrl documentation.
Implementation:
- As "num-cs" is marked optional, provide a sensible default.
Signed-off-by: Geert Uytterhoeven <geert+renesas-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
v2:
- As num-cs is marked optional, provide a sensible default
Documentation/devicetree/bindings/spi/sh-msiof.txt | 24 ++++++++++++++------
drivers/spi/spi-sh-msiof.c | 2 +-
2 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt b/Documentation/devicetree/bindings/spi/sh-msiof.txt
index e6222106ca36..eae3c8c9300e 100644
--- a/Documentation/devicetree/bindings/spi/sh-msiof.txt
+++ b/Documentation/devicetree/bindings/spi/sh-msiof.txt
@@ -1,12 +1,22 @@
Renesas MSIOF spi controller
Required properties:
-- compatible : "renesas,sh-msiof" for SuperH or
- "renesas,sh-mobile-msiof" for SH Mobile series
-- reg : Offset and length of the register set for the device
-- interrupts : interrupt line used by MSIOF
+- compatible : "renesas,sh-msiof" for SuperH, or
+ "renesas,sh-mobile-msiof" for SH Mobile series.
+- reg : Offset and length of the register set for the device
+- interrupt-parent : The phandle for the interrupt controller that
+ services interrupts for this device
+- interrupts : Interrupt specifier
+- #address-cells : Must be <1>
+- #size-cells : Must be <0>
Optional properties:
-- num-cs : total number of chip-selects
-- renesas,tx-fifo-size : Overrides the default tx fifo size given in words
-- renesas,rx-fifo-size : Overrides the default rx fifo size given in words
+- clocks : Must contain a reference to the functional clock.
+- num-cs : Total number of chip-selects (default is 1)
+- renesas,tx-fifo-size : Overrides the default tx fifo size given in words
+ (default is 64)
+- renesas,rx-fifo-size : Overrides the default rx fifo size given in words
+ (default is 64)
+
+Pinctrl properties might be needed, too. See
+Documentation/devicetree/bindings/pinctrl/renesas,*.
diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index 92515c1ececa..bbe963018e1a 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -663,7 +663,7 @@ static struct sh_msiof_spi_info *sh_msiof_spi_parse_dt(struct device *dev)
{
struct sh_msiof_spi_info *info;
struct device_node *np = dev->of_node;
- u32 num_cs = 0;
+ u32 num_cs = 1;
info = devm_kzalloc(dev, sizeof(struct sh_msiof_spi_info), GFP_KERNEL);
if (!info) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" 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 v2 3/6] spi: sh-msiof: Add support for R-Car H2 and M2
From: Geert Uytterhoeven @ 2014-02-25 10:21 UTC (permalink / raw)
To: Mark Brown
Cc: Takashi Yoshii, Magnus Damm, linux-spi, linux-sh, linux-kernel,
Geert Uytterhoeven, devicetree
In-Reply-To: <1393323673-2751-1-git-send-email-geert@linux-m68k.org>
From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Add support for the MSIOF variant in the R-Car H2 (r8a7790) and M2
(r8a7791) SoCs.
Binding documentation:
- Add future-proof "renesas,msiof-<soctype>" compatible values,
- The default for "renesas,rx-fifo-size" is 256 on R-Car H2 and M2,
- "renesas,tx-fifo-size" and "renesas,rx-fifo-size" are deprecated for
soctype-specific bindings,
- Add example bindings.
Implementation:
- MSIOF on R-Car H2 and M2 requires the transmission of dummy data if
data is being received only (cfr. "Set SICTR.TSCKE to 1" and "Write
dummy transmission data to SITFDR" in paragraph "Transmit and Receive
Procedures" of the Hardware User's Manual).
- As RX depends on TX, MSIOF on R-Car H2 and M2 also lacks the RSCR
register (Receive Clock Select Register), and some bits in the RMDR1
(Receive Mode Register 1) and TMDR2 (Transmit Mode Register 2)
registers.
- Use the recently introduced SPI_MASTER_MUST_TX flag to enable support
for dummy transmission in the SPI core, and to differentiate from other
MSIOF implementations in code paths that need this.
- New DT compatible values ("renesas,msiof-r8a7790" and
"renesas,msiof-r8a7791") are added, as well as new platform device
names ("spi_r8a7790_msiof" and "spi_r8a7791_msiof").
- The default RX FIFO size is 256 words on R-Car H2 and M2.
This is loosely based on a set of patches from Takashi Yoshii
<takasi-y@ops.dti.ne.jp>.
Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Cc: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
Cc: devicetree@vger.kernel.org
---
v2:
- Rebased on top of new "spi: sh-msiof: Move default FIFO sizes to device
ID data",
- The default RX FIFO size is 256 words on R-Car H2 and M2,
- Deprecated overriding the FIFO size,
- Synced DT example with node from real DTS.
Documentation/devicetree/bindings/spi/sh-msiof.txt | 23 ++++++++++++++++++--
drivers/spi/spi-sh-msiof.c | 23 +++++++++++++++++---
2 files changed, 41 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt b/Documentation/devicetree/bindings/spi/sh-msiof.txt
index eae3c8c9300e..1f0cb33763a1 100644
--- a/Documentation/devicetree/bindings/spi/sh-msiof.txt
+++ b/Documentation/devicetree/bindings/spi/sh-msiof.txt
@@ -1,8 +1,13 @@
Renesas MSIOF spi controller
Required properties:
-- compatible : "renesas,sh-msiof" for SuperH, or
+- compatible : "renesas,msiof-<soctype>" for SoCs,
+ "renesas,sh-msiof" for SuperH, or
"renesas,sh-mobile-msiof" for SH Mobile series.
+ Examples with soctypes are:
+ "renesas,msiof-sh7724" (SH)
+ "renesas,msiof-r8a7790" (R-Car H2)
+ "renesas,msiof-r8a7791" (R-Car M2)
- reg : Offset and length of the register set for the device
- interrupt-parent : The phandle for the interrupt controller that
services interrupts for this device
@@ -13,10 +18,24 @@ Required properties:
Optional properties:
- clocks : Must contain a reference to the functional clock.
- num-cs : Total number of chip-selects (default is 1)
+
+Optional properties, deprecated for soctype-specific bindings:
- renesas,tx-fifo-size : Overrides the default tx fifo size given in words
(default is 64)
- renesas,rx-fifo-size : Overrides the default rx fifo size given in words
- (default is 64)
+ (default is 64, or 256 on R-Car H2 and M2)
Pinctrl properties might be needed, too. See
Documentation/devicetree/bindings/pinctrl/renesas,*.
+
+Example:
+
+ msiof0: spi@e6e20000 {
+ compatible = "renesas,msiof-r8a7791";
+ reg = <0 0xe6e20000 0 0x0064>;
+ interrupts = <0 156 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&mstp0_clks R8A7791_CLK_MSIOF0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index bf389184924d..3baef2bacaed 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -34,6 +34,7 @@
struct sh_msiof_chipdata {
u16 tx_fifo_size;
u16 rx_fifo_size;
+ u16 master_flags;
};
struct sh_msiof_spi_priv {
@@ -214,7 +215,8 @@ static void sh_msiof_spi_set_clk_regs(struct sh_msiof_spi_priv *p,
k = min_t(int, k, ARRAY_SIZE(sh_msiof_spi_clk_table) - 1);
sh_msiof_write(p, TSCR, sh_msiof_spi_clk_table[k].scr);
- sh_msiof_write(p, RSCR, sh_msiof_spi_clk_table[k].scr);
+ if (!(p->chipdata->master_flags & SPI_MASTER_MUST_TX))
+ sh_msiof_write(p, RSCR, sh_msiof_spi_clk_table[k].scr);
}
static void sh_msiof_spi_set_pin_regs(struct sh_msiof_spi_priv *p,
@@ -237,6 +239,10 @@ static void sh_msiof_spi_set_pin_regs(struct sh_msiof_spi_priv *p,
tmp |= !cs_high << MDR1_SYNCAC_SHIFT;
tmp |= lsb_first << MDR1_BITLSB_SHIFT;
sh_msiof_write(p, TMDR1, tmp | MDR1_TRMD | TMDR1_PCON);
+ if (p->chipdata->master_flags & SPI_MASTER_MUST_TX) {
+ /* These bits are reserved if RX needs TX */
+ tmp &= ~0x0000ffff;
+ }
sh_msiof_write(p, RMDR1, tmp);
tmp = 0;
@@ -257,7 +263,7 @@ static void sh_msiof_spi_set_mode_regs(struct sh_msiof_spi_priv *p,
{
u32 dr2 = MDR2_BITLEN1(bits) | MDR2_WDLEN1(words);
- if (tx_buf)
+ if (tx_buf || (p->chipdata->master_flags & SPI_MASTER_MUST_TX))
sh_msiof_write(p, TMDR2, dr2);
else
sh_msiof_write(p, TMDR2, dr2 | MDR2_GRPMASK1);
@@ -666,11 +672,20 @@ static u32 sh_msiof_spi_txrx_word(struct spi_device *spi, unsigned nsecs,
static const struct sh_msiof_chipdata sh_data = {
.tx_fifo_size = 64,
.rx_fifo_size = 64,
+ .master_flags = 0,
+};
+
+static const struct sh_msiof_chipdata r8a779x_data = {
+ .tx_fifo_size = 64,
+ .rx_fifo_size = 256,
+ .master_flags = SPI_MASTER_MUST_TX,
};
static const struct of_device_id sh_msiof_match[] = {
{ .compatible = "renesas,sh-msiof", .data = &sh_data },
{ .compatible = "renesas,sh-mobile-msiof", .data = &sh_data },
+ { .compatible = "renesas,msiof-r8a7790", .data = &r8a779x_data },
+ { .compatible = "renesas,msiof-r8a7791", .data = &r8a779x_data },
{},
};
MODULE_DEVICE_TABLE(of, sh_msiof_match);
@@ -789,7 +804,7 @@ static int sh_msiof_spi_probe(struct platform_device *pdev)
/* init master and bitbang code */
master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH;
master->mode_bits |= SPI_LSB_FIRST | SPI_3WIRE;
- master->flags = 0;
+ master->flags = p->chipdata->master_flags;
master->bus_num = pdev->id;
master->dev.of_node = pdev->dev.of_node;
master->num_chipselect = p->info->num_chipselect;
@@ -832,6 +847,8 @@ static int sh_msiof_spi_remove(struct platform_device *pdev)
static struct platform_device_id spi_driver_ids[] = {
{ "spi_sh_msiof", (kernel_ulong_t)&sh_data },
+ { "spi_r8a7790_msiof", (kernel_ulong_t)&r8a779x_data },
+ { "spi_r8a7791_msiof", (kernel_ulong_t)&r8a779x_data },
{},
};
MODULE_DEVICE_TABLE(platform, spi_driver_ids);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v8 02/14] mfd: omap-usb-host: Always fail on clk_get() error
From: Lee Jones @ 2014-02-25 10:28 UTC (permalink / raw)
To: Roger Quadros
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ, bcousson-rdvid1DuHRBWk0Htik3J/w,
balbi-l0cyMroinI0, nm-l0cyMroinI0, khilman-QSEj5FYQhm4dnm+yROfE0A,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Samuel Ortiz
In-Reply-To: <20140225095913.GA13143@lee--X1>
On Tue, 25 Feb 2014, Lee Jones wrote:
> > Be more strict and always fail on clk_get() error.
> >
> > For OMAP3 platforms, get the 120MHz EHCI clock by its proper name
> > 'usbhost_120m_fck' instead of its alias 'ehci_logic_fck'.
> >
> > CC: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > CC: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
> > ---
> > drivers/mfd/omap-usb-host.c | 65 +++++++++++++++++++++++++++++----------------
> > 1 file changed, 42 insertions(+), 23 deletions(-)
>
> Appied, thanks.
Won't apply. I guess this depends on the changes made in patch 1.
I'll wait for the next drop.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 05/11] ARM: shmobile: r8a7790/lager dts: Rename label spi to qspi, add spi0 alias
From: Geert Uytterhoeven @ 2014-02-25 10:30 UTC (permalink / raw)
To: Simon Horman, Magnus Damm
Cc: linux-sh, linux-arm-kernel, linux-kernel, Geert Uytterhoeven,
devicetree
In-Reply-To: <1393324219-3317-1-git-send-email-geert@linux-m68k.org>
From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Prepare for the advent of MSIOF SPI, which will be spi1 to spi4.
Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Cc: devicetree@vger.kernel.org
---
v2:
- No changes
arch/arm/boot/dts/r8a7790-lager.dts | 4 ++--
arch/arm/boot/dts/r8a7790.dtsi | 3 ++-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
index 6e99eb2df076..86dbdc10fe9c 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -155,7 +155,7 @@
renesas,function = "mmc1";
};
- qspi_pins: spi {
+ qspi_pins: spi0 {
renesas,groups = "qspi_ctrl", "qspi_data4";
renesas,function = "qspi";
};
@@ -190,7 +190,7 @@
status = "okay";
};
-&spi {
+&qspi {
pinctrl-0 = <&qspi_pins>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 618e5b537eaf..9383b8436111 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -24,6 +24,7 @@
i2c1 = &i2c1;
i2c2 = &i2c2;
i2c3 = &i2c3;
+ spi0 = &qspi;
};
cpus {
@@ -765,7 +766,7 @@
};
};
- spi: spi@e6b10000 {
+ qspi: spi@e6b10000 {
compatible = "renesas,qspi-r8a7790", "renesas,qspi";
reg = <0 0xe6b10000 0 0x2c>;
interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 06/11] ARM: shmobile: r8a7791/koelsch dts: Rename label spi to qspi, add spi0 alias
From: Geert Uytterhoeven @ 2014-02-25 10:30 UTC (permalink / raw)
To: Simon Horman, Magnus Damm
Cc: linux-sh-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1393324219-3317-1-git-send-email-geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
From: Geert Uytterhoeven <geert+renesas-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
Prepare for the advent of MSIOF SPI, which will be spi1 to spi3.
Signed-off-by: Geert Uytterhoeven <geert+renesas-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
v2:
- No changes
arch/arm/boot/dts/r8a7791-koelsch.dts | 4 ++--
arch/arm/boot/dts/r8a7791.dtsi | 3 ++-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 603af8caae5b..03508cc73e8b 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -157,7 +157,7 @@
renesas,function = "intc";
};
- qspi_pins: spi {
+ qspi_pins: spi0 {
renesas,groups = "qspi_ctrl", "qspi_data4";
renesas,function = "qspi";
};
@@ -182,7 +182,7 @@
status = "okay";
};
-&spi {
+&qspi {
pinctrl-0 = <&qspi_pins>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index cde7bc486f22..3bc4546fa9c5 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -27,6 +27,7 @@
i2c3 = &i2c3;
i2c4 = &i2c4;
i2c5 = &i2c5;
+ spi0 = &qspi;
};
cpus {
@@ -762,7 +763,7 @@
};
};
- spi: spi@e6b10000 {
+ qspi: spi@e6b10000 {
compatible = "renesas,qspi-r8a7791", "renesas,qspi";
reg = <0 0xe6b10000 0 0x2c>;
interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
--
1.7.9.5
--
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
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