* Re: [RESEND PATCH] ARM: dts: stm32f469-disco: Fix memory size from 8MB to 16MB
From: Alexandre Torgue @ 2017-01-06 16:33 UTC (permalink / raw)
To: Bruno Meirelles Herrera, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161118145845.30455-1-bmh-Mok47lTHhVP0xEqrn79Vhg@public.gmane.org>
Hi Bruno,
On 11/18/2016 03:58 PM, Bruno Meirelles Herrera wrote:
> From: Bruno Herrera <bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> This patch fix memory size to support 16MB of external SDRAM.
>
> Signed-off-by: Bruno Herrera <bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> arch/arm/boot/dts/stm32f469-disco.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
> index 75f4303..fda12a4 100644
> --- a/arch/arm/boot/dts/stm32f469-disco.dts
> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
> @@ -58,7 +58,7 @@
> };
>
> memory {
> - reg = <0x00000000 0x800000>;
> + reg = <0x00000000 0x1000000>;
> };
>
> aliases {
>
After a little cosmetic change in commit header:
Applied on stm32-dt-for-v4.11-1
Thanks!
Alex
--
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: [RESEND PATCH v1] ARM: dts: stm32f429: Add missing USART3 pin config to STM32F469I-DISCO board
From: Alexandre Torgue @ 2017-01-06 16:34 UTC (permalink / raw)
To: Bruno Meirelles Herrera, robh+dt, mark.rutland, linux,
mcoquelin.stm32
Cc: devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20161118151033.30592-1-bmh@certi.org.br>
Hi Bruno,
On 11/18/2016 04:10 PM, Bruno Meirelles Herrera wrote:
> Including new STM32 maintainer. Rebased at stm32-dt-for-v4.10-1 and
> stm32-dt-for-v4.10-2 branches. It fix the port/pin initialization in
> case boot-loader does not configure/initialize the pins.
> Fixing line wrapping from last patch
>
> This patch adds USART3 pin configuration on PB10/PA11 pins
> for STM32F469I-DISCO board.
>
> Signed-off-by: Bruno Herrera <bruherrera@gmail.com>
> ---
> arch/arm/boot/dts/stm32f429.dtsi | 13 +++++++++++++
> arch/arm/boot/dts/stm32f469-disco.dts | 2 ++
> 2 files changed, 15 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> index e4dae0e..1b8b105 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -316,6 +316,19 @@
> };
> };
>
> + usart3_pins_a: usart3@0 {
> + pins1 {
> + pinmux = <STM32F429_PB10_FUNC_USART3_TX>;
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <0>;
> + };
> + pins2 {
> + pinmux = <STM32F429_PB11_FUNC_USART3_RX>;
> + bias-disable;
> + };
> + };
> +
> usbotg_hs_pins_a: usbotg_hs@0 {
> pins {
> pinmux = <STM32F429_PH4_FUNC_OTG_HS_ULPI_NXT>,
> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
> index 8877c00..75f4303 100644
> --- a/arch/arm/boot/dts/stm32f469-disco.dts
> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
> @@ -79,5 +79,7 @@
> };
>
> &usart3 {
> + pinctrl-0 = <&usart3_pins_a>;
> + pinctrl-names = "default";
> status = "okay";
> };
>
After a little cosmetic change in commit header:
Applied on stm32-dt-for-v4.11-1
Thanks!
Alex
^ permalink raw reply
* Re: [PATCH] i2c: core: helper function to detect slave mode
From: Rob Herring @ 2017-01-06 16:35 UTC (permalink / raw)
To: Luis Oliveira
Cc: wsa@the-dreams.de, Mark Rutland, jarkko.nikula@linux.intel.com,
Andy Shevchenko, mika.westerberg@linux.intel.com,
linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, roliveir, Joao Pinto,
CARLOS.PALMINHA
In-Reply-To: <f4ec62119145bc70c938800c91eb396d30457304.1483636071.git.lolivei@synopsys.com>
On Thu, Jan 5, 2017 at 11:24 AM, Luis Oliveira
<Luis.Oliveira@synopsys.com> wrote:
> This function has the purpose of mode detection by checking the
> device nodes for a reg matching with the I2C_OWN_SLAVE_ADDREESS flag.
> Currently only checks using OF functions (ACPI slave not supported yet).
>
> Signed-off-by: Luis Oliveira <lolivei@synopsys.com>
> ---
> Due to the need of checking if the I2C slave address is our own (in
> other words: if we are the I2C slave) I created a helper function
> (proposed to me by @Andy) to enable that check.
> Currently (because I am not able to test it using ACPI) it only
> supports devicetree declarations.
>
> drivers/i2c/i2c-core.c | 19 +++++++++++++++++++
> include/linux/i2c.h | 1 +
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index 3de95a29024c..48e705b23c59 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -3691,6 +3691,25 @@ int i2c_slave_unregister(struct i2c_client *client)
> return ret;
> }
> EXPORT_SYMBOL_GPL(i2c_slave_unregister);
> +
> +int i2c_slave_mode_detect(struct device *dev)
This can be bool instead. Otherwise, looks good to me.
> +{
> + struct device_node *child;
> + u32 reg;
> +
> + if (IS_BUILTIN(CONFIG_OF) && dev->of_node) {
> + for_each_child_of_node(dev->of_node, child) {
> + of_property_read_u32(child, "reg", ®);
> + if (reg & I2C_OWN_SLAVE_ADDRESS)
> + return 1;
> + }
> + } else if (IS_BUILTIN(CONFIG_ACPI) && ACPI_HANDLE(dev)) {
> + dev_dbg(dev, "ACPI slave is not supported yet\n");
> + }
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(i2c_slave_mode_detect);
> +
> #endif
>
> MODULE_AUTHOR("Simon G. Vogl <simon@tk.uni-linz.ac.at>");
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index b2109c522dec..53cf99569af5 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -282,6 +282,7 @@ enum i2c_slave_event {
>
> extern int i2c_slave_register(struct i2c_client *client, i2c_slave_cb_t slave_cb);
> extern int i2c_slave_unregister(struct i2c_client *client);
> +extern int i2c_slave_mode_detect(struct device *dev);
>
> static inline int i2c_slave_event(struct i2c_client *client,
> enum i2c_slave_event event, u8 *val)
> --
> 2.11.0
>
>
^ permalink raw reply
* Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling
From: Rob Clark @ 2017-01-06 16:36 UTC (permalink / raw)
To: Will Deacon
Cc: Robin Murphy, Mark Rutland, Rob Herring,
devicetree@vger.kernel.org, linux-arm-msm,
iommu@lists.linux-foundation.org, Jordan Crouse
In-Reply-To: <20170105172557.GS679@arm.com>
On Thu, Jan 5, 2017 at 12:25 PM, Will Deacon <will.deacon@arm.com> wrote:
>> That's still got to be a per-master property, not a SMMU property, I
>> think. To illustrate:
>>
>> [A] [B] [C]
>> | |_____|
>> __|______________|___
>> | TBU | | TBU |
>> |_____| SMMU |_____|
>> |__|______________|__|
>> | |
>>
>> Say A and B are instances of some device happy to be stalled, and C is a
>> PCIe RC, and each is attached to their own context bank - enabling
>> stalls for A is definitely fine. However even though B and C are using
>> different context banks, enabling stalls for B might deadlock C if it
>> results in more total outstanding transactions than the TBU's slave port
>> supports. Therefore A can happily claim to be stall-safe, but B cannot
>> due to its integration with respect to C.
>
> So in this case, don't say that B and C can DMA to unpinned memory. You
> need the third property. This property (property 2) is concerned with the
> SMMU itself because, e.g. the way the walker has been integrated can
> cause a deadlock.
fwiw, I guess I'm mostly thinking about case (A).. but I guess in the
(B) case amend my suggestion about adding param to
iommu_set_fault_handler() slightly to consider the enable_stall param
passed in when both (B) and (C) register their fault handlers?
Or I guess the idea about increasing extra cell (which IIUC would let
us add an extra param in dt in the devices iommus property) could also
work. Unless maybe there could be some cases where whether a device
can do stalling is also a function of the driver as well (ie. some
feature needs to be implemented type thing)..
BR,
-R
^ permalink raw reply
* Re: [PATCH v2] ARM: omap3: beagleboard-xm: dt: Add ethernet to the device tree
From: Tony Lindgren @ 2017-01-06 16:49 UTC (permalink / raw)
To: Rob Herring
Cc: Laurent Pinchart, linux-omap,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Benoît Cousson
In-Reply-To: <CAL_JsqKQLd2SFNVKwZDPTKL-spWknEe5aFDT5RZoCnV1qOP=4Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
* Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [170105 10:51]:
> On Thu, Jan 5, 2017 at 10:48 AM, Laurent Pinchart
> <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> wrote:
> > Hello,
> >
> > On Thursday 05 Jan 2017 08:39:29 Tony Lindgren wrote:
> >> * Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [170105 08:28]:
> >> > On Fri, Dec 2, 2016 at 3:11 PM, Laurent Pinchart wrote:
> >> >> The Beagleboard-xM has a LAN9514 USB hub and ethernet controller,
> >> >> connected to port 2 of the OMAP EHCI controller. The board however has
> >> >> no EEPROM to store the ethernet MAC address, which is programmed by the
> >> >> boot loader.
> >> >>
> >> >> To allow Linux to use the same MAC address as the boot loader (or for
> >> >> that matter any fixed MAC address), we need a node in the device tree
> >> >> for the ethernet controller that the boot loader can update at runtime
> >> >> with a local-mac-address property. Add it, along with an alias for the
> >> >> ethernet controller to let the boot loader locate it easily.
> >> >>
> >> >> Signed-off-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> >> >> ---
> >> >> Changes since v1:
> >> >>
> >> >> - Renamed usb2 DT node to hub
> >> >> ---
> >> >>
> >> >> arch/arm/boot/dts/omap3-beagle-xm.dts | 16 ++++++++++++++++
> >> >> 1 file changed, 16 insertions(+)
> >> >>
> >> >> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
> >> >> b/arch/arm/boot/dts/omap3-beagle-xm.dts index
> >> >> 85e297ed0ea1..673cee2234b2 100644
> >> >> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
> >> >> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
> >> >> @@ -27,6 +27,7 @@
> >> >> aliases {
> >> >> display0 = &dvi0;
> >> >> display1 = &tv0;
> >> >> + ethernet = ðernet;
> >> >
> >> > Sorry, just noticed this, but this should be dropped. It's not used
> >> > nor do we want an alias here.
> >>
> >> OK, will update locally as I have not pushed out yet.
> >
> > The ethernet alias is used by U-Boot to locate the ethernet controller and
> > update the MAC address.
>
> Okay. Though with only only one, I don't see why that is hard to find.
> Anyway, this is the least of u-boot's DT abuses.
Applying Laurent's original patch then into omap-for-v4.11/dt.
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 v11 0/8] power: add power sequence library
From: Krzysztof Kozlowski @ 2017-01-06 17:08 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Peter Chen, gregkh, stern, ulf.hansson, broonie, sre, robh+dt,
shawnguo, rjw, dbaryshkov, heiko, linux-arm-kernel, p.zabel,
devicetree, pawel.moll, mark.rutland, linux-usb, arnd, s.hauer,
mail, troy.kisky, festevam, oscar, stephen.boyd, linux-pm,
stillcompiling, linux-kernel, mka, vaibhav.hiremath, gary.bisson,
hverkuil
In-Reply-To: <20170106151841.l6ehqmpben4ilkaf@kozik-lap>
On Fri, Jan 06, 2017 at 05:18:41PM +0200, Krzysztof Kozlowski wrote:
> On Thu, Jan 05, 2017 at 02:01:51PM +0800, Peter Chen wrote:
> > Hi all,
> >
> > This is a follow-up for my last power sequence framework patch set [1].
> > According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> > power sequence instances will be added at postcore_initcall, the match
> > criteria is compatible string first, if the compatible string is not
> > matched between dts and library, it will try to use generic power sequence.
> >
> > The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > if only one power sequence instance is needed, for more power sequences
> > are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub driver).
> >
> > In future, if there are special power sequence requirements, the special
> > power sequence library can be created.
> >
> > This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> > two hot-plug devices to simulate this use case, the related binding
> > change is updated at patch [1/6], The udoo board changes were tested
> > using my last power sequence patch set.[3]
> >
> > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> > need to power on itself before it can be found by ULPI bus.
> >
> > [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> > [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> > [3] http://www.spinics.net/lists/linux-usb/msg142815.html
> >
>
> Unfortunately I was unable to utilize this library to solve Odroid U3
> usb3503/lan9730 power sequence (as a continuation of my old series [0][1]).
>
> The main problem is that power sequence instance (pwrseq_generic.c) is
> not a device. I don't get why it is not a device. It would be rather
> intuitive to me to make it a device. Also it would make life easier
> because you could use all device-like consumer APIs (of getting clocks,
> GPIOs etc). Since it is not a device, it is not possible to use
> regulator consumer API.
>
> I need a regulator because I need to toggle the power.
>
> Other encountered issue is that power sequence happens early, before the
> unused regulators are turned off by the system. However maybe this is
> the necessity from other point of view.
>
> My case is annoyingly over-complicated so I am slowly getting sertain
> that it is not generic. Anyway it looks like this:
>
> EHCI controller
> |
> |--HSIC0--lan9730 (reset is done only through regulator)
> |--HSIC1--usb3504 (it has a reset GPIO... but it is toggled by
> usb3504 driver)
>
> Overall, I want to reset the lan9730. This can be done only through
> power - buck8. buck8 state is an logical OR of register set by I2C and
> GPIO. Thus to turn it off, it is not sufficient just to set register to
> 0x0 because the GPIO is keeping it on. The best way is to switch the
> buck8 to gpio-enable-control thus only GPIO will be toggling it... still
> through the regulator consumer API (because it is an GPIO for the
> regulator, not for the reset!).
>
> However these two seems coupled. On invalid reset sequence, both chips
> die. The usb3504 has its own existing reset sequence and my findings
> show that it should happen after lan9730 reset sequence. Otherwise all
> devices might be lost...
Update - it's working! I skipped entirely the regulator API and I am
playing with its GPIO. This sounds like a hack but finally after few
days of different tries I was able to find a working, reproducible
solution. It turned out that the yours pwrseq is working quite good.
I'll send a follow-up for my board soon.
Best regards,
Krzysztof
>
> [0] http://www.spinics.net/lists/linux-mmc/msg37386.html
> [1] https://github.com/krzk/linux/commits/for-next/odroid-u3-usb3503-lan-boot-fixes-v4
>
^ permalink raw reply
* Re: [PATCH] i2c: core: helper function to detect slave mode
From: Luis Oliveira @ 2017-01-06 17:12 UTC (permalink / raw)
To: Rob Herring, Luis Oliveira
Cc: wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org, Mark Rutland,
jarkko.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
Andy Shevchenko,
mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, roliveir,
Joao Pinto, CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <CAL_JsqK1=R6M=vrW5aqmQtMHUGGws_Hb=VHb9RNcvesjfkCjRA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 06-Jan-17 16:35, Rob Herring wrote:
> On Thu, Jan 5, 2017 at 11:24 AM, Luis Oliveira
> <Luis.Oliveira-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> wrote:
>> This function has the purpose of mode detection by checking the
>> device nodes for a reg matching with the I2C_OWN_SLAVE_ADDREESS flag.
>> Currently only checks using OF functions (ACPI slave not supported yet).
>>
>> Signed-off-by: Luis Oliveira <lolivei-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>> ---
>> Due to the need of checking if the I2C slave address is our own (in
>> other words: if we are the I2C slave) I created a helper function
>> (proposed to me by @Andy) to enable that check.
>> Currently (because I am not able to test it using ACPI) it only
>> supports devicetree declarations.
>>
>> drivers/i2c/i2c-core.c | 19 +++++++++++++++++++
>> include/linux/i2c.h | 1 +
>> 2 files changed, 20 insertions(+)
>>
>> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
>> index 3de95a29024c..48e705b23c59 100644
>> --- a/drivers/i2c/i2c-core.c
>> +++ b/drivers/i2c/i2c-core.c
>> @@ -3691,6 +3691,25 @@ int i2c_slave_unregister(struct i2c_client *client)
>> return ret;
>> }
>> EXPORT_SYMBOL_GPL(i2c_slave_unregister);
>> +
>> +int i2c_slave_mode_detect(struct device *dev)
>
> This can be bool instead. Otherwise, looks good to me.
>
Ok great, thank you.
>> +{
>> + struct device_node *child;
>> + u32 reg;
>> +
>> + if (IS_BUILTIN(CONFIG_OF) && dev->of_node) {
>> + for_each_child_of_node(dev->of_node, child) {
>> + of_property_read_u32(child, "reg", ®);
>> + if (reg & I2C_OWN_SLAVE_ADDRESS)
>> + return 1;
>> + }
>> + } else if (IS_BUILTIN(CONFIG_ACPI) && ACPI_HANDLE(dev)) {
>> + dev_dbg(dev, "ACPI slave is not supported yet\n");
>> + }
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(i2c_slave_mode_detect);
>> +
>> #endif
>>
>> MODULE_AUTHOR("Simon G. Vogl <simon-nD9nYVNVf00W+b/DJNNodF6hYfS7NtTn@public.gmane.org>");
>> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
>> index b2109c522dec..53cf99569af5 100644
>> --- a/include/linux/i2c.h
>> +++ b/include/linux/i2c.h
>> @@ -282,6 +282,7 @@ enum i2c_slave_event {
>>
>> extern int i2c_slave_register(struct i2c_client *client, i2c_slave_cb_t slave_cb);
>> extern int i2c_slave_unregister(struct i2c_client *client);
>> +extern int i2c_slave_mode_detect(struct device *dev);
>>
>> static inline int i2c_slave_event(struct i2c_client *client,
>> enum i2c_slave_event event, u8 *val)
>> --
>> 2.11.0
>>
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] i2c: core: helper function to detect slave mode
From: Luis Oliveira @ 2017-01-06 17:15 UTC (permalink / raw)
To: Andy Shevchenko, Luis Oliveira
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Jarkko Nikula,
Andy Shevchenko, Mika Westerberg, linux-i2c, devicetree,
linux-kernel@vger.kernel.org, Ramiro.Oliveira, Joao Pinto,
CARLOS.PALMINHA
In-Reply-To: <CAHp75VdB+pApFgjFOwWYYQFUmxv5k6OYKgB4fstuy=3=2QesBQ@mail.gmail.com>
On 06-Jan-17 16:29, Andy Shevchenko wrote:
> On Thu, Jan 5, 2017 at 7:24 PM, Luis Oliveira
> <Luis.Oliveira@synopsys.com> wrote:
>> This function has the purpose of mode detection by checking the
>> device nodes for a reg matching with the I2C_OWN_SLAVE_ADDREESS flag.
>> Currently only checks using OF functions (ACPI slave not supported yet).
>
> The code looks good, one important comment below, after addressing it:
>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>
> P.S. Btw, we have Suggested-by tag for giving credit for suggestion.
> Please use it.
>
I will do it in the V2, thank you.
>> --- a/drivers/i2c/i2c-core.c
>> +++ b/drivers/i2c/i2c-core.c
>> @@ -3691,6 +3691,25 @@ int i2c_slave_unregister(struct i2c_client *client)
>
> Please, add kernel doc description here, important thing is to explain
> return codes in Return: section of it.
>
>> +int i2c_slave_mode_detect(struct device *dev)
>> +{
>
>> + struct device_node *child;
>> + u32 reg;
>
> I would consider them as private to the OF branch. But it's really
> minor and up to you (I don't remember if we have such style examples
> in i2c core code).
I can change that in the V2 too.
>
>> +
>> + if (IS_BUILTIN(CONFIG_OF) && dev->of_node) {
>> + for_each_child_of_node(dev->of_node, child) {
>> + of_property_read_u32(child, "reg", ®);
>> + if (reg & I2C_OWN_SLAVE_ADDRESS)
>> + return 1;
>> + }
>> + } else if (IS_BUILTIN(CONFIG_ACPI) && ACPI_HANDLE(dev)) {
>> + dev_dbg(dev, "ACPI slave is not supported yet\n");
>> + }
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(i2c_slave_mode_detect);
>
^ permalink raw reply
* Re: [PATCH] i2c: core: helper function to detect slave mode
From: Andy Shevchenko @ 2017-01-06 17:17 UTC (permalink / raw)
To: Luis Oliveira
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Jarkko Nikula,
Andy Shevchenko, Mika Westerberg,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, devicetree,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w, Joao Pinto,
CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <475d9c2a-da11-97d0-d0b6-37ccd4990f18-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On Fri, Jan 6, 2017 at 7:15 PM, Luis Oliveira
<Luis.Oliveira-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> wrote:
> On 06-Jan-17 16:29, Andy Shevchenko wrote:
>> On Thu, Jan 5, 2017 at 7:24 PM, Luis Oliveira
>> Please, add kernel doc description here, important thing is to explain
>> return codes in Return: section of it.
>>
>>> +int i2c_slave_mode_detect(struct device *dev)
Just to make sure you didn't miss this one.
--
With Best Regards,
Andy Shevchenko
--
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/3] Input: pwm-beeper: add optional enable gpio
From: Andy Shevchenko @ 2017-01-06 17:28 UTC (permalink / raw)
To: David Lechner
Cc: Dmitry Torokhov, Rob Herring, Mark Rutland, linux-input,
devicetree, linux-kernel@vger.kernel.org
In-Reply-To: <1483670635-25060-4-git-send-email-david@lechnology.com>
On Fri, Jan 6, 2017 at 4:43 AM, David Lechner <david@lechnology.com> wrote:
> This adds an optional enable gpio to the pwm-beeper device. This gpio is
> used in cases where the beeper needs to be switched on before using it.
Isn't it a property of pin muxing?
> For
> example, there may be an amplifier that is not always powered on.
This looks like GPIO based fixed voltage regulator.
>
> Tested on LEGO MINDSTORMS EV3, which has a speaker connected to PWM through
> an amplifier. The amplifier has an enable pin that is connected to a gpio.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 3/3] power: bq27xxx: add support for NVRAM R/W access
From: Sebastian Reichel @ 2017-01-06 17:28 UTC (permalink / raw)
To: Matt Ranostay; +Cc: Tony Lindgren, devicetree, linux-pm
In-Reply-To: <CAJ_EiSQjRn=rot7Zu+oB80DruN0qexd+3_PxjXS6_JaF7CY1Bw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3093 bytes --]
Hi,
On Thu, Jan 05, 2017 at 07:23:48PM -0800, Matt Ranostay wrote:
> On Thu, Jan 5, 2017 at 6:34 PM, Matt Ranostay <matt@ranostay.consulting> wrote:
> > On Thu, Jan 5, 2017 at 5:53 PM, Sebastian Reichel <sre@kernel.org> wrote:
> >> On Wed, Jan 04, 2017 at 06:10:07PM -0800, Matt Ranostay wrote:
> >>> Initial support for access and modification of the non-volatile regions
> >>> of the bq27425 fuel gauge DesignEnergy, DesignCapacity, and
> >>> TerminateVoltage settings.
> >>>
> >>> This is intended for fine tuning the fuel gauge state machine for the
> >>> respective battery specifications.
> >>>
> >>> Cc: Sebastian Reichel <sre@kernel.org>
> >>> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
> >>> ---
> >>> drivers/power/supply/bq27xxx_battery_i2c.c | 335 +++++++++++++++++++++++++++++
> >>> include/linux/power/bq27xxx_battery.h | 4 +
> >>> 2 files changed, 339 insertions(+)
> >>
> >> I only skipped over this one, as the changed DT binding requires
> >> quite some changes in this patch anyways. Here are a couple of
> >> comments how I would like to see this implemented:
> >>
> >> Add a patch for the power-supply core, which implements a
> >> structure for the battery info. Something like this:
> >>
> >> struct power_supply_battery_info {
> >> uint32 energy; /* µWh */
> >> uint32 power; /* µAh */
> >> uint32 nominal_voltage; /* µV */
> >> /* ... */
> >> };
> >>
> >> And a function in the core framework, which gets the information
> >> from DT. The function itself should *not* be DT specific, so that
> >> ACPI/platformdata/whatever support can be added later without
> >> modifying every single driver.
> >>
> >> static struct power_supply_battery_info*
> >> power_supply_get_battery_info(struct power_supply *psy) {
> >> if (psy->dt) {
> >> /* get battery phandle or return -ENXIO */
> >> /* fill and return struct */
> >> }
> >>
> >> return -ENOTSUP;
> >> }
> >>
> >> Then call power_supply_get_battery_info() during bq27xxx probe and
> >> use the struct to initialize the registers. Also I expect that
> >> functionality in bq27xxx_battery.c instead of bq27xxx_battery_i2c.c,
> >> since it's not I²C specific.
> >
> > They may not be i2c specific but they are only used by the i2c path of
> > the code currently. Do you think that platform data would ever have a
> > struct to pass with the respective data?
I think it is possible, that there will be some non-i2c bq27xxx
device in the future, that needs this feature.
> > Also it would have to be in bq27xxx_battery_setup() and not
> > bq27xxx_battery_platform_probe() since the former is only thing called
> > by both code paths.
bq27xxx_battery_setup is fine.
> Also there is no bq27xxx_battery_platform_write to even write the
> configuration data.
Just check if the callback exists.
The plan is to convert the 1wire bq27xxx to regmap at some point, so
that the bus-specific bq27xxx files can be dropped by just using
regmap in the core bq27xxx driver.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table
From: Ladislav Michl @ 2017-01-06 17:39 UTC (permalink / raw)
To: Brian Norris
Cc: Tony Lindgren, Teresa Remmet, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benoît Cousson, Rob Herring, Mark Rutland, Adam Ford,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Brian Norris
In-Reply-To: <20170105175619.GA56877-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On Thu, Jan 05, 2017 at 09:56:20AM -0800, Brian Norris wrote:
[snip]
> The best solution would be to try to migrate away from static device
> tree representations of partition info entirely. UBI volumes are best
> where possible. If not, then some other kind of on-flash data structures
> (along the lines of a GPT) with a corresponding MTD partition parser is
> an OK alternative. Unfortunately, there isn't any good standard format
> for this on MTD, so it's typically all custom -- and so people use the
> easiest approach: device tree. And it's even more difficult with NAND,
> which has reliability problems, especially with static data (e.g., read
> disturb).
Just as a side note, there is some work in this area:
https://www.mail-archive.com/u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org/msg232759.html
> Anyway, the parser solution is helpful only if one can properly fix the
> "flag day" first. And it requires a little bit more work to be generally
> useful; I posted some work for this over a year ago, but bikeshedding
> brought it down.
Best regards,
ladis
--
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/3] Input: pwm-beeper: add optional enable gpio
From: David Lechner @ 2017-01-06 17:45 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Dmitry Torokhov, Rob Herring, Mark Rutland, linux-input,
devicetree, linux-kernel@vger.kernel.org
In-Reply-To: <CAHp75VfY4CXOmvT5y2NucKLDvdt4i2LhW5rthke1pdvuAVm7gA@mail.gmail.com>
On 01/06/2017 11:28 AM, Andy Shevchenko wrote:
> On Fri, Jan 6, 2017 at 4:43 AM, David Lechner <david@lechnology.com> wrote:
>> This adds an optional enable gpio to the pwm-beeper device. This gpio is
>> used in cases where the beeper needs to be switched on before using it.
>
> Isn't it a property of pin muxing?
You may want to turn if off when not making a sound to save power.
>
>> For
>> example, there may be an amplifier that is not always powered on.
>
> This looks like GPIO based fixed voltage regulator.
Yes, I think a regulator could work here just as well.
>
>>
>> Tested on LEGO MINDSTORMS EV3, which has a speaker connected to PWM through
>> an amplifier. The amplifier has an enable pin that is connected to a gpio.
>
^ permalink raw reply
* Re: [PATCH] i2c: core: helper function to detect slave mode
From: Luis Oliveira @ 2017-01-06 17:46 UTC (permalink / raw)
To: Andy Shevchenko, Luis Oliveira
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Jarkko Nikula,
Andy Shevchenko, Mika Westerberg, linux-i2c, devicetree,
linux-kernel@vger.kernel.org, Ramiro.Oliveira, Joao Pinto,
CARLOS.PALMINHA
In-Reply-To: <CAHp75Vdv3daVnkFmGc7gXWoqcy+CNgyqdtRXkvTJQpjyJX3eDg@mail.gmail.com>
On 06-Jan-17 17:17, Andy Shevchenko wrote:
> On Fri, Jan 6, 2017 at 7:15 PM, Luis Oliveira
> <Luis.Oliveira@synopsys.com> wrote:
>> On 06-Jan-17 16:29, Andy Shevchenko wrote:
>>> On Thu, Jan 5, 2017 at 7:24 PM, Luis Oliveira
>
>>> Please, add kernel doc description here, important thing is to explain
>>> return codes in Return: section of it.
>>>
>>>> +int i2c_slave_mode_detect(struct device *dev)
>
> Just to make sure you didn't miss this one.
>
>
Yes, I saw it. You were talking of something like this, right?
/**
* i2c_slave_mode_detect - detect operation mode
* @dev: The device owning the bus
*
* This checks the device nodes for a I2C slave by checking the address
* used.
*
* Returns true if a I2C slave is detected, otherwise returns false.
*/
^ permalink raw reply
* Re: [PATCH 1/7] ARM: dts: NSP: DT Clean-ups
From: Florian Fainelli @ 2017-01-06 17:47 UTC (permalink / raw)
To: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Jon Mason,
Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481652831-2744-2-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Tue, 13 Dec 2016 13:13:45 -0500, Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> The QSPI entry was added out of the sequental order that the rest of the
> DTSI file is in. Move it to make it fit in properly. Also, some other
> entries have been added in a non-alphabetical order in the DTS files,
> making them different from the other NSP DTS files. Move the relevant
> peices to make it match. Finally, remove errant new lines.
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
Applied, thanks!
--
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: [PATCH 2/7] ARM: dts: NSP: Correct NAND partition unit address
From: Florian Fainelli @ 2017-01-06 17:47 UTC (permalink / raw)
To: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Jon Mason,
Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481652831-2744-3-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Tue, 13 Dec 2016 13:13:46 -0500, Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> The NAND partition unit address does not match the other NSP device tree
> files. This change makes them uniform.
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
Applied, thanks!
--
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: [PATCH 3/7] ARM: dts: NSP: Add QSPI support to missing boards
From: Florian Fainelli @ 2017-01-06 17:48 UTC (permalink / raw)
To: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Jon Mason,
Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481652831-2744-4-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Tue, 13 Dec 2016 13:13:47 -0500, Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> QSPI device tree entries are present in bcm958625k, but missing from
> bcm958522er, bcm958525er, bcm958525xmc, bcm958622hr, bcm958623hr,
> bcm958625hr, and bcm988312hr. Duplicate the entry in bcm958625k for
> all of those that are missing it (as they are identical).
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
Applied, thanks!
--
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: [PATCH 4/7] ARM: dts: NSP: Add BCM958625K switch ports
From: Florian Fainelli @ 2017-01-06 17:48 UTC (permalink / raw)
To: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Jon Mason,
Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481652831-2744-5-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Tue, 13 Dec 2016 13:13:48 -0500, Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> Add the layout of the switch ports found on the BCM958625K reference
> board. The CPU port is hooked up to the AMAC0 Ethernet controller
> adapter.
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
Applied, thanks!
--
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: [PATCH 5/7] ARM: dts: NSP: Add and enable amac2
From: Florian Fainelli @ 2017-01-06 17:48 UTC (permalink / raw)
To: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Jon Mason,
Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481652831-2744-6-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Tue, 13 Dec 2016 13:13:49 -0500, Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> Add and enable the third AMAC ethernet interface in the device trees for
> the platforms where it is present. Also, enable amac1 on some of the
> platforms where that was missing.
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
Applied, thanks!
--
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: [PATCH 6/7] ARM: dts: NSP: Add Ethernet to NSP XMC
From: Florian Fainelli @ 2017-01-06 17:48 UTC (permalink / raw)
To: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Jon Mason,
Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481652831-2744-7-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Tue, 13 Dec 2016 13:13:50 -0500, Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> Enable the ethernet in the NSP XMC (bcm958525xmc) device tree
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
Applied, thanks!
--
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: [PATCH 7/7] ARM: dts: NSP: Add SD/MMC support
From: Florian Fainelli @ 2017-01-06 17:48 UTC (permalink / raw)
To: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Jon Mason,
Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481652831-2744-8-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Tue, 13 Dec 2016 13:13:51 -0500, Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> Add SD/MMC support to the Broadcom NSP SVK and XMC.
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
Applied, thanks!
--
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: [PATCH v2 5/5] ARM: dts: Add LEGO MINDSTORMS EV3 dts
From: kbuild test robot @ 2017-01-06 18:04 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, Sekhar Nori, David Lechner, Kevin Hilman,
Rob Herring, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1483677228-2325-6-git-send-email-david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]
Hi David,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc2 next-20170106]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/David-Lechner/Support-for-LEGO-MINDSTORMS-EV3/20170107-002649
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> Error: arch/arm/boot/dts/da850-lego-ev3.dts:378.1-6 Label or path usb1 not found
FATAL ERROR: Syntax error parsing input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 22125 bytes --]
^ permalink raw reply
* Re: [PATCH v2 11/19] media: imx: Add CSI subdev driver
From: Steve Longerbeam @ 2017-01-06 18:05 UTC (permalink / raw)
To: Vladimir Zapolskiy, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, fabio.estevam-3arQi8VN3Tc,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, mchehab-DgEjT+Ai2ygdnm+yROfE0A,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, Steve Longerbeam
In-Reply-To: <21b54a7b-1254-a14f-767c-c92feed7433d-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
On 01/04/2017 05:44 AM, Vladimir Zapolskiy wrote:
>
>> diff --git a/drivers/staging/media/imx/imx-csi.c b/drivers/staging/media/imx/imx-csi.c
>> new file mode 100644
>> index 0000000..975eafb
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-csi.c
>> @@ -0,0 +1,638 @@
>> +/*
>> + * V4L2 Capture CSI Subdev for Freescale i.MX5/6 SOC
>> + *
>> + * Copyright (c) 2014-2016 Mentor Graphics Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +#include <linux/module.h>
>> +#include <linux/platform_device.h>
>> +#include <media/v4l2-device.h>
>> +#include <media/v4l2-subdev.h>
>> +#include <media/videobuf2-dma-contig.h>
>> +#include <media/v4l2-of.h>
>> +#include <media/v4l2-ctrls.h>
> Please add the headers alphabetically ordered.
done.
>> +
>> +static int csi_start(struct csi_priv *priv)
>> +{
>> + int ret;
>> +
>> + if (!priv->sensor) {
>> + v4l2_err(&priv->sd, "no sensor attached\n");
>> + return -EINVAL;
>> + }
>> +
>> + ret = csi_setup(priv);
>> + if (ret)
>> + return ret;
>> +
>> + /* start the frame interval monitor */
>> + ret = imx_media_fim_set_stream(priv->fim, priv->sensor, true);
>> + if (ret)
>> + return ret;
>> +
>> + ret = ipu_csi_enable(priv->csi);
>> + if (ret) {
>> + v4l2_err(&priv->sd, "CSI enable error: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + return 0;
> if (ret)
> v4l2_err(&priv->sd, "CSI enable error: %d\n", ret);
>
> return ret;
I failed to cleanup in this path, so it is now:
ret = ipu_csi_enable(priv->csi);
if (ret) {
v4l2_err(&priv->sd, "CSI enable error: %d\n", ret);
goto fim_off;
}
return 0;
fim_off:
if (priv->fim)
imx_media_fim_set_stream(priv->fim, priv->sensor, false);
return ret;
>> +
>> +static int csi_link_setup(struct media_entity *entity,
>> + const struct media_pad *local,
>> + const struct media_pad *remote, u32 flags)
>> +{
>> + struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
>> + struct csi_priv *priv = v4l2_get_subdevdata(sd);
>> + struct v4l2_subdev *remote_sd;
>> +
>> + dev_dbg(priv->dev, "link setup %s -> %s", remote->entity->name,
>> + local->entity->name);
>> +
>> + remote_sd = media_entity_to_v4l2_subdev(remote->entity);
>> +
>> + if (local->flags & MEDIA_PAD_FL_SINK) {
>> + if (flags & MEDIA_LNK_FL_ENABLED) {
>> + if (priv->src_sd)
>> + return -EBUSY;
>> + priv->src_sd = remote_sd;
>> + } else {
>> + priv->src_sd = NULL;
>> + return 0;
> You can remove the return above.
right, fixed.
>
>> +
>> + ret = v4l2_async_register_subdev(&priv->sd);
>> + if (ret)
>> + goto free_ctrls;
>> +
>> + return 0;
>> +free_ctrls:
>> + v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
>> + return ret;
> This is a functionally equal and simplified version:
>
> if (ret)
> v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
>
> return ret;
thanks, done.
>> +
>> +static struct platform_driver imx_csi_driver = {
>> + .probe = imx_csi_probe,
>> + .remove = imx_csi_remove,
>> + .id_table = imx_csi_ids,
>> + .driver = {
>> + .name = "imx-ipuv3-csi",
>> + .owner = THIS_MODULE,
> Please drop .owner.
ok, I tested this and there are no regressions, done
for all modules.
Steve
--
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 12/19] media: imx: Add SMFC subdev driver
From: Steve Longerbeam @ 2017-01-06 18:11 UTC (permalink / raw)
To: Vladimir Zapolskiy, shawnguo, kernel, fabio.estevam, robh+dt,
mark.rutland, linux, mchehab, gregkh, p.zabel
Cc: devel, devicetree, Steve Longerbeam, linux-kernel,
linux-arm-kernel, linux-media
In-Reply-To: <13ff9579-ce8e-9272-ee44-9b597631f6b5@mentor.com>
On 01/04/2017 06:23 AM, Vladimir Zapolskiy wrote:
> On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
>> This is a media entity subdevice driver for the i.MX Sensor Multi-FIFO
>> Controller module. Video frames are received from the CSI and can
>> be routed to various sinks including the i.MX Image Converter for
>> scaling, color-space conversion, motion compensated deinterlacing,
>> and image rotation.
>>
>> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
>> ---
>> drivers/staging/media/imx/Makefile | 1 +
>> drivers/staging/media/imx/imx-smfc.c | 739 +++++++++++++++++++++++++++++++++++
>> 2 files changed, 740 insertions(+)
>> create mode 100644 drivers/staging/media/imx/imx-smfc.c
>>
>> diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile
>> index 133672a..3559d7b 100644
>> --- a/drivers/staging/media/imx/Makefile
>> +++ b/drivers/staging/media/imx/Makefile
>> @@ -5,4 +5,5 @@ obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media.o
>> obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-common.o
>>
>> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-csi.o
>> +obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-smfc.o
> May be
>
> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-csi.o imx-smfc.o
I'd prefer to keep them on separate lines, to indicate they
are all built as separate modules.
>
>>
>> diff --git a/drivers/staging/media/imx/imx-smfc.c b/drivers/staging/media/imx/imx-smfc.c
>> new file mode 100644
>> index 0000000..565048c
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-smfc.c
>> @@ -0,0 +1,739 @@
>> +/*
>> + * V4L2 Capture SMFC Subdev for Freescale i.MX5/6 SOC
>> + *
>> + * This subdevice handles capture of raw/unconverted video frames
>> + * from the CSI, directly to memory via the Sensor Multi-FIFO Controller.
>> + *
>> + * Copyright (c) 2012-2016 Mentor Graphics Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +#include <linux/module.h>
>> +#include <linux/delay.h>
>> +#include <linux/fs.h>
>> +#include <linux/timer.h>
>> +#include <linux/sched.h>
>> +#include <linux/slab.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/spinlock.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pinctrl/consumer.h>
>> +#include <media/v4l2-device.h>
>> +#include <media/v4l2-ioctl.h>
>> +#include <media/videobuf2-dma-contig.h>
>> +#include <media/v4l2-subdev.h>
>> +#include <media/v4l2-of.h>
>> +#include <media/v4l2-ctrls.h>
> Please sort the list of headers alphabetically.
done.
>
>> +static irqreturn_t imx_smfc_eof_interrupt(int irq, void *dev_id)
>> +{
>> + struct imx_smfc_priv *priv = dev_id;
>> + struct imx_media_dma_buf *done, *next;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&priv->irqlock, flags);
> spin_lock(&priv->irqlock) should be sufficient.
yes thanks.
>
>> +
>> +static const struct platform_device_id imx_smfc_ids[] = {
>> + { .name = "imx-ipuv3-smfc" },
>> + { },
>> +};
>> +MODULE_DEVICE_TABLE(platform, imx_smfc_ids);
>> +
>> +static struct platform_driver imx_smfc_driver = {
>> + .probe = imx_smfc_probe,
>> + .remove = imx_smfc_remove,
>> + .id_table = imx_smfc_ids,
>> + .driver = {
>> + .name = "imx-ipuv3-smfc",
>> + .owner = THIS_MODULE,
> You can drop owner assignment.
done.
Steve
^ permalink raw reply
* [PATCH v2] i2c: core: helper function to detect slave mode
From: Luis Oliveira @ 2017-01-06 18:14 UTC (permalink / raw)
To: wsa, robh+dt, mark.rutland, jarkko.nikula, andriy.shevchenko,
mika.westerberg, linux-i2c, devicetree, linux-kernel
Cc: Luis.Oliveira, Ramiro.Oliveira, Joao.Pinto, CARLOS.PALMINHA
This function has the purpose of mode detection by checking the
device nodes for a reg matching with the I2C_OWN_SLAVE_ADDREESS flag.
Currently only checks using OF functions (ACPI slave not supported yet).
Signed-off-by: Luis Oliveira <lolivei@synopsys.com>
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
Changes V1->V2:
- Kernel doc added to i2c-core. (@Andy)
- Moved the definitions to the OF branch. (@Andy)
- Changed the return type from int to bool. (@Rob)
drivers/i2c/i2c-core.c | 28 ++++++++++++++++++++++++++++
include/linux/i2c.h | 1 +
2 files changed, 29 insertions(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 3de95a29024c..937605e65976 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -3691,6 +3691,34 @@ int i2c_slave_unregister(struct i2c_client *client)
return ret;
}
EXPORT_SYMBOL_GPL(i2c_slave_unregister);
+
+/**
+ * i2c_slave_mode_detect - detect operation mode
+ * @dev: The device owning the bus
+ *
+ * This checks the device nodes for a I2C slave by checking the address
+ * used.
+ *
+ * Returns true if a I2C slave is detected, otherwise returns false.
+ */
+bool i2c_slave_mode_detect(struct device *dev)
+{
+ if (IS_BUILTIN(CONFIG_OF) && dev->of_node) {
+ struct device_node *child;
+ u32 reg;
+
+ for_each_child_of_node(dev->of_node, child) {
+ of_property_read_u32(child, "reg", ®);
+ if (reg & I2C_OWN_SLAVE_ADDRESS)
+ return true;
+ }
+ } else if (IS_BUILTIN(CONFIG_ACPI) && ACPI_HANDLE(dev)) {
+ dev_dbg(dev, "ACPI slave is not supported yet\n");
+ }
+ return false;
+}
+EXPORT_SYMBOL_GPL(i2c_slave_mode_detect);
+
#endif
MODULE_AUTHOR("Simon G. Vogl <simon@tk.uni-linz.ac.at>");
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index b2109c522dec..bfc3e0cee57e 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -282,6 +282,7 @@ enum i2c_slave_event {
extern int i2c_slave_register(struct i2c_client *client, i2c_slave_cb_t slave_cb);
extern int i2c_slave_unregister(struct i2c_client *client);
+extern bool i2c_slave_mode_detect(struct device *dev);
static inline int i2c_slave_event(struct i2c_client *client,
enum i2c_slave_event event, u8 *val)
--
2.11.0
^ 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