* Re: [PATCH v2] ARM: omap3: beagleboard-xm: dt: Add ethernet to the device tree
From: Tony Lindgren @ 2017-01-05 16:51 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Rob Herring, linux-omap,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Benoît Cousson
In-Reply-To: <2557392.58vudoaMIY@avalon>
* Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> [170105 08:49]:
> 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.
OK let's wait a bit on this one then.
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 v2] ARM: omap3: beagleboard-xm: dt: Add ethernet to the device tree
From: Laurent Pinchart @ 2017-01-05 16:48 UTC (permalink / raw)
To: Tony Lindgren
Cc: Rob Herring, linux-omap,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Benoît Cousson
In-Reply-To: <20170105163928.GD4310-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
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.
> > P.S. The display ones are questionable, too. Only OMAP has them and
> > per platform alias names is not something we want.
>
> OK. What about the mmc ones? Otherwise the MMC devices keep moving
> around depending on the kernel version..
--
Regards,
Laurent Pinchart
--
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: dts: am335x-chilisom: Wakeup from RTC-only state by power on event
From: Tony Lindgren @ 2017-01-05 16:47 UTC (permalink / raw)
To: Marcin Niestroj
Cc: Benoît Cousson, Rob Herring, Mark Rutland,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161209113327.19727-1-m.niestroj-z3quKL4iOrmQ6ZAhV5LmOA@public.gmane.org>
* Marcin Niestroj <m.niestroj-z3quKL4iOrmQ6ZAhV5LmOA@public.gmane.org> [161209 03:33]:
> On chiliSOM TPS65217 nWAKEUP pin is connected to AM335x internal RTC
> EXT_WAKEUP input. In RTC-only state TPS65217 is notifying about power on
> events (such as power buton presses) by setting nWAKEUP output
> low. After that it waits 5s for proper device boot. Currently it doesn't
> happen, as the processor doesn't listen for such events. Consequently
> TPS65217 changes state from SLEEP (RTC-only state) to OFF.
>
> Enable EXT_WAKEUP input of AM335x's RTC, so the processor can properly
> detect power on events and recover immediately from RTC-only states,
> without powering off RTC and losing time.
Applying into omap-for-v4.11/dt thanks.
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 03/22] iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs
From: Maxime Ripard @ 2017-01-05 16:46 UTC (permalink / raw)
To: Quentin Schulz
Cc: Mark Rutland, devicetree, Lars-Peter Clausen, open list:THERMAL,
linux-iio, linux-kernel, Sebastian Reichel, Russell King,
Chen-Yu Tsai, Rob Herring, linux-arm-kernel,
Peter Meerwald-Stadler, knaack.h, Bruno Prémont, Lee Jones,
Thomas Petazzoni, Jonathan Cameron, Icenowy Zheng
In-Reply-To: <cf4590d1-5381-f1da-7271-e6e7fee0c479@free-electrons.com>
[-- Attachment #1.1: Type: text/plain, Size: 1415 bytes --]
On Thu, Jan 05, 2017 at 10:50:33AM +0100, Quentin Schulz wrote:
> >>>> +static int axp20x_remove(struct platform_device *pdev)
> >>>> +{
> >>>> + struct axp20x_adc_iio *info;
> >>>> + struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> >>>> +
> >>>> + info = iio_priv(indio_dev);
> >>>
> >>> Nit: you could just reverse the 2 declarations above and join this
> >>> line after struct axp20x_adc_iio *info;
> >>>
> >>>> + regmap_write(info->regmap, AXP20X_ADC_EN1, 0);
> >>>> + regmap_write(info->regmap, AXP20X_ADC_EN2, 0);
> >>>
> >>> The existing VBUS power supply driver enables the VBUS ADC bits itself,
> >>> and does not check them later on. This means if one were to remove this
> >>> axp20x-adc module, the voltage/current readings in the VBUS power supply
> >>> would be invalid. Some sort of workaround would be needed here in this
> >>> driver of the VBUS driver.
> >>>
> >>
> >> That would be one reason to migrate the VBUS driver to use the IIO
> >> channels, wouldn't it?
> >
> > It is, preferably without changing the device tree.
> >
>
> Yes, of course.
Note that you can have something like a test for the iio channel
property in the VBUS driver, and keep the old behaviour in the case
where we wouldn't have it.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 01/22] dt-bindings: iio: adc: add AXP20X/AXP22X ADC DT binding
From: Maxime Ripard @ 2017-01-05 16:40 UTC (permalink / raw)
To: Quentin Schulz
Cc: mark.rutland, devicetree, lars, linux-pm, linux-iio, linux-kernel,
sre, linux, wens, robh+dt, linux-arm-kernel, pmeerw, knaack.h,
bonbons, lee.jones, thomas.petazzoni, jic23, icenowy
In-Reply-To: <20170102163723.7939-2-quentin.schulz@free-electrons.com>
[-- Attachment #1.1: Type: text/plain, Size: 654 bytes --]
On Mon, Jan 02, 2017 at 05:37:01PM +0100, Quentin Schulz wrote:
> The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose the
> battery voltage, battery charge and discharge currents, AC-in and VBUS
> voltages and currents, 2 GPIOs muxable in ADC mode and PMIC temperature.
>
> This adds the device tree binding documentation for the X-Powers AXP20X
> and AXP22X PMICs ADCs.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 v2] ARM: omap3: beagleboard-xm: dt: Add ethernet to the device tree
From: Tony Lindgren @ 2017-01-05 16:39 UTC (permalink / raw)
To: Rob Herring
Cc: Laurent Pinchart, linux-omap,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Benoît Cousson
In-Reply-To: <CAL_Jsq+M7RWiytEA7zPZvR+7CK37WCxN5ZBOQkpjdswjLHL4fA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
* Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [170105 08:28]:
> On Fri, Dec 2, 2016 at 3:11 PM, Laurent Pinchart
> <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> 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.
> P.S. The display ones are questionable, too. Only OMAP has them and
> per platform alias names is not something we want.
OK. What about the mmc ones? Otherwise the MMC devices keep moving
around depending on the kernel version..
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 v4 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma
From: Rob Herring @ 2017-01-05 16:39 UTC (permalink / raw)
To: Appana Durga Kedareswara Rao
Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org,
Soren Brinkmann,
moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w@public.gmane.org,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org,
luis-HiykPkW1eAzzDCI4PIEvbQC/G2K4zDHf@public.gmane.org,
Jose.Abreu-HKixBCOQz3hWk0Htik3J/w@public.gmane.org,
dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <C246CAC1457055469EF09E3A7AC4E11A4A660958-4lKfpRxZ5enZMOc0yg5rMog+Gb3gawCHQz34XiSyOiE@public.gmane.org>
On Wed, Jan 4, 2017 at 11:00 AM, Appana Durga Kedareswara Rao
<appana.durga.rao-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
> Hi Rob,
>
> Thanks for the review....
>
>> On Wed, Jan 04, 2017 at 07:05:53PM +0530, Kedareswara rao Appana wrote:
>> > When VDMA is configured for more than one frame in the h/w for example
>> > h/w is configured for n number of frames and user Submits n number of
>> > frames and triggered the DMA using issue_pending API.
>> > In the current driver flow we are submitting one frame at a time but
>> > we should submit all the n number of frames at one time as the h/w Is
>> > configured for n number of frames.
>>
>> Please fix run-on sentences, capitalization, and word wrapping.
>
> Sure will fix in the next version....
>
> [Snip]
> -- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
>> > +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
>> > @@ -66,6 +66,8 @@ Optional child node properties:
>> > Optional child node properties for VDMA:
>> > - xlnx,genlock-mode: Tells Genlock synchronization is
>> > enabled/disabled in hardware.
>> > +- xlnx,fstore-config: Tells Whether Frame Store Configuration is
>> > + enabled/disabled in hardware.
>>
>> What's the default (when not present)? That should be the most common case.
>> Looks like the code treats this as bool, but that's not clear here. The name is not
>> clear what it is doing. Enabling or disabling the feature?
>
> Default value is zero...
> When this property is present it tells hardware is configured for frame store configuration.
So most people will not want "frame store configuration"?
> Will fix the explanation part in the next version like below.
> xlnx,fstore-config: Tells hardware is configured for frame store configuration.
> Is the above explanation clear???
No, I mean make it obvious from the name of the property:
xlnx,fstore-config-enable or xlnx,fstore-enable
And the description needs to say it is boolean.
Rob
--
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 3/3] ARM: dts: omap5-igep0050: Allow bootloader to configure USB Ethernet MAC
From: Tony Lindgren @ 2017-01-05 16:37 UTC (permalink / raw)
To: Tony Lindgren
Cc: Benoît Cousson, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Laurent Pinchart
In-Reply-To: <20170105163703.1982-1-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
This is slightly different wiring compared to omap5-uevm or pandaboard:
/sys/bus/usb/devices/3-2 hub
/sys/bus/usb/devices/3-2.3 7500
Cc: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/omap5-igep0050.dts | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-igep0050.dts b/arch/arm/boot/dts/omap5-igep0050.dts
--- a/arch/arm/boot/dts/omap5-igep0050.dts
+++ b/arch/arm/boot/dts/omap5-igep0050.dts
@@ -19,6 +19,10 @@
reg = <0x0 0x80000000 0 0x7f000000>; /* 2032 MB */
};
+ aliases {
+ ethernet = ðernet;
+ };
+
gpio_keys {
compatible = "gpio-keys";
pinctrl-0 = <&power_button_pin>;
@@ -116,3 +120,20 @@
OMAP5_IOPAD(0x1ca, PIN_OUTPUT | MUX_MODE6) /* perslimbus2_clock.gpio5_145 */
>;
};
+
+&usbhsehci {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hub@2 {
+ compatible = "usb424,3503";
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet: usbether@3 {
+ compatible = "usb424,7500";
+ reg = <3>;
+ };
+ };
+};
--
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
* [PATCH 2/3] ARM: dts: omap5-uevm: Allow bootloader to configure USB Ethernet MAC
From: Tony Lindgren @ 2017-01-05 16:37 UTC (permalink / raw)
To: Tony Lindgren
Cc: Benoît Cousson, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Laurent Pinchart
In-Reply-To: <20170105163703.1982-1-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Note that with 9730 the wiring is different compared to 9514 found on
beagleboard xm for example.
On beagleboard xm we have:
/sys/bus/usb/devices/1-2 hub
/sys/bus/usb/devices/1-2.1 9514
While on omap5-uevm we have:
/sys/bus/usb/devices/1-2 hub
/sys/bus/usb/devices/1-3 9730
Cc: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/omap5-uevm.dts | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -18,6 +18,10 @@
reg = <0 0x80000000 0 0x7f000000>; /* 2032 MB */
};
+ aliases {
+ ethernet = ðernet;
+ };
+
leds {
compatible = "gpio-leds";
led1 {
@@ -164,6 +168,23 @@
>;
};
+&usbhsehci {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hub@2 {
+ compatible = "usb424,3503";
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ ethernet: usbether@3 {
+ compatible = "usb424,9730";
+ reg = <3>;
+ };
+};
+
&wlcore {
compatible = "ti,wl1837";
};
--
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
* [PATCH 1/3] ARM: dts: pandaboard: Allow bootloader to configure USB Ethernet MAC
From: Tony Lindgren @ 2017-01-05 16:37 UTC (permalink / raw)
To: Tony Lindgren
Cc: Benoît Cousson, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Laurent Pinchart
In-Reply-To: <20170105163703.1982-1-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Inspired by a patch for beagleboard xm by Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>, similar patch also works for
pandaboard. The only difference is that the hub is address 1 instead
of 2.
Cc: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,6 +16,7 @@
aliases {
display0 = &dvi0;
display1 = &hdmi0;
+ ethernet = ðernet;
};
leds: leds {
@@ -520,6 +521,21 @@
&usbhsehci {
phys = <&hsusb1_phy>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hub@1 {
+ compatible = "usb424,9514";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet: usbether@1 {
+ compatible = "usb424,ec00";
+ reg = <1>;
+ };
+ };
};
&dss {
--
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
* [PATCHv2 0/3] Configure USB Ethernet mac for omap4 and 5
From: Tony Lindgren @ 2017-01-05 16:37 UTC (permalink / raw)
To: Tony Lindgren
Cc: Benoît Cousson, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Hi,
Here are these patches reposted using the hub naming.
Regards,
Tony
Tony Lindgren (3):
ARM: dts: pandaboard: Allow bootloader to configure USB Ethernet MAC
ARM: dts: omap5-uevm: Allow bootloader to configure USB Ethernet MAC
ARM: dts: omap5-igep0050: Allow bootloader to configure USB Ethernet
MAC
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 ++++++++++++++++
arch/arm/boot/dts/omap5-igep0050.dts | 21 +++++++++++++++++++++
arch/arm/boot/dts/omap5-uevm.dts | 21 +++++++++++++++++++++
3 files changed, 58 insertions(+)
--
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 V6 1/3] dt-bindings: document common IEEE 802.11 frequency limit property
From: Rob Herring @ 2017-01-05 16:34 UTC (permalink / raw)
To: Johannes Berg
Cc: Rafał Miłecki, linux-wireless, Martin Blumenstingl,
Felix Fietkau, Arend van Spriel, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rafał Miłecki
In-Reply-To: <1483617089.4394.13.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
On Thu, Jan 5, 2017 at 5:51 AM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
>
>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> Do I take that to mean that we'll merge it through the subsystem tree,
> and not go through some common DT tree?
Yes, that's generally the case when bindings are in a series with
driver changes.
Rob
--
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 10/12] ARM: dts: socfpga: add base fpga region and fpga bridges
From: Alan Tull @ 2017-01-05 16:34 UTC (permalink / raw)
To: Dinh Nguyen
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Dinh Nguyen,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Alan Tull
In-Reply-To: <CANk1AXSbqohp73xHpp7e9-37d61ZB-dRAPAFc2eQGRYUnvB+0w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Jan 5, 2017 at 10:28 AM, Alan Tull <atull-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Wed, Jan 4, 2017 at 6:21 PM, Dinh Nguyen <dinguyen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> From: Alan Tull <atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
>>
>> Add h2f and lwh2f bridges.
>> Add base FPGA Region to support DT overlays for FPGA programming.
>> Add l3regs.
>>
>> Signed-off-by: Alan Tull <atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
>> Signed-off-by: Dinh Nguyen <dinguyen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> ---
>> arch/arm/boot/dts/socfpga.dtsi | 31 +++++++++++++++++++++++++++++++
>> 1 file changed, 31 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
>> index de29172..dccc281 100644
>> --- a/arch/arm/boot/dts/socfpga.dtsi
>> +++ b/arch/arm/boot/dts/socfpga.dtsi
>> @@ -93,6 +93,16 @@
>> };
>> };
>>
>> + base_fpga_region {
>> + compatible = "fpga-region";
>> + fpga-mgr = <&fpgamgr0>;
>> + fpga-bridges = <&fpga_bridge0>, <&fpga_bridge1>;
>
> Hi Dinh,
>
> We want to get rid of the 'fpga-bridges' line.
>
>> +
>> + #address-cells = <0x1>;
>> + #size-cells = <0x1>;
>> + ranges = <0 0xff200000 0x100000>;
>
> Should get rid of the ranges line here too. The 'fpga-bridges' and
> 'ranges' line can be added in the overlay.
>
> Alan
>
>> + };
>> +
>> can0: can@ffc00000 {
>> compatible = "bosch,d_can";
>> reg = <0xffc00000 0x1000>;
>> @@ -513,6 +523,22 @@
>> };
>> };
>>
>> + fpga_bridge0: fpga_bridge@ff400000 {
>> + compatible = "altr,socfpga-lwhps2fpga-bridge";
>> + reg = <0xff400000 0x100000>;
>> + resets = <&rst LWHPS2FPGA_RESET>;
>> + reset-names = "lwhps2fpga";
The driver doesn't need 'reset-names' here or below for fpga_bridge1.
>> + clocks = <&l4_main_clk>;
>> + };
>> +
>> + fpga_bridge1: fpga_bridge@ff500000 {
>> + compatible = "altr,socfpga-hps2fpga-bridge";
>> + reg = <0xff500000 0x10000>;
>> + resets = <&rst HPS2FPGA_RESET>;
>> + reset-names = "hps2fpga";
>> + clocks = <&l4_main_clk>;
>> + };
>> +
>> fpgamgr0: fpgamgr@ff706000 {
>> compatible = "altr,socfpga-fpga-mgr";
>> reg = <0xff706000 0x1000
>> @@ -694,6 +720,11 @@
>> arm,prefetch-offset = <7>;
>> };
>>
>> + l3regs@0xff800000 {
>> + compatible = "altr,l3regs", "syscon";
>> + reg = <0xff800000 0x1000>;
>> + };
>> +
>> mmc: dwmmc0@ff704000 {
>> compatible = "altr,socfpga-dw-mshc";
>> reg = <0xff704000 0x1000>;
>> --
>> 2.7.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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] ARM64: dts: exynos5433-tm2: enable HDMI/TV path
From: Javier Martinez Canillas @ 2017-01-05 16:33 UTC (permalink / raw)
To: Andrzej Hajda, linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
Krzysztof Kozlowski
Cc: Bartlomiej Zolnierkiewicz, Marek Szyprowski, Inki Dae,
Rob Herring, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1483629943-31183-3-git-send-email-a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Hello Andrzej,
On 01/05/2017 12:25 PM, Andrzej Hajda wrote:
> TV path consist of following interconnected components:
> - DECON_TV - display controller,
> - HDMI - video signal converter RGB / HDMI,
> - MHL - video signal converter HDMI / MHL,
> - DDC - i2c slave device for EDID reading (on hsi2c_11 bus).
>
> The same path/configuration is used by TM2E board and is
> automatically applied thanks to dts file inclusion.
>
> Signed-off-by: Andrzej Hajda <a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 71 +++++++++++++++++++++++++++
> 1 file changed, 71 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
[snip]
>
> +&hdmi {
> + hpd-gpio = <&gpa3 0 0>;
Same comment than interrupts, please use the GPIO_ACTIVE_HIGH here.
The rest looks good to me.
Reviewed-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 2/2] dt-bindings: Add DT bindings info for FlexRM ring manager
From: Rob Herring @ 2017-01-05 16:32 UTC (permalink / raw)
To: Anup Patel
Cc: Jassi Brar, Mark Rutland, Ray Jui, Scott Branden, Pramod KUMAR,
Rob Rice, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
bcm-kernel-feedback-list@broadcom.com
In-Reply-To: <1483614475-3442-3-git-send-email-anup.patel@broadcom.com>
On Thu, Jan 5, 2017 at 5:07 AM, Anup Patel <anup.patel@broadcom.com> wrote:
> This patch adds device tree bindings document for the FlexRM
> ring manager found on Broadcom iProc SoCs.
>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
> ---
> .../bindings/mailbox/brcm,iproc-flexrm-mbox.txt | 59 ++++++++++++++++++++++
> 1 file changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 2/5] mfd: lm3533: Support initialization from Device Tree
From: Bjorn Andersson @ 2017-01-05 16:30 UTC (permalink / raw)
To: Lee Jones
Cc: Rob Herring, Mark Rutland, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Richard Purdie,
Jacek Anaszewski, Pavel Machek, Jingoo Han, devicetree,
linux-kernel, linux-iio, linux-leds, Bjorn Andersson
In-Reply-To: <20170105074952.GG24225@dell>
On Wed 04 Jan 23:49 PST 2017, Lee Jones wrote:
> On Wed, 04 Jan 2017, Bjorn Andersson wrote:
>
> > On Wed 04 Jan 03:54 PST 2017, Lee Jones wrote:
> >
> > > On Mon, 26 Dec 2016, Bjorn Andersson wrote:
> > >
> > > > From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> > > >
> > > > Implement support for initialization of the lm3533 driver core and
> > > > probing child devices from Device Tree.
> > > >
> >
> > [..]
> >
> > > > @@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533 *lm3533)
> > > > lm3533_device_bl_init(lm3533);
> > > > lm3533_device_led_init(lm3533);
> > > >
> > > > + if (lm3533->dev->of_node) {
> > > > + of_platform_populate(lm3533->dev->of_node, NULL, NULL,
> > > > + lm3533->dev);
> > > > + }
> > >
> > > I think it's save to call of_platform_populate(), even if !of_node.
> > > It will just fail and return an error code, which you are ignoring
> > > anyway.
> > >
> >
> > I thought so too, but that's apparently how you trigger probing children
> > of the root node. So we're stuck with a conditional.
>
> Ah, so this is to protect against the case where DT is present, but a
> node for this device is not (or is disabled), so is left unprobed.
> Then the bind is initiated via I2C? Or something else?
>
In the event that a new lm3533 is spawned from sysfs we would not have
platform_data when entering lm3533_device_init() and just bail early.
Therefor, this issue would be limited to the odd case of lm3533 being
initiated from code (e.g. a board file) on a DT enabled system. In which
case it will create and probe new devices from the root of the DT.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH 10/12] ARM: dts: socfpga: add base fpga region and fpga bridges
From: Alan Tull @ 2017-01-05 16:28 UTC (permalink / raw)
To: Dinh Nguyen
Cc: Alan Tull, devicetree@vger.kernel.org, Dinh Nguyen,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1483575694-29599-11-git-send-email-dinguyen@kernel.org>
On Wed, Jan 4, 2017 at 6:21 PM, Dinh Nguyen <dinguyen@kernel.org> wrote:
> From: Alan Tull <atull@opensource.altera.com>
>
> Add h2f and lwh2f bridges.
> Add base FPGA Region to support DT overlays for FPGA programming.
> Add l3regs.
>
> Signed-off-by: Alan Tull <atull@opensource.altera.com>
> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
> ---
> arch/arm/boot/dts/socfpga.dtsi | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
> index de29172..dccc281 100644
> --- a/arch/arm/boot/dts/socfpga.dtsi
> +++ b/arch/arm/boot/dts/socfpga.dtsi
> @@ -93,6 +93,16 @@
> };
> };
>
> + base_fpga_region {
> + compatible = "fpga-region";
> + fpga-mgr = <&fpgamgr0>;
> + fpga-bridges = <&fpga_bridge0>, <&fpga_bridge1>;
Hi Dinh,
We want to get rid of the 'fpga-bridges' line.
> +
> + #address-cells = <0x1>;
> + #size-cells = <0x1>;
> + ranges = <0 0xff200000 0x100000>;
Should get rid of the ranges line here too. The 'fpga-bridges' and
'ranges' line can be added in the overlay.
Alan
> + };
> +
> can0: can@ffc00000 {
> compatible = "bosch,d_can";
> reg = <0xffc00000 0x1000>;
> @@ -513,6 +523,22 @@
> };
> };
>
> + fpga_bridge0: fpga_bridge@ff400000 {
> + compatible = "altr,socfpga-lwhps2fpga-bridge";
> + reg = <0xff400000 0x100000>;
> + resets = <&rst LWHPS2FPGA_RESET>;
> + reset-names = "lwhps2fpga";
> + clocks = <&l4_main_clk>;
> + };
> +
> + fpga_bridge1: fpga_bridge@ff500000 {
> + compatible = "altr,socfpga-hps2fpga-bridge";
> + reg = <0xff500000 0x10000>;
> + resets = <&rst HPS2FPGA_RESET>;
> + reset-names = "hps2fpga";
> + clocks = <&l4_main_clk>;
> + };
> +
> fpgamgr0: fpgamgr@ff706000 {
> compatible = "altr,socfpga-fpga-mgr";
> reg = <0xff706000 0x1000
> @@ -694,6 +720,11 @@
> arm,prefetch-offset = <7>;
> };
>
> + l3regs@0xff800000 {
> + compatible = "altr,l3regs", "syscon";
> + reg = <0xff800000 0x1000>;
> + };
> +
> mmc: dwmmc0@ff704000 {
> compatible = "altr,socfpga-dw-mshc";
> reg = <0xff704000 0x1000>;
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" 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 v2] ARM: omap3: beagleboard-xm: dt: Add ethernet to the device tree
From: Rob Herring @ 2017-01-05 16:27 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-omap, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Tony Lindgren, Benoît Cousson
In-Reply-To: <1480713097-5931-1-git-send-email-laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
On Fri, Dec 2, 2016 at 3:11 PM, Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> 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.
Rob
P.S. The display ones are questionable, too. Only OMAP has them and
per platform alias names is not something we want.
--
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 v7 05/12] mux: support simplified bindings for single-user gpio mux
From: Peter Rosin @ 2017-01-05 16:21 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Jonathan Corbet, Arnd Bergmann, Greg Kroah-Hartman,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1483532187-28494-6-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
On 2017-01-04 13:16, Peter Rosin wrote:
> Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
> ---
> drivers/mux/mux-core.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++--
> drivers/mux/mux-gpio.c | 56 ++--------------------------------
> include/linux/mux.h | 7 +++++
> 3 files changed, 89 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/mux/mux-core.c b/drivers/mux/mux-core.c
> index 21da15a264ad..d887ae1c0e55 100644
> --- a/drivers/mux/mux-core.c
> +++ b/drivers/mux/mux-core.c
> @@ -15,6 +15,7 @@
> #include <linux/device.h>
> #include <linux/err.h>
> #include <linux/idr.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/module.h>
> #include <linux/mux.h>
> #include <linux/of.h>
> @@ -288,6 +289,63 @@ static struct mux_chip *of_find_mux_chip_by_node(struct device_node *np)
> return dev ? to_mux_chip(dev) : NULL;
> }
>
> +#ifdef CONFIG_MUX_GPIO
> +
> +static int mux_gpio_set(struct mux_control *mux, int state)
> +{
> + struct mux_gpio *mux_gpio = mux_chip_priv(mux->chip);
> + int i;
> +
> + for (i = 0; i < mux_gpio->gpios->ndescs; i++)
> + mux_gpio->val[i] = (state >> i) & 1;
> +
> + gpiod_set_array_value_cansleep(mux_gpio->gpios->ndescs,
> + mux_gpio->gpios->desc,
> + mux_gpio->val);
> +
> + return 0;
> +}
> +
> +static const struct mux_control_ops mux_gpio_ops = {
> + .set = mux_gpio_set,
> +};
> +
> +struct mux_chip *mux_gpio_alloc(struct device *dev)
> +{
> + struct mux_chip *mux_chip;
> + struct mux_gpio *mux_gpio;
> + int pins;
> + int ret;
> +
> + pins = gpiod_count(dev, "mux");
> + if (pins < 0)
> + return ERR_PTR(pins);
> +
> + mux_chip = devm_mux_chip_alloc(dev, 1, sizeof(*mux_gpio) +
> + pins * sizeof(*mux_gpio->val));
> + if (!mux_chip)
> + return ERR_PTR(-ENOMEM);
> +
> + mux_gpio = mux_chip_priv(mux_chip);
> + mux_gpio->val = (int *)(mux_gpio + 1);
> + mux_chip->ops = &mux_gpio_ops;
> +
> + mux_gpio->gpios = devm_gpiod_get_array(dev, "mux", GPIOD_OUT_LOW);
> + if (IS_ERR(mux_gpio->gpios)) {
> + ret = PTR_ERR(mux_gpio->gpios);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "failed to get gpios\n");
> + return ERR_PTR(ret);
> + }
> + WARN_ON(pins != mux_gpio->gpios->ndescs);
> + mux_chip->mux->states = 1 << pins;
> +
> + return mux_chip;
> +}
> +EXPORT_SYMBOL_GPL(mux_gpio_alloc);
> +
> +#endif /* CONFIG_MUX_GPIO */
> +
> struct mux_control *mux_control_get(struct device *dev, const char *mux_name)
> {
> struct device_node *np = dev->of_node;
> @@ -307,9 +365,28 @@ struct mux_control *mux_control_get(struct device *dev, const char *mux_name)
> ret = of_parse_phandle_with_args(np,
> "mux-controls", "#mux-control-cells",
> index, &args);
> +
> +#ifdef CONFIG_MUX_GPIO
> + if (ret == -ENOENT && !mux_name && gpiod_count(dev, "mux") > 0) {
> + mux_chip = mux_gpio_alloc(dev);
> + if (!IS_ERR(mux_chip)) {
> + ret = devm_mux_chip_register(dev, mux_chip);
> + if (ret < 0) {
> + dev_err(dev, "failed to register mux-chip\n");
> + return ERR_PTR(ret);
> + }
> + get_device(&mux_chip->dev);
> + return mux_chip->mux;
> + }
> +
> + ret = PTR_ERR(mux_chip);
> + }
> +#endif
> +
> if (ret) {
> - dev_err(dev, "%s: failed to get mux-control %s(%i)\n",
> - np->full_name, mux_name ?: "", index);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "%s: failed to get mux-control %s(%i)\n",
> + np->full_name, mux_name ?: "", index);
> return ERR_PTR(ret);
> }
>
> diff --git a/drivers/mux/mux-gpio.c b/drivers/mux/mux-gpio.c
> index 76b52bc63470..8a7bfbc0c4bb 100644
> --- a/drivers/mux/mux-gpio.c
> +++ b/drivers/mux/mux-gpio.c
> @@ -11,37 +11,12 @@
> */
>
> #include <linux/err.h>
> -#include <linux/gpio/consumer.h>
> #include <linux/module.h>
> #include <linux/mux.h>
> #include <linux/of_platform.h>
> #include <linux/platform_device.h>
> #include <linux/property.h>
Instead of moving the mux-gpio guts from mux-gpio.c to mux-core.c, I
will instead make CONFIG_MUX_GPIO a bool option (no module possible)
and call it from the mux-core. That will be cleaner and less of a
break of abstractions in my opinion.
Cheers,
Peter
> -struct mux_gpio {
> - struct gpio_descs *gpios;
> - int *val;
> -};
> -
> -static int mux_gpio_set(struct mux_control *mux, int state)
> -{
> - struct mux_gpio *mux_gpio = mux_chip_priv(mux->chip);
> - int i;
> -
> - for (i = 0; i < mux_gpio->gpios->ndescs; i++)
> - mux_gpio->val[i] = (state >> i) & 1;
> -
> - gpiod_set_array_value_cansleep(mux_gpio->gpios->ndescs,
> - mux_gpio->gpios->desc,
> - mux_gpio->val);
> -
> - return 0;
> -}
> -
> -static const struct mux_control_ops mux_gpio_ops = {
> - .set = mux_gpio_set,
> -};
> -
> static const struct of_device_id mux_gpio_dt_ids[] = {
> { .compatible = "mux-gpio", },
> { /* sentinel */ }
> @@ -51,38 +26,13 @@ MODULE_DEVICE_TABLE(of, mux_gpio_dt_ids);
> static int mux_gpio_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - struct device_node *np = dev->of_node;
> struct mux_chip *mux_chip;
> - struct mux_gpio *mux_gpio;
> - int pins;
> u32 idle_state;
> int ret;
>
> - if (!np)
> - return -ENODEV;
> -
> - pins = gpiod_count(dev, "mux");
> - if (pins < 0)
> - return pins;
> -
> - mux_chip = devm_mux_chip_alloc(dev, 1, sizeof(*mux_gpio) +
> - pins * sizeof(*mux_gpio->val));
> - if (!mux_chip)
> - return -ENOMEM;
> -
> - mux_gpio = mux_chip_priv(mux_chip);
> - mux_gpio->val = (int *)(mux_gpio + 1);
> - mux_chip->ops = &mux_gpio_ops;
> -
> - mux_gpio->gpios = devm_gpiod_get_array(dev, "mux", GPIOD_OUT_LOW);
> - if (IS_ERR(mux_gpio->gpios)) {
> - ret = PTR_ERR(mux_gpio->gpios);
> - if (ret != -EPROBE_DEFER)
> - dev_err(dev, "failed to get gpios\n");
> - return ret;
> - }
> - WARN_ON(pins != mux_gpio->gpios->ndescs);
> - mux_chip->mux->states = 1 << pins;
> + mux_chip = mux_gpio_alloc(dev);
> + if (IS_ERR(mux_chip))
> + return PTR_ERR(mux_chip);
>
> ret = device_property_read_u32(dev, "idle-state", &idle_state);
> if (ret >= 0) {
> diff --git a/include/linux/mux.h b/include/linux/mux.h
> index 3b9439927f11..3bfee23cfb8c 100644
> --- a/include/linux/mux.h
> +++ b/include/linux/mux.h
> @@ -241,4 +241,11 @@ struct mux_control *devm_mux_control_get(struct device *dev,
> */
> void devm_mux_control_put(struct device *dev, struct mux_control *mux);
>
> +struct mux_gpio {
> + struct gpio_descs *gpios;
> + int *val;
> +};
> +
> +struct mux_chip *mux_gpio_alloc(struct device *dev);
> +
> #endif /* _LINUX_MUX_H */
>
^ permalink raw reply
* Re: [PATCH 2/3] ARM64: dts: exynos5433: add HDMI node
From: Javier Martinez Canillas @ 2017-01-05 16:21 UTC (permalink / raw)
To: Andrzej Hajda, linux-samsung-soc, Krzysztof Kozlowski
Cc: Bartlomiej Zolnierkiewicz, Marek Szyprowski, Inki Dae,
Rob Herring, Mark Rutland, devicetree
In-Reply-To: <1483629943-31183-2-git-send-email-a.hajda@samsung.com>
Hello Andrzej,
On 01/05/2017 12:25 PM, Andrzej Hajda wrote:
> HDMI converts RGB/I80 signal from DECON_TV to HDMI/TMDS video stream.
>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> ---
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH v2] ARM: omap3: beagleboard-xm: dt: Add ethernet to the device tree
From: Tony Lindgren @ 2017-01-05 16:19 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Benoît Cousson
In-Reply-To: <1480713097-5931-1-git-send-email-laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
* Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> [161202 13:11]:
> 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
Applying this finally into omap-for-v4.11/dt. Will post my related
patches using the hub naming shortly.
Regards,
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] n900 device tree: cleanup
From: Tony Lindgren @ 2017-01-05 16:15 UTC (permalink / raw)
To: Pali Rohár
Cc: Sebastian Reichel, Pavel Machek, kernel list, linux-arm-kernel,
linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75,
patrikbachan, serge, bcousson, robh+dt, mark.rutland, devicetree
In-Reply-To: <201612141328.27244@pali>
* Pali Rohár <pali.rohar@gmail.com> [161214 04:28]:
> On Wednesday 07 December 2016 04:10:48 Sebastian Reichel wrote:
> > Hi Tony,
> >
> > It looks like this fell through the cracks. Apart from inconsistent
> > patch subject:
> >
> > Reviewed-By: Sebastian Reichel <sre@kernel.org>
>
> Fine for me too. Reviewed-By: Pali Rohár <pali.rohar@gmail.com>
Fixing subject line to use "ARM: dts: n900: cleanup" and applying into
omap-for-v4.11/dt.
Tony
^ permalink raw reply
* Re: [PATCH 1/3] ARM64: dts: exynos5433: add DECON_TV node
From: Javier Martinez Canillas @ 2017-01-05 16:11 UTC (permalink / raw)
To: Andrzej Hajda, linux-samsung-soc, Krzysztof Kozlowski
Cc: Bartlomiej Zolnierkiewicz, Marek Szyprowski, Inki Dae,
Rob Herring, Mark Rutland, devicetree
In-Reply-To: <1483629943-31183-1-git-send-email-a.hajda@samsung.com>
Hello Andrzej,
It seems the subject line "arm64" is more common than the capitalized "ARM64".
On 01/05/2017 12:25 PM, Andrzej Hajda wrote:
> DECON_TV is 2nd display controller on Exynos5433, used in HDMI path
> or 2nd DSI path.
>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 44 ++++++++++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> index 8cbfd1d..b47951b 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -821,6 +821,28 @@
> };
> };
>
> + decon_tv: decon@13880000 {
> + compatible = "samsung,exynos5433-decon-tv";
> + reg = <0x13880000 0x20B8>;
> + clocks = <&cmu_disp CLK_PCLK_DECON_TV>,
> + <&cmu_disp CLK_ACLK_DECON_TV>,
> + <&cmu_disp CLK_ACLK_SMMU_TV0X>,
> + <&cmu_disp CLK_ACLK_XIU_TV0X>,
> + <&cmu_disp CLK_PCLK_SMMU_TV0X>,
> + <&cmu_disp CLK_SCLK_DECON_TV_VCLK>,
> + <&cmu_disp CLK_SCLK_DECON_TV_ECLK>;
> + clock-names = "pclk", "aclk_decon", "aclk_smmu_decon0x",
> + "aclk_xiu_decon0x", "pclk_smmu_decon0x",
> + "sclk_decon_vclk", "sclk_decon_eclk";
> + samsung,disp-sysreg = <&syscon_disp>;
> + interrupt-names = "fifo", "vsync", "lcd_sys";
> + interrupts = <0 210 0>, <0 211 0>, <0 212 0>;
You can use the GIC_SPI macro for the interrupt type instead. Also, I think
IRQ_TYPE_NONE (0) isn't a valid flag for GIC interrupts. AFAIU the platform
supports both IRQ_TYPE_EDGE_RISING and IRQ_TYPE_LEVEL_HIGH, and the latter
is what's used consistently in the other Exynos DTS.
Besides this comment, patch looks good to me.
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling
From: Will Deacon @ 2017-01-05 16:07 UTC (permalink / raw)
To: Robin Murphy
Cc: Mark Rutland, robh, devicetree, linux-arm-msm, Jordan Crouse,
iommu
In-Reply-To: <d1a36cc5-265d-6971-f698-29b8d76e7884@arm.com>
On Thu, Jan 05, 2017 at 03:32:50PM +0000, Robin Murphy wrote:
> On 05/01/17 14:47, Will Deacon wrote:
> > On Thu, Jan 05, 2017 at 02:07:31PM +0000, Mark Rutland wrote:
> >> Ok. It would be good to elaborate on what "stalling is useable" means in
> >> the property description. i.e. what specificallty the implementation and
> >> integration need to ensure.
> >
> > We can describe some of those guarantees in the property description, but
> > it's difficult to enumerate them exhaustively. For example, you wouldn't
> > want stalling to lead to data corruption, denial of service, or for the
> > thing to catch fire, but having those as explicit requirements is a bit
> > daft. It's also impossible to check that you thought of everything.
> >
> > Aside from renaming the option, I'm really after an opinion on whether
> > it's better to have one property or combine it with the compatible
> > string, because I can see benefits of both and don't much care either
> > way.
>
> The SMMU implementation side of the decision (i.e. independence of IRQ
> assertion vs. SS) seems like exactly the sort of stuff the compatible
> string already has covered. The integration side I'm less confident can
> be described this way at all - the "this device definitely won't go
> wrong if stalled for an indefinite length of time" is inherently a
> per-master thing, so a single property on the SMMU implying that for
> every device connected to it seems a bit optimistic, and breaks down as
> soon as you have one device in the system for which that isn't true (a
> PCI root complex, say), even if that guy's traffic never crosses paths
> with whichever few devices you actually care about using stalls with.
>
> I think this needs to be some kind of "arm,smmu-stall-safe" property
> placed on individual master device nodes (mad idea: or even an extra
> cell of flags in the IOMMU specifier) to encapsulate both that the given
> device itself is OK with being stalled, and that it's integrated in such
> a way that its stalled transactions cannot disrupt any *other* device
> (e.g. it has a TBU all to itself). Then upon initialising a context bank
> on a suitable SMMU implementation, we set CFCFG based on whatever device
> is being attached to the corresponding domain, and refuse any subsequent
> attempts to attach a non-stallable device to a stalling domain (and
> possibly even vice-versa).
If we're going to add per-master properties, I'd *really* like them to be
independent of the IOMMU in use. That is, we should be able to re-use this
property as part of supporting SVM for platform devices in future.
But I think we agree that we need:
1. A compatible string for the SMMU that can be used to infer the SS
behaviour in the driver
2. A property on the SMMU to say that it's been integrated in such a
way that stalling is safe (doesn't deadlock)
3. A generic master property that says that the device can DMA to
unpinned memory
Anything else?
Will
^ permalink raw reply
* [PATCH 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC
From: sean.wang @ 2017-01-05 16:06 UTC (permalink / raw)
To: mchehab, hdegoede, hkallweit1, robh+dt, mark.rutland,
matthias.bgg
Cc: andi.shyti, hverkuil, sean, ivo.g.dimitrov.75, linux-media,
devicetree, linux-mediatek, linux-arm-kernel, linux-kernel,
keyhaede, Sean Wang
In-Reply-To: <1483632384-8107-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
This patch adds driver for IR controller on
Mediatek MT7623 SoC. Currently testing successfully
on NEC and SONY remote controller only but it should
work on others (lirc, rc-5 and rc-6).
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
drivers/media/rc/Kconfig | 10 ++
drivers/media/rc/Makefile | 1 +
drivers/media/rc/mtk-cir.c | 319 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 330 insertions(+)
create mode 100644 linux-4.8.rc1_p0/drivers/media/rc/mtk-cir.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 370e16e..626c500 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -389,4 +389,14 @@ config IR_SUNXI
To compile this driver as a module, choose M here: the module will
be called sunxi-ir.
+config IR_MTK
+ tristate "Mediatek IR remote control"
+ depends on RC_CORE
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ ---help---
+ Say Y if you want to use Mediatek internal IR Controller
+
+ To compile this driver as a module, choose M here: the module will
+ be called mtk-cir.
+
endif #RC_DEVICES
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 379a5c0..505908d 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -37,3 +37,4 @@ obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
obj-$(CONFIG_RC_ST) += st_rc.o
obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
obj-$(CONFIG_IR_IMG) += img-ir/
+obj-$(CONFIG_IR_MTK) += mtk-cir.o
diff --git a/drivers/media/rc/mtk-cir.c b/drivers/media/rc/mtk-cir.c
new file mode 100644
index 0000000..4fa4cab
--- /dev/null
+++ b/drivers/media/rc/mtk-cir.c
@@ -0,0 +1,319 @@
+/*
+ * Driver for Mediatek MT7623 IR Receiver Controller
+ *
+ * Copyright (C) 2017 Sean Wang <sean.wang@mediatek.com>
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/reset.h>
+#include <media/rc-core.h>
+
+#define MTK_IR_DEV "mtk-ir"
+
+/* Register to enable PWM and IR */
+#define MTK_CONFIG_HIGH_REG 0x0c
+/* Enable IR pulse width detection */
+#define MTK_PWM_EN BIT(13)
+/* Enable IR hardware function */
+#define MTK_IR_EN BIT(0)
+
+/* Register to setting sample period */
+#define MTK_CONFIG_LOW_REG 0x10
+/* Field to set sample period */
+#define CHK_PERIOD 0xC00
+#define MTK_CHK_PERIOD (((CHK_PERIOD) << 8) & (GENMASK(20, 8)))
+#define MTK_CHK_PERIOD_MASK (GENMASK(20, 8))
+
+/* Register to clear state of state machine */
+#define MTK_IRCLR_REG 0x20
+/* Bit to restart IR receiving */
+#define MTK_IRCLR BIT(0)
+
+/* Register containing pulse width data */
+#define MTK_CHKDATA_REG(i) (0x88 + 4 * i)
+
+/* Register to enable IR interrupt */
+#define MTK_IRINT_EN_REG 0xcc
+/* Bit to enable interrupt */
+#define MTK_IRINT_EN BIT(0)
+
+/* Register to ack IR interrupt */
+#define MTK_IRINT_CLR_REG 0xd0
+/* Bit to clear interrupt status */
+#define MTK_IRINT_CLR BIT(0)
+
+/* Number of registers to record the pulse width */
+#define MTK_CHKDATA_SZ 17
+/* Required frequency */
+#define MTK_IR_BASE_CLK 273000000
+/* Frequency after IR internal divider */
+#define MTK_IR_CLK (MTK_IR_BASE_CLK / 4)
+/* Sample period in ns */
+#define MTK_IR_SAMPLE (((1000000000ul / MTK_IR_CLK) * CHK_PERIOD))
+/* Indicate the end of IR data*/
+#define MTK_IR_END(v) (v == 0xff)
+
+/* struct mtk_ir - This is the main datasructure for holding the state
+ * of the driver
+ * @dev: The device pointer
+ * @ir_lock: Make sure that synchronization between remove and ISR
+ * @rc: The rc instrance
+ * @base: The mapped register i/o base
+ * @irq: The IRQ that we are using
+ * @clk: The clock that we are using
+ * @map_name: The name for keymap lookup
+ */
+struct mtk_ir {
+ struct device *dev;
+ /*Protect concurrency between driver removal and ISR*/
+ spinlock_t ir_lock;
+ struct rc_dev *rc;
+ void __iomem *base;
+ int irq;
+ struct clk *clk;
+ const char *map_name;
+};
+
+static void mtk_w32_mask(struct mtk_ir *ir, u32 val, u32 mask, unsigned int reg)
+{
+ u32 tmp;
+
+ tmp = __raw_readl(ir->base + reg);
+ tmp = (tmp & ~mask) | val;
+ __raw_writel(tmp, ir->base + reg);
+}
+
+static void mtk_w32(struct mtk_ir *ir, u32 val, unsigned int reg)
+{
+ __raw_writel(val, ir->base + reg);
+}
+
+static u32 mtk_r32(struct mtk_ir *ir, unsigned int reg)
+{
+ return __raw_readl(ir->base + reg);
+}
+
+static inline void mtk_irq_disable(struct mtk_ir *ir, u32 mask)
+{
+ u32 val;
+
+ val = mtk_r32(ir, MTK_IRINT_EN_REG);
+ mtk_w32(ir, val & ~mask, MTK_IRINT_EN_REG);
+}
+
+static inline void mtk_irq_enable(struct mtk_ir *ir, u32 mask)
+{
+ u32 val;
+
+ val = mtk_r32(ir, MTK_IRINT_EN_REG);
+ mtk_w32(ir, val | mask, MTK_IRINT_EN_REG);
+}
+
+static irqreturn_t mtk_ir_irq(int irqno, void *dev_id)
+{
+ struct mtk_ir *ir = dev_id;
+ u8 wid = 0;
+ u32 i, j, val;
+ DEFINE_IR_RAW_EVENT(rawir);
+
+ spin_lock(&ir->ir_lock);
+
+ mtk_irq_disable(ir, MTK_IRINT_EN);
+
+ /* Reset decoder state machine */
+ ir_raw_event_reset(ir->rc);
+
+ /* First message must be pulse */
+ rawir.pulse = false;
+
+ /* Handle pulse and space until end of message */
+ for (i = 0 ; i < MTK_CHKDATA_SZ ; i++) {
+ val = mtk_r32(ir, MTK_CHKDATA_REG(i));
+ dev_dbg(ir->dev, "@reg%d=0x%08x\n", i, val);
+
+ for (j = 0 ; j < 4 ; j++) {
+ wid = (val & (0xff << j * 8)) >> j * 8;
+ rawir.pulse = !rawir.pulse;
+ rawir.duration = wid * (MTK_IR_SAMPLE + 1);
+ ir_raw_event_store_with_filter(ir->rc, &rawir);
+
+ if (MTK_IR_END(wid))
+ goto end_msg;
+ }
+ }
+end_msg:
+ /* Restart the next receive */
+ mtk_w32_mask(ir, 0x1, MTK_IRCLR, MTK_IRCLR_REG);
+
+ ir_raw_event_set_idle(ir->rc, true);
+ ir_raw_event_handle(ir->rc);
+
+ /* Clear interrupt status */
+ mtk_w32_mask(ir, 0x1, MTK_IRINT_CLR, MTK_IRINT_CLR_REG);
+
+ /* Enable interrupt */
+ mtk_irq_enable(ir, MTK_IRINT_EN);
+
+ spin_unlock(&ir->ir_lock);
+
+ return IRQ_HANDLED;
+}
+
+static int mtk_ir_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *dn = dev->of_node;
+ struct resource *res;
+ struct mtk_ir *ir;
+ u32 val;
+ int ret = 0;
+
+ ir = devm_kzalloc(dev, sizeof(struct mtk_ir), GFP_KERNEL);
+ if (!ir)
+ return -ENOMEM;
+
+ spin_lock_init(&ir->ir_lock);
+
+ ir->dev = dev;
+
+ if (!of_device_is_compatible(dn, "mediatek,mt7623-ir"))
+ return -ENODEV;
+
+ ir->clk = devm_clk_get(dev, "clk");
+ if (IS_ERR(ir->clk)) {
+ dev_err(dev, "failed to get a ir clock.\n");
+ return PTR_ERR(ir->clk);
+ }
+
+ if (clk_prepare_enable(ir->clk)) {
+ dev_err(dev, "try to enable ir_clk failed\n");
+ ret = -EINVAL;
+ goto exit_clkdisable_clk;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ ir->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(ir->base)) {
+ dev_err(dev, "failed to map registers\n");
+ ret = PTR_ERR(ir->base);
+ goto exit_clkdisable_clk;
+ }
+
+ ir->rc = rc_allocate_device();
+ if (!ir->rc) {
+ dev_err(dev, "failed to allocate device\n");
+ ret = -ENOMEM;
+ goto exit_clkdisable_clk;
+ }
+
+ ir->rc->priv = ir;
+ ir->rc->input_name = MTK_IR_DEV;
+ ir->rc->input_phys = "mtk-ir/input0";
+ ir->rc->input_id.bustype = BUS_HOST;
+ ir->rc->input_id.vendor = 0x0001;
+ ir->rc->input_id.product = 0x0001;
+ ir->rc->input_id.version = 0x0001;
+ ir->map_name = of_get_property(dn, "linux,rc-map-name", NULL);
+ ir->rc->map_name = ir->map_name ?: RC_MAP_EMPTY;
+ ir->rc->dev.parent = dev;
+ ir->rc->driver_type = RC_DRIVER_IR_RAW;
+ ir->rc->driver_name = MTK_IR_DEV;
+ ir->rc->allowed_protocols = RC_BIT_ALL;
+ ir->rc->rx_resolution = MTK_IR_SAMPLE;
+
+ ret = rc_register_device(ir->rc);
+ if (ret) {
+ dev_err(dev, "failed to register rc device\n");
+ goto exit_free_dev;
+ }
+
+ platform_set_drvdata(pdev, ir);
+
+ ir->irq = platform_get_irq(pdev, 0);
+ if (ir->irq < 0) {
+ dev_err(dev, "no irq resource\n");
+ ret = ir->irq;
+ goto exit_free_dev;
+ }
+
+ ret = devm_request_irq(dev, ir->irq, mtk_ir_irq, 0, MTK_IR_DEV, ir);
+ if (ret) {
+ dev_err(dev, "failed request irq\n");
+ goto exit_free_dev;
+ }
+
+ mtk_irq_disable(ir, MTK_IRINT_EN);
+
+ val = mtk_r32(ir, MTK_CONFIG_HIGH_REG);
+ val |= MTK_PWM_EN | MTK_IR_EN;
+ mtk_w32(ir, val, MTK_CONFIG_HIGH_REG);
+
+ /* Setting sample period */
+ mtk_w32_mask(ir, MTK_CHK_PERIOD, MTK_CHK_PERIOD_MASK,
+ MTK_CONFIG_LOW_REG);
+
+ mtk_irq_enable(ir, MTK_IRINT_EN);
+
+ dev_info(dev, "initialized MT7623 IR driver\n");
+ return 0;
+
+exit_free_dev:
+ rc_free_device(ir->rc);
+exit_clkdisable_clk:
+ clk_disable_unprepare(ir->clk);
+
+ return ret;
+}
+
+static int mtk_ir_remove(struct platform_device *pdev)
+{
+ unsigned long flags;
+
+ struct mtk_ir *ir = platform_get_drvdata(pdev);
+
+ spin_lock_irqsave(&ir->ir_lock, flags);
+
+ mtk_irq_disable(ir, MTK_IRINT_EN);
+
+ clk_disable_unprepare(ir->clk);
+
+ spin_unlock_irqrestore(&ir->ir_lock, flags);
+
+ rc_unregister_device(ir->rc);
+
+ return 0;
+}
+
+static const struct of_device_id mtk_ir_match[] = {
+ { .compatible = "mediatek,mt7623-ir" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mtk_ir_match);
+
+static struct platform_driver mtk_ir_driver = {
+ .probe = mtk_ir_probe,
+ .remove = mtk_ir_remove,
+ .driver = {
+ .name = MTK_IR_DEV,
+ .of_match_table = mtk_ir_match,
+ },
+};
+
+module_platform_driver(mtk_ir_driver);
+
+MODULE_DESCRIPTION("Mediatek MT7623 IR Receiver Controller Driver");
+MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
+MODULE_LICENSE("GPL");
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox