Re: [GIT PULL] On-demand device probing
On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote: > Hi Rob, > > here is the pull request you asked for, with no changes from the version > that I posted last to the list. > > The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: > > Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) > > are available in the git repository at: > > git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git > on-demand-probes-for-next That's not a signed tag :( Anyway, I REALLY don't like this series (sorry for the delay in reviewing them, normally I trust Rob's judgement...) I can't see adding calls like this all over the tree just to solve a bus-specific problem, you are adding of_* calls where they aren't needed, or wanted, at all. What is the root-problem of your delay in device probing? I read your last patch series and I can't seem to figure out what the issue is that this is solving in any "better" way from the existing deferred probing. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 13/20] usb: phy: Probe phy devices on demand
On Tue, Sep 29, 2015 at 11:10:51AM +0200, Tomeu Vizoso wrote: > When looking up a phy through its OF node, probe it if it hasn't > already. > > The goal is to reduce deferred probes to a minimum, as it makes it very > cumbersome to find out why a device failed to probe, and can introduce > very big delays in when a critical device is probed. > > Signed-off-by: Tomeu Vizoso > --- > > > drivers/usb/phy/phy.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c > index 98f75d2842b7..fb0b650bb494 100644 > --- a/drivers/usb/phy/phy.c > +++ b/drivers/usb/phy/phy.c > @@ -15,6 +15,7 @@ > #include > #include > #include > +#include > > #include > > @@ -196,6 +197,8 @@ struct usb_phy *devm_usb_get_phy_by_node(struct device > *dev, > goto err0; > } > > + of_device_probe(node); Ugh, this "sprinkling" of calls all over different subsystems like this isn't ok. Why is of just so broken that it has to do crap like this? I really don't like this solution / series at all, sorry. We have deferred probing, if you need stuff like that (where the dependancy tree isn't in order), how slow is that really? What is taking your hardware so long to init that warrents this being spread all across the tree? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 04/20] of: add function to allow probing a device from a OF node
On Tue, Sep 29, 2015 at 11:10:42AM +0200, Tomeu Vizoso wrote: > Walks the OF tree up and finds the closest ancestor that has a struct > device associated with it, probing it if isn't bound to a driver yet. > > The above should ensure that the dependency represented by the passed OF > node is available, because probing a device should cause its descendants > to be probed as well (when they get registered). > > Subsystems can use this when looking up resources for drivers, to reduce > the chances of deferred probes because of the probing order of devices. How do subsystems know to do this? Under what situation? Why is this a of-only type thing? Why don't other busses need this? I don't like to special-case a single bus like this at all if possible... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 01/20] driver core: handle -EPROBE_DEFER from bus_type.match()
On Tue, Sep 29, 2015 at 11:10:39AM +0200, Tomeu Vizoso wrote:
> Lets implementations of the match() callback in struct bus_type to
> return errors and if it's -EPROBE_DEFER then queue the device for
> deferred probing.
>
> This is useful to buses such as AMBA in which devices are registered
> before their matching information can be retrieved from the HW
> (typically because a clock driver hasn't probed yet).
>
> Signed-off-by: Tomeu Vizoso
> ---
>
>
> drivers/base/dd.c | 24 ++--
> include/linux/device.h | 2 +-
> 2 files changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index be0eb4639128..7dc04ee81c8b 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -488,6 +488,7 @@ static int __device_attach_driver(struct device_driver
> *drv, void *_data)
> struct device_attach_data *data = _data;
> struct device *dev = data->dev;
> bool async_allowed;
> + int ret;
>
> /*
>* Check if device has already been claimed. This may
> @@ -498,8 +499,17 @@ static int __device_attach_driver(struct device_driver
> *drv, void *_data)
> if (dev->driver)
> return -EBUSY;
>
> - if (!driver_match_device(drv, dev))
> + ret = driver_match_device(drv, dev);
> + if (!ret)
> return 0;
> + else if (ret < 0) {
> + if (ret == -EPROBE_DEFER) {
> + dev_dbg(dev, "Device match requests probe deferral\n");
> + driver_deferred_probe_add(dev);
> + } else
> + dev_warn(dev, "Bus failed to match device: %d", ret);
This is going to start to cause warnings where there were previously
none, which isn't going to be a good idea. It's completly normal for a
bus to not match a device, let's not be noisy for no good reason, unless
you are going to deal with all of the confused user emails?
You do this a bunch in this patch, please don't.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
GREETINGS TO YOU
You have Been Issued with the SUM of 1.1 Million Euro from the Weir Family Donation.Kindly get in Touch with your details Following: Full Names ... Address: Phone No: Country ... Age .. Check Link HTTP://www.bbc.com/news/uk-scotland-glasgow-west-18801698 We await your reply. Chris and Colin Weir --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PowerPC: Move Freescale device tree files into fsl folder
On Fri, Sep 18, 2015 at 12:00:24PM +0800, Hongtao Jia wrote: > It makes no sense that some Freescale device tree files are in fsl > directory while some others not. This patch move Freescale device tree > files into fsl folder. To do that the following two steps are made: > - Move Freescale device tree files into fsl folder. > - Update the include path in these files from "fsl/*.dtsi" to "*.dtsi". > > Please add "fsl/" prefix when you make dtb using Makefile. > > Signed-off-by: Jia Hongtao This broke cuImage -- I made this change when applying: diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 4eec430..99e4487 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -364,6 +364,9 @@ $(obj)/cuImage.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits) $(obj)/cuImage.%: vmlinux $(obj)/%.dtb $(wrapperbits) $(call if_changed,wrap,cuboot-$*,,$(obj)/$*.dtb) +$(obj)/cuImage.%: vmlinux $(obj)/fsl/%.dtb $(wrapperbits) + $(call if_changed,wrap,cuboot-$*,,$(obj)/fsl/$*.dtb) + $(obj)/simpleImage.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits) $(call if_changed,wrap,simpleboot-$*,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz) -Scott -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND v4.1 0/5] Mailbox: Provide support STi based platforms
On 16 October 2015 at 12:51, Lee Jones wrote: > Hi Jassi, > > [Resending the updated patch-set this time] > > This should be it. Exciting times! > > ST's platforms currently support a maximum of 5 Mailboxes, one for > each of the supported co-processors situated on the platform. Each > Mailbox is divided up into 4 instances which consist of 32 channels. > Messages are passed between the application and co-processors using > shared memory areas. > > Also included in the set is an example Client which should be generic > enough to use as a testing environment for all Mailbox IPs which use > shared memory or the API to pass messages. With small changes, it > should also be able to test more extravagant implementations. > > v3 -> v4: > - More protection in MBOX_BASE() MACRO > - Remove unused tx-only marker > > v2 => v3: > - Controller >- Shared (DT <=> Device Driver) defines removed >- Return actual error codes instead of NULL in xlate() >- Not passing 'direction' configuration via DT anymore > - Removed all accompanying configuration checking code > - Test F/W >- Allow Rx-only and Tx-only controllers to be tested >- Cater for controllers requiring pre-Tx 'signal' to be sent >- Supply 'wr-' message debugfs file > - When written to, will Tx message through Mailbox Framework > - When read from, will print out a hexdump of Rx'ed message > > v1 => v2: > - New MACRO() to obtain base address for a given instance > - Move locking into the structure it protects > - Stop checking for 'ready' state when sending data > - Don't clear channel data (that belongs to the API) > - #define register offsets instead of providing via pdata > - Register driver with module_platform_driver() > > Lee Jones (5): > mailbox: dt: Supply bindings for ST's Mailbox IP > mailbox: Add support for ST's Mailbox IP > ARM: STi: stih407-family: Add nodes for Mailbox > mailbox: Add generic mechanism for testing Mailbox Controllers > ARM: STi: DT: STiH407: Enable Mailbox testing facility > Picked patches 1,2 & 4. Thanks for overhauling the old drivers, now we have fewer lines and simpler but more complete driver. Thanks. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/16] PM / OPP: Add 'supply-names' binding
On 16-10-15, 12:16, Stephen Boyd wrote: > On 10/16, Viresh Kumar wrote: > > On 15-10-15, 17:22, Stephen Boyd wrote: > > > I'm lost why we need this property at all. What happened to using > > > > > > opp-microvolt-0 = <1 2 3>; > > > opp-microvolt-1 = <1>; > > > opp-microvolt-2 = <3 4 5>; > > > etc. > > > > Perhaps you are confusing this with the bindings we came up for > > picking right voltage levels based on the cuts/version of the hardware > > we are running on. The problem that Lee Jones mentioned and that can > > be used in your case as well. > > Isn't that what this patch series is for? Hehe, no. Okay here is the problem statement: We have two supplies for a device and the device node will have something like: name1-supply = <&supply1>; name2-supply = <&supply2>; And the OPP node needs to have voltages for both of them: opp-microvolt = , ; Where XYZ(1) are for supply1 and XYZ(2) are for supply2. Now we need to identify the supplies for which the values are present here and their order as well. How do we do that? The way I am suggesting is to add a property in opp node which will keep "name1" and "name2" in it. -- viresh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] net: phy: smsc: disable energy detect mode
On some boards the energy enable detect mode leads in
trouble with some switches, so make the enabling of
this mode configurable through DT.
Signed-off-by: Heiko Schocher
---
Changes in v2:
- add comments from Florian Fainelli
- I did not change disable property name into enable
because I fear to break existing behaviour
- add smsc vendor prefix
- remove CONFIG_OF and use __maybe_unused
- introduce "phy-handle" ability into ti,cpsw
driver, so I can remove bogus:
if (!of_node && dev->parent->of_node)
of_node = dev->parent->of_node;
construct. Therefore new patch for the ti,cpsw
driver is necessary.
.../devicetree/bindings/net/smsc-lan87xx.txt | 24 ++
drivers/net/phy/smsc.c | 19 -
2 files changed, 38 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/smsc-lan87xx.txt
diff --git a/Documentation/devicetree/bindings/net/smsc-lan87xx.txt
b/Documentation/devicetree/bindings/net/smsc-lan87xx.txt
new file mode 100644
index 000..974edd5
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/smsc-lan87xx.txt
@@ -0,0 +1,24 @@
+SMSC LAN87xx Ethernet PHY
+
+Some boards require special tuning values. Configure them
+through an Ethernet OF device node.
+
+Optional properties:
+
+- smsc,disable-energy-detect:
+ If set, do not enable energy detect mode for the SMSC phy.
+ default: enable energy detect mode
+
+Examples:
+smsc phy with disabled energy detect mode on an am335x based board.
+&davinci_mdio {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&davinci_mdio_default>;
+ pinctrl-1 = <&davinci_mdio_sleep>;
+ status = "okay";
+
+ ethernetphy0: ethernet-phy@0 {
+ reg = <0>;
+ smsc,disable-energy-detect;
+ };
+};
diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index 70b0895..dc2da87 100644
--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -43,16 +43,25 @@ static int smsc_phy_ack_interrupt(struct phy_device *phydev)
static int smsc_phy_config_init(struct phy_device *phydev)
{
+ int __maybe_unused len;
+ struct device *dev __maybe_unused = &phydev->dev;
+ struct device_node *of_node __maybe_unused = dev->of_node;
int rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
+ int enable_energy = 1;
if (rc < 0)
return rc;
- /* Enable energy detect mode for this SMSC Transceivers */
- rc = phy_write(phydev, MII_LAN83C185_CTRL_STATUS,
- rc | MII_LAN83C185_EDPWRDOWN);
- if (rc < 0)
- return rc;
+ if (of_find_property(of_node, "smsc,disable-energy-detect", &len))
+ enable_energy = 0;
+
+ if (enable_energy) {
+ /* Enable energy detect mode for this SMSC Transceivers */
+ rc = phy_write(phydev, MII_LAN83C185_CTRL_STATUS,
+ rc | MII_LAN83C185_EDPWRDOWN);
+ if (rc < 0)
+ return rc;
+ }
return smsc_phy_ack_interrupt(phydev);
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] net, phy, smsc: add posibility to disable energy detect mode
On some boards the energy enable detect mode leads in trouble with some switches, so make the enabling of this mode configurable through DT. Therefore the property "smsc,disable-energy-detect" is introduced. Patch 1 introduces phy-handle support for the ti,cpsw driver. This is needed now for the smsc phy. Patch 2 adds the disable energy mode functionality to the smsc phy Changes in v2: - add comments from Florian Fainelli - I did not change disable property name into enable because I fear to break existing behaviour - add smsc vendor prefix - remove CONFIG_OF and use __maybe_unused - introduce "phy-handle" ability into ti,cpsw driver, so I can remove bogus: if (!of_node && dev->parent->of_node) of_node = dev->parent->of_node; construct. Therefore new patch for the ti,cpsw driver is necessary. Heiko Schocher (2): drivers: net: cpsw: add phy-handle parsing net: phy: smsc: disable energy detect mode Documentation/devicetree/bindings/net/cpsw.txt | 1 + .../devicetree/bindings/net/smsc-lan87xx.txt | 24 ++ drivers/net/ethernet/ti/cpsw.c | 15 ++ drivers/net/phy/smsc.c | 19 - 4 files changed, 50 insertions(+), 9 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/smsc-lan87xx.txt -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: phy: smsc: disable energy detect mode
Hello Florian, Am 16.10.2015 um 18:27 schrieb Florian Fainelli: 2015-10-13 21:17 GMT-07:00 Heiko Schocher : Hello Florian, Am 13.10.2015 um 21:26 schrieb Florian Fainelli: On 12/10/15 22:13, Heiko Schocher wrote: On some boards the energy enable detect mode leads in trouble with some switches, so make the enabling of this mode configurable through DT. Signed-off-by: Heiko Schocher --- .../devicetree/bindings/net/smsc-lan87xx.txt | 19 + drivers/net/phy/smsc.c | 24 +- 2 files changed, 38 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/smsc-lan87xx.txt diff --git a/Documentation/devicetree/bindings/net/smsc-lan87xx.txt b/Documentation/devicetree/bindings/net/smsc-lan87xx.txt new file mode 100644 index 000..39aa1dc --- /dev/null +++ b/Documentation/devicetree/bindings/net/smsc-lan87xx.txt @@ -0,0 +1,19 @@ +SMSC LAN87xx Ethernet PHY + +Some boards require special tuning values. Configure them +through an Ethernet OF device node. + +Optional properties: + +- disable-energy-detect: + If set, do not enable energy detect mode for the SMSC phy. + default: enable energy detect mode Although energy detection is something that is implemented by many PHYs, I am not sure a generic property is suitable here, I would prefix that with the SMSC vendor prefix here to make it clear this only applies to this PHY. Hmm... but all PHYs should be able to enable, disable it in some way, or? It may not always be controlled directly at the PHY level, sometimes this is something that needs cooperation with the Ethernet MAC as well in case of integrated designs. Ah, ok! Would not you want to make it a reverse property here though, something like this: smsc,energy-detect: boolean, when present indicates the PHY reliably supports energy detection Yes, that was also my first thought, but currently, on this PHYs energy detect mode is on ... and if I introduce such a property, it will disable it for all existing boards, because property is missing ... so, maybe I break boards ... Fair enough, how about smsc,disabled-energy-detect or something like that then? Yes, changed it to "smsc,disable-energy-detect" bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/4] mtd: brcmnand: Fix pointer type-cast in brcmnand_write()
> -Original Message- > From: Ray Jui [mailto:r...@broadcom.com] > Sent: 16 October 2015 21:06 > To: Anup Patel; David Woodhouse; Brian Norris; linux-...@lists.infradead.org > Cc: Rob Herring; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala; Catalin > Marinas; Will Deacon; Scott Branden; Florian Fainelli; Pramod Kumar; Vikram > Prakash; Sandeep Tripathy; linux-arm-ker...@lists.infradead.org; > devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; bcm-kernel- > feedback-list > Subject: Re: [PATCH v2 1/4] mtd: brcmnand: Fix pointer type-cast in > brcmnand_write() > > Correct me if I remember it wrong, but I thought this patch has already been > merged by Brian? Yes, patch1 and patch2 were merged by Brian. I realized this after I had send-out v2. Anyways we can ignore patch1 and patch2 from this patchset because they are same as v1. Regards, Anup -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] phy: rcar-gen3-usb2: add runtime ID/VBUS pin detection
Hi,
On Tuesday 13 October 2015 03:52 PM, Yoshihiro Shimoda wrote:
> This patch adds support for runtime ID/VBUS pin detection if
> the channel 0 of R-Car gen3 is used. So, we are able to use
> the channel as both host and peripheral.
>
> Signed-off-by: Yoshihiro Shimoda
> ---
> .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 2 +
> drivers/phy/phy-rcar-gen3-usb2.c | 43
> +-
> 2 files changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> index 589f5c0..b30a98a 100644
> --- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> +++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> @@ -18,6 +18,7 @@ properties. This is because HSUSB has registers to select
> USB 2.0 host or
> peripheral at that channel:
> - reg: offset and length of the partial HSUSB register block.
> - reg-names: must be "hsusb".
> +- interrupts: interrupt specifier for the PHY.
>
> Example (R-Car H3):
>
> @@ -25,6 +26,7 @@ Example (R-Car H3):
> compatible = "renesas,usb2-phy-r8a7795";
> reg = <0 0xee080200 0 0x700>, <0 0xe6590100 0 0x100>;
> reg-names = "usb2_host", "hsusb";
> + interrupts = ;
> clocks = <&mstp7_clks R8A7795_CLK_EHCI0>,
><&mstp7_clks R8A7795_CLK_HSUSB>;
> };
> diff --git a/drivers/phy/phy-rcar-gen3-usb2.c
> b/drivers/phy/phy-rcar-gen3-usb2.c
> index 03d7079..40d0005 100644
> --- a/drivers/phy/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/phy-rcar-gen3-usb2.c
> @@ -12,6 +12,7 @@
> * published by the Free Software Foundation.
> */
>
> +#include
> #include
> #include
> #include
> @@ -26,14 +27,18 @@
> #define USB2_SPD_RSM_TIMSET 0x10c
> #define USB2_OC_TIMSET 0x110
> #define USB2_COMMCTRL0x600
> +#define USB2_OBINTSTA0x604
> +#define USB2_OBINTEN 0x608
> #define USB2_VBCTRL 0x60c
> #define USB2_LINECTRL1 0x610
> #define USB2_ADPCTRL 0x630
>
> /* INT_ENABLE */
> +#define USB2_INT_ENABLE_UCOM_INTEN BIT(3)
> #define USB2_INT_ENABLE_USBH_INTB_EN BIT(2)
> #define USB2_INT_ENABLE_USBH_INTA_EN BIT(1)
> -#define USB2_INT_ENABLE_INIT (USB2_INT_ENABLE_USBH_INTB_EN | \
> +#define USB2_INT_ENABLE_INIT (USB2_INT_ENABLE_UCOM_INTEN | \
> + USB2_INT_ENABLE_USBH_INTB_EN | \
>USB2_INT_ENABLE_USBH_INTA_EN)
>
> /* USBCTR */
> @@ -49,6 +54,12 @@
> /* COMMCTRL */
> #define USB2_COMMCTRL_OTG_PERI BIT(31) /* 1 = Peripheral mode
> */
>
> +/* OBINTSTA and OBINTEN */
> +#define USB2_OBINT_SESSVLDCHGBIT(12)
> +#define USB2_OBINT_IDDIGCHG BIT(11)
> +#define USB2_OBINT_BITS (USB2_OBINT_SESSVLDCHG | \
> + USB2_OBINT_IDDIGCHG)
> +
> /* VBCTRL */
> #define USB2_VBCTRL_DRVVBUSSEL BIT(8)
>
> @@ -178,6 +189,9 @@ static void rcar_gen3_init_otg(struct rcar_gen3_chan *ch)
>
> tmp = readl(usb2_base + USB2_VBCTRL);
> writel(tmp | USB2_VBCTRL_DRVVBUSSEL, usb2_base + USB2_VBCTRL);
> + writel(USB2_OBINT_BITS, usb2_base + USB2_OBINTSTA);
> + tmp = readl(usb2_base + USB2_OBINTEN);
> + writel(tmp | USB2_OBINT_BITS, usb2_base + USB2_OBINTEN);
> tmp = readl(usb2_base + USB2_ADPCTRL);
> writel(tmp | USB2_ADPCTRL_IDPULLUP, usb2_base + USB2_ADPCTRL);
> tmp = readl(usb2_base + USB2_LINECTRL1);
> @@ -289,6 +303,23 @@ static struct phy_ops rcar_gen3_phy_usb2_ops = {
> .owner = THIS_MODULE,
> };
>
> +static irqreturn_t rcar_gen3_phy_usb2_irq(int irq, void *_ch)
> +{
> + struct rcar_gen3_chan *ch = _ch;
> + void __iomem *usb2_base = ch->usb2.base;
> + u32 status = readl(usb2_base + USB2_OBINTSTA);
> + irqreturn_t ret = IRQ_NONE;
> +
> + if (status & USB2_OBINT_BITS) {
> + dev_dbg(&ch->phy->dev, "%s: %08x\n", __func__, status);
This can be removed or use dev_vdbg.
> + writel(USB2_OBINT_BITS, usb2_base + USB2_OBINTSTA);
> + rcar_gen3_device_recognition(ch);
> + ret = IRQ_HANDLED;
> + }
> +
> + return ret;
> +}
> +
> static const struct of_device_id rcar_gen3_phy_usb2_match_table[] = {
> { .compatible = "renesas,usb2-phy-r8a7795" },
> { }
> @@ -323,9 +354,19 @@ static int rcar_gen3_phy_usb2_probe(struct
> platform_device *pdev)
>
> /* To avoid error message by devm_ioremap_resource() */
> if (res) {
> + int ret, irq;
> +
> channel->hsusb.base = devm_ioremap_resource(dev, res);
> if (IS_ERR(channel->hsusb.base))
> channel->hsusb.base = NULL;
> + /* call request_irq for OTG */
> + ret = irq = platform_get_irq(pd
Re: [PATCH v4 2/3] phy: rcar-gen3-usb2: change the mode to OTG on the combined channel
Hi,
On Tuesday 13 October 2015 03:52 PM, Yoshihiro Shimoda wrote:
> To use the channel 0 of R-Car gen3 as periperal mode, This patch changes
> the mode to OTG instead of HOST. Then, this driver needs to set some
> registers to enable host mode and detects ID pin and VBUS pin at
> phy_init() timing.
>
> For now, the channel 0 can be used as host mode only.
>
> Signed-off-by: Yoshihiro Shimoda
> ---
> drivers/phy/phy-rcar-gen3-usb2.c | 126
> ++-
> 1 file changed, 124 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/phy/phy-rcar-gen3-usb2.c
> b/drivers/phy/phy-rcar-gen3-usb2.c
> index d90dfcf..03d7079 100644
> --- a/drivers/phy/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/phy-rcar-gen3-usb2.c
> @@ -25,6 +25,10 @@
> #define USB2_USBCTR 0x00c
> #define USB2_SPD_RSM_TIMSET 0x10c
> #define USB2_OC_TIMSET 0x110
> +#define USB2_COMMCTRL0x600
> +#define USB2_VBCTRL 0x60c
> +#define USB2_LINECTRL1 0x610
> +#define USB2_ADPCTRL 0x630
>
> /* INT_ENABLE */
> #define USB2_INT_ENABLE_USBH_INTB_EN BIT(2)
> @@ -42,6 +46,24 @@
> /* OC_TIMSET */
> #define USB2_OC_TIMSET_INIT 0x000209ab
>
> +/* COMMCTRL */
> +#define USB2_COMMCTRL_OTG_PERI BIT(31) /* 1 = Peripheral mode
> */
> +
> +/* VBCTRL */
> +#define USB2_VBCTRL_DRVVBUSSEL BIT(8)
> +
> +/* LINECTRL1 */
> +#define USB2_LINECTRL1_DPRPD_EN BIT(19)
> +#define USB2_LINECTRL1_DP_RPDBIT(18)
> +#define USB2_LINECTRL1_DMRPD_EN BIT(17)
> +#define USB2_LINECTRL1_DM_RPDBIT(16)
> +
> +/* ADPCTRL */
> +#define USB2_ADPCTRL_OTGSESSVLD BIT(20)
> +#define USB2_ADPCTRL_IDDIG BIT(19)
> +#define USB2_ADPCTRL_IDPULLUPBIT(5) /* 1 = ID sampling is
> enabled */
> +#define USB2_ADPCTRL_DRVVBUS BIT(4)
> +
> /*** HSUSB registers (original offset is +0x100) ***/
> #define HSUSB_LPSTS 0x02
> #define HSUSB_UGCTRL20x84
> @@ -68,6 +90,104 @@ struct rcar_gen3_chan {
> spinlock_t lock;
> };
>
> +static void rcar_gen3_set_host_mode(struct rcar_gen3_chan *ch, int host)
> +{
> + void __iomem *usb2_base = ch->usb2.base;
> + u32 tmp = readl(usb2_base + USB2_COMMCTRL);
It's your preference but I'd like to have something like val instead of tmp.
> +
> + dev_dbg(&ch->phy->dev, "%s: %08x, %d\n", __func__, tmp, host);
This shoulod be dev_vdbg.
> + if (host)
> + tmp &= ~USB2_COMMCTRL_OTG_PERI;
> + else
> + tmp |= USB2_COMMCTRL_OTG_PERI;
> + writel(tmp, usb2_base + USB2_COMMCTRL);
> +}
> +
> +static void rcar_gen3_set_linectrl(struct rcar_gen3_chan *ch, int dp, int dm)
> +{
> + void __iomem *usb2_base = ch->usb2.base;
> + u32 tmp = readl(usb2_base + USB2_LINECTRL1);
> +
> + dev_dbg(&ch->phy->dev, "%s: %08x, %d, %d\n", __func__, tmp, dp, dm);
same here.
> + tmp &= ~(USB2_LINECTRL1_DP_RPD | USB2_LINECTRL1_DM_RPD);
> + if (dp)
> + tmp |= USB2_LINECTRL1_DP_RPD;
> + if (dm)
> + tmp |= USB2_LINECTRL1_DM_RPD;
> + writel(tmp, usb2_base + USB2_LINECTRL1);
> +}
> +
> +static void rcar_gen3_enable_vbus_ctrl(struct rcar_gen3_chan *ch, int vbus)
> +{
> + void __iomem *usb2_base = ch->usb2.base;
> + u32 tmp = readl(usb2_base + USB2_ADPCTRL);
> +
> + dev_dbg(&ch->phy->dev, "%s: %08x, %d\n", __func__, tmp, vbus);
here too.
> + if (vbus)
> + tmp |= USB2_ADPCTRL_DRVVBUS;
> + else
> + tmp &= ~USB2_ADPCTRL_DRVVBUS;
> + writel(tmp, usb2_base + USB2_ADPCTRL);
> +}
> +
> +static void rcar_gen3_init_for_host(struct rcar_gen3_chan *ch)
> +{
> + rcar_gen3_set_linectrl(ch, 1, 1);
> + rcar_gen3_set_host_mode(ch, 1);
> + rcar_gen3_enable_vbus_ctrl(ch, 1);
> +}
> +
> +static void rcar_gen3_init_for_peri(struct rcar_gen3_chan *ch)
> +{
> + rcar_gen3_set_linectrl(ch, 0, 1);
> + rcar_gen3_set_host_mode(ch, 0);
> + rcar_gen3_enable_vbus_ctrl(ch, 0);
> +}
> +
> +static bool rcar_gen3_check_vbus(struct rcar_gen3_chan *ch)
> +{
> + return !!(readl(ch->usb2.base + USB2_ADPCTRL) &
> + USB2_ADPCTRL_OTGSESSVLD);
> +}
> +
> +static bool rcar_gen3_check_id(struct rcar_gen3_chan *ch)
> +{
> + return !!(readl(ch->usb2.base + USB2_ADPCTRL) & USB2_ADPCTRL_IDDIG);
> +}
> +
> +static void rcar_gen3_device_recognition(struct rcar_gen3_chan *ch)
> +{
> + bool is_host = true;
> +
> + if (rcar_gen3_check_id(ch)) {
> + /* B-device? */
> + if (rcar_gen3_check_vbus(ch))
This can be rcar_gen3_check_id(ch) && rcar_gen3_check_vbus(ch) no?
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver
Hi,
On Tuesday 13 October 2015 03:52 PM, Yoshihiro Shimoda wrote:
> This patch adds support for R-Car generation 3 USB2 PHY driver.
> This SoC has 3 EHCI/OHCI channels, and the channel 0 is shared
> with the HSUSB (USB2.0 peripheral) device. And each channel has
> independent registers about the PHYs.
>
> So, the purpose of this driver is:
> 1) initializes some registers of SoC specific to use the
> {ehci,ohci}-platform driver.
>
> 2) detects id pin to select host or peripheral on the channel 0.
>
> For now, this driver only supports 1) above.
>
> Signed-off-by: Yoshihiro Shimoda
> ---
> .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 37
> drivers/phy/Kconfig| 8 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-rcar-gen3-usb2.c | 240
> +
> 4 files changed, 286 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> create mode 100644 drivers/phy/phy-rcar-gen3-usb2.c
>
> diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> new file mode 100644
> index 000..589f5c0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> @@ -0,0 +1,37 @@
> +* Renesas R-Car generation 3 USB 2.0 PHY
> +
> +This file provides information on what the device node for the R-Car
> generation
> +3 USB 2.0 PHY contains.
> +
> +Required properties:
> +- compatible: "renesas,usb2-phy-r8a7795" if the device is a part of an
> R8A7795
> + SoC.
> +- reg: offset and length of the partial USB 2.0 Host register block.
> +- reg-names: must be "usb2_host".
> +- clocks: clock phandle and specifier pair(s).
> +- #phy-cells: see phy-bindings.txt in the same directory, must be <0>.
> +
> +Optional properties:
> +To use a USB channel where USB 2.0 Host and HSUSB (USB 2.0 Peripheral) are
> +combined, the device tree node should set HSUSB properties to reg and
> reg-names
> +properties. This is because HSUSB has registers to select USB 2.0 host or
> +peripheral at that channel:
> +- reg: offset and length of the partial HSUSB register block.
> +- reg-names: must be "hsusb".
> +
> +Example (R-Car H3):
> +
> + usb-phy@ee080200 {
> + compatible = "renesas,usb2-phy-r8a7795";
> + reg = <0 0xee080200 0 0x700>, <0 0xe6590100 0 0x100>;
> + reg-names = "usb2_host", "hsusb";
> + clocks = <&mstp7_clks R8A7795_CLK_EHCI0>,
> + <&mstp7_clks R8A7795_CLK_HSUSB>;
> + };
> +
> + usb-phy@ee0a0200 {
> + compatible = "renesas,usb2-phy-r8a7795";
> + reg = <0 0xee0a0200 0 0x6ff>;
> + reg-names = "usb2_host";
> + clocks = <&mstp7_clks R8A7795_CLK_EHCI0>;
> + };
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 7eb5859d..45c6131 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -118,6 +118,14 @@ config PHY_RCAR_GEN2
> help
> Support for USB PHY found on Renesas R-Car generation 2 SoCs.
>
> +config PHY_RCAR_GEN3_USB2
> + tristate "Renesas R-Car generation 3 USB 2.0 PHY driver"
> + depends on OF
> + depends on ARCH_SHMOBILE
The depends on can be moved to a single line.
> + depends on GENERIC_PHY
all the PHY drivers inside drivers/phy directory use select PHY. Please
use select here.
> + help
> + Support for USB 2.0 PHY found on Renesas R-Car generation 3 SoCs.
> +
> config OMAP_CONTROL_PHY
> tristate "OMAP CONTROL PHY Driver"
> depends on ARCH_OMAP2PLUS || COMPILE_TEST
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 075db1a..91d7a62 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -17,6 +17,7 @@ obj-$(CONFIG_PHY_MVEBU_SATA)+=
> phy-mvebu-sata.o
> obj-$(CONFIG_PHY_MIPHY28LP) += phy-miphy28lp.o
> obj-$(CONFIG_PHY_MIPHY365X) += phy-miphy365x.o
> obj-$(CONFIG_PHY_RCAR_GEN2) += phy-rcar-gen2.o
> +obj-$(CONFIG_PHY_RCAR_GEN3_USB2) += phy-rcar-gen3-usb2.o
> obj-$(CONFIG_OMAP_CONTROL_PHY) += phy-omap-control.o
> obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
> obj-$(CONFIG_TI_PIPE3) += phy-ti-pipe3.o
> diff --git a/drivers/phy/phy-rcar-gen3-usb2.c
> b/drivers/phy/phy-rcar-gen3-usb2.c
> new file mode 100644
> index 000..d90dfcf
> --- /dev/null
> +++ b/drivers/phy/phy-rcar-gen3-usb2.c
Add a MAINTAINER entry for this file if there is no one else.
> @@ -0,0 +1,240 @@
> +/*
> + * Renesas R-Car Gen3 for USB2.0 PHY driver
> + *
> + * Copyright (C) 2015 Renesas Electronics Corporation
> + *
> + * This is based on the phy-rcar-gen2 driver:
> + * Copyright (C) 2014 Renesas Solutions Corp.
> + * Copyright (C) 2014 Cogent Embedded, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
>
Re: [V2,1/2] powerpc/fsl: Add PCI node in device tree of bsc9132qds
On Fri, Oct 16, 2015 at 05:01:10PM +0800, Zhiqiang Hou wrote: > From: Harninder Rai > > Signed-off-by: Harninder Rai > Signed-off-by: Minghuan Lian > Change-Id: I4355add4a92d1fcf514843aea5ecadd2e2517969 > Reviewed-on: http://git.am.freescale.net:8181/2454 > Reviewed-by: Zang Tiefei-R61911 > Reviewed-by: Kushwaha Prabhakar-B32579 > Reviewed-by: Fleming Andrew-AFLEMING > Tested-by: Fleming Andrew-AFLEMING Again: Get rid of the gerrit stuff. And where is your signoff? -Scott -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] clk: rockchip: Add sclk_mipidsi_24m for mipi dsi
On 10/17/2015 05:39 AM, Stephen Boyd wrote:
On 10/10, Chris Zhong wrote:
sclk_mipidsi_24m is the gating of mipi dsi phy.
Signed-off-by: Chris Zhong
---
Acked-by: Stephen Boyd
drivers/clk/rockchip/clk-rk3288.c | 2 +-
include/dt-bindings/clock/rk3288-cru.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index 9040878..c7d7ebf 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -709,7 +709,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
GATE(SCLK_LCDC_PWM1, "sclk_lcdc_pwm1", "xin24m", 0,
RK3288_CLKGATE_CON(13), 11, GFLAGS),
GATE(SCLK_PVTM_CORE, "sclk_pvtm_core", "xin24m", 0,
RK3288_CLKGATE_CON(5), 9, GFLAGS),
GATE(SCLK_PVTM_GPU, "sclk_pvtm_gpu", "xin24m", 0,
RK3288_CLKGATE_CON(5), 10, GFLAGS),
- GATE(0, "sclk_mipidsi_24m", "xin24m", 0, RK3288_CLKGATE_CON(5), 15,
GFLAGS),
+ GATE(SCLK_MIPI_24M, "sclk_mipidsi_24m", "xin24m", 0,
RK3288_CLKGATE_CON(5), 15, GFLAGS),
It would have been better to make #defines for all these clocks
even if they weren't going to be used here. Then we could have
applied this patch directly to clk tree without having a clk tree
to arm-soc dependency.
Thanks for your great suggestion, I'll defines all clocks at next
version patch serial
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] misc: Add w2sg0004 gps receiver driver
Hi Nikolaus,
[auto build test WARNING on tty/tty-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/H-Nikolaus-Schaller/UART-slave-device-support-goldelico-version/20151017-021238
config: xtensa-allmodconfig (attached as .config)
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=xtensa
All warnings (new ones prefixed by >>):
>> drivers/misc/w2sg0004.c:361:12: warning: 'w2sg_data_suspend' defined but not
>> used [-Wunused-function]
static int w2sg_data_suspend(struct device *dev)
^
>> drivers/misc/w2sg0004.c:399:12: warning: 'w2sg_data_resume' defined but not
>> used [-Wunused-function]
static int w2sg_data_resume(struct device *dev)
^
vim +/w2sg_data_suspend +361 drivers/misc/w2sg0004.c
355 uart_register_rx_notification(data->uart, NULL, NULL);
356 uart_register_slave(data->uart, NULL);
357 }
358 return 0;
359 }
360
> 361 static int w2sg_data_suspend(struct device *dev)
362 {
363 struct w2sg_data *data = dev_get_drvdata(dev);
364
365 spin_lock_irq(&data->lock);
366 data->suspended = true;
367 spin_unlock_irq(&data->lock);
368
369 cancel_delayed_work_sync(&data->work);
370
371 w2sg_data_set_lna_power(data); /* shuts down if needed */
372
373 if (data->state == W2SG_PULSE) {
374 msleep(10);
375 gpio_set_value_cansleep(data->on_off_gpio, 1);
376 data->last_toggle = jiffies;
377 data->is_on = !data->is_on;
378 data->state = W2SG_NOPULSE;
379 }
380
381 if (data->state == W2SG_NOPULSE) {
382 msleep(10);
383 data->state = W2SG_IDLE;
384 }
385
386 if (data->is_on) {
387 pr_info("GPS off for suspend %d %d %d\n",
data->requested,
388 data->is_on, data->lna_is_off);
389
390 gpio_set_value_cansleep(data->on_off_gpio, 0);
391 msleep(10);
392 gpio_set_value_cansleep(data->on_off_gpio, 1);
393 data->is_on = 0;
394 }
395
396 return 0;
397 }
398
> 399 static int w2sg_data_resume(struct device *dev)
400 {
401 struct w2sg_data *data = dev_get_drvdata(dev);
402
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH v2 1/2] clk: samsung: exynos5250: Add DISP1 clocks
On 10/17/15 03:56, Tomeu Vizoso wrote: > On 16 October 2015 at 19:26, Stephen Boyd wrote: >> On 10/16, Michael Turquette wrote: >>> Quoting Krzysztof Kozlowski (2015-10-15 16:46:27) On 15.10.2015 19:31, Tomeu Vizoso wrote: > When the DISP1 power domain is powered off, there's two clocks that need > to be temporarily reparented to OSC, and back to their original parents > when the domain is powered on again. > > We expose these two clocks in the DT bindings so that the DT node of the > power domain can reference them. > > Signed-off-by: Tomeu Vizoso > Acked-by: Stephen Boyd > --- > > Changes in v2: > - Reuse mout_aclk200_p > - Rename div_aclk300 as div_aclk300_disp > > drivers/clk/samsung/clk-exynos5250.c | 14 +- > include/dt-bindings/clock/exynos5250.h | 4 +++- > 2 files changed, 16 insertions(+), 2 deletions(-) > Reviewed-by: Krzysztof Kozlowski >>> >>> Applied to clk-next. >>> >> >> I think Tomeu wanted to take this through arm-soc? Otherwise >> we'll need to provide a stable branch for the dt header. > > Hi, Stephen is right, the second patch depends on this one. > So...how can I take 2nd patch of this series in samsung(arm-soc) tree? And this series shouldn't be for fixes for 4.3?...Mike how do you think? Thanks, Kukjin -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2/3] powerpc: dts: p1022si: Add fsl,wake-on-filer for eTSEC
On Thu, Oct 01, 2015 at 01:10:22PM +0300, Claudiu Manoil wrote: > Enable the "wake-on-filer" (aka. wake on user defined packet) > wake on lan capability for the eTSEC ethernet nodes. > > Cc: Li Yang > Cc: Zhao Chenhui > > Signed-off-by: Claudiu Manoil > --- > arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 2 ++ > 1 file changed, 2 insertions(+) Acked-by: Scott Wood -Scott -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] ARM: dts: bcm5301x: Add BCM SVK DT files
Hi Hauke,
On 15-10-16 03:42 PM, Hauke Mehrtens wrote:
On 10/17/2015 12:38 AM, Scott Branden wrote:
Hi Jon,
No need for the board in the compatible string.
I think the board should be named here, so we could take some code
branches based on the board, if it would have bad wiring for example.
The device tree wiki says:
"The first string in the list specifies the exact device that the node
represents"
http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property
The exact device here is the board not the SoC.
Thanks for link to understand this compatible string more.
Hauke
On 15-10-16 02:41 PM, Hauke Mehrtens wrote:
On 10/16/2015 12:24 AM, Jon Mason wrote:
Add device tree files for Broadcom Northstar based SVKs. Since the
bcm5301x.dtsi already exists, all that is necessary is the dts files to
enable the UARTs. With these files, the SVKs are able to boot to shell.
Signed-off-by: Jon Mason
Acked-by: Hauke Mehrtens
Acked-by: Scott Branden
---
arch/arm/boot/dts/Makefile | 5 +++-
arch/arm/boot/dts/bcm94708.dts | 56
+++
arch/arm/boot/dts/bcm94709.dts | 56
+++
arch/arm/boot/dts/bcm953012k.dts | 63
4 files changed, 179 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/bcm94708.dts
create mode 100644 arch/arm/boot/dts/bcm94709.dts
create mode 100644 arch/arm/boot/dts/bcm953012k.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 233159d..96a1b58 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -72,7 +72,10 @@ dtb-$(CONFIG_ARCH_BCM_5301X) += \
bcm47081-buffalo-wzr-900dhp.dtb \
bcm4709-asus-rt-ac87u.dtb \
bcm4709-buffalo-wxr-1900dhp.dtb \
-bcm4709-netgear-r8000.dtb
+bcm4709-netgear-r8000.dtb \
+bcm94708.dtb \
+bcm94709.dtb \
+bcm953012k.dtb
dtb-$(CONFIG_ARCH_BCM_63XX) += \
bcm963138dvt.dtb
dtb-$(CONFIG_ARCH_BCM_CYGNUS) += \
diff --git a/arch/arm/boot/dts/bcm94708.dts
b/arch/arm/boot/dts/bcm94708.dts
new file mode 100644
index 000..49682d6
--- /dev/null
+++ b/arch/arm/boot/dts/bcm94708.dts
@@ -0,0 +1,56 @@
+/*
+ * BSD LICENSE
+ *
+ * Copyright(c) 2015 Broadcom Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above
copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ ** Neither the name of Broadcom Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
+ */
+
+/dts-v1/;
+
+#include "bcm4708.dtsi"
+
+/ {
+model = "NorthStar SVK (BCM94708)";
+compatible = "brcm,bcm94708", "brcm,bcm4708";
no need for brcm,bcm94708
+
+aliases {
+serial0 = &uart0;
+};
+
+chosen {
+bootargs = "console=ttyS0,115200";
+};
+
+memory {
+reg = <0x 0x0800>;
+};
+};
+
+&uart0 {
+status = "okay";
+};
diff --git a/arch/arm/boot/dts/bcm94709.dts
b/arch/arm/boot/dts/bcm94709.dts
new file mode 100644
index 000..4ab19c0
--- /dev/null
+++ b/arch/arm/boot/dts/bcm94709.dts
@@ -0,0 +1,56 @@
+/*
+ * BSD LICENSE
+ *
+ * Copyright(c) 2015 Broadcom Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above
copyright
+ * notice, this
[PATCHv2 1/3] ARM: dt: fpga: Added binding docs for Xilinx Zynq FPGA manager.
Signed-off-by: Moritz Fischer
---
v2:
- Clock names are now a required property
- Removed interrupt-parent property
---
.../devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt | 19 +++
1 file changed, 19 insertions(+)
create mode 100644
Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt
diff --git a/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt
b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt
new file mode 100644
index 000..7018aa8
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt
@@ -0,0 +1,19 @@
+Xilinx Zynq FPGA Manager
+
+Required properties:
+- compatible: should contain "xlnx,zynq-devcfg-1.0"
+- reg: base address and size for memory mapped io
+- interrupts: interrupt for the FPGA manager device
+- clocks: phandle for clocks required operation
+- clock-names: name for the clock, should be "ref_clk"
+- syscon: phandle for access to SLCR registers
+
+Example:
+ devcfg: devcfg@f8007000 {
+ compatible = "xlnx,zynq-devcfg-1.0";
+ reg = <0xf8007000 0x100>;
+ interrupts = <0 8 4>;
+ clocks = <&clkc 12>;
+ clock-names = "ref_clk";
+ syscon = <&slcr>;
+ };
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 2/3] ARM: zynq: dt: Updated devicetree for Zynq 7000 platform.
Added addtional nodes required for FPGA Manager operation
of the Xilinx Zynq Devc configuration interface.
Reviewed-by: Sören Brinkmann
Signed-off-by: Moritz Fischer
---
v2: No changes
---
arch/arm/boot/dts/zynq-7000.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index dc0457e..1a5220e 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -294,6 +294,11 @@
devcfg: devcfg@f8007000 {
compatible = "xlnx,zynq-devcfg-1.0";
reg = <0xf8007000 0x100>;
+ interrupt-parent = <&intc>;
+ interrupts = <0 8 4>;
+ clocks = <&clkc 12>;
+ clock-names = "ref_clk";
+ syscon = <&slcr>;
};
global_timer: timer@f8f00200 {
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 3/3] fpga manager: Adding FPGA Manager support for Xilinx Zynq 7000
This commit adds FPGA Manager support for the Xilinx Zynq chip. The code borrows some from the xdevcfg driver in Xilinx' vendor tree. Signed-off-by: Moritz Fischer --- v2: - Replaced locking error flag and broken completion with irq masking and changed completion handling - Dealing with timeout cases - Reworked clock handling - Moved initialization from probe() to write_init() - Fixed return value of devm_request_irq() check to check for non-zero - Alphabetized includes ;-) - Changed some of the comments, to better explain what's happening --- drivers/fpga/Kconfig | 5 + drivers/fpga/Makefile| 1 + drivers/fpga/zynq-fpga.c | 533 +++ 3 files changed, 539 insertions(+) create mode 100644 drivers/fpga/zynq-fpga.c diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig index dfc1f1e..c9b9fdf 100644 --- a/drivers/fpga/Kconfig +++ b/drivers/fpga/Kconfig @@ -19,6 +19,11 @@ config FPGA_MGR_SOCFPGA help FPGA manager driver support for Altera SOCFPGA. +config FPGA_MGR_ZYNQ_FPGA + tristate "Xilinx Zynq FPGA" + help + FPGA manager driver support for Xilinx Zynq FPGAs. + endif # FPGA endmenu diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile index ba6c5c5..8d83fc6 100644 --- a/drivers/fpga/Makefile +++ b/drivers/fpga/Makefile @@ -7,3 +7,4 @@ obj-$(CONFIG_FPGA) += fpga-mgr.o # FPGA Manager Drivers obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o +obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o diff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/zynq-fpga.c new file mode 100644 index 000..103303c --- /dev/null +++ b/drivers/fpga/zynq-fpga.c @@ -0,0 +1,533 @@ +/* + * Copyright (c) 2011-2015 Xilinx Inc. + * Copyright (c) 2015, National Instruments Corp. + * + * FPGA Manager Driver for Xilinx Zynq, heavily based on xdevcfg driver + * in their vendor tree. + * + * 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; version 2 of the License. + * + * 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 +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* Offsets into SLCR regmap */ + +/* FPGA Software Reset Control */ +#define SLCR_FPGA_RST_CTRL_OFFSET 0x240 +/* Level Shifters Enable */ +#define SLCR_LVL_SHFTR_EN_OFFSET 0x900 + +/* Constant Definitions */ + +/* Control Register */ +#define CTRL_OFFSET0x00 +/* Lock Register */ +#define LOCK_OFFSET0x04 +/* Interrupt Status Register */ +#define INT_STS_OFFSET 0x0c +/* Interrupt Mask Register */ +#define INT_MASK_OFFSET0x10 +/* Status Register */ +#define STATUS_OFFSET 0x14 +/* DMA Source Address Register */ +#define DMA_SRC_ADDR_OFFSET0x18 +/* DMA Destination Address Reg */ +#define DMA_DST_ADDR_OFFSET0x1c +/* DMA Source Transfer Length */ +#define DMA_SRC_LEN_OFFSET 0x20 +/* DMA Destination Transfer */ +#define DMA_DEST_LEN_OFFSET0x24 +/* Unlock Register */ +#define UNLOCK_OFFSET 0x34 +/* Misc. Control Register */ +#define MCTRL_OFFSET 0x80 + +/* Control Register Bit definitions */ + +/* Signal to reset FPGA */ +#define CTRL_PCFG_PROG_B_MASK BIT(30) +/* Enable PCAP for PR */ +#define CTRL_PCAP_PR_MASK BIT(27) +/* Enable PCAP */ +#define CTRL_PCAP_MODE_MASKBIT(26) + +/* Miscellaneous Control Register bit definitions */ +/* Internal PCAP loopback */ +#define MCTRL_PCAP_LPBK_MASK BIT(4) + +/* Status register bit definitions */ + +/* FPGA init status */ +#define STATUS_DMA_Q_F BIT(31) +#define STATUS_PCFG_INIT_MASK BIT(4) + +/* Interrupt Status/Mask Register Bit definitions */ +/* DMA command done */ +#define IXR_DMA_DONE_MASK BIT(13) +/* DMA and PCAP cmd done */ +#define IXR_D_P_DONE_MASK BIT(12) + /* FPGA programmed */ +#define IXR_PCFG_DONE_MASK BIT(2) +#define IXR_ERROR_FLAGS_MASK 0x00F0F860 +#define IXR_ALL_MASK 0xF8F7F87F + +/* Miscellaneous constant values */ + +/* Invalid DMA addr */ +#define DMA_INVALID_ADDRESSGENMASK(31, 0) +/* Used to unlock the dev */ +#define UNLOCK_MASK0x757bdf0d +/* Timeout for DMA to complete */ +#define DMA_DONE_TIMEOUT msecs_to_jiffies(1000) +/* Timeout for polling reset bits */ +#define INIT_POLL_TIMEOUT 250 +/* Delay for polling reset bits */ +#define INIT_POLL_DELAY
[PATCHv2 0/3] Adding FPGA Manager support for Xilinx Zynq
Hi all, I've tried to address most of the feedback that was brought up, the one thing I haven't looked at was the firmware format part, since that was still in discussion. So I'm still open to suggestions on how to handle this. In the interest of moving forward, and early feedback I decided to submit another rev without the firmware format part addressed. Thanks to all the reviewers of the first round, can we maybe get ACKs for the docs and devicetree changes? Cheers, Moritz Moritz Fischer (3): ARM: dt: fpga: Added binding docs for Xilinx Zynq FPGA manager. ARM: zynq: dt: Updated devicetree for Zynq 7000 platform. fpga manager: Adding FPGA Manager support for Xilinx Zynq 7000 .../bindings/fpga/xilinx-zynq-fpga-mgr.txt | 19 + arch/arm/boot/dts/zynq-7000.dtsi | 5 + drivers/fpga/Kconfig | 5 + drivers/fpga/Makefile | 1 + drivers/fpga/zynq-fpga.c | 533 + 5 files changed, 563 insertions(+) create mode 100644 Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt create mode 100644 drivers/fpga/zynq-fpga.c -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] ARM: dts: bcm5301x: Add BCM SVK DT files
On 10/17/2015 12:38 AM, Scott Branden wrote:
> Hi Jon,
>
> No need for the board in the compatible string.
I think the board should be named here, so we could take some code
branches based on the board, if it would have bad wiring for example.
The device tree wiki says:
"The first string in the list specifies the exact device that the node
represents"
http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property
The exact device here is the board not the SoC.
Hauke
>
> On 15-10-16 02:41 PM, Hauke Mehrtens wrote:
>> On 10/16/2015 12:24 AM, Jon Mason wrote:
>>> Add device tree files for Broadcom Northstar based SVKs. Since the
>>> bcm5301x.dtsi already exists, all that is necessary is the dts files to
>>> enable the UARTs. With these files, the SVKs are able to boot to shell.
>>>
>>> Signed-off-by: Jon Mason
>>
>> Acked-by: Hauke Mehrtens
>>
>>> ---
>>> arch/arm/boot/dts/Makefile | 5 +++-
>>> arch/arm/boot/dts/bcm94708.dts | 56
>>> +++
>>> arch/arm/boot/dts/bcm94709.dts | 56
>>> +++
>>> arch/arm/boot/dts/bcm953012k.dts | 63
>>>
>>> 4 files changed, 179 insertions(+), 1 deletion(-)
>>> create mode 100644 arch/arm/boot/dts/bcm94708.dts
>>> create mode 100644 arch/arm/boot/dts/bcm94709.dts
>>> create mode 100644 arch/arm/boot/dts/bcm953012k.dts
>>>
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>> index 233159d..96a1b58 100644
>>> --- a/arch/arm/boot/dts/Makefile
>>> +++ b/arch/arm/boot/dts/Makefile
>>> @@ -72,7 +72,10 @@ dtb-$(CONFIG_ARCH_BCM_5301X) += \
>>> bcm47081-buffalo-wzr-900dhp.dtb \
>>> bcm4709-asus-rt-ac87u.dtb \
>>> bcm4709-buffalo-wxr-1900dhp.dtb \
>>> -bcm4709-netgear-r8000.dtb
>>> +bcm4709-netgear-r8000.dtb \
>>> +bcm94708.dtb \
>>> +bcm94709.dtb \
>>> +bcm953012k.dtb
>>> dtb-$(CONFIG_ARCH_BCM_63XX) += \
>>> bcm963138dvt.dtb
>>> dtb-$(CONFIG_ARCH_BCM_CYGNUS) += \
>>> diff --git a/arch/arm/boot/dts/bcm94708.dts
>>> b/arch/arm/boot/dts/bcm94708.dts
>>> new file mode 100644
>>> index 000..49682d6
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/bcm94708.dts
>>> @@ -0,0 +1,56 @@
>>> +/*
>>> + * BSD LICENSE
>>> + *
>>> + * Copyright(c) 2015 Broadcom Corporation. All rights reserved.
>>> + *
>>> + * Redistribution and use in source and binary forms, with or without
>>> + * modification, are permitted provided that the following conditions
>>> + * are met:
>>> + *
>>> + ** Redistributions of source code must retain the above copyright
>>> + * notice, this list of conditions and the following disclaimer.
>>> + ** Redistributions in binary form must reproduce the above
>>> copyright
>>> + * notice, this list of conditions and the following disclaimer in
>>> + * the documentation and/or other materials provided with the
>>> + * distribution.
>>> + ** Neither the name of Broadcom Corporation nor the names of its
>>> + * contributors may be used to endorse or promote products derived
>>> + * from this software without specific prior written permission.
>>> + *
>>> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>>> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>>> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
>>> FITNESS FOR
>>> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
>>> COPYRIGHT
>>> + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
>>> INCIDENTAL,
>>> + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>>> + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
>>> USE,
>>> + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
>>> ON ANY
>>> + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>>> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
>>> THE USE
>>> + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
>>> DAMAGE.
>>> + */
>>> +
>>> +/dts-v1/;
>>> +
>>> +#include "bcm4708.dtsi"
>>> +
>>> +/ {
>>> +model = "NorthStar SVK (BCM94708)";
>>> +compatible = "brcm,bcm94708", "brcm,bcm4708";
> no need for brcm,bcm94708
>>> +
>>> +aliases {
>>> +serial0 = &uart0;
>>> +};
>>> +
>>> +chosen {
>>> +bootargs = "console=ttyS0,115200";
>>> +};
>>> +
>>> +memory {
>>> +reg = <0x 0x0800>;
>>> +};
>>> +};
>>> +
>>> +&uart0 {
>>> +status = "okay";
>>> +};
>>> diff --git a/arch/arm/boot/dts/bcm94709.dts
>>> b/arch/arm/boot/dts/bcm94709.dts
>>> new file mode 100644
>>> index 000..4ab19c0
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/bcm94709.dts
>>> @@ -0,0 +1,56 @@
>>> +/*
>>> + * BSD LICENSE
>>> + *
>>> + * Copyright(c) 2015 Broadcom Corporation. All rights reserved.
>>> + *
>>> + * Redistribution and use in source and binary forms, with or without
>>> + * m
Re: [PATCH v3 1/2] dt-bindings: Add new SoCs to bcm4708 DT bindings
On 15-10-16 02:42 PM, Hauke Mehrtens wrote: On 10/16/2015 12:24 AM, Jon Mason wrote: Add the 4708, 4709, and 53012 SoCs to the the documentation for the Broadcom Northstar device tree bindings. Signed-off-by: Jon Mason Acked-by: Hauke Mehrtens Acked-by: Scott Branden --- Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt index 6b0f49f..8608a77 100644 --- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt @@ -5,4 +5,11 @@ Boards with the BCM4708 SoC shall have the following properties: Required root node property: +bcm4708 compatible = "brcm,bcm4708"; + +bcm4709 +compatible = "brcm,bcm4709"; + +bcm53012 +compatible = "brcm,bcm53012"; -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] ARM: dts: bcm5301x: Add BCM SVK DT files
Hi Jon,
No need for the board in the compatible string.
On 15-10-16 02:41 PM, Hauke Mehrtens wrote:
On 10/16/2015 12:24 AM, Jon Mason wrote:
Add device tree files for Broadcom Northstar based SVKs. Since the
bcm5301x.dtsi already exists, all that is necessary is the dts files to
enable the UARTs. With these files, the SVKs are able to boot to shell.
Signed-off-by: Jon Mason
Acked-by: Hauke Mehrtens
---
arch/arm/boot/dts/Makefile | 5 +++-
arch/arm/boot/dts/bcm94708.dts | 56 +++
arch/arm/boot/dts/bcm94709.dts | 56 +++
arch/arm/boot/dts/bcm953012k.dts | 63
4 files changed, 179 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/bcm94708.dts
create mode 100644 arch/arm/boot/dts/bcm94709.dts
create mode 100644 arch/arm/boot/dts/bcm953012k.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 233159d..96a1b58 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -72,7 +72,10 @@ dtb-$(CONFIG_ARCH_BCM_5301X) += \
bcm47081-buffalo-wzr-900dhp.dtb \
bcm4709-asus-rt-ac87u.dtb \
bcm4709-buffalo-wxr-1900dhp.dtb \
- bcm4709-netgear-r8000.dtb
+ bcm4709-netgear-r8000.dtb \
+ bcm94708.dtb \
+ bcm94709.dtb \
+ bcm953012k.dtb
dtb-$(CONFIG_ARCH_BCM_63XX) += \
bcm963138dvt.dtb
dtb-$(CONFIG_ARCH_BCM_CYGNUS) += \
diff --git a/arch/arm/boot/dts/bcm94708.dts b/arch/arm/boot/dts/bcm94708.dts
new file mode 100644
index 000..49682d6
--- /dev/null
+++ b/arch/arm/boot/dts/bcm94708.dts
@@ -0,0 +1,56 @@
+/*
+ * BSD LICENSE
+ *
+ * Copyright(c) 2015 Broadcom Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ ** Neither the name of Broadcom Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/dts-v1/;
+
+#include "bcm4708.dtsi"
+
+/ {
+ model = "NorthStar SVK (BCM94708)";
+ compatible = "brcm,bcm94708", "brcm,bcm4708";
no need for brcm,bcm94708
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ memory {
+ reg = <0x 0x0800>;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/bcm94709.dts b/arch/arm/boot/dts/bcm94709.dts
new file mode 100644
index 000..4ab19c0
--- /dev/null
+++ b/arch/arm/boot/dts/bcm94709.dts
@@ -0,0 +1,56 @@
+/*
+ * BSD LICENSE
+ *
+ * Copyright(c) 2015 Broadcom Corporation. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ ** Neither the name of Broadcom Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE
Re: [RFC 4/5] clk: iproc: define Broadcom NS2 iProc clock binding
On 10/14, Ray Jui wrote: > > > On 10/14/2015 8:44 AM, Jon Mason wrote: > > On Tue, Oct 13, 2015 at 03:24:52PM -0700, Ray Jui wrote: > >> Same as this patch. I thought device tree binding document should go > >> with the clock driver changes. > >> > >> Strictly speaking, device tree binding document should always go before > >> the driver changes. In the binding document the DT interface is defined, > >> then changes are implemented in the driver. > > > > I split them off this way due to the clk maintainer not wanting to > > pull in any device tree changes. Since the documentation is for the > > device tree enties, it makes logical sense to me that they be in the > > same device tree series. If Stephen will pull these in with the clk > > changes, I am more than happy to have it done by him :) > > > > Thanks, > > Jon > > Yeah the clock maintainers do not pull in device tree changes like > *.dtsi and *.dts. But they do take changes including the binding > documents and clock driver changes. You can confirm with Stephen. > Yes we take bindings (I know I'm replying to an old patch). -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] dt-bindings: Add new SoCs to bcm4708 DT bindings
On 10/16/2015 12:24 AM, Jon Mason wrote: > Add the 4708, 4709, and 53012 SoCs to the the documentation for the > Broadcom Northstar device tree bindings. > > Signed-off-by: Jon Mason Acked-by: Hauke Mehrtens > --- > Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt > b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt > index 6b0f49f..8608a77 100644 > --- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt > +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt > @@ -5,4 +5,11 @@ Boards with the BCM4708 SoC shall have the following > properties: > > Required root node property: > > +bcm4708 > compatible = "brcm,bcm4708"; > + > +bcm4709 > +compatible = "brcm,bcm4709"; > + > +bcm53012 > +compatible = "brcm,bcm53012"; > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] ARM: dts: bcm5301x: Add BCM SVK DT files
On 10/16/2015 12:24 AM, Jon Mason wrote:
> Add device tree files for Broadcom Northstar based SVKs. Since the
> bcm5301x.dtsi already exists, all that is necessary is the dts files to
> enable the UARTs. With these files, the SVKs are able to boot to shell.
>
> Signed-off-by: Jon Mason
Acked-by: Hauke Mehrtens
> ---
> arch/arm/boot/dts/Makefile | 5 +++-
> arch/arm/boot/dts/bcm94708.dts | 56 +++
> arch/arm/boot/dts/bcm94709.dts | 56 +++
> arch/arm/boot/dts/bcm953012k.dts | 63
>
> 4 files changed, 179 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/bcm94708.dts
> create mode 100644 arch/arm/boot/dts/bcm94709.dts
> create mode 100644 arch/arm/boot/dts/bcm953012k.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 233159d..96a1b58 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -72,7 +72,10 @@ dtb-$(CONFIG_ARCH_BCM_5301X) += \
> bcm47081-buffalo-wzr-900dhp.dtb \
> bcm4709-asus-rt-ac87u.dtb \
> bcm4709-buffalo-wxr-1900dhp.dtb \
> - bcm4709-netgear-r8000.dtb
> + bcm4709-netgear-r8000.dtb \
> + bcm94708.dtb \
> + bcm94709.dtb \
> + bcm953012k.dtb
> dtb-$(CONFIG_ARCH_BCM_63XX) += \
> bcm963138dvt.dtb
> dtb-$(CONFIG_ARCH_BCM_CYGNUS) += \
> diff --git a/arch/arm/boot/dts/bcm94708.dts b/arch/arm/boot/dts/bcm94708.dts
> new file mode 100644
> index 000..49682d6
> --- /dev/null
> +++ b/arch/arm/boot/dts/bcm94708.dts
> @@ -0,0 +1,56 @@
> +/*
> + * BSD LICENSE
> + *
> + * Copyright(c) 2015 Broadcom Corporation. All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + *
> + ** Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + ** Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in
> + * the documentation and/or other materials provided with the
> + * distribution.
> + ** Neither the name of Broadcom Corporation nor the names of its
> + * contributors may be used to endorse or promote products derived
> + * from this software without specific prior written permission.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +/dts-v1/;
> +
> +#include "bcm4708.dtsi"
> +
> +/ {
> + model = "NorthStar SVK (BCM94708)";
> + compatible = "brcm,bcm94708", "brcm,bcm4708";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,115200";
> + };
> +
> + memory {
> + reg = <0x 0x0800>;
> + };
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/bcm94709.dts b/arch/arm/boot/dts/bcm94709.dts
> new file mode 100644
> index 000..4ab19c0
> --- /dev/null
> +++ b/arch/arm/boot/dts/bcm94709.dts
> @@ -0,0 +1,56 @@
> +/*
> + * BSD LICENSE
> + *
> + * Copyright(c) 2015 Broadcom Corporation. All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + *
> + ** Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + ** Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in
> + * the documentation and/or other materials provided with the
> + * distribution.
> + ** Neither the name of Broadcom Corporation nor the names of its
> + * contributors may be used to endorse or promote products derived
> + * from this software without specific prior written permission.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> + * "AS IS" AND ANY EXPRESS OR IMP
Re: [PATCH 01/10] clk: rockchip: Add sclk_mipidsi_24m for mipi dsi
On 10/10, Chris Zhong wrote:
> sclk_mipidsi_24m is the gating of mipi dsi phy.
>
> Signed-off-by: Chris Zhong
> ---
Acked-by: Stephen Boyd
>
> drivers/clk/rockchip/clk-rk3288.c | 2 +-
> include/dt-bindings/clock/rk3288-cru.h | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/rockchip/clk-rk3288.c
> b/drivers/clk/rockchip/clk-rk3288.c
> index 9040878..c7d7ebf 100644
> --- a/drivers/clk/rockchip/clk-rk3288.c
> +++ b/drivers/clk/rockchip/clk-rk3288.c
> @@ -709,7 +709,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
> __initdata = {
> GATE(SCLK_LCDC_PWM1, "sclk_lcdc_pwm1", "xin24m", 0,
> RK3288_CLKGATE_CON(13), 11, GFLAGS),
> GATE(SCLK_PVTM_CORE, "sclk_pvtm_core", "xin24m", 0,
> RK3288_CLKGATE_CON(5), 9, GFLAGS),
> GATE(SCLK_PVTM_GPU, "sclk_pvtm_gpu", "xin24m", 0,
> RK3288_CLKGATE_CON(5), 10, GFLAGS),
> - GATE(0, "sclk_mipidsi_24m", "xin24m", 0, RK3288_CLKGATE_CON(5), 15,
> GFLAGS),
> + GATE(SCLK_MIPI_24M, "sclk_mipidsi_24m", "xin24m", 0,
> RK3288_CLKGATE_CON(5), 15, GFLAGS),
>
It would have been better to make #defines for all these clocks
even if they weren't going to be used here. Then we could have
applied this patch directly to clk tree without having a clk tree
to arm-soc dependency.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: shmobile: silk: add SDHI1 DT support
Define the SILK board dependent part of the SDHI1 (connected to micro-SD
slot) device nodes along with the necessary voltage regulators.
Based on the original patch by Vladimir Barinov
.
Signed-off-by: Sergei Shtylyov
---
This patch is against 'renesas-devel-20151015-v4.3-rc5' tag of Simon Horman's
'renesas.git' repo.
Changes in version 3:
- removed the "disable-wp" property;
- added empty line before the regulator nodes;
- reformatted the changelog;
- refreshed the patch.
Changes in version 2:
- removed non-working SDHI0 stuff, renamed the patch;
- replaced SDHI1's "wp-gpios" property with "disable-wp".
arch/arm/boot/dts/r8a7794-silk.dts | 40 +
1 file changed, 40 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7794-silk.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7794-silk.dts
+++ renesas/arch/arm/boot/dts/r8a7794-silk.dts
@@ -12,6 +12,7 @@
/dts-v1/;
#include "r8a7794.dtsi"
+#include
/ {
model = "SILK";
@@ -39,6 +40,30 @@
regulator-boot-on;
regulator-always-on;
};
+
+ vcc_sdhi1: regulator@3 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "SDHI1 Vcc";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+
+ gpio = <&gpio4 26 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vccq_sdhi1: regulator@4 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "SDHI1 VccQ";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+
+ gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <330 1
+ 180 0>;
+ };
};
&extal_clk {
@@ -71,6 +96,11 @@
renesas,function = "mmc";
};
+ sdhi1_pins: sd1 {
+ renesas,groups = "sdhi1_data4", "sdhi1_ctrl";
+ renesas,function = "sdhi1";
+ };
+
qspi_pins: spi0 {
renesas,groups = "qspi_ctrl", "qspi_data4";
renesas,function = "qspi";
@@ -147,6 +177,16 @@
status = "okay";
};
+&sdhi1 {
+ pinctrl-0 = <&sdhi1_pins>;
+ pinctrl-names = "default";
+
+ vmmc-supply = <&vcc_sdhi1>;
+ vqmmc-supply = <&vccq_sdhi1>;
+ cd-gpios = <&gpio6 14 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
&qspi {
pinctrl-0 = <&qspi_pins>;
pinctrl-names = "default";
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 1/2] drivers: net: xgene: Add support RGMII TX/RX delay configuration
On 16/10/15 13:35, Iyappan Subramanian wrote:
> Add RGMII TX/RX delay configuration support. RGMII standard requires 2ns
> delay to help the RGMII bridge receiver to sample data correctly. If the
> default value does not provide proper centering of the data sample, the
> TX/RX delay parameters can be used to adjust accordingly.
There is a standard 'phy-mode' property which can take multiple values
for RGMII: "rgmii" (no delay), "rgmii-txid" (transmit delay),
"rgmii-rxid" (receive delay) and "rgmii-id" (symetric delay). There does
not seem to be any verification of whether the rx or tx delay parameters
you introduce are going to be either sensible, or not conflicting with
the 'phy-mode' that should be configured.
>
> Signed-off-by: Iyappan Subramanian
> ---
> drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 8 +++-
> drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 1 +
> drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 49
>
> drivers/net/ethernet/apm/xgene/xgene_enet_main.h | 2 +
> 4 files changed, 59 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
> b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
> index 652f218..33850a0 100644
> --- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
> +++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
> @@ -461,6 +461,7 @@ static void xgene_gmac_reset(struct xgene_enet_pdata
> *pdata)
>
> static void xgene_gmac_init(struct xgene_enet_pdata *pdata)
> {
> + struct device *dev = &pdata->pdev->dev;
> u32 value, mc2;
> u32 intf_ctl, rgmii;
> u32 icm0, icm2;
> @@ -490,7 +491,12 @@ static void xgene_gmac_init(struct xgene_enet_pdata
> *pdata)
> default:
> ENET_INTERFACE_MODE2_SET(&mc2, 2);
> intf_ctl |= ENET_GHD_MODE;
> - CFG_TXCLK_MUXSEL0_SET(&rgmii, 4);
> +
> + if (dev->of_node) {
> + CFG_TXCLK_MUXSEL0_SET(&rgmii, pdata->tx_delay);
> + CFG_RXCLK_MUXSEL0_SET(&rgmii, pdata->rx_delay);
> + }
> +
> xgene_enet_rd_csr(pdata, DEBUG_REG_ADDR, &value);
> value |= CFG_BYPASS_UNISEC_TX | CFG_BYPASS_UNISEC_RX;
> xgene_enet_wr_csr(pdata, DEBUG_REG_ADDR, value);
> diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
> b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
> index ff05bbc..6dee73c 100644
> --- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
> +++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
> @@ -144,6 +144,7 @@ enum xgene_enet_rm {
> #define CFG_BYPASS_UNISEC_RX BIT(1)
> #define CFG_CLE_BYPASS_EN0 BIT(31)
> #define CFG_TXCLK_MUXSEL0_SET(dst, val) xgene_set_bits(dst, val, 29, 3)
> +#define CFG_RXCLK_MUXSEL0_SET(dst, val) xgene_set_bits(dst, val, 26, 3)
>
> #define CFG_CLE_IP_PROTOCOL0_SET(dst, val) xgene_set_bits(dst, val, 16, 2)
> #define CFG_CLE_DSTQID0_SET(dst, val)xgene_set_bits(dst,
> val, 0, 12)
> diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
> b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
> index 6b1846d..ce10687 100644
> --- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
> +++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
> @@ -1118,6 +1118,47 @@ static int xgene_get_port_id_dt(struct device *dev,
> struct xgene_enet_pdata *pda
> return ret;
> }
>
> +static int xgene_get_tx_delay(struct xgene_enet_pdata *pdata)
> +{
> + struct device *dev = &pdata->pdev->dev;
> + int delay, ret;
> +
> + ret = of_property_read_u32(dev->of_node, "tx-delay", &delay);
> + if (ret) {
> + pdata->tx_delay = 4;
> + return 0;
> + }
> +
> + if (delay < 0 || delay > 7) {
> + dev_err(dev, "Invalid tx-delay specified\n");
> + return -EINVAL;
> + }
> +
> + pdata->tx_delay = delay;
> +
> + return 0;
> +}
> +
> +static int xgene_get_rx_delay(struct xgene_enet_pdata *pdata)
> +{
> + struct device *dev = &pdata->pdev->dev;
> + int delay, ret;
> +
> + ret = of_property_read_u32(dev->of_node, "rx-delay", &delay);
> + if (ret) {
> + pdata->rx_delay = 2;
> + return 0;
> + }
> +
> + if (delay < 0 || delay > 7) {
> + dev_err(dev, "Invalid rx-delay specified\n");
> + return -EINVAL;
> + }
> +
> + pdata->rx_delay = delay;
> +
> + return 0;
> +}
>
> static int xgene_enet_get_resources(struct xgene_enet_pdata *pdata)
> {
> @@ -1194,6 +1235,14 @@ static int xgene_enet_get_resources(struct
> xgene_enet_pdata *pdata)
> return -ENODEV;
> }
>
> + ret = xgene_get_tx_delay(pdata);
> + if (ret)
> + return ret;
> +
> + ret = xgene_get_rx_delay(pdata);
> + if (ret)
> + return ret;
> +
> ret = platform_get_irq(pdev, 0);
> if (ret <= 0) {
> dev_err(dev, "Unable to get ENET Rx IRQ\n");
> diff --git a/d
Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
* Roger Quadros [151006 04:13]: > > Fine. The updated series is now at > > g...@github.com:rogerq/linux.git > * [new branch] for-v4.4/gpmc-v4 Looks like it produces some build errors, this with RMKs 3430 and 4430 only .configs: drivers/memory/omap-gpmc.c:2035:43: error: ‘struct gpio_chip’ has no member named ‘irqdomain’ drivers/memory/omap-gpmc.c:2116:8: error: implicit declaration of function ‘gpiochip_irqchip_add’ [-Werror=implicit-function-declaration] Maybe run randconfig builds on it for overnight? Other than that your series seems to behave for me now, so feel free to add: Acked-by: Tony Lindgren Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] On-demand device probing
Hi, I've bisected boot failures in next-20151016 down to patches in this branch: On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso wrote: > Tomeu Vizoso (20): > driver core: handle -EPROBE_DEFER from bus_type.match() The machine it happened on was OMAP5UEVM: http://arm-soc.lixom.net/bootlogs/next/next-20151016/omap5uevm-arm-omap2plus_defconfig.html But I've also seen it on tegra2, that one bisected down to: > regulator: core: Probe regulators on demand http://arm-soc.lixom.net/bootlogs/next/next-20151016/seaboard-arm-multi_v7_defconfig.html -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] gpiolib: Add and use OF_GPIO_SINGLE_ENDED flag
On Mon, Oct 12, 2015 at 11:20 PM, Laurent Pinchart wrote: > The flag matches the DT GPIO_SINGLE_ENDED flag and allows drivers to > parse and use the DT flag to handle single-ended (open-drain or > open-source) GPIOs. > > Signed-off-by: Laurent Pinchart Patch applied! I feel a bit guilty for fixing the OF docs (with help from Nikolaus Schaller) and then just leaving it open as an exercise for someone else to implement it in gpiolib ... hats of for immediately grasping this and implementing it exactly as it should be! All of a sudden I now have an influx of GPIO drivers supporting open drain. I wonder why it happens right now, probably sun spot activity. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] gpiolib: Split GPIO flags parsing and GPIO configuration
On Mon, Oct 12, 2015 at 11:20 PM, Laurent Pinchart wrote: > When requesting a GPIO through the legacy or the gpiod_* API the > gpiochip request operation is first called and then the GPIO flags are > parsed and the GPIO is configured. This prevents the gpiochip from > rejecting the request if the flags are not supported by the device. > > To fix this split the parse-and-configure operation in two and parse > flags before requesting the GPIO. > > Signed-off-by: Laurent Pinchart Very elegant, this is exactly how we need things to happen. Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 2/2] Documentation: dts: xgene: Add TX/RX delay field
Signed-off-by: Iyappan Subramanian
---
Documentation/devicetree/bindings/net/apm-xgene-enet.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
index f55aa28..5b17c13 100644
--- a/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
+++ b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
@@ -37,6 +37,14 @@ Required properties for ethernet interfaces that have
external PHY:
Optional properties:
- status: Should be "ok" or "disabled" for enabled/disabled. Default is "ok".
+- tx-delay: Delay value for RGMII TXD timming.
+ Valid values are between 0 to 7, that maps to
+ 417, 717, 1020, 1321, 1611, 1913, 2215, 2514 ps
+ Default value is 4, which corresponds to 1611 ps
+- rx-delay: Delay value for RGMII RXD timming in ps.
+ Valid values are between 0 to 7, that maps to
+ 273, 589, 899, 1222, 1480, 1806, 2147, 2464 ps
+ Default value is 2, which corresponds to 899 ps
Example:
menetclk: menetclk {
@@ -72,5 +80,7 @@ Example:
/* Board-specific peripheral configurations */
&menet {
+ tx-delay = <4>;
+ rx-delay = <2>;
status = "ok";
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 0/2] drivers: xgene: Add support RGMII TX/RX delay configuration
This patch adds support RGMII TX/RX delay configuration. Signed-off-by: Iyappan Subramanian --- Iyappan Subramanian (2): drivers: net: xgene: Add support RGMII TX/RX delay configuration Documentation: dts: xgene: Add TX/RX delay field .../devicetree/bindings/net/apm-xgene-enet.txt | 10 + drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 8 +++- drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 1 + drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 49 ++ drivers/net/ethernet/apm/xgene/xgene_enet_main.h | 2 + 5 files changed, 69 insertions(+), 1 deletion(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 1/2] drivers: net: xgene: Add support RGMII TX/RX delay configuration
Add RGMII TX/RX delay configuration support. RGMII standard requires 2ns
delay to help the RGMII bridge receiver to sample data correctly. If the
default value does not provide proper centering of the data sample, the
TX/RX delay parameters can be used to adjust accordingly.
Signed-off-by: Iyappan Subramanian
---
drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 8 +++-
drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 1 +
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 49
drivers/net/ethernet/apm/xgene/xgene_enet_main.h | 2 +
4 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
index 652f218..33850a0 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -461,6 +461,7 @@ static void xgene_gmac_reset(struct xgene_enet_pdata *pdata)
static void xgene_gmac_init(struct xgene_enet_pdata *pdata)
{
+ struct device *dev = &pdata->pdev->dev;
u32 value, mc2;
u32 intf_ctl, rgmii;
u32 icm0, icm2;
@@ -490,7 +491,12 @@ static void xgene_gmac_init(struct xgene_enet_pdata *pdata)
default:
ENET_INTERFACE_MODE2_SET(&mc2, 2);
intf_ctl |= ENET_GHD_MODE;
- CFG_TXCLK_MUXSEL0_SET(&rgmii, 4);
+
+ if (dev->of_node) {
+ CFG_TXCLK_MUXSEL0_SET(&rgmii, pdata->tx_delay);
+ CFG_RXCLK_MUXSEL0_SET(&rgmii, pdata->rx_delay);
+ }
+
xgene_enet_rd_csr(pdata, DEBUG_REG_ADDR, &value);
value |= CFG_BYPASS_UNISEC_TX | CFG_BYPASS_UNISEC_RX;
xgene_enet_wr_csr(pdata, DEBUG_REG_ADDR, value);
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
index ff05bbc..6dee73c 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
@@ -144,6 +144,7 @@ enum xgene_enet_rm {
#define CFG_BYPASS_UNISEC_RX BIT(1)
#define CFG_CLE_BYPASS_EN0 BIT(31)
#define CFG_TXCLK_MUXSEL0_SET(dst, val)xgene_set_bits(dst, val, 29, 3)
+#define CFG_RXCLK_MUXSEL0_SET(dst, val)xgene_set_bits(dst, val, 26, 3)
#define CFG_CLE_IP_PROTOCOL0_SET(dst, val) xgene_set_bits(dst, val, 16, 2)
#define CFG_CLE_DSTQID0_SET(dst, val) xgene_set_bits(dst, val, 0, 12)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index 6b1846d..ce10687 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -1118,6 +1118,47 @@ static int xgene_get_port_id_dt(struct device *dev,
struct xgene_enet_pdata *pda
return ret;
}
+static int xgene_get_tx_delay(struct xgene_enet_pdata *pdata)
+{
+ struct device *dev = &pdata->pdev->dev;
+ int delay, ret;
+
+ ret = of_property_read_u32(dev->of_node, "tx-delay", &delay);
+ if (ret) {
+ pdata->tx_delay = 4;
+ return 0;
+ }
+
+ if (delay < 0 || delay > 7) {
+ dev_err(dev, "Invalid tx-delay specified\n");
+ return -EINVAL;
+ }
+
+ pdata->tx_delay = delay;
+
+ return 0;
+}
+
+static int xgene_get_rx_delay(struct xgene_enet_pdata *pdata)
+{
+ struct device *dev = &pdata->pdev->dev;
+ int delay, ret;
+
+ ret = of_property_read_u32(dev->of_node, "rx-delay", &delay);
+ if (ret) {
+ pdata->rx_delay = 2;
+ return 0;
+ }
+
+ if (delay < 0 || delay > 7) {
+ dev_err(dev, "Invalid rx-delay specified\n");
+ return -EINVAL;
+ }
+
+ pdata->rx_delay = delay;
+
+ return 0;
+}
static int xgene_enet_get_resources(struct xgene_enet_pdata *pdata)
{
@@ -1194,6 +1235,14 @@ static int xgene_enet_get_resources(struct
xgene_enet_pdata *pdata)
return -ENODEV;
}
+ ret = xgene_get_tx_delay(pdata);
+ if (ret)
+ return ret;
+
+ ret = xgene_get_rx_delay(pdata);
+ if (ret)
+ return ret;
+
ret = platform_get_irq(pdev, 0);
if (ret <= 0) {
dev_err(dev, "Unable to get ENET Rx IRQ\n");
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
index ff89a5d..a6e56b8 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
@@ -184,6 +184,8 @@ struct xgene_enet_pdata {
u8 bp_bufnum;
u16 ring_num;
u32 mss;
+ u8 tx_delay;
+ u8 rx_delay;
};
struct xgene_indirect_ctl {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
Re: [PATCH v6 4/7] arm64: berlin: add the pinctrl dependency for Marvell Berlin SoCs
On 16.10.2015 16:15, Linus Walleij wrote: On Fri, Oct 16, 2015 at 9:37 AM, Jisheng Zhang wrote: This is to add the pinctrl dependency for Marvell Berlin SoCs. Signed-off-by: Jisheng Zhang Acked-by: Sebastian Hesselbarth Acked-by: Antoine Tenart Acked-by: Linus Walleij Please push this through the ARM SoC tree or wherever patches to this file goes. It doesn't seem to be a hard dependency to the pin control patches. [Added arm-soc Maintainers] This patch is touching arch/arm64/Kconfig.platforms. The hunk is very small so that it may be ok that I apply and send it with the next PR. If the arm-soc Maintainers want to pick it up, I can resend the original patch with all Acked-by to arm-soc maintainer e-mail directly. Sebastian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v4 03/11] drm/mediatek: Add DSI sub driver
From: CK Hu
This patch add a drm encoder/connector driver for the MIPI DSI function
block of the Mediatek display subsystem and a phy driver for the MIPI TX
D-PHY control module.
Signed-off-by: Jitao Shi
Signed-off-by: Philipp Zabel
---
Changes since v3:
- Simplified bind function
- Removed superfluous module_platform_driver
- Fixed phy power refcounting (double phy_power_off)
---
drivers/gpu/drm/mediatek/Makefile | 4 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 19 +
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +
drivers/gpu/drm/mediatek/mtk_dsi.c | 787 +
drivers/gpu/drm/mediatek/mtk_dsi.h | 54 +++
drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 375
drivers/gpu/drm/mediatek/mtk_mipi_tx.h | 21 +
7 files changed, 1261 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/mediatek/mtk_dsi.c
create mode 100644 drivers/gpu/drm/mediatek/mtk_dsi.h
create mode 100644 drivers/gpu/drm/mediatek/mtk_mipi_tx.c
create mode 100644 drivers/gpu/drm/mediatek/mtk_mipi_tx.h
diff --git a/drivers/gpu/drm/mediatek/Makefile
b/drivers/gpu/drm/mediatek/Makefile
index ba6d3fc..0d4aeeb 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -4,7 +4,9 @@ mediatek-drm-y := mtk_drm_drv.o \
mtk_drm_ddp_comp.o \
mtk_drm_fb.o \
mtk_drm_gem.o \
- mtk_drm_plane.o
+ mtk_drm_plane.o \
+ mtk_dsi.o \
+ mtk_mipi_tx.o
obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index bb03b4a..6a6c792 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -534,8 +534,25 @@ static int __init mtk_drm_init(void)
goto drm_err;
}
+ ret = platform_driver_register(&mtk_dsi_driver);
+ if (ret < 0) {
+ pr_err("Failed to register DSI platform driver: %d\n!", ret);
+ goto disp_ovl_err;
+ }
+
+ ret = platform_driver_register(&mtk_mipi_tx_driver);
+ if (ret < 0) {
+ pr_err("Failed to register MIPI TX platform driver: %d\n!",
+ ret);
+ goto dsi_err;
+ }
+
return 0;
+dsi_err:
+ platform_driver_unregister(&mtk_dsi_driver);
+disp_ovl_err:
+ platform_driver_unregister(&mtk_disp_ovl_driver);
drm_err:
platform_driver_unregister(&mtk_drm_platform_driver);
err:
@@ -544,6 +561,8 @@ err:
static void __exit mtk_drm_exit(void)
{
+ platform_driver_unregister(&mtk_mipi_tx_driver);
+ platform_driver_unregister(&mtk_dsi_driver);
platform_driver_unregister(&mtk_disp_ovl_driver);
platform_driver_unregister(&mtk_drm_platform_driver);
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index 5e5128e..9c81abe 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -57,5 +57,7 @@ struct mtk_drm_private {
};
extern struct platform_driver mtk_disp_ovl_driver;
+extern struct platform_driver mtk_dsi_driver;
+extern struct platform_driver mtk_mipi_tx_driver;
#endif /* MTK_DRM_DRV_H */
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
new file mode 100644
index 000..fe3c450
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -0,0 +1,787 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mtk_dsi.h"
+#include "mtk_mipi_tx.h"
+
+#define DSI_VIDEO_FIFO_DEPTH (1920 / 4)
+#define DSI_HOST_FIFO_DEPTH64
+
+#define DSI_START 0x00
+
+#define DSI_CON_CTRL 0x10
+#define DSI_RESET BIT(0)
+#define DSI_EN BIT(1)
+
+#define DSI_MODE_CTRL 0x14
+#define MODE (3)
+#define CMD_MODE 0
+#define SYNC_PULSE_MODE1
+#define SYNC_EVENT_MODE2
+#define BURST_MODE 3
+#define FRM_MODE BIT(16)
+#define MIX_MODE BIT(17)
+
+#define DSI_TXRX_CTRL 0x18
+#define VC_NUM (2 << 0)
+#define LANE_NUM (0xf << 2)
+#define DIS_EOT
[RFC v4 04/11] drm/mediatek: Add DPI sub driver
From: Jie Qiu
Add DPI connector/encoder to support HDMI output via the
attached HDMI bridge.
Signed-off-by: Jie Qiu
Signed-off-by: Philipp Zabel
---
- Removed unused mtk_dpi_config_bit_swap function
- Enable/disable pixel clock instead of its ancestor PLL
- Instead of manually setting the dpi0_sel mux to the different divider
parents, call clk_set_rate on the leaf pixel clock.
This currently looks more complicated than it needs to be, it can
be simplified when the dpi0_sel mux gets changed to round_closest
- Drop the div and sel clock inputs
- Do not enable the pixel clock in the probe function. This allows to actually
power down the TVDPLL while HDMI output is disabled.
---
drivers/gpu/drm/mediatek/Makefile | 3 +-
drivers/gpu/drm/mediatek/mtk_dpi.c | 683
drivers/gpu/drm/mediatek/mtk_dpi.h | 80
drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 228 +++
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 9 +
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
6 files changed, 1003 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/mediatek/mtk_dpi.c
create mode 100644 drivers/gpu/drm/mediatek/mtk_dpi.h
create mode 100644 drivers/gpu/drm/mediatek/mtk_dpi_regs.h
diff --git a/drivers/gpu/drm/mediatek/Makefile
b/drivers/gpu/drm/mediatek/Makefile
index 0d4aeeb..93380fe 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -6,7 +6,8 @@ mediatek-drm-y := mtk_drm_drv.o \
mtk_drm_gem.o \
mtk_drm_plane.o \
mtk_dsi.o \
- mtk_mipi_tx.o
+ mtk_mipi_tx.o \
+ mtk_dpi.o
obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
new file mode 100644
index 000..43eaf33
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -0,0 +1,683 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Jie Qiu
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mtk_dpi.h"
+#include "mtk_dpi_regs.h"
+
+enum mtk_dpi_polarity {
+ MTK_DPI_POLARITY_RISING,
+ MTK_DPI_POLARITY_FALLING,
+};
+
+struct mtk_dpi_polarities {
+ enum mtk_dpi_polarity de_pol;
+ enum mtk_dpi_polarity ck_pol;
+ enum mtk_dpi_polarity hsync_pol;
+ enum mtk_dpi_polarity vsync_pol;
+};
+
+struct mtk_dpi_sync_param {
+ u32 sync_width;
+ u32 front_porch;
+ u32 back_porch;
+ bool shift_half_line;
+};
+
+struct mtk_dpi_yc_limit {
+ u16 y_top;
+ u16 y_bottom;
+ u16 c_top;
+ u16 c_bottom;
+};
+
+static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)
+{
+ u32 tmp = readl(dpi->regs + offset) & ~mask;
+
+ tmp |= (val & mask);
+ writel(tmp, dpi->regs + offset);
+}
+
+static void mtk_dpi_sw_reset(struct mtk_dpi *dpi, bool reset)
+{
+ mtk_dpi_mask(dpi, DPI_RET, reset ? RST : 0, RST);
+}
+
+static void mtk_dpi_enable(struct mtk_dpi *dpi)
+{
+ mtk_dpi_mask(dpi, DPI_EN, EN, EN);
+}
+
+static void mtk_dpi_disable(struct mtk_dpi *dpi)
+{
+ mtk_dpi_mask(dpi, DPI_EN, 0, EN);
+}
+
+static void mtk_dpi_config_hsync(struct mtk_dpi *dpi,
+struct mtk_dpi_sync_param *sync)
+{
+ mtk_dpi_mask(dpi, DPI_TGEN_HWIDTH,
+ sync->sync_width << HPW, HPW_MASK);
+ mtk_dpi_mask(dpi, DPI_TGEN_HPORCH,
+ sync->back_porch << HBP, HBP_MASK);
+ mtk_dpi_mask(dpi, DPI_TGEN_HPORCH, sync->front_porch << HFP,
+ HFP_MASK);
+}
+
+static void mtk_dpi_config_vsync(struct mtk_dpi *dpi,
+struct mtk_dpi_sync_param *sync,
+u32 width_addr, u32 porch_addr)
+{
+ mtk_dpi_mask(dpi, width_addr,
+sync->sync_width << VSYNC_WIDTH_SHIFT,
+VSYNC_WIDTH_MASK);
+ mtk_dpi_mask(dpi, width_addr,
+sync->shift_half_line << VSYNC_HALF_LINE_SHIFT,
+VSYNC_HALF_LINE_MASK);
+ mtk_dpi_mask(dpi, porch_addr,
+sync->back_porch << VSYNC_BACK_PORCH_SHIFT,
+VSYNC_BACK_PORCH_MASK);
+ mtk_dpi_mask(dpi, porch_addr,
+sync->front_porch << VSYNC_FRONT_PORCH_SHIFT,
+VSYNC_FRONT_PORCH_MASK);
+}
+
+static void mtk_dpi_config_vsync_lodd(struct mtk_d
[RFC v4 06/11] drm/mediatek: Add HDMI support
From: Daniel Kurtz This patch adds drivers for the HDMI bridge connected to the DPI0 display subsystem function block, for the HDMI DDC block, and for the HDMI PHY to support HDMI output. Signed-off-by: Jie Qiu Signed-off-by: Philipp Zabel --- Changes since v3: - Split CEC register access out into a separate driver, I suppose this will grow CEC I/O functionality in the future. The hotplug interrupt is handled by the CEC module. - Dropped DT configurable min_clock and max_clock - Changed MMSYS_CONFIG access to syscon/regmap - Use clk_set_rate on the pll_ck input instead of manually setting the hdmi_sel parent, dropped sel, div, cec and dpi clocks from the hdmi driver - Moved hotplug irq handling into the CEC driver, stopped disabling the hotplug irq on hdmi_power_off - Removed direct register access to the undocumented apmixedsys register, this turned out to be the divider feeding the hdmi_ref PLL reference input to the PHY. - Add PLL reference clock handling to the PHY. - Disable hdmi_pll and pll_ref clock inputs while HDMI output is disabled. --- drivers/gpu/drm/mediatek/Kconfig| 6 + drivers/gpu/drm/mediatek/Makefile | 8 + drivers/gpu/drm/mediatek/mtk_cec.c | 252 + drivers/gpu/drm/mediatek/mtk_cec.h | 25 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 + drivers/gpu/drm/mediatek/mtk_drm_hdmi_drv.c | 630 ++ drivers/gpu/drm/mediatek/mtk_hdmi.c | 515 ++ drivers/gpu/drm/mediatek/mtk_hdmi.h | 119 + drivers/gpu/drm/mediatek/mtk_hdmi_ddc_drv.c | 362 + drivers/gpu/drm/mediatek/mtk_hdmi_hw.c | 778 drivers/gpu/drm/mediatek/mtk_hdmi_hw.h | 76 +++ drivers/gpu/drm/mediatek/mtk_hdmi_phy.c | 339 drivers/gpu/drm/mediatek/mtk_hdmi_phy.h | 20 + drivers/gpu/drm/mediatek/mtk_hdmi_regs.h| 320 include/drm/mediatek/mtk_hdmi_audio.h | 150 ++ 15 files changed, 3601 insertions(+) create mode 100644 drivers/gpu/drm/mediatek/mtk_cec.c create mode 100644 drivers/gpu/drm/mediatek/mtk_cec.h create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_hdmi_drv.c create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi.c create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi.h create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_ddc_drv.c create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_hw.c create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_hw.h create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_phy.c create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_phy.h create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_regs.h create mode 100644 include/drm/mediatek/mtk_hdmi_audio.h diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig index 5343cf1..85af51c 100644 --- a/drivers/gpu/drm/mediatek/Kconfig +++ b/drivers/gpu/drm/mediatek/Kconfig @@ -14,3 +14,9 @@ config DRM_MEDIATEK This driver provides kernel mode setting and buffer management to userspace. +config DRM_MEDIATEK_HDMI + tristate "DRM HDMI Support for Mediatek SoCs" + depends on DRM_MEDIATEK + select GENERIC_PHY + help + DRM/KMS HDMI driver for Mediatek SoCs diff --git a/drivers/gpu/drm/mediatek/Makefile b/drivers/gpu/drm/mediatek/Makefile index 93380fe..e2a5c5c 100644 --- a/drivers/gpu/drm/mediatek/Makefile +++ b/drivers/gpu/drm/mediatek/Makefile @@ -11,3 +11,11 @@ mediatek-drm-y := mtk_drm_drv.o \ obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o +mediatek-drm-hdmi-objs := mtk_drm_hdmi_drv.o \ + mtk_cec.o \ + mtk_hdmi_ddc_drv.o \ + mtk_hdmi.o \ + mtk_hdmi_hw.o \ + mtk_hdmi_phy.o + +obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c b/drivers/gpu/drm/mediatek/mtk_cec.c new file mode 100644 index 000..5fa7888 --- /dev/null +++ b/drivers/gpu/drm/mediatek/mtk_cec.c @@ -0,0 +1,252 @@ +/* + * Copyright (c) 2014 MediaTek Inc. + * Author: Jie Qiu + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * 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 +#include +#include +#include +#include +#include + +#define TR_CONFIG 0x00 +#define CLEAR_CEC_IRQ BIT(15) + +#define CEC_CKGEN 0x04 +#define CEC_32K_PDNBIT(19) +#define PDNBIT(16) + +#define RX_EVENT 0x54 +#define HDMI_PORD BIT(25) +#define HDMI_HT
[RFC v4 00/11] MT8173 DRM support
Hi,
this is an update to the MT8173 DRM support RFC, now with the connections
between display function blocks completely left out of the device tree.
I have included the two patches that add all relevant nodes to the mt8173.dtsi,
and two mt8173 clock patches that are needed to support the new clock bindings.
So there are a few more patch dependencies now on top of v4.3-rc5. To apply:
https://patchwork.kernel.org/patch/6980951/ ("arm64: dts: mt8173: Add subsystem
clock controller device nodes"),
https://patchwork.kernel.org/patch/6825601/ ("arm64: dts: mt8173: add MT8173
display PWM driver support node"),
https://patchwork.kernel.org/patch/7138531/ ("arm64: dts: mediatek: add xHCI &
usb phy for mt8173"),
https://patchwork.kernel.org/patch/6928651/ ("dts: mt8173: Add iommu/smi nodes
for mt8173"), and
https://patchwork.kernel.org/patch/6983351/ ("clk: mediatek: Add USB clock
support in MT8173 APMIXEDSYS").
And to build,
https://patchwork.kernel.org/patch/6914941/ ("iommu: Implement common IOMMU ops
for DMA mapping"),
https://patchwork.kernel.org/patch/6928621/ ("memory: mediatek: Add SMI
driver"),
https://patchwork.kernel.org/patch/6928561/ ("dt-bindings: iommu: Add binding
for mediatek IOMMU"),
https://patchwork.kernel.org/patch/6980911/ ("clk: mediatek: Removed unused
dpi_ck clock from MT8173"),
https://patchwork.kernel.org/patch/6980981/ ("clk: mediatek: Add __initdata and
__init for data and functions"),
https://patchwork.kernel.org/patch/6981021/ ("clk: mediatek: Add fixed clocks
support for Mediatek SoC."),
https://patchwork.kernel.org/patch/6980961/ ("clk: mediatek: Fix rate and
dependency of MT8173 clocks"),
https://patchwork.kernel.org/patch/6981031/ ("dt-bindings: ARM: Mediatek:
Document devicetree bindings for clock controllers"), and
https://patchwork.kernel.org/patch/6981041/ ("clk: mediatek: Add subsystem
clocks of MT8173").
Changes since v3:
- Added device mt8173 dtsi changes
- Added clock patches to allow calling clk_set_rate on the dpi0_sel and
hdmi_sel muxes, added the hdmi_ref PLL output.
- Moved DISP function blocks back out of the group node
- Removed intermediate divider and mux clocks from the DPI bindings
- Let the DRM driver bind to the mediatek,mt8173-mmsys compatible,
find sibling components in the device tree via compatible value,
determine component instance from of alias id.
- Split the CEC node/driver out of the HDMI bindings/driver, respectively.
- Moved hotplug irq handling into the CEC driver, stopped disabling the
hotplug irq on hdmi_power_off.
- Removed direct apmixedsys register access from the hdmi driver,
added a PLL reference clock input to the HDMI PHY.
- Dropped DT configurable HDMI min_clock and max_clock
- Changed HDMI MMSYS_CONFIG access to syscon/regmap
- Changed clock handling of the DPI, HDMI, and HDMI PHY drivers, allowing to
drop div and sel clocks from the bindings, and to power down the TVDPLL
while HDMI is not in use.
- Various fixes
Patch 8 still contains a TODO:
- The power-domain property should be added to all blocks that are in the
MM power domain.
I'm not quite sure which those are. All of the nodes in the mmsys region?
- The iommus property should be removed from the mmsys node.
I have not yet managed to properly attach the drm device to the iommu domain
that can be retrieved from the ovl, rdma, and wdma nodes.
Those are the only devices connected to the iommu via their local arbiter.
regards
Philipp
CK Hu (5):
dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding
drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.
drm/mediatek: Add DSI sub driver
arm64: dts: mt8173: Add display subsystem related nodes
arm64: dts: mt8173: Add HDMI related nodes
Daniel Kurtz (1):
drm/mediatek: Add HDMI support
Jie Qiu (2):
drm/mediatek: Add DPI sub driver
drm/mediatek: enable hdmi output control bit
Philipp Zabel (3):
dt-bindings: drm/mediatek: Add Mediatek HDMI dts binding
clk: mediatek: make dpi0_sel and hdmi_sel not propagate rate changes
clk: mediatek: Add hdmi_ref HDMI PHY PLL reference clock output
.../bindings/drm/mediatek/mediatek,disp.txt| 182 +
.../bindings/drm/mediatek/mediatek,dpi.txt | 35 +
.../bindings/drm/mediatek/mediatek,dsi.txt | 53 ++
.../bindings/drm/mediatek/mediatek,hdmi.txt| 127
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 284
drivers/clk/mediatek/clk-mt8173.c | 9 +-
drivers/clk/mediatek/clk-mtk.h | 7 +-
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/mediatek/Kconfig | 22 +
drivers/gpu/drm/mediatek/Makefile | 21 +
drivers/gpu/drm/mediatek/mtk_cec.c | 252 +++
drivers/gpu/drm/mediatek/mtk_cec.h | 25 +
drivers/gpu/drm/mediatek/mtk_dpi.c | 683
[RFC v4 07/11] drm/mediatek: enable hdmi output control bit
From: Jie Qiu
MT8173 HDMI hardware has a output control bit to enable/disable HDMI
output. Because of security reason, so this bit can ONLY be controlled
in ARM supervisor mode. Now the only way to enter ARM supervisor is the
ARM trusted firmware. So atf provides a API for HDMI driver to call to
setup this HDMI control bit to enable HDMI output in supervisor mode.
Signed-off-by: Jie Qiu
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/mediatek/mtk_hdmi_hw.c | 11 +++
drivers/gpu/drm/mediatek/mtk_hdmi_regs.h | 1 +
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_hw.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_hw.c
index 2e898fd..5093a7f 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_hw.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_hw.c
@@ -19,8 +19,15 @@
#include
#include
#include
+#include
#include
+static int (*invoke_psci_fn)(u64, u64, u64, u64);
+typedef int (*psci_initcall_t)(const struct device_node *);
+
+asmlinkage int __invoke_psci_fn_hvc(u64, u64, u64, u64);
+asmlinkage int __invoke_psci_fn_smc(u64, u64, u64, u64);
+
static u32 mtk_hdmi_read(struct mtk_hdmi *hdmi, u32 offset)
{
return readl(hdmi->regs + offset);
@@ -173,6 +180,10 @@ void mtk_hdmi_hw_vid_black(struct mtk_hdmi *hdmi,
void mtk_hdmi_hw_make_reg_writable(struct mtk_hdmi *hdmi,
bool enable)
{
+ invoke_psci_fn = __invoke_psci_fn_smc;
+ invoke_psci_fn(MTK_SIP_SET_AUTHORIZED_SECURE_REG,
+ 0x14000904, 0x8000, 0);
+
regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
HDMI_PCLK_FREE_RUN, enable ? HDMI_PCLK_FREE_RUN : 0);
regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG1C,
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
index b3d75e2..87cea50 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
@@ -317,4 +317,5 @@
#define RGS_HDMITX_5T1_EDG (0xf << 4)
#define RGS_HDMITX_PLUG_TST BIT(0)
+#define MTK_SIP_SET_AUTHORIZED_SECURE_REG 0x8201
#endif
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v4 01/11] dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding
From: CK Hu
Add device tree binding documentation for the display subsystem in
Mediatek MT8173 SoCs. The display function block nodes are grouped
under a display-subsystem node.
Signed-off-by: CK Hu
Signed-off-by: Philipp Zabel
---
Changes since v3:
- Moved DISP function blocks back out of the group node, updated example
from the device tree, including wdma blocks.
- Removed the divider and mux clocks from the DPI bindings, those are
not direct inputs and can be set by the clock framework.
---
.../bindings/drm/mediatek/mediatek,disp.txt| 182 +
.../bindings/drm/mediatek/mediatek,dpi.txt | 35
.../bindings/drm/mediatek/mediatek,dsi.txt | 53 ++
3 files changed, 270 insertions(+)
create mode 100644
Documentation/devicetree/bindings/drm/mediatek/mediatek,disp.txt
create mode 100644
Documentation/devicetree/bindings/drm/mediatek/mediatek,dpi.txt
create mode 100644
Documentation/devicetree/bindings/drm/mediatek/mediatek,dsi.txt
diff --git a/Documentation/devicetree/bindings/drm/mediatek/mediatek,disp.txt
b/Documentation/devicetree/bindings/drm/mediatek/mediatek,disp.txt
new file mode 100644
index 000..cc23eed
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/mediatek/mediatek,disp.txt
@@ -0,0 +1,182 @@
+Mediatek display subsystem
+==
+
+The Mediatek display subsystem consists of various DISP function blocks in the
+MMSYS register space. The connections between them can be configured by output
+and input selectors in the MMSYS_CONFIG register space and register updates can
+be synchronized to video frame boundaries with help of a DISP_MUTEX function
+block.
+
+For a description of the MMSYS_CONFIG binding, see
+Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt.
+
+DISP function blocks
+
+
+A display stream starts at a source function block that reads pixel data from
+memory and ends with a sink function block that drives pixels on a display
+interface, or writes pixels back to memory. All DISP function blocks have
+their own register space, interrupt, and clock gate. The blocks that can
+access memory additionally have to list the IOMMU and local arbiter they are
+connected to.
+
+For a description of the display interface sink function blocks, see
+Documentation/devicetree/bindings/drm/mediatek/mediatek,dsi.txt and
+Documentation/devicetree/bindings/drm/mediatek/mediatek,dpi.txt.
+
+Required properties (all function blocks):
+- compatible: "mediatek,-disp-", one of
+ "mediatek,-disp-ovl" - overlay (4 layers, blending, csc)
+ "mediatek,-disp-rdma" - read DMA / line buffer
+ "mediatek,-disp-wdma" - write DMA
+ "mediatek,-disp-color" - color processor
+ "mediatek,-disp-aal" - adaptive ambient light controller
+ "mediatek,-disp-gamma" - gamma correction
+ "mediatek,-disp-ufoe" - data compression engine
+ "mediatek,-dsi"- DSI controller, see mediatek,dsi.txt
+ "mediatek,-dpi"- DPI controller, see mediatek,dpi.txt
+ "mediatek,-disp-mutex" - display mutex
+ "mediatek,-disp-od"- overdrive
+- reg: Physical base address and length of the function block register space
+- interrupts: The interrupt signal from the function block.
+- clocks: device clocks
+ See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
+- compatible: "mediatek,-ddp"
+
+Required properties (DMA function blocks):
+- compatible: Should be one of
+ "mediatek,-disp-ovl"
+ "mediatek,-disp-rdma"
+ "mediatek,-disp-wdma"
+- larb: Should contain a phandle pointing to the local arbiter device as
defined
+ in Documentation/devicetree/bindings/soc/mediatek/mediatek,smi-larb.txt
+- iommus: required a iommu node
+
+Examples:
+
+mmsys: clock-controller@1400 {
+ compatible = "mediatek,mt8173-mmsys", "syscon";
+ reg = <0 0x1400 0 0x1000>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ #clock-cells = <1>;
+};
+
+ovl0: ovl@1400c000 {
+ compatible = "mediatek,mt8173-disp-ovl";
+ reg = <0 0x1400c000 0 0x1000>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_DISP_OVL0>;
+ iommus = <&iommu M4U_LARB0_ID M4U_PORT_DISP_OVL0>;
+ mediatek,larb = <&larb0>;
+};
+
+ovl1: ovl@1400d000 {
+ compatible = "mediatek,mt8173-disp-ovl";
+ reg = <0 0x1400d000 0 0x1000>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_DISP_OVL1>;
+ iommus = <&iommu M4U_LARB4_ID M4U_PORT_DISP_OVL1>;
+ mediatek,larb = <&larb4>;
+};
+
+rdma0: rdma@1400e000 {
+ compatible = "mediatek,mt8173-disp-rdma";
+ reg = <0 0x1400e000 0 0x1000>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_DISP_RDMA0>;
+ iommus = <&iommu M4U_LARB0_ID M4U_PORT_DISP_RDMA0>;
+ mediatek,larb = <&larb0>;
+};
+
+rdma1: rdma@1400f000 {
+ compatible = "mediatek,mt8173-disp-rdma";
+ reg = <0 0x1400f000 0 0x1000>;
+ inte
[RFC v4 05/11] dt-bindings: drm/mediatek: Add Mediatek HDMI dts binding
Add the device tree binding documentation for Mediatek HDMI,
HDMI PHY and HDMI DDC devices.
Signed-off-by: Philipp Zabel
---
Changes since v3:
- Split CEC block into a separate node, move the hotplug interrupt there
- Removed reg-names, hdmi now only as a single register range
- Added mediatek,cec and mediatek,syscon-hdmi phandles
- Shortened clock names, removed div and sel clocks from the binding
- Added a pll_ref clock input to the hdmi phy.
- Fixed the hdmi interrupt to the documented value.
---
.../bindings/drm/mediatek/mediatek,hdmi.txt| 127 +
1 file changed, 127 insertions(+)
create mode 100644
Documentation/devicetree/bindings/drm/mediatek/mediatek,hdmi.txt
diff --git a/Documentation/devicetree/bindings/drm/mediatek/mediatek,hdmi.txt
b/Documentation/devicetree/bindings/drm/mediatek/mediatek,hdmi.txt
new file mode 100644
index 000..2ba5f65
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/mediatek/mediatek,hdmi.txt
@@ -0,0 +1,127 @@
+Mediatek HDMI Encoder
+=
+
+The Mediatek HDMI encoder can generate HDMI 1.4a or MHL 2.0 signals from
+its parallel input.
+
+Required properties:
+- compatible: Should be "mediatek,-hdmi".
+- reg: Physical base address and length of the controller's registers
+- interrupts: The interrupt signal from the function block.
+- clocks: device clocks
+ See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
+- clock-names: must contain "pixel", "pll", "bclk", and "spdif".
+- mediatek,cec: phandle link to the HDMI CEC node.
+- ddc-i2c-bus: phandle link to the I2C controller used for DDC EDID probing
+- phys: phandle link to the HDMI PHY node.
+ See Documentation/devicetree/bindings/phy/phy-bindings.txt for details.
+- phy-names: must contain "hdmi"
+- mediatek,syscon-hdmi: phandle link and register offset to the system
+ configuration registers. For mt8173 this must be offset 0x900 into the
+ MMSYS_CONFIG region: <&mmsys 0x900>.
+- ports: A node containing input and output port nodes with endpoint
+ definitions as documented in Documentation/devicetree/bindings/graph.txt.
+- port@0: The input port in the ports node should be connected to a DPI output
+ port.
+
+Optional properties:
+- port@1: The output port in the ports node can be connected to the input port
+ of an attached bridge chip, such as a SlimPort transmitter.
+
+HDMI CEC
+
+
+The HDMI CEC controller handles hotplug detection and CEC communication.
+
+Required properties:
+- compatible: Should be "mediatek,-cec"
+- reg: Physical base address and length of the controller's registers
+- interrupts: The interrupt signal from the function block.
+- clocks: device clock
+
+HDMI DDC
+
+
+The HDMI DDC i2c controller is used to interface with the HDMI DDC pins.
+The Mediatek's I2C controller is used to interface with I2C devices.
+
+Required properties:
+- compatible: Should be "mediatek,-hdmi-ddc"
+- reg: Physical base address and length of the controller's registers
+- clocks: device clock
+- clock-names: Should be "ddc-i2c".
+
+HDMI PHY
+
+
+The HDMI PHY serializes the HDMI encoder's three channel 10-bit parallel
+output and drives the HDMI pads.
+
+Required properties:
+- compatible: "mediatek,-hdmi-phy"
+- reg: Physical base address and length of the module's registers
+- clocks: PLL reference clock
+- clock-names: must contain "pll_ref"
+- #phy-cells: must be <0>.
+
+Optional properties:
+- ibias: TX DRV bias current for <1.65Gbps, defaults to 0xa
+- ibias_up: TX DRV bias current for >1.65Gbps, defaults to 0x1c
+
+Example:
+
+cec: cec@10013000 {
+ compatible = "mediatek,mt8173-cec";
+ reg = <0 0x10013000 0 0xbc>;
+ interrupts = ;
+ clocks = <&infracfg CLK_INFRA_CEC>;
+};
+
+hdmi_phy: hdmi-phy@10209100 {
+ compatible = "mediatek,mt8173-hdmi-phy";
+ reg = <0 0x10209100 0 0x24>;
+ clocks = <&apmixedsys CLK_APMIXED_HDMI_REF>;
+ clock-names = "pll_ref";
+ ibias = <0xa>;
+ ibias_up = <0x1c>;
+ #phy-cells = <0>;
+};
+
+hdmi_ddc0: i2c@11012000 {
+ compatible = "mediatek,mt8173-hdmi-ddc";
+ reg = <0 0x11012000 0 0x1c>;
+ interrupts = ;
+ clocks = <&pericfg CLK_PERI_I2C5>;
+ clock-names = "ddc-i2c";
+};
+
+hdmi0: hdmi@14025000 {
+ compatible = "mediatek,mt8173-hdmi";
+ reg = <0 0x14025000 0 0x400>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_HDMI_PIXEL>,
+<&mmsys CLK_MM_HDMI_PLLCK>,
+<&mmsys CLK_MM_HDMI_AUDIO>,
+<&mmsys CLK_MM_HDMI_SPDIF>;
+ clock-names = "pixel", "pll", "bclk", "spdif";
+ mediatek,cec = <&cec>;
+ ddc-i2c-bus = <&hdmiddc0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_pin>;
+ phys = <&hdmi_phy>;
+ phy-names = "hdmi";
+ mediatek,syscon-hdmi = <&mmsys 0x900>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
[RFC v4 10/11] clk: mediatek: make dpi0_sel and hdmi_sel not propagate rate changes
These muxes are supposed to select a fitting divider after the PLL
is already set to the correct rate.
Signed-off-by: Philipp Zabel
---
drivers/clk/mediatek/clk-mt8173.c | 4 ++--
drivers/clk/mediatek/clk-mtk.h| 7 +--
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt8173.c
b/drivers/clk/mediatek/clk-mt8173.c
index 01f7365..e7b3997 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -550,7 +550,7 @@ static const struct mtk_composite top_muxes[] __initconst =
{
MUX_GATE(CLK_TOP_ATB_SEL, "atb_sel", atb_parents, 0x0090, 16, 2, 23),
MUX_GATE(CLK_TOP_VENC_LT_SEL, "venclt_sel", venc_lt_parents, 0x0090,
24, 4, 31),
/* CLK_CFG_6 */
- MUX_GATE(CLK_TOP_DPI0_SEL, "dpi0_sel", dpi0_parents, 0x00a0, 0, 3, 7),
+ MUX_GATE_FLAGS(CLK_TOP_DPI0_SEL, "dpi0_sel", dpi0_parents, 0x00a0, 0,
3, 7, 0),
MUX_GATE(CLK_TOP_IRDA_SEL, "irda_sel", irda_parents, 0x00a0, 8, 2, 15),
MUX_GATE(CLK_TOP_CCI400_SEL, "cci400_sel", cci400_parents, 0x00a0, 16,
3, 23),
MUX_GATE(CLK_TOP_AUD_1_SEL, "aud_1_sel", aud_1_parents, 0x00a0, 24, 2,
31),
@@ -561,7 +561,7 @@ static const struct mtk_composite top_muxes[] __initconst =
{
MUX_GATE(CLK_TOP_SCAM_SEL, "scam_sel", scam_parents, 0x00b0, 24, 2, 31),
/* CLK_CFG_12 */
MUX_GATE(CLK_TOP_SPINFI_IFR_SEL, "spinfi_ifr_sel", spinfi_ifr_parents,
0x00c0, 0, 3, 7),
- MUX_GATE(CLK_TOP_HDMI_SEL, "hdmi_sel", hdmi_parents, 0x00c0, 8, 2, 15),
+ MUX_GATE_FLAGS(CLK_TOP_HDMI_SEL, "hdmi_sel", hdmi_parents, 0x00c0, 8,
2, 15, 0),
MUX_GATE(CLK_TOP_DPILVDS_SEL, "dpilvds_sel", dpilvds_parents, 0x00c0,
24, 3, 31),
/* CLK_CFG_13 */
MUX_GATE(CLK_TOP_MSDC50_2_H_SEL, "msdc50_2_h_sel", msdc50_2_h_parents,
0x00d0, 0, 3, 7),
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index f390cb0..1acb046 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -66,7 +66,7 @@ struct mtk_composite {
signed char num_parents;
};
-#define MUX_GATE(_id, _name, _parents, _reg, _shift, _width, _gate) { \
+#define MUX_GATE_FLAGS(_id, _name, _parents, _reg, _shift, _width, _gate,
_flags) {\
.id = _id, \
.name = _name, \
.mux_reg = _reg,\
@@ -77,9 +77,12 @@ struct mtk_composite {
.divider_shift = -1,\
.parent_names = _parents, \
.num_parents = ARRAY_SIZE(_parents),\
- .flags = CLK_SET_RATE_PARENT, \
+ .flags = _flags,\
}
+#define MUX_GATE(_id, _name, _parents, _reg, _shift, _width, _gate)\
+ MUX_GATE_FLAGS(_id, _name, _parents, _reg, _shift, _width, _gate,
CLK_SET_RATE_PARENT)
+
#define MUX(_id, _name, _parents, _reg, _shift, _width) { \
.id = _id, \
.name = _name, \
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v4 09/11] arm64: dts: mt8173: Add HDMI related nodes
From: CK Hu
This patch adds the device nodes for the HDMI encoder, HDMI PHY,
and HDMI CEC modules.
Signed-off-by: CK Hu
Signed-off-by: Cawa Cheng
Signed-off-by: Jie Qiu
Signed-off-by: Daniel Kurtz
Signed-off-by: Philipp Zabel
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 73
1 file changed, 73 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 9874ab1..cd7b1b6 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -199,6 +199,30 @@
,
;
+ hdmi_pin: xxx {
+
+ /*hdmi htplg pin*/
+ pins1 {
+ pinmux =
;
+ input-enable;
+ bias-pull-down;
+ };
+
+ /*hdmi flt 5v pin*/
+ pins2 {
+ pinmux =
;
+ input-enable;
+ bias-pull-up;
+ };
+
+ /*hdmi 5v pin*/
+ pins3 {
+ pinmux =
;
+ output-enable;
+ bias-pull-up;
+ };
+ };
+
i2c0_pins_a: i2c0 {
pins1 {
pinmux =
,
@@ -275,6 +299,13 @@
clock-names = "spi", "wrap";
};
+ cec: cec@10013000 {
+ compatible = "mediatek,mt8173-cec";
+ reg = <0 0x10013000 0 0xbc>;
+ interrupts = ;
+ clocks = <&infracfg CLK_INFRA_CEC>;
+ };
+
sysirq: intpol-controller@10200620 {
compatible = "mediatek,mt8173-sysirq",
"mediatek,mt6577-sysirq";
@@ -301,6 +332,16 @@
#clock-cells = <1>;
};
+ hdmi_phy: hdmi-phy@10209100 {
+ compatible = "mediatek,mt8173-hdmi-phy";
+ reg = <0 0x10209100 0 0x24>;
+ clocks = <&apmixedsys CLK_APMIXED_HDMI_REF>;
+ clock-names = "pll_ref";
+ ibias = <0xa>;
+ ibias_up = <0x1c>;
+ #phy-cells = <0>;
+ };
+
mipi_tx0: mipi-dphy@10215000 {
compatible = "mediatek,mt8173-mipi-tx";
reg = <0 0x10215000 0 0x1000>;
@@ -808,6 +849,38 @@
clock-names = "apb", "smi";
};
+ hdmi0: hdmi@14025000 {
+ compatible = "mediatek,mt8173-hdmi";
+ reg = <0 0x14025000 0 0x400>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_HDMI_PIXEL>,
+<&mmsys CLK_MM_HDMI_PLLCK>,
+<&mmsys CLK_MM_HDMI_AUDIO>,
+<&mmsys CLK_MM_HDMI_SPDIF>;
+ clock-names = "pixel", "pll", "bclk", "spdif";
+ mediatek,cec = <&cec>;
+ ddc-i2c-bus = <&hdmiddc0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_pin>;
+ phys = <&hdmi_phy>;
+ phy-names = "hdmi";
+ mediatek,syscon-hdmi = <&mmsys 0x900>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ hdmi0_in: endpoint {
+ remote-endpoint = <&dpi0_out>;
+ };
+ };
+ };
+ };
+
larb4: larb@14027000 {
compatible = "mediatek,mt8173-smi-larb";
reg = <0 0x14027000 0 0x1000>;
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v4 08/11] arm64: dts: mt8173: Add display subsystem related nodes
From: CK Hu
This patch adds the device nodes for the DISP function blocks
comprising the display subsystem.
---
TODO:
- The power-domain property should be added to all blocks
that are in the MM power domain.
- The iommus property should be removed from the mmsys node.
Signed-off-by: CK Hu
Signed-off-by: Cawa Cheng
Signed-off-by: Jie Qiu
Signed-off-by: Daniel Kurtz
Signed-off-by: Philipp Zabel
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 211 +++
1 file changed, 211 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 85ec24f..9874ab1 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -26,6 +26,23 @@
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ ovl0 = &ovl0;
+ ovl1 = &ovl1;
+ rdma0 = &rdma0;
+ rdma1 = &rdma1;
+ rdma2 = &rdma2;
+ wdma0 = &wdma0;
+ wdma1 = &wdma1;
+ color0 = &color0;
+ color1 = &color1;
+ split0 = &split0;
+ split1 = &split1;
+ dpi0 = &dpi0;
+ dsi0 = &dsi0;
+ dsi1 = &dsi1;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -284,6 +301,18 @@
#clock-cells = <1>;
};
+ mipi_tx0: mipi-dphy@10215000 {
+ compatible = "mediatek,mt8173-mipi-tx";
+ reg = <0 0x10215000 0 0x1000>;
+ #phy-cells = <0>;
+ };
+
+ mipi_tx1: mipi-dphy@10216000 {
+ compatible = "mediatek,mt8173-mipi-tx";
+ reg = <0 0x10216000 0 0x1000>;
+ #phy-cells = <0>;
+ };
+
gic: interrupt-controller@1022 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
@@ -417,6 +446,14 @@
status = "disabled";
};
+ hdmiddc0: i2c@11012000 {
+ compatible = "mediatek,mt8173-hdmi-ddc";
+ interrupts = ;
+ reg = <0 0x11012000 0 0x1C>;
+ clocks = <&pericfg CLK_PERI_I2C5>;
+ clock-names = "ddc-i2c";
+ };
+
i2c6: i2c6@11013000 {
compatible = "mediatek,mt8173-i2c";
reg = <0 0x11013000 0 0x70>,
@@ -553,7 +590,167 @@
mmsys: clock-controller@1400 {
compatible = "mediatek,mt8173-mmsys", "syscon";
reg = <0 0x1400 0 0x1000>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
#clock-cells = <1>;
+
+ /* FIXME - remove iommus here */
+ iommus = <&iommu M4U_LARB0_ID M4U_PORT_DISP_OVL0>,
+<&iommu M4U_LARB4_ID M4U_PORT_DISP_OVL1>;
+ };
+
+ ovl0: ovl@1400c000 {
+ compatible = "mediatek,mt8173-disp-ovl";
+ reg = <0 0x1400c000 0 0x1000>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_DISP_OVL0>;
+ iommus = <&iommu M4U_LARB0_ID M4U_PORT_DISP_OVL0>;
+ mediatek,larb = <&larb0>;
+ };
+
+ ovl1: ovl@1400d000 {
+ compatible = "mediatek,mt8173-disp-ovl";
+ reg = <0 0x1400d000 0 0x1000>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_DISP_OVL1>;
+ iommus = <&iommu M4U_LARB4_ID M4U_PORT_DISP_OVL1>;
+ mediatek,larb = <&larb4>;
+ };
+
+ rdma0: rdma@1400e000 {
+ compatible = "mediatek,mt8173-disp-rdma";
+ reg = <0 0x1400e000 0 0x1000>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_DISP_RDMA0>;
+ iommus = <&iommu M4U_LARB0_ID M4U_PORT_DISP_RDMA0>;
+ mediatek,larb = <&larb0>;
+ };
+
+ rdma1: rdma@1400f000 {
+ compatible = "mediatek,mt8173-disp-rdma";
+ reg = <0 0x1400f000 0 0x1000>;
+ interrupts = ;
+ clocks = <&mmsys CLK_MM_DISP_RDMA1>;
+ iommus = <&iommu M4U_LARB4_ID M4U_PORT_DISP_RDMA1>;
+ mediatek,larb = <&larb4>;
+ };
+
+ rdma2: rdma@1401 {
+ compatible = "mediatek,mt8173-disp-rdma";
+ reg = <0 0x1401 0 0x1000>;
+
[RFC v4 02/11] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.
From: CK Hu This patch adds an initial DRM driver for the Mediatek MT8173 DISP subsystem. It currently supports two fixed output streams from the OVL0/OVL1 sources to the DSI0/DPI0 sinks, respectively. Signed-off-by: CK Hu Signed-off-by: YT Shen Signed-off-by: Philipp Zabel --- Changes since v3: - Removed crtc enabling/disabling on bind/unbind, the enable/disable callbacks should suffice. - Find sibling components in the device tree via compatible value - Split component type and instance id enums - Determine component type from compatible, component instance id from type and of alias - Added remaining DSI, RDMA and WDMA ids - Moved register mapping and mutex node search into probe function - Bind drm driver to mediatek,mt8173-mmsys compatible node - Do not try to call dma_free_attrs if dma_alloc_attrs failed. --- drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile| 1 + drivers/gpu/drm/mediatek/Kconfig| 16 + drivers/gpu/drm/mediatek/Makefile | 10 + drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 524 ++ drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 84 + drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 218 +++ drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 39 ++ drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 409 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 86 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 556 drivers/gpu/drm/mediatek/mtk_drm_drv.h | 61 +++ drivers/gpu/drm/mediatek/mtk_drm_fb.c | 151 drivers/gpu/drm/mediatek/mtk_drm_fb.h | 29 ++ drivers/gpu/drm/mediatek/mtk_drm_gem.c | 208 +++ drivers/gpu/drm/mediatek/mtk_drm_gem.h | 56 +++ drivers/gpu/drm/mediatek/mtk_drm_plane.c| 175 + drivers/gpu/drm/mediatek/mtk_drm_plane.h| 38 ++ 18 files changed, 2663 insertions(+) create mode 100644 drivers/gpu/drm/mediatek/Kconfig create mode 100644 drivers/gpu/drm/mediatek/Makefile create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_crtc.c create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_crtc.h create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp.c create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp.h create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_drv.c create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_drv.h create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.c create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.h create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_gem.c create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_gem.h create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_plane.c create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_plane.h diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 1a0a8df..9e9987b 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -264,3 +264,5 @@ source "drivers/gpu/drm/sti/Kconfig" source "drivers/gpu/drm/amd/amdkfd/Kconfig" source "drivers/gpu/drm/imx/Kconfig" + +source "drivers/gpu/drm/mediatek/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 45e7719..af6b592 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -67,6 +67,7 @@ obj-$(CONFIG_DRM_MSM) += msm/ obj-$(CONFIG_DRM_TEGRA) += tegra/ obj-$(CONFIG_DRM_STI) += sti/ obj-$(CONFIG_DRM_IMX) += imx/ +obj-$(CONFIG_DRM_MEDIATEK) += mediatek/ obj-y += i2c/ obj-y += panel/ obj-y += bridge/ diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig new file mode 100644 index 000..5343cf1 --- /dev/null +++ b/drivers/gpu/drm/mediatek/Kconfig @@ -0,0 +1,16 @@ +config DRM_MEDIATEK + tristate "DRM Support for Mediatek SoCs" + depends on DRM + depends on ARCH_MEDIATEK || (ARM && COMPILE_TEST) + select MTK_SMI + select DRM_PANEL + select DRM_MIPI_DSI + select DRM_PANEL_SIMPLE + select DRM_KMS_HELPER + select IOMMU_DMA + help + Choose this option if you have a Mediatek SoCs. + The module will be called mediatek-drm + This driver provides kernel mode setting and + buffer management to userspace. + diff --git a/drivers/gpu/drm/mediatek/Makefile b/drivers/gpu/drm/mediatek/Makefile new file mode 100644 index 000..ba6d3fc --- /dev/null +++ b/drivers/gpu/drm/mediatek/Makefile @@ -0,0 +1,10 @@ +mediatek-drm-y := mtk_drm_drv.o \ + mtk_drm_crtc.o \ + mtk_drm_ddp.o \ + mtk_drm_ddp_comp.o \ + mtk_drm_fb.o \ + mtk_drm_gem.o \ + mtk_drm_plane.o + +obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o + diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_dr
[RFC v4 11/11] clk: mediatek: Add hdmi_ref HDMI PHY PLL reference clock output
The configurable hdmi_ref output of the PLL block is derived from
the tvdpll_594m clock signal via a configurable PLL post-divider.
It is used as the PLL reference input to the HDMI PHY module.
Signed-off-by: Philipp Zabel
---
drivers/clk/mediatek/clk-mt8173.c | 5 +
include/dt-bindings/clock/mt8173-clk.h | 3 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/mediatek/clk-mt8173.c
b/drivers/clk/mediatek/clk-mt8173.c
index e7b3997..fe7a91b 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -901,6 +901,11 @@ static void __init mtk_apmixedsys_init(struct device_node
*node)
clk_data->clks[cku->id] = clk;
}
+ clk = clk_register_divider(NULL, "hdmi_ref", "tvdpll_594m", 0,
+ base + 0x40, 16, 3, CLK_DIVIDER_POWER_OF_TWO,
+ NULL);
+ clk_data->clks[CLK_APMIXED_HDMI_REF] = clk;
+
r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
if (r)
pr_err("%s(): could not register clock provider: %d\n",
diff --git a/include/dt-bindings/clock/mt8173-clk.h
b/include/dt-bindings/clock/mt8173-clk.h
index bf1302e..784e987 100644
--- a/include/dt-bindings/clock/mt8173-clk.h
+++ b/include/dt-bindings/clock/mt8173-clk.h
@@ -173,7 +173,8 @@
#define CLK_APMIXED_LVDSPLL13
#define CLK_APMIXED_MSDCPLL2 14
#define CLK_APMIXED_REF2USB_TX 15
-#define CLK_APMIXED_NR_CLK 16
+#define CLK_APMIXED_HDMI_REF 16
+#define CLK_APMIXED_NR_CLK 17
/* INFRA_SYS */
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 7/7] arm64: dts: berlin4ct: add default pinmux for uart0
On 16.10.2015 16:18, Linus Walleij wrote: On Fri, Oct 16, 2015 at 9:37 AM, Jisheng Zhang wrote: Add urt0 txd and rxd muxing setup in the dtsi because uart0 always uses them to work, no other possibilities. Signed-off-by: Jisheng Zhang Acked-by: Sebastian Hesselbarth Acked-by: Antoine Tenart Acked-by: Linus Walleij Funnel this through ARM SoC. Applied to berlin64/dt with Linus' Ack. Thanks, Sebastian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 6/7] arm64: dts: berlin4ct: add the pinctrl node
On 16.10.2015 16:17, Linus Walleij wrote: On Fri, Oct 16, 2015 at 9:37 AM, Jisheng Zhang wrote: Add the avio, soc, sm pinctrl nodes for Marvell berlin4ct SoC. Signed-off-by: Jisheng Zhang Acked-by: Sebastian Hesselbarth Acked-by: Antoine Tenart Acked-by: Linus Walleij Funnel this through ARM SoC. Applied to berlin64/dt with Linus' Ack. Thanks, Sebastian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] misc: Add w2sg0004 gps receiver driver
Am 16.10.2015 um 21:38 schrieb Arnd Bergmann :
> On Friday 16 October 2015 21:27:11 H. Nikolaus Schaller wrote:
>> Am 16.10.2015 um 21:06 schrieb Arnd Bergmann :
>>
>>> On Friday 16 October 2015 20:08:35 H. Nikolaus Schaller wrote:
+
+static int w2sg_data_probe(struct platform_device *pdev)
+{
+ struct w2sg_pdata *pdata = dev_get_platdata(&pdev->dev);
+ struct w2sg_data *data;
+ struct rfkill *rf_kill;
+ int err;
+
+ pr_debug("%s()\n", __func__);
+
+ if (pdev->dev.of_node) {
+ struct device *dev = &pdev->dev;
+ enum of_gpio_flags flags;
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
>>>
>>> Why is this a platform_device and not a serio_device?
>>
>> I can't find a struct serio_device. What is that?
>>
>
> Sorry, I meant 'struct serio', see drivers/input/serio/
>
> This is an existing infrastructure that is used for devices attached
> to a dumb serial device (rs232 or 8042/psaux usually). They have
> a user interface for connecting a driver to a port, but you should
> be able to do it all in the kernel as well if DT has the information
> what device is connected.
Ah, I understand. But it is for a different purpose. E.g. making a
serial device (mouse/touch) an input device. So it is a driver sitting
"on top" of tty/uart drivers.
The problem to be solved here is a different one. The only task for
the driver is to do power control of the device. I.e. turn it on by
open("/dev/ttyX") or asserting DTR.
So we are on a much lower level.
Please see also the patch 0/3 I have resent (the BLURB defined
by git --edit-description was apparently eaten by my git send-email).
BR and thanks,
Nikolaus
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] mmc: sdhci-pxav3: fix optional clock name
On 16.10.2015 13:40, Jisheng Zhang wrote:
On Thu, 15 Oct 2015 23:41:22 +0200
Sebastian Hesselbarth wrote:
On 12.10.2015 07:46, Jisheng Zhang wrote:
Commit 8afdc9cca27f ("mmc: sdhci-pxav3: Get optional core clock") adds
additional optional clock support, but the clock names isn't correct.
The current "io" clock is really the PXAv3 SDHCI IP's "core" clock
which is manadatory. The current "core" clock is really the IP's "axi"
clock which is optional.
Signed-off-by: Jisheng Zhang
---
[...]
Please split the DT changes from the driver changes.
Such split will break berlin SDHC functionality, I'm not sure whether this is
acceptable.
I am not going to funnel any driver stuff through berlin-tree anymore
if it isn't really neccessary.
[...]
- clocks: Array of clocks required for SDHCI; requires at least one for
-I/O clock.
+core clock.
- clock-names: Array of names corresponding to clocks property; shall be
-"io" for I/O clock and "core" for optional core clock.
+"core" for core clock and "axi" for optional axi clock.
s/axi/bus/ ?
HW call this clk as axi, "bus" seems more generic, right?
Yes, please pick the generic name. Given the age of that IP,
I guess it will run on AHB instead of AXI on PXA.
[...]
- pxa->clk_io = devm_clk_get(dev, "io");
- if (IS_ERR(pxa->clk_io))
- pxa->clk_io = devm_clk_get(dev, NULL);
- if (IS_ERR(pxa->clk_io)) {
- dev_err(dev, "failed to get io clock\n");
- ret = PTR_ERR(pxa->clk_io);
+ pxa->clk_core = devm_clk_get(dev, "core");
To maintain backward compatibility, we should still
I just grep the kernel source, found that only mrvl berlin SoCs have two clks,
other SoCs just have one clk and don't provide clock name. So the question
here is whether we can break linux backward compatibility for mrvl berlin
SoCs. I think we could for the following reason:
That is the point: do not break it on purpose.
Try to separate DT and driver changes without breaking the tree
in between.
Sebastian
1. rare boards outside mrvl can boot user self-built kernel, most boards should
be protected by trust-chainloader mechanism.
2. mrvl berlin SoCs upgrade linux kernel and dtb at the same time
what do you think?
Is it better to refine patch 2, 3, 4, 5 to make use current "io","core" binding
to clean up the clk's CLK_IGNORE_UNUSED flags? In fact, they doesn't depend
on patch1. Could you please kindly give advice?
Thanks in advance,
Jisheng
devm_clk_get(dev, "io") here - or even better, first
probe for "io" to catch old binding semantics including
old "core"/"bus" misnaming.
If we detected old semantics, print a warning that
firmware should be updated.
Sebastian
+ if (IS_ERR(pxa->clk_core))
+ pxa->clk_core = devm_clk_get(dev, NULL);
+ if (IS_ERR(pxa->clk_core)) {
+ dev_err(dev, "failed to get core clock\n");
+ ret = PTR_ERR(pxa->clk_core);
goto err_clk_get;
}
- pltfm_host->clk = pxa->clk_io;
- clk_prepare_enable(pxa->clk_io);
+ pltfm_host->clk = pxa->clk_core;
+ clk_prepare_enable(pxa->clk_core);
- pxa->clk_core = devm_clk_get(dev, "core");
- if (!IS_ERR(pxa->clk_core))
- clk_prepare_enable(pxa->clk_core);
+ pxa->clk_axi = devm_clk_get(dev, "axi");
+ if (!IS_ERR(pxa->clk_axi))
+ clk_prepare_enable(pxa->clk_axi);
/* enable 1/8V DDR capable */
host->mmc->caps |= MMC_CAP_1_8V_DDR;
@@ -475,8 +475,8 @@ err_add_host:
err_of_parse:
err_cd_req:
err_mbus_win:
- clk_disable_unprepare(pxa->clk_io);
clk_disable_unprepare(pxa->clk_core);
+ clk_disable_unprepare(pxa->clk_axi);
err_clk_get:
sdhci_pltfm_free(pdev);
return ret;
@@ -494,8 +494,8 @@ static int sdhci_pxav3_remove(struct platform_device *pdev)
sdhci_remove_host(host, 1);
- clk_disable_unprepare(pxa->clk_io);
clk_disable_unprepare(pxa->clk_core);
+ clk_disable_unprepare(pxa->clk_axi);
sdhci_pltfm_free(pdev);
@@ -542,9 +542,9 @@ static int sdhci_pxav3_runtime_suspend(struct device *dev)
if (ret)
return ret;
- clk_disable_unprepare(pxa->clk_io);
- if (!IS_ERR(pxa->clk_core))
- clk_disable_unprepare(pxa->clk_core);
+ clk_disable_unprepare(pxa->clk_core);
+ if (!IS_ERR(pxa->clk_axi))
+ clk_disable_unprepare(pxa->clk_axi);
return 0;
}
@@ -555,9 +555,9 @@ static int sdhci_pxav3_runtime_resume(struct device *dev)
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_pxa *pxa = pltfm_host->priv;
- clk_prepare_enable(pxa->clk_io);
- if (!IS_ERR(pxa->clk_core))
- clk_prepare_enable(pxa->clk_core);
+ clk_prepare_enable(pxa->clk_core);
+ if (!IS_ERR(pxa->clk_axi))
+ clk_prepare_enable(pxa->clk_axi);
return sdhci_runtim
Re: [PATCH v2 2/4] mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64
On Friday 16 October 2015 12:28:03 Florian Fainelli wrote:
> >
> > Sorry, can't reproduce it any more. My patch is dated June 4, so it was
> > probably broken then but got fixed since. I normally try to verify that
> > the patches are still needed before I send them, but this time I only
> > saw the current discussion and remembered something vague about it
> > and sent what I had in my backlog of the randconfig-fixes series.
>
> It may have been a problem before this patch:
>
> d80d942bcc8e1555a76774d20be9800cfef2d415 ("ARM: BCM: Do not select
> CONFIG_MTD_NAND_BRCMNAND")
> --
>
Yes, that must have been it. So my patch was not only outdated but
also wrong ;-)
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] misc: Add w2sg0004 gps receiver driver
On Friday 16 October 2015 21:27:11 H. Nikolaus Schaller wrote:
> Am 16.10.2015 um 21:06 schrieb Arnd Bergmann :
>
> > On Friday 16 October 2015 20:08:35 H. Nikolaus Schaller wrote:
> >> +
> >> +static int w2sg_data_probe(struct platform_device *pdev)
> >> +{
> >> + struct w2sg_pdata *pdata = dev_get_platdata(&pdev->dev);
> >> + struct w2sg_data *data;
> >> + struct rfkill *rf_kill;
> >> + int err;
> >> +
> >> + pr_debug("%s()\n", __func__);
> >> +
> >> + if (pdev->dev.of_node) {
> >> + struct device *dev = &pdev->dev;
> >> + enum of_gpio_flags flags;
> >> +
> >> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> >> + if (!pdata)
> >>
> >
> > Why is this a platform_device and not a serio_device?
>
> I can't find a struct serio_device. What is that?
>
Sorry, I meant 'struct serio', see drivers/input/serio/
This is an existing infrastructure that is used for devices attached
to a dumb serial device (rs232 or 8042/psaux usually). They have
a user interface for connecting a driver to a port, but you should
be able to do it all in the kernel as well if DT has the information
what device is connected.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] tty: serial core: provide a method to search uart by phandle
Hi Nikolaus, [auto build test WARNING on tty/tty-next -- if it's inappropriate base, please suggest rules for selecting the more suitable base] url: https://github.com/0day-ci/linux/commits/H-Nikolaus-Schaller/UART-slave-device-support-goldelico-version/20151017-021238 reproduce: make htmldocs All warnings (new ones prefixed by >>): include/linux/init.h:1: warning: no structured comments found kernel/sys.c:1: warning: no structured comments found drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found drivers/dma-buf/reservation.c:1: warning: no structured comments found include/linux/reservation.h:1: warning: no structured comments found include/media/v4l2-dv-timings.h:29: warning: cannot understand function prototype: 'const struct v4l2_dv_timings v4l2_dv_timings_presets[]; ' include/media/v4l2-dv-timings.h:147: warning: No description found for parameter 'frame_height' include/media/v4l2-dv-timings.h:147: warning: No description found for parameter 'hfreq' include/media/v4l2-dv-timings.h:147: warning: No description found for parameter 'vsync' include/media/v4l2-dv-timings.h:147: warning: No description found for parameter 'active_width' include/media/v4l2-dv-timings.h:147: warning: No description found for parameter 'polarities' include/media/v4l2-dv-timings.h:147: warning: No description found for parameter 'interlaced' include/media/v4l2-dv-timings.h:147: warning: No description found for parameter 'fmt' include/media/v4l2-dv-timings.h:171: warning: No description found for parameter 'frame_height' include/media/v4l2-dv-timings.h:171: warning: No description found for parameter 'hfreq' include/media/v4l2-dv-timings.h:171: warning: No description found for parameter 'vsync' include/media/v4l2-dv-timings.h:171: warning: No description found for parameter 'polarities' include/media/v4l2-dv-timings.h:171: warning: No description found for parameter 'interlaced' include/media/v4l2-dv-timings.h:171: warning: No description found for parameter 'aspect' include/media/v4l2-dv-timings.h:171: warning: No description found for parameter 'fmt' include/media/v4l2-dv-timings.h:184: warning: No description found for parameter 'hor_landscape' include/media/v4l2-dv-timings.h:184: warning: No description found for parameter 'vert_portrait' include/media/videobuf2-core.h:112: warning: No description found for parameter 'get_dmabuf' include/media/videobuf2-core.h:233: warning: No description found for parameter 'cnt_mem_alloc' include/media/videobuf2-core.h:233: warning: No description found for parameter 'cnt_mem_put' include/media/videobuf2-core.h:233: warning: No description found for parameter 'cnt_mem_get_dmabuf' include/media/videobuf2-core.h:233: warning: No description found for parameter 'cnt_mem_get_userptr' include/media/videobuf2-core.h:233: warning: No description found for parameter 'cnt_mem_put_userptr' include/media/videobuf2-core.h:233: warning: No description found for parameter 'cnt_mem_prepare' include/media/videobuf2-core.h:233: warning: No description found for parameter 'cnt_mem_finish' include/media/videobuf2-core.h:233: warning: No description found for parameter 'cnt_mem_attach_dmabuf' include/media/videobuf2-core.h:233: warning: No description found for parameter 'cnt_mem_detach_dmabuf' include/media/videobuf2-core.h:233: warning: No description found for parameter 'cnt_mem_map_dmabuf' include/media/videobuf2-core.h:233: warning: No description found for parameter 'cnt_mem_unmap_dmabuf' include/media/videobuf2-core.h:233: warning: No description found for parameter 'cnt_mem_vaddr' include/media/videobuf2-core.h:233: warning: No description found for parameter 'cnt_mem_cookie' include/media/videobuf2-core.h:233: warning: No description found for parameter 'cnt_mem_num_users' include/media/videobuf2-core.h:233: warning: No description found for parameter 'cnt_mem_mmap' include/media/videobuf2-core.h:233: warning: No description found for parameter 'cnt_buf_init' include/media/videobuf2-core.h:233: warning: No description found for parameter 'cnt_buf_prepare' include/media/videobuf2-core.h:233: warning: No description found for parameter 'cnt_buf_finish' include/media/videobuf2-core.h:233: warning: No description found for parameter 'cnt_buf_cleanup' include/media/videobuf2-core.h:233: warning: No description found for parameter 'cnt_buf_queue' include/media/videobuf2-core.h:233: warning: No description found for parameter 'cnt_buf_done' drivers/media/dvb-core/dvbdev.h:199: warning: Excess function parameter 'device' description in 'dvb_register_device' drivers/media/dvb-core/dvbdev.h:199: warning: Excess function parameter 'adapter_nums' description in 'dvb_register_device' >> drivers/tty/serial/serial_core.c:117: warning: No description found for >> parameter 'dev' >> drivers/tty/serial/serial_c
Re: [PATCH v2 2/4] mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64
On 16/10/15 12:25, Arnd Bergmann wrote:
> On Friday 16 October 2015 09:54:45 Brian Norris wrote:
>>> MTD_NAND_BRCMNAND uses the generic nand functions, but is currently allowed
>>> to be built without CONFIG_MTD_NAND, which results in a link error:
>>>
>>> drivers/built-in.o: In function `brcmnand_remove':
>>> coresight-replicator.c:(.text+0x17ae6c): undefined reference to
>>> `nand_release'
>>> drivers/built-in.o: In function `brcmnand_probe':
>>> coresight-replicator.c:(.text+0x17d4b4): undefined reference to
>>> `nand_scan_ident'
>>> coresight-replicator.c:(.text+0x17d948): undefined reference to
>>> `nand_scan_tail'
>>
>> How did you get this? MTD_NAND_BRCMNAND is surrounded in the
>> 'if MTD_NAND' block, which implicitly generates a MTD_NAND dependency.
>> And I can confirm that in menuconfig, I see this when I disable MTD_NAND
>> and search for BRCMNAND:
>>
>>Symbol: MTD_NAND_BRCMNAND [=n]
>>Type : tristate
>>Prompt: Broadcom STB NAND controller
>> Location:
>>-> Device Drivers
>> -> Memory Technology Device (MTD) support (MTD [=y])
>>(1) -> NAND Device Support (MTD_NAND [=n])
>> Defined at drivers/mtd/nand/Kconfig:394
>> Depends on: MTD [=y] && MTD_NAND [=n] && (ARM [=y] || ARM64 || MIPS)
>
> Sorry, can't reproduce it any more. My patch is dated June 4, so it was
> probably broken then but got fixed since. I normally try to verify that
> the patches are still needed before I send them, but this time I only
> saw the current discussion and remembered something vague about it
> and sent what I had in my backlog of the randconfig-fixes series.
It may have been a problem before this patch:
d80d942bcc8e1555a76774d20be9800cfef2d415 ("ARM: BCM: Do not select
CONFIG_MTD_NAND_BRCMNAND")
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] misc: Add w2sg0004 gps receiver driver
Am 16.10.2015 um 21:06 schrieb Arnd Bergmann :
> On Friday 16 October 2015 20:08:35 H. Nikolaus Schaller wrote:
>> +
>> +static int w2sg_data_probe(struct platform_device *pdev)
>> +{
>> + struct w2sg_pdata *pdata = dev_get_platdata(&pdev->dev);
>> + struct w2sg_data *data;
>> + struct rfkill *rf_kill;
>> + int err;
>> +
>> + pr_debug("%s()\n", __func__);
>> +
>> + if (pdev->dev.of_node) {
>> + struct device *dev = &pdev->dev;
>> + enum of_gpio_flags flags;
>> +
>> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>> + if (!pdata)
>>
>
> Why is this a platform_device and not a serio_device?
I can't find a struct serio_device. What is that?
BR and thanks,
Nikolaus
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64
On Friday 16 October 2015 09:54:45 Brian Norris wrote: > > MTD_NAND_BRCMNAND uses the generic nand functions, but is currently allowed > > to be built without CONFIG_MTD_NAND, which results in a link error: > > > > drivers/built-in.o: In function `brcmnand_remove': > > coresight-replicator.c:(.text+0x17ae6c): undefined reference to > > `nand_release' > > drivers/built-in.o: In function `brcmnand_probe': > > coresight-replicator.c:(.text+0x17d4b4): undefined reference to > > `nand_scan_ident' > > coresight-replicator.c:(.text+0x17d948): undefined reference to > > `nand_scan_tail' > > How did you get this? MTD_NAND_BRCMNAND is surrounded in the > 'if MTD_NAND' block, which implicitly generates a MTD_NAND dependency. > And I can confirm that in menuconfig, I see this when I disable MTD_NAND > and search for BRCMNAND: > >Symbol: MTD_NAND_BRCMNAND [=n] >Type : tristate >Prompt: Broadcom STB NAND controller > Location: >-> Device Drivers > -> Memory Technology Device (MTD) support (MTD [=y]) >(1) -> NAND Device Support (MTD_NAND [=n]) > Defined at drivers/mtd/nand/Kconfig:394 > Depends on: MTD [=y] && MTD_NAND [=n] && (ARM [=y] || ARM64 || MIPS) Sorry, can't reproduce it any more. My patch is dated June 4, so it was probably broken then but got fixed since. I normally try to verify that the patches are still needed before I send them, but this time I only saw the current discussion and remembered something vague about it and sent what I had in my backlog of the randconfig-fixes series. Sorry for the confusion. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] tty: serial core: provide a method to search uart by phandle
Am 16.10.2015 um 20:39 schrieb Mark Rutland :
> On Fri, Oct 16, 2015 at 08:08:33PM +0200, H. Nikolaus Schaller wrote:
>> 1. add uart_ports to a search list as soon as they are registered
>> 2. provide a function to search an uart_port by phandle. This copies the
>> mechanism how devm_usb_get_phy_by_phandle() works
>> 3. add a bindings document how serial slaves should use this feature
>> 4. add Documentation how serla slaves work in general
>
> I thought maintainers preferred the child node approach to the phandle
> approach,
> and this series comes with no rationale (nor change log,
> despite being 'v3').
For unknown reasons it was not part of the outgoing git send-email.
Today is not my day of operating command line git...
I have added it as a reply.
>
> I don't understand. What is going on here?
There was a discussion about child vs. phandle and I came up with thousands
of technical arguments and examples from other subsystems where phandle
is common. Because I still don't believe that child node approach is the right
one.
At some time of this discussion, I was asked to provide code because people
wanted to compare both ideas on code basis.
Therefore I wrote an implementation that works and shows all aspects.
I published V1 and V2 and got some comments, but not really much.
What I never got was a really convincing argumentation or principle or DT
writer's
guideline why uart slaves must be subnodes (except that "uart" is a degenerate
variant of a "bus" and therefore must be prepared to have multiple child nodes).
The latest counter-example I have found is how iio adcs are accessed:
Documentation/devicetree/bindings/iio/iio-bindings.txt
One could as well argue that adcs are a "bus" (especially if they have multiple
inputs) and therefore all consumers of adc data must be their children... But
they
are not.
Nothing has happened since I submittted RFC V2. I.e. there is no child node
based
approach accepted. There was no significant comparison or discussion.
Therefore I took the freedom to resubmit my code and prevent it from bitrotting
in my local git repo.
Hope this explains.
BR and thanks,
Nikolaus
> Mark.
>
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> .../devicetree/bindings/serial/slaves.txt | 16 +++
>> Documentation/serial/slaves.txt| 36 +++
>> drivers/tty/serial/serial_core.c | 107
>> +
>> include/linux/serial_core.h| 10 ++
>> 4 files changed, 169 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/serial/slaves.txt
>> create mode 100644 Documentation/serial/slaves.txt
>>
>> diff --git a/Documentation/devicetree/bindings/serial/slaves.txt
>> b/Documentation/devicetree/bindings/serial/slaves.txt
>> new file mode 100644
>> index 000..353b87f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/serial/slaves.txt
>> @@ -0,0 +1,16 @@
>> +Device-Tree bindings for UART slave devices
>> +
>> +A node describing a slave device defines a phandle to reference the UART
>> +the device is connected to. In the (unexpected) case of two or more UARTs
>> +a list of phandles can be specified.
>> +
>> +properties:
>> +- uart: (list of) phandle(s) of UART(s) the device is connected to
>> +
>> +
>> +example:
>> +
>> +gps {
>> +compatible = "wi2wi,w2sg0004";
>> +uart = <&uart1>;
>> +};
>> diff --git a/Documentation/serial/slaves.txt
>> b/Documentation/serial/slaves.txt
>> new file mode 100644
>> index 000..6f8d44d
>> --- /dev/null
>> +++ b/Documentation/serial/slaves.txt
>> @@ -0,0 +1,36 @@
>> +UART slave device support
>> +
>> +A remote device connected to a RS232 interface is usually power controlled
>> by the DTR line.
>> +The DTR line is managed automatically by the UART driver for open() and
>> close() syscalls
>> +and on demand by tcsetattr().
>> +
>> +With embedded devices, the serial peripheral might be directly and always
>> connected to the UART
>> +and there might be no physical DTR line involved. Power control (on/off)
>> has to be done by some
>> +chip specific device driver (which we call "UART slave") through some
>> mechanisms (I2C, GPIOs etc.)
>> +not related to the serial interface. Some devices do not explicitly tell
>> their power state except
>> +by sending or not sending data to the UART. In such a case the device
>> driver must be able to monitor
>> +data activity. The role of the device driver is to encapsulate such power
>> control in a single place.
>> +
>> +This patch series allows to support such drivers by providing:
>> +* a mechanism that a slave driver can identify the UART instance it is
>> connected to
>> +* a mechanism that UART slave drivers can register to be notified
>> +* notfications for DTR (and other modem control) state changes
>> +* notifications that the UART has received some data from the UART
>> +
>> +A slave device simply adds a phandle reference to the UART it is conne
Re: [PATCH 01/16] PM / OPP: Add 'supply-names' binding
On 10/16, Viresh Kumar wrote: > On 15-10-15, 17:22, Stephen Boyd wrote: > > I'm lost why we need this property at all. What happened to using > > > > opp-microvolt-0 = <1 2 3>; > > opp-microvolt-1 = <1>; > > opp-microvolt-2 = <3 4 5>; > > etc. > > Perhaps you are confusing this with the bindings we came up for > picking right voltage levels based on the cuts/version of the hardware > we are running on. The problem that Lee Jones mentioned and that can > be used in your case as well. Isn't that what this patch series is for? > > > That seems to avoid any problem with 3 vs. 1 element properties > > combined into one large array. > > That's not the problem I was trying to solve here. What problem are you trying to solve then? > > > Having supply-names seems too > > brittle and would tie us to a particular OPP user's decision to > > call supplies by some name. > > No. The name has to match the -supply property present in the > device's node, that's why we need this property :) Why does it need to match? Sorry I'm totally lost now. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/3] UART slave device support (goldelico version)
Changes V3:
- changed from RFC to PATCH
- added separate bindings and concept documentation documents
- worked in comments by Sergei Zviagintsev
Changes V2:
- fixed some formatting
This patch series is our proposal to add hooks so that the driver for a device
connected to an UART can
monitor modem control lines and data activity of the connected chip.
It contains an example for such a device driver which needs such sophisticated
power control: wi2wi,w2sg0004
A remote device connected to a RS232 interface is usually power controlled by
the DTR line.
The DTR line is managed automatically by the UART driver for open() and close()
syscalls
and on demand by tcsetattr().
With embedded devices, the serial peripheral might be directly and always
connected to the UART
and there might be no physical DTR line involved. Power control (on/off) has to
be done by some
chip specific device driver (which we call "UART slave") through some
mechanisms (I2C, GPIOs etc.)
not related to the serial interface. Some devices do not tell their power state
except by sending
or not sending data to the UART. In such a case the device driver must be able
to monitor data
activity. The role of the device driver is to encapsulate such power control in
a single place.
This patch series allows to support such UART slave drivers by providing:
* a mechanism that a slave driver can identify the UART instance it is
connected to
* a mechanism that UART slave drivers can register to be notified
* notfications for DTR (and other modem control) state changes
* notifications that the device has sent some data to the UART
A slave device tree entry simply adds a phandle reference to the UART it is
connected to, e.g.
gps {
compatible = "wi2wi,w2sg0004";
uart = <&uart1>;
};
The slave driver calls devm_serial_get_uart_by_phandle() to identify the uart
driver.
devm_serial_get_uart_by_phandle() follows the concept of
devm_usb_get_phy_by_phandle().
A slave device driver registers itself with serial_register_slave() to receive
notifications.
Notification handlers can be registered by serial_register_mctrl_notification()
and
serial_register_rx_notification(). If an UART has a NULL slave or a NULL
handler registered,
no notifications are sent.
RX notification handlers can define a ktermios setup and modify or decide to
throw away the
character that is passed upwards.
This all is a follow-up to the w2sg0004 driver submitted in 2014 that did want
to add an optional
GPIO to DTR in omap-serial.c and required the w2sg0004 driver to present itself
as a "virtual
GPIO". The idea of a "virtual GPIO" is not compatible with the concept that DT
must
describe hardware (and not virtual hardware). So in this new solution DT only
describes that
the w2sg0004 is connected to some UART and how the power state signalling works
is left
to the driver implementations.
The rx data notification also removes the concept of having two different
pinmux states
and make the w2sg0004 driver intercept rx activities by switching the rx line
to a GPIO
interrupt. This was very OMAP3 specific. The new solution is generic and might
even be
extensible that the chip driver could filter or consume the rx data before it
is passed
to the tty layer.
This patch works on 4.3-rc as intended except one major weakness: we have to
call
uart_change_speed() each time we open the tty. This is the opposite of what we
would like
to have: that the slave initializes the uart speed through some termios and the
tty level just uses
this setting. We have not yet completely understood how to make this work and
are happy
about help in this area.
Am 16.10.2015 um 20:08 schrieb H. Nikolaus Schaller :
> H. Nikolaus Schaller (3):
> tty: serial core: provide a method to search uart by phandle
> tty: serial_core: add hooks for uart slave drivers
> misc: Add w2sg0004 gps receiver driver
>
> .../devicetree/bindings/misc/wi2wi,w2sg0004.txt| 18 +
> .../devicetree/bindings/serial/slaves.txt | 16 +
> .../devicetree/bindings/vendor-prefixes.txt| 1 +
> Documentation/serial/slaves.txt| 36 ++
> drivers/misc/Kconfig | 18 +
> drivers/misc/Makefile | 1 +
> drivers/misc/w2sg0004.c| 443 +
> drivers/tty/serial/serial_core.c | 214 +-
> include/linux/serial_core.h| 25 +-
> include/linux/w2sg0004.h | 27 ++
> 10 files changed, 793 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
> create mode 100644 Documentation/devicetree/bindings/serial/slaves.txt
> create mode 100644 Documentation/serial/slaves.txt
> create mode 100644 drivers/misc/w2sg0004.c
> create mode 100644 include/linux/w2sg0004.h
>
> --
> 2.5.1
>
--
To unsubscribe from this list: send the line "uns
Re: [PATCH v3 3/3] misc: Add w2sg0004 gps receiver driver
On Friday 16 October 2015 20:08:35 H. Nikolaus Schaller wrote:
> +
> +static int w2sg_data_probe(struct platform_device *pdev)
> +{
> + struct w2sg_pdata *pdata = dev_get_platdata(&pdev->dev);
> + struct w2sg_data *data;
> + struct rfkill *rf_kill;
> + int err;
> +
> + pr_debug("%s()\n", __func__);
> +
> + if (pdev->dev.of_node) {
> + struct device *dev = &pdev->dev;
> + enum of_gpio_flags flags;
> +
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
>
Why is this a platform_device and not a serio_device?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] tty: serial core: provide a method to search uart by phandle
On Friday 16 October 2015 20:08:33 H. Nikolaus Schaller wrote:
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/slaves.txt
> @@ -0,0 +1,16 @@
> +Device-Tree bindings for UART slave devices
> +
> +A node describing a slave device defines a phandle to reference the UART
> +the device is connected to. In the (unexpected) case of two or more UARTs
> +a list of phandles can be specified.
> +
> +properties:
> + - uart: (list of) phandle(s) of UART(s) the device is connected to
> +
> +
> +example:
> +
> + gps {
> + compatible = "wi2wi,w2sg0004";
> + uart = <&uart1>;
> + };
>
I would have expected the gps device here to be a child node of the
uart in DT. Can you explain why you chose differently?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] clk: samsung: exynos5250: Add DISP1 clocks
On 16 October 2015 at 19:26, Stephen Boyd wrote: > On 10/16, Michael Turquette wrote: >> Quoting Krzysztof Kozlowski (2015-10-15 16:46:27) >> > On 15.10.2015 19:31, Tomeu Vizoso wrote: >> > > When the DISP1 power domain is powered off, there's two clocks that need >> > > to be temporarily reparented to OSC, and back to their original parents >> > > when the domain is powered on again. >> > > >> > > We expose these two clocks in the DT bindings so that the DT node of the >> > > power domain can reference them. >> > > >> > > Signed-off-by: Tomeu Vizoso >> > > Acked-by: Stephen Boyd >> > > --- >> > > >> > > Changes in v2: >> > > - Reuse mout_aclk200_p >> > > - Rename div_aclk300 as div_aclk300_disp >> > > >> > > drivers/clk/samsung/clk-exynos5250.c | 14 +- >> > > include/dt-bindings/clock/exynos5250.h | 4 +++- >> > > 2 files changed, 16 insertions(+), 2 deletions(-) >> > > >> > >> > Reviewed-by: Krzysztof Kozlowski >> >> Applied to clk-next. >> > > I think Tomeu wanted to take this through arm-soc? Otherwise > we'll need to provide a stable branch for the dt header. Hi, Stephen is right, the second patch depends on this one. Thanks, Tomeu > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] tty: serial core: provide a method to search uart by phandle
Hi Nikolaus,
[auto build test WARNING on tty/tty-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/H-Nikolaus-Schaller/UART-slave-device-support-goldelico-version/20151017-021238
config: i386-randconfig-s1-201541 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/tty/serial/serial_core.c: In function 'devm_serial_uart_release':
>> drivers/tty/serial/serial_core.c:64:20: warning: unused variable 'uart'
>> [-Wunused-variable]
struct uart_port *uart = *(struct uart_port **)res;
^
vim +/uart +64 drivers/tty/serial/serial_core.c
48
49 if (!of_device_is_available(node))
50 return ERR_PTR(-ENODEV);
51
52 list_for_each_entry(uart, &uart_list, head) {
53 if (node != uart->dev->of_node)
54 continue;
55
56 return uart;
57 }
58
59 return ERR_PTR(-EPROBE_DEFER);
60 }
61
62 static void devm_serial_uart_release(struct device *dev, void *res)
63 {
> 64 struct uart_port *uart = *(struct uart_port **)res;
65
66 /* FIXME: I don't understand the serial subsystem well enough
67 * to know if we should call serial_put_uart(uart); here
68 */
69 }
70
71 /*
72 * This is used to lock changes in serial line configuration.
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH 2/2] DT: nvmem: Add NXP LPC18xx EEPROM memory binding documentation
Ezequiel, Joachim, all, El 16/10/15 a las 14:09, Joachim Eastwood escribió: > On 16 October 2015 at 17:41, Ezequiel Garcia > wrote: >> +DT bindings maintainers >> >> As per the documentation in >> Documentation/devicetree/bindings/submitting-patches.txt >> this binding should be patch 1/2. I see. I'll modify that. >> >> On 16 October 2015 at 11:07, Ariel D'Alessandro >> wrote: >>> Add the devicetree binding document for NXP LPC18xx EEPROM memory. >>> >>> Signed-off-by: Ariel D'Alessandro >>> --- >>> .../devicetree/bindings/nvmem/lpc18xx_eeprom.txt | 26 >>> ++ >>> 1 file changed, 26 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/nvmem/lpc18xx_eeprom.txt >>> >>> diff --git a/Documentation/devicetree/bindings/nvmem/lpc18xx_eeprom.txt >>> b/Documentation/devicetree/bindings/nvmem/lpc18xx_eeprom.txt >>> new file mode 100644 >>> index 000..372ff8c >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/nvmem/lpc18xx_eeprom.txt >>> @@ -0,0 +1,26 @@ >>> +* NXP LPC18xx EEPROM memory NVMEM driver >>> + >>> +Required properties: >>> + - compatible: Should be "nxp,lpc1850-eeprom" >> >> Correct me if I'm wrong, but I believe not all LPC18xx/43xx devices >> have an EEPROM. >> >> Isn't it restricted to LPC18x7/LPC43x7 devices? > > The EEPROM can only be found on Flash devices. Flashless devices > doesn't have the EEPROM. Yes, you're right. LPC1850 is wrong, sorry. The UM10430 (LPC18xx User Manual) says that LPC18(5|3|2|1)(7|5|3|2) parts have flash and that the LPC185x/3x parts with flash also include the 16 kB EEPROM. I'll add this info in a new set of patches v2. > > >> Should the compatible be nxp,lpc1857-eeprom to avoid confusion? > > Yes, please. The EEPROM doesn't exist on LPC1850 so please use the > compatibility string from Ezequiel. OK. I'll fix this. Is there any reason for using lpc1857 instead of a different available one? Thanks! -- Ariel D'Alessandro, VanguardiaSur www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] tty: serial core: provide a method to search uart by phandle
On Fri, Oct 16, 2015 at 08:08:33PM +0200, H. Nikolaus Schaller wrote:
> 1. add uart_ports to a search list as soon as they are registered
> 2. provide a function to search an uart_port by phandle. This copies the
>mechanism how devm_usb_get_phy_by_phandle() works
> 3. add a bindings document how serial slaves should use this feature
> 4. add Documentation how serla slaves work in general
I thought maintainers preferred the child node approach to the phandle
approach, and this series comes with no rationale (nor change log,
despite being 'v3').
I don't understand. What is going on here?
Mark.
> Signed-off-by: H. Nikolaus Schaller
> ---
> .../devicetree/bindings/serial/slaves.txt | 16 +++
> Documentation/serial/slaves.txt| 36 +++
> drivers/tty/serial/serial_core.c | 107
> +
> include/linux/serial_core.h| 10 ++
> 4 files changed, 169 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/serial/slaves.txt
> create mode 100644 Documentation/serial/slaves.txt
>
> diff --git a/Documentation/devicetree/bindings/serial/slaves.txt
> b/Documentation/devicetree/bindings/serial/slaves.txt
> new file mode 100644
> index 000..353b87f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/slaves.txt
> @@ -0,0 +1,16 @@
> +Device-Tree bindings for UART slave devices
> +
> +A node describing a slave device defines a phandle to reference the UART
> +the device is connected to. In the (unexpected) case of two or more UARTs
> +a list of phandles can be specified.
> +
> +properties:
> + - uart: (list of) phandle(s) of UART(s) the device is connected to
> +
> +
> +example:
> +
> + gps {
> + compatible = "wi2wi,w2sg0004";
> + uart = <&uart1>;
> + };
> diff --git a/Documentation/serial/slaves.txt b/Documentation/serial/slaves.txt
> new file mode 100644
> index 000..6f8d44d
> --- /dev/null
> +++ b/Documentation/serial/slaves.txt
> @@ -0,0 +1,36 @@
> +UART slave device support
> +
> +A remote device connected to a RS232 interface is usually power controlled
> by the DTR line.
> +The DTR line is managed automatically by the UART driver for open() and
> close() syscalls
> +and on demand by tcsetattr().
> +
> +With embedded devices, the serial peripheral might be directly and always
> connected to the UART
> +and there might be no physical DTR line involved. Power control (on/off) has
> to be done by some
> +chip specific device driver (which we call "UART slave") through some
> mechanisms (I2C, GPIOs etc.)
> +not related to the serial interface. Some devices do not explicitly tell
> their power state except
> +by sending or not sending data to the UART. In such a case the device driver
> must be able to monitor
> +data activity. The role of the device driver is to encapsulate such power
> control in a single place.
> +
> +This patch series allows to support such drivers by providing:
> +* a mechanism that a slave driver can identify the UART instance it is
> connected to
> +* a mechanism that UART slave drivers can register to be notified
> +* notfications for DTR (and other modem control) state changes
> +* notifications that the UART has received some data from the UART
> +
> +A slave device simply adds a phandle reference to the UART it is connected
> to, e.g.
> +
> + gps {
> + compatible = "wi2wi,w2sg0004";
> + uart = <&uart1>;
> + };
> +
> +The slave driver calls devm_serial_get_uart_by_phandle() to identify the
> uart driver.
> +This API follows the concept of devm_usb_get_phy_by_phandle().
> +
> +A slave device driver registers itself with serial_register_slave() to
> receive notifications.
> +Notification handler callbacks can be registered by
> serial_register_mctrl_notification() and
> +serial_register_rx_notification(). If an UART has registered a NULL slave or
> a NULL handler,
> +no notifications are sent.
> +
> +RX notification handlers can define a ktermios during setup and the handler
> function can modify
> +or decide to throw away each character that is passed upwards.
> diff --git a/drivers/tty/serial/serial_core.c
> b/drivers/tty/serial/serial_core.c
> index 603d2cc..9caa33e 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -38,6 +38,36 @@
> #include
> #include
>
> +static LIST_HEAD(uart_list);
> +static DEFINE_SPINLOCK(uart_lock);
> +
> +/* same concept as __of_usb_find_phy */
> +static struct uart_port *__of_serial_find_uart(struct device_node *node)
> +{
> + struct uart_port *uart;
> +
> + if (!of_device_is_available(node))
> + return ERR_PTR(-ENODEV);
> +
> + list_for_each_entry(uart, &uart_list, head) {
> + if (node != uart->dev->of_node)
> + continue;
> +
> + return uart;
> + }
> +
> + return ERR_PTR(-EPROBE_DEFER);
> +}
> +
> +static void devm_serial_uart
Re: [PATCH v3 3/3] misc: Add w2sg0004 gps receiver driver
Am 16.10.2015 um 20:08 schrieb H. Nikolaus Schaller :
> Add driver for Wi2Wi W2SG0004/84 GPS module connected through uart.
> Use uart slave + notification hooks to glue with tty and turn on/off the
> module. Detect if the module is turned on (sends data) but should be off,
> e.g. if already turned on during boot.
>
> Additionally, rfkill block/unblock can be used to control an external LNA
> (and power down the module if not needed).
>
> The driver concept is based on code developed by NeilBrown
> but simplified and adapted to use the serial slave API.
>
> Signed-off-by: H. Nikolaus Schaller
> ---
> .../devicetree/bindings/misc/wi2wi,w2sg0004.txt| 18 +
> .../devicetree/bindings/vendor-prefixes.txt| 1 +
> drivers/misc/Kconfig | 18 +
> drivers/misc/Makefile | 1 +
> drivers/misc/w2sg0004.c| 443 +
> drivers/tty/serial/serial_core.c | 25 +-
^^^sorry this change is garbage from patch editing^^^
> include/linux/w2sg0004.h | 27 ++
> 7 files changed, 522 insertions(+), 11 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
> create mode 100644 drivers/misc/w2sg0004.c
> create mode 100644 include/linux/w2sg0004.h
>
> diff --git a/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
> b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
> new file mode 100644
> index 000..ef0d6d5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
> @@ -0,0 +1,18 @@
> +Wi2Wi GPS module connected through UART
> +
> +Required properties:
> +- compatible: wi2wi,w2sg0004 or wi2wi,w2sg0084
> +- on-off-gpio: the GPIO that controls the module's on-off toggle input
> +- uart: the uart we are connected to (provides DTR for power control)
> +
> +Optional properties:
> +- lna-suppy: an (optional) LNA regulator that is enabled together with the
> GPS receiver
> +
> +example:
> +
> +gps_receiver: w2sg0004 {
> +compatible = "wi2wi,w2sg0004";
> +lna-supply = <&vsim>;/* LNA regulator */
> +on-off-gpio = <&gpio5 17 0>; /* GPIO_145: trigger for
> turning on/off w2sg0004 */
> +uart = <&uart1>; /* we are a slave of uart1 */
> +}
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 82d2ac9..a778eb5 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -230,6 +230,7 @@ via VIA Technologies, Inc.
> virtioVirtual I/O Device Specification, developed by the OASIS
> consortium
> voipacVoipac Technologies s.r.o.
> wexlerWexler
> +wi2wiWi2Wi, Inc.
> winbond Winbond Electronics corp.
> wlf Wolfson Microelectronics
> wmWondermedia Technologies, Inc.
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index c29..1279faf 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -537,4 +537,22 @@ source "drivers/misc/mic/Kconfig"
> source "drivers/misc/genwqe/Kconfig"
> source "drivers/misc/echo/Kconfig"
> source "drivers/misc/cxl/Kconfig"
> +
> +menu "GTA04 misc hardware support"
> +
> +config W2SG0004
> + tristate "W2SG0004 on/off control"
> + depends on GPIOLIB
> + help
> + Enable on/off control of W2SG0004 GPS to allow powering up/down if
> + the /dev/tty$n is opened/closed.
> + It also provides a rfkill gps node to control the LNA power.
> +
> +config W2SG0004_DEBUG
> + bool "W2SG0004 on/off debugging"
> + depends on W2SG0004
> + help
> + Enable driver debugging mode of W2SG0004 GPS.
> +
> +endmenu
> endmenu
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 537d7f3..a153a89 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -54,5 +54,6 @@ obj-$(CONFIG_SRAM) += sram.o
> obj-y += mic/
> obj-$(CONFIG_GENWQE) += genwqe/
> obj-$(CONFIG_ECHO)+= echo/
> +obj-$(CONFIG_W2SG0004) += w2sg0004.o
> obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
> obj-$(CONFIG_CXL_BASE)+= cxl/
> diff --git a/drivers/misc/w2sg0004.c b/drivers/misc/w2sg0004.c
> new file mode 100644
> index 000..6aadf44
> --- /dev/null
> +++ b/drivers/misc/w2sg0004.c
> @@ -0,0 +1,443 @@
> +/*
> + * w2sg0004.c
> + * Driver for power controlling the w2sg0004/w2sg0084 GPS receiver.
> + *
> + * This receiver has an ON/OFF pin which must be toggled to
> + * turn the device 'on' of 'off'. A high->low->high toggle
> + * will switch the device on if it is off, and off if it is on.
> + *
> + * To enable receiving on/off requests we register with the
> + * UART power management notifications.
> + *
> + * It is not possible to directly detect the state of the d
Re: [RFC 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
Hi Jitao,
[auto build test ERROR on drm-exynos/exynos-drm/for-next -- if it's
inappropriate base, please suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/CK-Hu/Dcumentation-bridge-Add-documentation-for-ps8640-DT-properties/20151016-201658
config: s390-allmodconfig (attached as .config)
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=s390
All errors (new ones prefixed by >>):
drivers/gpu/drm/bridge/parade-ps8640.c: In function 'ps8640_prepare':
>> drivers/gpu/drm/bridge/parade-ps8640.c:178:2: error: implicit declaration of
>> function 'gpiod_set_value' [-Werror=implicit-function-declaration]
gpiod_set_value(ps_bridge->gpio_pwr_n, 1);
^
drivers/gpu/drm/bridge/parade-ps8640.c: In function 'ps8640_probe':
>> drivers/gpu/drm/bridge/parade-ps8640.c:391:2: error: implicit declaration of
>> function 'devm_gpiod_get' [-Werror=implicit-function-declaration]
ps_bridge->gpio_mode_sel_n = devm_gpiod_get(&client->dev, "mode-sel",
^
>> drivers/gpu/drm/bridge/parade-ps8640.c:392:11: error: 'GPIOD_OUT_HIGH'
>> undeclared (first use in this function)
GPIOD_OUT_HIGH);
^
drivers/gpu/drm/bridge/parade-ps8640.c:392:11: note: each undeclared
identifier is reported only once for each function it appears in
>> drivers/gpu/drm/bridge/parade-ps8640.c:399:2: error: implicit declaration of
>> function 'gpiod_direction_output' [-Werror=implicit-function-declaration]
ret = gpiod_direction_output(ps_bridge->gpio_mode_sel_n, 1);
^
cc1: some warnings being treated as errors
vim +/gpiod_set_value +178 drivers/gpu/drm/bridge/parade-ps8640.c
172 err = regulator_enable(ps_bridge->pwr_3v3_supply);
173 if (err < 0) {
174 DRM_ERROR("failed to enable pwr_3v3_supply: %d\n", err);
175 return;
176 }
177
> 178 gpiod_set_value(ps_bridge->gpio_pwr_n, 1);
179 gpiod_set_value(ps_bridge->gpio_rst_n, 0);
180 usleep_range(500, 700);
181 gpiod_set_value(ps_bridge->gpio_rst_n, 1);
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
[PATCH v3 2/3] tty: serial_core: add hooks for uart slave drivers
1. allow drivers to get notified about mctrl changes
2. allow drivers to get notified about rx data (indicating to the
driver that the connected chip is active)
3. the driver also has the option to modify or block the
received character instead of passing to the tty layer
Signed-off-by: H. Nikolaus Schaller
---
drivers/tty/serial/serial_core.c | 104 +--
include/linux/serial_core.h | 15 +-
2 files changed, 113 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 9caa33e..b731100 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -166,6 +166,86 @@ err0:
}
EXPORT_SYMBOL_GPL(devm_serial_get_uart_by_phandle);
+void uart_register_slave(struct uart_port *uport, void *slave)
+{
+ if (!slave) {
+ uart_register_mctrl_notification(uport, NULL);
+ uart_register_rx_notification(uport, NULL, NULL);
+ }
+ uport->slave = slave;
+}
+EXPORT_SYMBOL_GPL(uart_register_slave);
+
+void uart_register_mctrl_notification(struct uart_port *uport,
+ int (*function)(void *slave, int state))
+{
+ uport->mctrl_notification = function;
+}
+EXPORT_SYMBOL_GPL(uart_register_mctrl_notification);
+
+static int uart_port_startup(struct tty_struct *tty, struct uart_state *state,
+ int init_hw);
+
+static void uart_port_shutdown(struct tty_port *port);
+
+void uart_register_rx_notification(struct uart_port *uport,
+ int (*function)(void *slave, unsigned int *c),
+ struct ktermios *termios)
+{
+ struct uart_state *state = uport->state;
+ struct tty_port *tty_port = &state->port;
+
+ if (!uport->slave)
+ return; /* slave must be registered first */
+
+ uport->rx_notification = function;
+
+ if (tty_port->count == 0) {
+ if (function) {
+ int retval = 0;
+
+ uart_change_pm(state, UART_PM_STATE_ON);
+ retval = uport->ops->startup(uport);
+ if (retval == 0 && termios) {
+ int hw_stopped;
+ /*
+* Initialise the hardware port settings.
+*/
+ uport->ops->set_termios(uport, termios, NULL);
+
+ /*
+* Set modem status enables based on termios
cflag
+*/
+ spin_lock_irq(&uport->lock);
+ if (termios->c_cflag & CRTSCTS)
+ uport->status |= UPSTAT_CTS_ENABLE;
+ else
+ uport->status &= ~UPSTAT_CTS_ENABLE;
+
+ if (termios->c_cflag & CLOCAL)
+ uport->status &= ~UPSTAT_DCD_ENABLE;
+ else
+ uport->status |= UPSTAT_DCD_ENABLE;
+
+ /* reset sw-assisted CTS flow control based on
(possibly) new mode */
+ hw_stopped = uport->hw_stopped;
+ uport->hw_stopped = uart_softcts_mode(uport) &&
+ !(uport->ops->get_mctrl(uport)
+ & TIOCM_CTS);
+ if (uport->hw_stopped) {
+ if (!hw_stopped)
+ uport->ops->stop_tx(uport);
+ } else {
+ if (hw_stopped)
+ uport->ops->start_tx(uport);
+ }
+ spin_unlock_irq(&uport->lock);
+ }
+ } else
+ uart_port_shutdown(tty_port);
+ }
+}
+EXPORT_SYMBOL_GPL(uart_register_rx_notification);
/*
* This routine is used by the interrupt handler to schedule processing in
@@ -224,6 +304,10 @@ uart_update_mctrl(struct uart_port *port, unsigned int
set, unsigned int clear)
port->mctrl = (old & ~clear) | set;
if (old != port->mctrl)
port->ops->set_mctrl(port, port->mctrl);
+
+ if (port->mctrl_notification)
+ (*port->mctrl_notification)(port->slave, port->mctrl);
+
spin_unlock_irqrestore(&port->lock, flags);
}
@@ -263,7 +347,8 @@ static int uart_port_startup(struct tty_struct *tty, struct
uart_state *state,
uart_circ_clear(&state->xmit);
}
- retval = uport->ops->startup(uport);
+ if (!state->uart_port->rx_notification)
+ retval = uport->ops->startup(uport);
i
[PATCH v3 3/3] misc: Add w2sg0004 gps receiver driver
Add driver for Wi2Wi W2SG0004/84 GPS module connected through uart.
Use uart slave + notification hooks to glue with tty and turn on/off the
module. Detect if the module is turned on (sends data) but should be off,
e.g. if already turned on during boot.
Additionally, rfkill block/unblock can be used to control an external LNA
(and power down the module if not needed).
The driver concept is based on code developed by NeilBrown
but simplified and adapted to use the serial slave API.
Signed-off-by: H. Nikolaus Schaller
---
.../devicetree/bindings/misc/wi2wi,w2sg0004.txt| 18 +
.../devicetree/bindings/vendor-prefixes.txt| 1 +
drivers/misc/Kconfig | 18 +
drivers/misc/Makefile | 1 +
drivers/misc/w2sg0004.c| 443 +
drivers/tty/serial/serial_core.c | 25 +-
include/linux/w2sg0004.h | 27 ++
7 files changed, 522 insertions(+), 11 deletions(-)
create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
create mode 100644 drivers/misc/w2sg0004.c
create mode 100644 include/linux/w2sg0004.h
diff --git a/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
new file mode 100644
index 000..ef0d6d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
@@ -0,0 +1,18 @@
+Wi2Wi GPS module connected through UART
+
+Required properties:
+- compatible: wi2wi,w2sg0004 or wi2wi,w2sg0084
+- on-off-gpio: the GPIO that controls the module's on-off toggle input
+- uart: the uart we are connected to (provides DTR for power control)
+
+Optional properties:
+- lna-suppy: an (optional) LNA regulator that is enabled together with the GPS
receiver
+
+example:
+
+gps_receiver: w2sg0004 {
+compatible = "wi2wi,w2sg0004";
+lna-supply = <&vsim>; /* LNA regulator */
+on-off-gpio = <&gpio5 17 0>; /* GPIO_145: trigger for
turning on/off w2sg0004 */
+uart = <&uart1>; /* we are a slave of uart1 */
+}
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 82d2ac9..a778eb5 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -230,6 +230,7 @@ via VIA Technologies, Inc.
virtio Virtual I/O Device Specification, developed by the OASIS consortium
voipac Voipac Technologies s.r.o.
wexler Wexler
+wi2wi Wi2Wi, Inc.
winbond Winbond Electronics corp.
wlfWolfson Microelectronics
wm Wondermedia Technologies, Inc.
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index c29..1279faf 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -537,4 +537,22 @@ source "drivers/misc/mic/Kconfig"
source "drivers/misc/genwqe/Kconfig"
source "drivers/misc/echo/Kconfig"
source "drivers/misc/cxl/Kconfig"
+
+menu "GTA04 misc hardware support"
+
+config W2SG0004
+ tristate "W2SG0004 on/off control"
+ depends on GPIOLIB
+ help
+ Enable on/off control of W2SG0004 GPS to allow powering up/down if
+ the /dev/tty$n is opened/closed.
+ It also provides a rfkill gps node to control the LNA power.
+
+config W2SG0004_DEBUG
+ bool "W2SG0004 on/off debugging"
+ depends on W2SG0004
+ help
+ Enable driver debugging mode of W2SG0004 GPS.
+
+endmenu
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 537d7f3..a153a89 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -54,5 +54,6 @@ obj-$(CONFIG_SRAM)+= sram.o
obj-y += mic/
obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
+obj-$(CONFIG_W2SG0004) += w2sg0004.o
obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
obj-$(CONFIG_CXL_BASE) += cxl/
diff --git a/drivers/misc/w2sg0004.c b/drivers/misc/w2sg0004.c
new file mode 100644
index 000..6aadf44
--- /dev/null
+++ b/drivers/misc/w2sg0004.c
@@ -0,0 +1,443 @@
+/*
+ * w2sg0004.c
+ * Driver for power controlling the w2sg0004/w2sg0084 GPS receiver.
+ *
+ * This receiver has an ON/OFF pin which must be toggled to
+ * turn the device 'on' of 'off'. A high->low->high toggle
+ * will switch the device on if it is off, and off if it is on.
+ *
+ * To enable receiving on/off requests we register with the
+ * UART power management notifications.
+ *
+ * It is not possible to directly detect the state of the device.
+ * However when it is on it will send characters on a UART line
+ * regularly.
+ *
+ * To detect that the power state is out of sync (e.g. if GPS
+ * was enabled before a reboot), we register for UART data received
+ * notifications.
+ *
+ * In addition we register as a rfkill client so that we can
+ * control the LNA power.
+ *
+ */
+
+#i
[PATCH v3 1/3] tty: serial core: provide a method to search uart by phandle
1. add uart_ports to a search list as soon as they are registered
2. provide a function to search an uart_port by phandle. This copies the
mechanism how devm_usb_get_phy_by_phandle() works
3. add a bindings document how serial slaves should use this feature
4. add Documentation how serla slaves work in general
Signed-off-by: H. Nikolaus Schaller
---
.../devicetree/bindings/serial/slaves.txt | 16 +++
Documentation/serial/slaves.txt| 36 +++
drivers/tty/serial/serial_core.c | 107 +
include/linux/serial_core.h| 10 ++
4 files changed, 169 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/slaves.txt
create mode 100644 Documentation/serial/slaves.txt
diff --git a/Documentation/devicetree/bindings/serial/slaves.txt
b/Documentation/devicetree/bindings/serial/slaves.txt
new file mode 100644
index 000..353b87f
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/slaves.txt
@@ -0,0 +1,16 @@
+Device-Tree bindings for UART slave devices
+
+A node describing a slave device defines a phandle to reference the UART
+the device is connected to. In the (unexpected) case of two or more UARTs
+a list of phandles can be specified.
+
+properties:
+ - uart: (list of) phandle(s) of UART(s) the device is connected to
+
+
+example:
+
+ gps {
+ compatible = "wi2wi,w2sg0004";
+ uart = <&uart1>;
+ };
diff --git a/Documentation/serial/slaves.txt b/Documentation/serial/slaves.txt
new file mode 100644
index 000..6f8d44d
--- /dev/null
+++ b/Documentation/serial/slaves.txt
@@ -0,0 +1,36 @@
+UART slave device support
+
+A remote device connected to a RS232 interface is usually power controlled by
the DTR line.
+The DTR line is managed automatically by the UART driver for open() and
close() syscalls
+and on demand by tcsetattr().
+
+With embedded devices, the serial peripheral might be directly and always
connected to the UART
+and there might be no physical DTR line involved. Power control (on/off) has
to be done by some
+chip specific device driver (which we call "UART slave") through some
mechanisms (I2C, GPIOs etc.)
+not related to the serial interface. Some devices do not explicitly tell their
power state except
+by sending or not sending data to the UART. In such a case the device driver
must be able to monitor
+data activity. The role of the device driver is to encapsulate such power
control in a single place.
+
+This patch series allows to support such drivers by providing:
+* a mechanism that a slave driver can identify the UART instance it is
connected to
+* a mechanism that UART slave drivers can register to be notified
+* notfications for DTR (and other modem control) state changes
+* notifications that the UART has received some data from the UART
+
+A slave device simply adds a phandle reference to the UART it is connected to,
e.g.
+
+ gps {
+ compatible = "wi2wi,w2sg0004";
+ uart = <&uart1>;
+ };
+
+The slave driver calls devm_serial_get_uart_by_phandle() to identify the uart
driver.
+This API follows the concept of devm_usb_get_phy_by_phandle().
+
+A slave device driver registers itself with serial_register_slave() to receive
notifications.
+Notification handler callbacks can be registered by
serial_register_mctrl_notification() and
+serial_register_rx_notification(). If an UART has registered a NULL slave or a
NULL handler,
+no notifications are sent.
+
+RX notification handlers can define a ktermios during setup and the handler
function can modify
+or decide to throw away each character that is passed upwards.
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 603d2cc..9caa33e 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -38,6 +38,36 @@
#include
#include
+static LIST_HEAD(uart_list);
+static DEFINE_SPINLOCK(uart_lock);
+
+/* same concept as __of_usb_find_phy */
+static struct uart_port *__of_serial_find_uart(struct device_node *node)
+{
+ struct uart_port *uart;
+
+ if (!of_device_is_available(node))
+ return ERR_PTR(-ENODEV);
+
+ list_for_each_entry(uart, &uart_list, head) {
+ if (node != uart->dev->of_node)
+ continue;
+
+ return uart;
+ }
+
+ return ERR_PTR(-EPROBE_DEFER);
+}
+
+static void devm_serial_uart_release(struct device *dev, void *res)
+{
+ struct uart_port *uart = *(struct uart_port **)res;
+
+ /* FIXME: I don't understand the serial subsystem well enough
+* to know if we should call serial_put_uart(uart); here
+*/
+}
+
/*
* This is used to lock changes in serial line configuration.
*/
@@ -64,6 +94,79 @@ static int uart_dcd_enabled(struct uart_port *uport)
return !!(uport->status & UPSTAT_DCD_ENABLE);
}
+/**
+ * devm_serial_get_uart_by_phandle
[PATCH v3 0/3] UART slave device support (goldelico version)
H. Nikolaus Schaller (3): tty: serial core: provide a method to search uart by phandle tty: serial_core: add hooks for uart slave drivers misc: Add w2sg0004 gps receiver driver .../devicetree/bindings/misc/wi2wi,w2sg0004.txt| 18 + .../devicetree/bindings/serial/slaves.txt | 16 + .../devicetree/bindings/vendor-prefixes.txt| 1 + Documentation/serial/slaves.txt| 36 ++ drivers/misc/Kconfig | 18 + drivers/misc/Makefile | 1 + drivers/misc/w2sg0004.c| 443 + drivers/tty/serial/serial_core.c | 214 +- include/linux/serial_core.h| 25 +- include/linux/w2sg0004.h | 27 ++ 10 files changed, 793 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt create mode 100644 Documentation/devicetree/bindings/serial/slaves.txt create mode 100644 Documentation/serial/slaves.txt create mode 100644 drivers/misc/w2sg0004.c create mode 100644 include/linux/w2sg0004.h -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] clk: samsung: exynos5250: Add DISP1 clocks
On 10/16, Michael Turquette wrote: > Quoting Krzysztof Kozlowski (2015-10-15 16:46:27) > > On 15.10.2015 19:31, Tomeu Vizoso wrote: > > > When the DISP1 power domain is powered off, there's two clocks that need > > > to be temporarily reparented to OSC, and back to their original parents > > > when the domain is powered on again. > > > > > > We expose these two clocks in the DT bindings so that the DT node of the > > > power domain can reference them. > > > > > > Signed-off-by: Tomeu Vizoso > > > Acked-by: Stephen Boyd > > > --- > > > > > > Changes in v2: > > > - Reuse mout_aclk200_p > > > - Rename div_aclk300 as div_aclk300_disp > > > > > > drivers/clk/samsung/clk-exynos5250.c | 14 +- > > > include/dt-bindings/clock/exynos5250.h | 4 +++- > > > 2 files changed, 16 insertions(+), 2 deletions(-) > > > > > > > Reviewed-by: Krzysztof Kozlowski > > Applied to clk-next. > I think Tomeu wanted to take this through arm-soc? Otherwise we'll need to provide a stable branch for the dt header. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] DT: nvmem: Add NXP LPC18xx EEPROM memory binding documentation
On 16 October 2015 at 17:41, Ezequiel Garcia wrote: > +DT bindings maintainers > > As per the documentation in > Documentation/devicetree/bindings/submitting-patches.txt > this binding should be patch 1/2. > > On 16 October 2015 at 11:07, Ariel D'Alessandro > wrote: >> Add the devicetree binding document for NXP LPC18xx EEPROM memory. >> >> Signed-off-by: Ariel D'Alessandro >> --- >> .../devicetree/bindings/nvmem/lpc18xx_eeprom.txt | 26 >> ++ >> 1 file changed, 26 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/nvmem/lpc18xx_eeprom.txt >> >> diff --git a/Documentation/devicetree/bindings/nvmem/lpc18xx_eeprom.txt >> b/Documentation/devicetree/bindings/nvmem/lpc18xx_eeprom.txt >> new file mode 100644 >> index 000..372ff8c >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/nvmem/lpc18xx_eeprom.txt >> @@ -0,0 +1,26 @@ >> +* NXP LPC18xx EEPROM memory NVMEM driver >> + >> +Required properties: >> + - compatible: Should be "nxp,lpc1850-eeprom" > > Correct me if I'm wrong, but I believe not all LPC18xx/43xx devices > have an EEPROM. > > Isn't it restricted to LPC18x7/LPC43x7 devices? The EEPROM can only be found on Flash devices. Flashless devices doesn't have the EEPROM. > Should the compatible be nxp,lpc1857-eeprom to avoid confusion? Yes, please. The EEPROM doesn't exist on LPC1850 so please use the compatibility string from Ezequiel. regards, Joachim Eastwood -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] gpio: tps65086: Add GPIO driver for the TPS65086 PMIC
Add support for the TPS65086 PMIC GPOs.
TPS65086 has four configurable GPOs that can be used for several
purposes.
Signed-off-by: Andrew F. Davis
---
drivers/gpio/Kconfig | 6 +++
drivers/gpio/Makefile| 1 +
drivers/gpio/gpio-tps65086.c | 114 +++
3 files changed, 121 insertions(+)
create mode 100644 drivers/gpio/gpio-tps65086.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b4fc9e4..c585d42 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -824,6 +824,12 @@ config GPIO_TIMBERDALE
---help---
Add support for the GPIO IP in the timberdale FPGA.
+config GPIO_TPS65086
+ tristate "TI TPS65086 GPO"
+ depends on MFD_TPS65086
+ help
+ This driver supports the GPO on the TI TPS65086 PMIC.
+
config GPIO_TPS6586X
bool "TPS6586X GPIO"
depends on MFD_TPS6586X
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f79a7c4..2611c7e 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -94,6 +94,7 @@ obj-$(CONFIG_GPIO_TC3589X)+= gpio-tc3589x.o
obj-$(CONFIG_ARCH_TEGRA) += gpio-tegra.o
obj-$(CONFIG_GPIO_TIMBERDALE) += gpio-timberdale.o
obj-$(CONFIG_GPIO_PALMAS) += gpio-palmas.o
+obj-$(CONFIG_GPIO_TPS65086)+= gpio-tps65086.o
obj-$(CONFIG_GPIO_TPS6586X)+= gpio-tps6586x.o
obj-$(CONFIG_GPIO_TPS65910)+= gpio-tps65910.o
obj-$(CONFIG_GPIO_TPS65912)+= gpio-tps65912.o
diff --git a/drivers/gpio/gpio-tps65086.c b/drivers/gpio/gpio-tps65086.c
new file mode 100644
index 000..9fba758
--- /dev/null
+++ b/drivers/gpio/gpio-tps65086.c
@@ -0,0 +1,114 @@
+/*
+ * TI TPS65086x GPIO Driver
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Andrew F. Davis
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the TPS65912 driver
+ */
+
+#include
+#include
+#include
+
+#include
+
+struct tps65086_gpio {
+ struct gpio_chip gpio_chip;
+ struct tps65086 *tps;
+};
+
+#define to_tps65086_gpio(gc) container_of(gc, struct tps65086_gpio, gpio_chip)
+
+static int tps65086_gpio_get(struct gpio_chip *gc, unsigned offset)
+{
+ struct tps65086_gpio *gpio = to_tps65086_gpio(gc);
+ int ret, val;
+
+ ret = regmap_read(gpio->tps->regmap, TPS65086_GPOCTRL, &val);
+ if (ret < 0)
+ return ret;
+
+ return val & BIT(4 + offset);
+}
+
+static void tps65086_gpio_set(struct gpio_chip *gc, unsigned offset,
+ int value)
+{
+ struct tps65086_gpio *gpio = to_tps65086_gpio(gc);
+
+ regmap_update_bits(gpio->tps->regmap, TPS65086_GPOCTRL,
+ BIT(4 + offset), value ? BIT(4 + offset) : 0);
+}
+
+static struct gpio_chip template_chip = {
+ .label = "tps65086-gpio",
+ .owner = THIS_MODULE,
+ .get= tps65086_gpio_get,
+ .set= tps65086_gpio_set,
+ .can_sleep = true,
+ .ngpio = 4,
+ .base = -1,
+};
+
+static int tps65086_gpio_probe(struct platform_device *pdev)
+{
+ struct tps65086_gpio *gpio;
+ int ret;
+
+ gpio = devm_kzalloc(&pdev->dev, sizeof(*gpio), GFP_KERNEL);
+ if (!gpio)
+ return -ENOMEM;
+
+ gpio->tps = dev_get_drvdata(pdev->dev.parent);
+ gpio->gpio_chip = template_chip;
+ ret = gpiochip_add(&gpio->gpio_chip);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "Could not register gpiochip, %d\n", ret);
+ return ret;
+ }
+
+ platform_set_drvdata(pdev, gpio);
+
+ return 0;
+}
+
+static int tps65086_gpio_remove(struct platform_device *pdev)
+{
+ struct tps65086_gpio *gpio = platform_get_drvdata(pdev);
+
+ gpiochip_remove(&gpio->gpio_chip);
+
+ return 0;
+}
+
+static const struct of_device_id tps65086_gpio_of_match_table[] = {
+ { .compatible = "ti,tps65086-gpio", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, tps65086_gpio_of_match_table);
+
+static struct platform_driver tps65086_gpio_driver = {
+ .driver = {
+ .name = "tps65086-gpio",
+ .of_match_table = tps65086_gpio_of_match_table,
+ },
+ .probe = tps65086_gpio_probe,
+ .remove = tps65086_gpio_remove,
+};
+
+module_platform_driver(tps65086_gpio_driver);
+
+MODULE_AUTHOR("Andrew F. Davis ");
+MODULE_DESCRIPTION("TPS65086 GPIO driver");
+MODULE_LICENSE("GPL v2");
--
1.9.1
--
To
[PATCH 2/4] mfd: tps65086: Add driver for the TPS65086 PMIC
Add support for the TPS65912 device. It provides communication
through I2C and contains the following components:
- Regulators
- Load switches
- GPO controller
Signed-off-by: Andrew F. Davis
---
drivers/mfd/Kconfig | 13
drivers/mfd/Makefile | 1 +
drivers/mfd/tps65086.c | 145 +++
include/linux/mfd/tps65086.h | 120 +++
4 files changed, 279 insertions(+)
create mode 100644 drivers/mfd/tps65086.c
create mode 100644 include/linux/mfd/tps65086.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 99d6367..ab3b392 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1093,6 +1093,19 @@ config TPS6507X
This driver can also be built as a module. If so, the module
will be called tps6507x.
+config MFD_TPS65086
+ tristate "TI TPS65086x Power Management chips"
+ select REGMAP
+ select REGMAP_IRQ
+ select REGMAP_I2C
+ depends on I2C
+ depends on OF || COMPILE_TEST
+ help
+ If you say yes here you get support for the TPS65086 series of
+ Power Management chips.
+ These include voltage regulators, GPO and other features
+ that are often used in portable devices.
+
config TPS65911_COMPARATOR
tristate
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a59e3fc..7adb902 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_MFD_WM8994) += wm8994-core.o wm8994-irq.o
wm8994-regmap.o
obj-$(CONFIG_TPS6105X) += tps6105x.o
obj-$(CONFIG_TPS65010) += tps65010.o
obj-$(CONFIG_TPS6507X) += tps6507x.o
+obj-$(CONFIG_MFD_TPS65086) += tps65086.o
obj-$(CONFIG_MFD_TPS65217) += tps65217.o
obj-$(CONFIG_MFD_TPS65218) += tps65218.o
obj-$(CONFIG_MFD_TPS65910) += tps65910.o
diff --git a/drivers/mfd/tps65086.c b/drivers/mfd/tps65086.c
new file mode 100644
index 000..be6d678
--- /dev/null
+++ b/drivers/mfd/tps65086.c
@@ -0,0 +1,145 @@
+/*
+ * Driver for TI TPS65086x PMICs
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Andrew F. Davis
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the TPS65912 driver
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+static const struct regmap_range tps65086_yes_ranges[] = {
+ regmap_reg_range(TPS65086_IRQ, TPS65086_IRQ),
+ regmap_reg_range(TPS65086_PMICSTAT, TPS65086_SHUTDNSRC),
+ regmap_reg_range(TPS65086_GPOCTRL, TPS65086_GPOCTRL),
+ regmap_reg_range(TPS65086_PG_STATUS1, TPS65086_OC_STATUS),
+};
+
+static const struct regmap_access_table tps65086_volatile_table = {
+ .yes_ranges = tps65086_yes_ranges,
+ .n_yes_ranges = ARRAY_SIZE(tps65086_yes_ranges),
+};
+
+static const struct regmap_config tps65086_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .cache_type = REGCACHE_RBTREE,
+ .volatile_table = &tps65086_volatile_table,
+};
+
+static const struct regmap_irq tps65086_irqs[] = {
+ REGMAP_IRQ_REG(TPS65086_IRQ_DIETEMP, 0, TPS65086_IRQ_DIETEMP_MASK),
+ REGMAP_IRQ_REG(TPS65086_IRQ_SHUTDN, 0, TPS65086_IRQ_SHUTDN_MASK),
+ REGMAP_IRQ_REG(TPS65086_IRQ_FAULT, 0, TPS65086_IRQ_FAULT_MASK),
+};
+
+static struct regmap_irq_chip tps65086_irq_chip = {
+ .name = "tps65086",
+ .status_base = TPS65086_IRQ,
+ .mask_base = TPS65086_IRQ_MASK,
+ .ack_base = TPS65086_IRQ,
+ .init_ack_masked = true,
+ .num_regs = 1,
+ .irqs = tps65086_irqs,
+ .num_irqs = ARRAY_SIZE(tps65086_irqs),
+};
+
+static const struct of_device_id tps65086_of_match_table[] = {
+ { .compatible = "ti,tps65086", },
+ { /* sentinel */ }
+};
+
+static int tps65086_probe(struct i2c_client *client,
+ const struct i2c_device_id *ids)
+{
+ struct tps65086 *tps;
+ unsigned int version;
+ int ret;
+
+ tps = devm_kzalloc(&client->dev, sizeof(*tps), GFP_KERNEL);
+ if (!tps)
+ return -ENOMEM;
+
+ i2c_set_clientdata(client, tps);
+ tps->dev = &client->dev;
+ tps->irq = client->irq;
+
+ tps->regmap = devm_regmap_init_i2c(client, &tps65086_regmap_config);
+ if (IS_ERR(tps->regmap)) {
+ dev_err(tps->dev, "Failed to initialize register map\n");
+ return PTR_ERR(tps->regmap);
+ }
+
+ ret = regmap_read(tps->regmap, TPS65086_DEVICEID, &version);
+ if (ret < 0) {
+
[PATCH 1/4] Documentation: tps65086: Add DT bindings for the TPS65086 PMIC
The TPS65086 PMIC contains several regulators and a GPO controller.
Add bindings for the TPS65086 PMIC.
Signed-off-by: Andrew F. Davis
---
.../devicetree/bindings/gpio/gpio-tps65086.txt | 17
Documentation/devicetree/bindings/mfd/tps65086.txt | 46 ++
.../bindings/regulator/tps65086-regulator.txt | 36 +
3 files changed, 99 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-tps65086.txt
create mode 100644 Documentation/devicetree/bindings/mfd/tps65086.txt
create mode 100644
Documentation/devicetree/bindings/regulator/tps65086-regulator.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-tps65086.txt
b/Documentation/devicetree/bindings/gpio/gpio-tps65086.txt
new file mode 100644
index 000..15e4063
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-tps65086.txt
@@ -0,0 +1,17 @@
+* TPS65086 GPO Controller bindings
+
+Required properties:
+ - compatible : Should be "ti,tps65086-gpio".
+ - gpio-controller : Marks the device node as a GPIO Controller.
+ - #gpio-cells : Should be two. The first cell is the pin number
+ and the second cell is used to specify flags.
+ See include/dt-bindings/gpio/gpio.h for possible
+ values.
+
+Example:
+
+ gpio4: tps65086_gpio {
+ compatible = "ti,tps65086-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/mfd/tps65086.txt
b/Documentation/devicetree/bindings/mfd/tps65086.txt
new file mode 100644
index 000..4b6aeb4
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps65086.txt
@@ -0,0 +1,46 @@
+* TPS65086 Power Management Integrated Circuit bindings
+
+Required properties:
+ - compatible : Should be "ti,tps65086".
+ - reg : Slave address.
+ - interrupt-parent: The parent interrupt controller.
+ - interrupts : The interrupt line the device is connected to.
+ - interrupt-controller: Marks the device node as an interrupt
controller.
+ - #interrupt-cells: The number of cells to describe an IRQ, this
+ should be 2. The first cell is the IRQ number.
+ The second cell is the flags, encoded as the trigger
+ masks from ../interrupt-controller/interrupts.txt.
+
+Additional nodes defined in:
+ - Regulators : ../regulator/tps65086-regulator.txt.
+ - GPIO: ../gpio/gpio-tps65086.txt.
+
+Example:
+
+ pmic: tps65086@5e {
+ compatible = "ti,tps65086";
+ reg = <0x5e>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ regulators {
+ compatible = "ti,tps65086-regulator";
+
+ buck1 {
+ regulator-name = "vcc1";
+ regulator-min-microvolt = <160>;
+ regulator-max-microvolt = <160>;
+ regulator-boot-on;
+ ti,regulator-decay;
+ ti,regulator-step-size-25mv;
+ };
+ };
+
+ gpio4: tps65086_gpio {
+ compatible = "ti,tps65086-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/tps65086-regulator.txt
b/Documentation/devicetree/bindings/regulator/tps65086-regulator.txt
new file mode 100644
index 000..023cd73
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65086-regulator.txt
@@ -0,0 +1,36 @@
+* TPS65086 regulator bindings
+
+Required properties:
+ - compatible : Should be "ti,tps65086-regulator".
+ - list of regulators provided by this controller, must be named
+ after their hardware counterparts: buck[1-6], ldoa[1-3], swa1,
+ swb[1-2], and vtt.
+
+Optional properties:
+ - Per-regulator optional properties are defined in regulator.txt
+ - ti,regulator-step-size-25mv : This is applicable for buck[1,2,6].
+ Set this if the regulator is factory
+ set with a 25mv step voltage mapping.
+ - ti,regulator-decay : This is applicable for buck[1-6].
+ Set this if the output needs to decay,
+ default is for the output to slew down.
+
+Example:
+
+ regulators {
+ compatible = "ti,tps65086-regulator";
+
+ buck1 {
+ regulator-name = "vcc1";
+ regulator-min-microvolt = <160>;
+ regulator-max-microvolt = <1600
[PATCH 3/4] regulator: tps65086: Add regulator driver for the TPS65086 PMIC
Add support for TPS65086 PMIC regulators.
The regulators set consists of 3 Step-down Controllers, 3 Step-down
Converters, 3 LDOs, 3 Load Switches, and a Sink and Source LDO. The
output voltages are configurable and are meant to supply power to a
SoC and/or other components.
Signed-off-by: Andrew F. Davis
---
drivers/regulator/Kconfig | 7 +
drivers/regulator/Makefile | 1 +
drivers/regulator/tps65086-regulator.c | 263 +
3 files changed, 271 insertions(+)
create mode 100644 drivers/regulator/tps65086-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 64bccff..cb5f04d 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -680,6 +680,13 @@ config REGULATOR_TPS6507X
three step-down converters and two general-purpose LDO voltage
regulators.
It supports TI's software based Class-2 SmartReflex implementation.
+config REGULATOR_TPS65086
+ tristate "TI TPS65086 Power regulator"
+ depends on MFD_TPS65086
+ help
+ This driver provides support for the voltage regulators on the
+ TI TPS65086 PMIC.
+
config REGULATOR_TPS65090
tristate "TI TPS65090 Power regulator"
depends on MFD_TPS65090
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 0f81749..945d8ec 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -85,6 +85,7 @@ obj-$(CONFIG_REGULATOR_TPS6105X) += tps6105x-regulator.o
obj-$(CONFIG_REGULATOR_TPS62360) += tps62360-regulator.o
obj-$(CONFIG_REGULATOR_TPS65023) += tps65023-regulator.o
obj-$(CONFIG_REGULATOR_TPS6507X) += tps6507x-regulator.o
+obj-$(CONFIG_REGULATOR_TPS65086) += tps65086-regulator.o
obj-$(CONFIG_REGULATOR_TPS65090) += tps65090-regulator.o
obj-$(CONFIG_REGULATOR_TPS65217) += tps65217-regulator.o
obj-$(CONFIG_REGULATOR_TPS65218) += tps65218-regulator.o
diff --git a/drivers/regulator/tps65086-regulator.c
b/drivers/regulator/tps65086-regulator.c
new file mode 100644
index 000..5fd6cf4
--- /dev/null
+++ b/drivers/regulator/tps65086-regulator.c
@@ -0,0 +1,263 @@
+/*
+ * Regulator driver for TPS65086x PMIC
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Andrew F. Davis
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the TPS65912 driver
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+enum tps65086_regulators { BUCK1, BUCK2, BUCK3, BUCK4, BUCK5, BUCK6, LDOA1,
+ LDOA2, LDOA3, SWA1, SWB1, SWB2, VTT };
+
+#define TPS65086_REGULATOR(_name, _id, _nv, _vr, _vm, _er, _em, _lr, _dr, _dm)\
+ [_id] = { \
+ .desc = { \
+ .name = _name,\
+ .id = _id, \
+ .ops= ®_ops, \
+ .n_voltages = _nv, \
+ .type = REGULATOR_VOLTAGE,\
+ .owner = THIS_MODULE, \
+ .vsel_reg = _vr, \
+ .vsel_mask = _vm, \
+ .enable_reg = _er, \
+ .enable_mask= _em, \
+ .volt_table = NULL, \
+ .linear_ranges = _lr, \
+ .n_linear_ranges= ARRAY_SIZE(_lr), \
+ }, \
+ .decay_reg = _dr, \
+ .decay_mask = _dm, \
+ }
+
+#define TPS65086_SWITCH(_name, _id, _er, _em) \
+ [_id] = { \
+ .desc = { \
+ .name = _name,\
+ .id = _id, \
+ .ops= &switch_ops, \
+ .type = REGULATOR_VOLTAGE,\
+ .owner
[PATCH 0/4] Add support for the TI TPS65086 PMIC.
This series adds support for the TPS65086 PMIC. It is a MFD with an I2C
interface, several regulators and load switches, and a GPO controller.
Based on v4.3-rc1 and needs b4fe8ba ("regmap: Add generic macro to define
regmap_irq")
from Lee Jones' tree to build.
Andrew F. Davis (4):
Documentation: tps65086: Add DT bindings for the TPS65086 PMIC
mfd: tps65086: Add driver for the TPS65086 PMIC
regulator: tps65086: Add regulator driver for the TPS65086 PMIC
gpio: tps65086: Add GPIO driver for the TPS65086 PMIC
.../devicetree/bindings/gpio/gpio-tps65086.txt | 17 ++
Documentation/devicetree/bindings/mfd/tps65086.txt | 46
.../bindings/regulator/tps65086-regulator.txt | 36 +++
drivers/gpio/Kconfig | 6 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-tps65086.c | 114 +
drivers/mfd/Kconfig| 13 +
drivers/mfd/Makefile | 1 +
drivers/mfd/tps65086.c | 145
drivers/regulator/Kconfig | 7 +
drivers/regulator/Makefile | 1 +
drivers/regulator/tps65086-regulator.c | 263 +
include/linux/mfd/tps65086.h | 120 ++
13 files changed, 770 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-tps65086.txt
create mode 100644 Documentation/devicetree/bindings/mfd/tps65086.txt
create mode 100644
Documentation/devicetree/bindings/regulator/tps65086-regulator.txt
create mode 100644 drivers/gpio/gpio-tps65086.c
create mode 100644 drivers/mfd/tps65086.c
create mode 100644 drivers/regulator/tps65086-regulator.c
create mode 100644 include/linux/mfd/tps65086.h
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64
On Fri, Oct 16, 2015 at 06:24:21PM +0200, Arnd Bergmann wrote: > I think you also need this one: Are you sure? > 8<--- > From 0ab7b2d32921b3f3da15274d8c3982ba1d54660f Mon Sep 17 00:00:00 2001 > From: Arnd Bergmann > Date: Thu, 4 Jun 2015 09:25:59 +0200 > Subject: [PATCH] mtd: brcmnand depends on MTD_NAND > > MTD_NAND_BRCMNAND uses the generic nand functions, but is currently allowed > to be built without CONFIG_MTD_NAND, which results in a link error: > > drivers/built-in.o: In function `brcmnand_remove': > coresight-replicator.c:(.text+0x17ae6c): undefined reference to `nand_release' > drivers/built-in.o: In function `brcmnand_probe': > coresight-replicator.c:(.text+0x17d4b4): undefined reference to > `nand_scan_ident' > coresight-replicator.c:(.text+0x17d948): undefined reference to > `nand_scan_tail' How did you get this? MTD_NAND_BRCMNAND is surrounded in the 'if MTD_NAND' block, which implicitly generates a MTD_NAND dependency. And I can confirm that in menuconfig, I see this when I disable MTD_NAND and search for BRCMNAND: Symbol: MTD_NAND_BRCMNAND [=n] Type : tristate Prompt: Broadcom STB NAND controller Location: -> Device Drivers -> Memory Technology Device (MTD) support (MTD [=y]) (1) -> NAND Device Support (MTD_NAND [=n]) Defined at drivers/mtd/nand/Kconfig:394 Depends on: MTD [=y] && MTD_NAND [=n] && (ARM [=y] || ARM64 || MIPS) Brian > This adds an explicit Kconfig dependency. > > Signed-off-by: Arnd Bergmann > > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig > index 289664089cf3..4b7e853ce35d 100644 > --- a/drivers/mtd/nand/Kconfig > +++ b/drivers/mtd/nand/Kconfig > @@ -393,6 +393,7 @@ config MTD_NAND_GPMI_NAND > > config MTD_NAND_BRCMNAND > tristate "Broadcom STB NAND controller" > + depends on MTD_NAND > depends on ARM || ARM64 || MIPS > help > Enables the Broadcom NAND controller driver. The controller was > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64
On Fri, Oct 16, 2015 at 08:36:58AM -0700, Ray Jui wrote: > This patch is the same. I thought it has already been merged by Brian? Right as well. I'll ignore this one. Brian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] mtd: brcmnand: Fix pointer type-cast in brcmnand_write()
On Fri, Oct 16, 2015 at 08:36:22AM -0700, Ray Jui wrote: > Correct me if I remember it wrong, but I thought this patch has already > been merged by Brian? You are correct. Anup, Please base MTD patches on the MTD development tree (i.e., l2-mtd.git): http://linux-mtd.infradead.org/source.html (In this case it's no problem; I'll just ignore the first two patches.) Brian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: phy: smsc: disable energy detect mode
2015-10-13 21:17 GMT-07:00 Heiko Schocher : > Hello Florian, > > > Am 13.10.2015 um 21:26 schrieb Florian Fainelli: >> >> On 12/10/15 22:13, Heiko Schocher wrote: >>> >>> On some boards the energy enable detect mode leads in >>> trouble with some switches, so make the enabling of >>> this mode configurable through DT. >>> >>> Signed-off-by: Heiko Schocher >>> --- >>> >>> .../devicetree/bindings/net/smsc-lan87xx.txt | 19 >>> + >>> drivers/net/phy/smsc.c | 24 >>> +- >>> 2 files changed, 38 insertions(+), 5 deletions(-) >>> create mode 100644 >>> Documentation/devicetree/bindings/net/smsc-lan87xx.txt >>> >>> diff --git a/Documentation/devicetree/bindings/net/smsc-lan87xx.txt >>> b/Documentation/devicetree/bindings/net/smsc-lan87xx.txt >>> new file mode 100644 >>> index 000..39aa1dc >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/net/smsc-lan87xx.txt >>> @@ -0,0 +1,19 @@ >>> +SMSC LAN87xx Ethernet PHY >>> + >>> +Some boards require special tuning values. Configure them >>> +through an Ethernet OF device node. >>> + >>> +Optional properties: >>> + >>> +- disable-energy-detect: >>> + If set, do not enable energy detect mode for the SMSC phy. >>> + default: enable energy detect mode >> >> >> Although energy detection is something that is implemented by many PHYs, >> I am not sure a generic property is suitable here, I would prefix that >> with the SMSC vendor prefix here to make it clear this only applies to >> this PHY. > > > Hmm... but all PHYs should be able to enable, disable it in some way, or? It may not always be controlled directly at the PHY level, sometimes this is something that needs cooperation with the Ethernet MAC as well in case of integrated designs. > >> Would not you want to make it a reverse property here though, something >> like this: >> >> smsc,energy-detect: boolean, when present indicates the PHY reliably >> supports energy detection > > > Yes, that was also my first thought, but currently, on this PHYs > energy detect mode is on ... and if I introduce such a property, > it will disable it for all existing boards, because property is > missing ... so, maybe I break boards ... Fair enough, how about smsc,disabled-energy-detect or something like that then? -- Florian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64
On Friday 16 October 2015 14:38:55 Anup Patel wrote: > > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig > index 3324281..a1b5819 100644 > --- a/drivers/mtd/nand/Kconfig > +++ b/drivers/mtd/nand/Kconfig > @@ -393,7 +393,7 @@ config MTD_NAND_GPMI_NAND > > config MTD_NAND_BRCMNAND > tristate "Broadcom STB NAND controller" > - depends on ARM || MIPS > + depends on ARM || ARM64 || MIPS > help > Enables the Broadcom NAND controller driver. The controller was > originally designed for Set-Top Box but is used on various BCM7xxx, > -- > I think you also need this one: 8<--- >From 0ab7b2d32921b3f3da15274d8c3982ba1d54660f Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Thu, 4 Jun 2015 09:25:59 +0200 Subject: [PATCH] mtd: brcmnand depends on MTD_NAND MTD_NAND_BRCMNAND uses the generic nand functions, but is currently allowed to be built without CONFIG_MTD_NAND, which results in a link error: drivers/built-in.o: In function `brcmnand_remove': coresight-replicator.c:(.text+0x17ae6c): undefined reference to `nand_release' drivers/built-in.o: In function `brcmnand_probe': coresight-replicator.c:(.text+0x17d4b4): undefined reference to `nand_scan_ident' coresight-replicator.c:(.text+0x17d948): undefined reference to `nand_scan_tail' This adds an explicit Kconfig dependency. Signed-off-by: Arnd Bergmann diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 289664089cf3..4b7e853ce35d 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -393,6 +393,7 @@ config MTD_NAND_GPMI_NAND config MTD_NAND_BRCMNAND tristate "Broadcom STB NAND controller" + depends on MTD_NAND depends on ARM || ARM64 || MIPS help Enables the Broadcom NAND controller driver. The controller was -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: dts: fix gpio-keys wakeup-source property
The keyboard driver for GPIO buttons(gpio-keys) checks for one of the
two boolean properties to enable gpio buttons as wakeup source:
1. "wakeup-source" or
2. the legacy "gpio-key,wakeup"
However juno, ste-snowball and emev2-kzm9d dts file have a undetected
"wakeup" property to indictate the wakeup source.
This patch fixes it by making use of "wakeup-source" property.
Cc: Magnus Damm
Acked-by: Simon Horman
Reviewed-by: Linus Walleij
Signed-off-by: Sudeep Holla
---
arch/arm/boot/dts/emev2-kzm9d.dts | 8
arch/arm/boot/dts/ste-snowball.dts| 10 +-
arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 12 ++--
3 files changed, 15 insertions(+), 15 deletions(-)
Hi ARM-SoC group,
Please consider this as a fix for v4.3 if possible.
v2->v1[1] :
- included all the reviewed/ack tags, also posting this fix independently
Regards,
Sudeep
[1] https://lkml.org/lkml/2015/10/13/413
diff --git a/arch/arm/boot/dts/emev2-kzm9d.dts
b/arch/arm/boot/dts/emev2-kzm9d.dts
index 955c24ee4a8c..8c24975e8f9d 100644
--- a/arch/arm/boot/dts/emev2-kzm9d.dts
+++ b/arch/arm/boot/dts/emev2-kzm9d.dts
@@ -35,28 +35,28 @@
button@1 {
debounce_interval = <50>;
- wakeup = <1>;
+ wakeup-source;
label = "DSW2-1";
linux,code = ;
gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
};
button@2 {
debounce_interval = <50>;
- wakeup = <1>;
+ wakeup-source;
label = "DSW2-2";
linux,code = ;
gpios = <&gpio0 15 GPIO_ACTIVE_HIGH>;
};
button@3 {
debounce_interval = <50>;
- wakeup = <1>;
+ wakeup-source;
label = "DSW2-3";
linux,code = ;
gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
};
button@4 {
debounce_interval = <50>;
- wakeup = <1>;
+ wakeup-source;
label = "DSW2-4";
linux,code = ;
gpios = <&gpio0 17 GPIO_ACTIVE_HIGH>;
diff --git a/arch/arm/boot/dts/ste-snowball.dts
b/arch/arm/boot/dts/ste-snowball.dts
index 32a5ccb14e7e..e80e42163883 100644
--- a/arch/arm/boot/dts/ste-snowball.dts
+++ b/arch/arm/boot/dts/ste-snowball.dts
@@ -47,35 +47,35 @@
button@1 {
debounce_interval = <50>;
- wakeup = <1>;
+ wakeup-source;
linux,code = <2>;
label = "userpb";
gpios = <&gpio1 0 0x4>;
};
button@2 {
debounce_interval = <50>;
- wakeup = <1>;
+ wakeup-source;
linux,code = <3>;
label = "extkb1";
gpios = <&gpio4 23 0x4>;
};
button@3 {
debounce_interval = <50>;
- wakeup = <1>;
+ wakeup-source;
linux,code = <4>;
label = "extkb2";
gpios = <&gpio4 24 0x4>;
};
button@4 {
debounce_interval = <50>;
- wakeup = <1>;
+ wakeup-source;
linux,code = <5>;
label = "extkb3";
gpios = <&gpio5 1 0x4>;
};
button@5 {
debounce_interval = <50>;
- wakeup = <1>;
+ wakeup-source;
linux,code = <6>;
label = "extkb4";
gpios = <&gpio5 2 0x4>;
diff --git a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
index 902f14a8e85b..42153860b41f 100644
--- a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
@@ -61,42 +61,42 @@
button@1 {
debounce_interval = <50>;
- wakeup = <1>;
+ wakeup-source;
linux,code = <116>;
label = "POWER";
gpios = <&iofpga_gpio0 0 0x4>;
};
button@2 {
debounce_interval = <50>;
-
[PATCH v4 0/3] arm64: Juno: Add support for PCIe on R1 board
Changes in v4 vs v3: - Dropped the quirks patches as the fixup can be done in firmware. Changes in v3 vs v2: - Add Documentation files describing the DT bindings for plda,xpressrich3-axi and arm,juno-r1-pcie properties. - Cosmetic changes in the .dts to bracket range and interrupt-map entries individually. Changes in v2 vs v1: - Add plda as OF vendor prefix - Add more specific compatible values to the Juno R1 DT Juno R1 board has a working PCIe host bridge that can be enabled and configured by the firmware and made use of by Linux. For UEFI, the Linaro releases contain firmware that configure the XpressRICH3 host bridge correctly. For U-Boot based setups, one needs the patchset posted here[1]. This patchset adds a quirk for setting the correct class to the host bridge device and the device tree changes that enable PCIe on Juno R1. We also update the defconfig to enable the generic PCI host bridge driver. The changes can also available in the git repository at: git://linux-arm.org/linux-ld.git for-upstream/juno-pcie They are based on v4.3-rc5. Catalin, Will: This series has got Mark's ACKs for the DT changes and now with the quirks dropped it can be pulled into whatever arm64 -next branch you want to prepare. Do you want a formal pull request for this? Best regards, Liviu 1. http://lists.denx.de/pipermail/u-boot/2015-October/229669.html Liviu Dudau (3): Documentation: of: Document the bindings used by Juno R1 PCIe host bridge arm64: Juno: Add support for the PCIe host bridge on Juno R1 arm64: defconfig: Enable PCI generic host bridge by default .../devicetree/bindings/pci/arm,juno-r1-pcie.txt | 10 ++ .../devicetree/bindings/pci/plda,xpressrich3-axi.txt | 12 .../devicetree/bindings/vendor-prefixes.txt | 1 + arch/arm64/boot/dts/arm/juno-r1.dts | 20 arch/arm64/configs/defconfig | 1 + 5 files changed, 44 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/arm,juno-r1-pcie.txt create mode 100644 Documentation/devicetree/bindings/pci/plda,xpressrich3-axi.txt -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/3] arm64: defconfig: Enable PCI generic host bridge by default
Now that pci-host-generic can be used under arm64, enable it by default so that SBSA compliant systems can use it. Cc: Will Deacon Cc: Catalin Marinas Signed-off-by: Liviu Dudau --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 34d71dd..7c9455a 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -49,6 +49,7 @@ CONFIG_ARCH_XGENE=y CONFIG_ARCH_ZYNQMP=y CONFIG_PCI=y CONFIG_PCI_MSI=y +CONFIG_PCI_HOST_GENERIC=y CONFIG_PCI_XGENE=y CONFIG_SMP=y CONFIG_PREEMPT=y -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] DT: nvmem: Add NXP LPC18xx EEPROM memory binding documentation
+DT bindings maintainers As per the documentation in Documentation/devicetree/bindings/submitting-patches.txt this binding should be patch 1/2. On 16 October 2015 at 11:07, Ariel D'Alessandro wrote: > Add the devicetree binding document for NXP LPC18xx EEPROM memory. > > Signed-off-by: Ariel D'Alessandro > --- > .../devicetree/bindings/nvmem/lpc18xx_eeprom.txt | 26 > ++ > 1 file changed, 26 insertions(+) > create mode 100644 Documentation/devicetree/bindings/nvmem/lpc18xx_eeprom.txt > > diff --git a/Documentation/devicetree/bindings/nvmem/lpc18xx_eeprom.txt > b/Documentation/devicetree/bindings/nvmem/lpc18xx_eeprom.txt > new file mode 100644 > index 000..372ff8c > --- /dev/null > +++ b/Documentation/devicetree/bindings/nvmem/lpc18xx_eeprom.txt > @@ -0,0 +1,26 @@ > +* NXP LPC18xx EEPROM memory NVMEM driver > + > +Required properties: > + - compatible: Should be "nxp,lpc1850-eeprom" Correct me if I'm wrong, but I believe not all LPC18xx/43xx devices have an EEPROM. Isn't it restricted to LPC18x7/LPC43x7 devices? Should the compatible be nxp,lpc1857-eeprom to avoid confusion? -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/3] Documentation: of: Document the bindings used by Juno R1 PCIe host bridge
ARM's Juno R1 board used PLDA XpressRICH3-AXI IP to implement a PCIe host bridge. Introduce "plda" as vendor prefix for PLDA and document the DT bindings for PLDA XpressRICH3-AXI IP as well as ARM's Juno R1. Signed-off-by: Liviu Dudau Acked-by: Mark Rutland --- Documentation/devicetree/bindings/pci/arm,juno-r1-pcie.txt | 10 ++ .../devicetree/bindings/pci/plda,xpressrich3-axi.txt | 12 Documentation/devicetree/bindings/vendor-prefixes.txt| 1 + 3 files changed, 23 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/arm,juno-r1-pcie.txt create mode 100644 Documentation/devicetree/bindings/pci/plda,xpressrich3-axi.txt diff --git a/Documentation/devicetree/bindings/pci/arm,juno-r1-pcie.txt b/Documentation/devicetree/bindings/pci/arm,juno-r1-pcie.txt new file mode 100644 index 000..f7514c1 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/arm,juno-r1-pcie.txt @@ -0,0 +1,10 @@ +* ARM Juno R1 PCIe interface + +This PCIe host controller is based on PLDA XpressRICH3-AXI IP +and thus inherits all the common properties defined in plda,xpressrich3-axi.txt +as well as the base properties defined in host-generic-pci.txt. + +Required properties: + - compatible: "arm,juno-r1-pcie" + - dma-coherent: The host controller bridges the AXI transactions into PCIe bus + in a manner that makes the DMA operations to appear coherent to the CPUs. diff --git a/Documentation/devicetree/bindings/pci/plda,xpressrich3-axi.txt b/Documentation/devicetree/bindings/pci/plda,xpressrich3-axi.txt new file mode 100644 index 000..f3f75bf --- /dev/null +++ b/Documentation/devicetree/bindings/pci/plda,xpressrich3-axi.txt @@ -0,0 +1,12 @@ +* PLDA XpressRICH3-AXI host controller + +The PLDA XpressRICH3-AXI host controller can be configured in a manner that +makes it compliant with the SBSA[1] standard published by ARM Ltd. For those +scenarios, the host-generic-pci.txt bindings apply with the following additions +to the compatible property: + +Required properties: + - compatible: should contain "plda,xpressrich3-axi" to identify the IP used. + + +[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0029a/ diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 82d2ac9..57653eb 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -168,6 +168,7 @@ pericom Pericom Technology Inc. phytec PHYTEC Messtechnik GmbH picochip Picochip Ltd plathome Plat'Home Co., Ltd. +plda PLDA pixcir PIXCIR MICROELECTRONICS Co., Ltd powervrPowerVR (deprecated, use img) qcaQualcomm Atheros, Inc. -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64
This patch is the same. I thought it has already been merged by Brian? On 10/16/2015 2:08 AM, Anup Patel wrote: > The BRCM NAND driver can be re-used for Broadcom ARM64 SoCs hence > this patch updates Kconfig to allow selection of MTD_NAND_BRCMNAND > for ARM64. > > Signed-off-by: Anup Patel > Reviewed-by: Vikram Prakash > Reviewed-by: Ray Jui > Reviewed-by: Pramod KUMAR > Reviewed-by: Scott Branden > --- > drivers/mtd/nand/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig > index 3324281..a1b5819 100644 > --- a/drivers/mtd/nand/Kconfig > +++ b/drivers/mtd/nand/Kconfig > @@ -393,7 +393,7 @@ config MTD_NAND_GPMI_NAND > > config MTD_NAND_BRCMNAND > tristate "Broadcom STB NAND controller" > - depends on ARM || MIPS > + depends on ARM || ARM64 || MIPS > help > Enables the Broadcom NAND controller driver. The controller was > originally designed for Set-Top Box but is used on various BCM7xxx, > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/3] arm64: Juno: Add support for the PCIe host bridge on Juno R1
Juno R1 board sports a functional PCIe host bridge that is
compliant with the SBSA standard found [1] here. With the right
firmware that initialises the XpressRICH3 controller one can
use the generic Host Bridge driver to use the PCIe hardware.
Signed-off-by: Liviu Dudau
Acked-by: Mark Rutland
[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0029a/
---
arch/arm64/boot/dts/arm/juno-r1.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/arm/juno-r1.dts
b/arch/arm64/boot/dts/arm/juno-r1.dts
index c627511..a25964d 100644
--- a/arch/arm64/boot/dts/arm/juno-r1.dts
+++ b/arch/arm64/boot/dts/arm/juno-r1.dts
@@ -109,6 +109,26 @@
#include "juno-base.dtsi"
+ pcie-controller@4000 {
+ compatible = "arm,juno-r1-pcie", "plda,xpressrich3-axi",
"pci-host-ecam-generic";
+ device_type = "pci";
+ reg = <0 0x4000 0 0x1000>; /* ECAM config space */
+ bus-range = <0 255>;
+ linux,pci-domain = <0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ dma-coherent;
+ ranges = <0x0100 0x00 0x5f80 0x00 0x5f80 0x0
0x0080>,
+<0x0200 0x00 0x5000 0x00 0x5000 0x0
0x0800>,
+<0x4200 0x40 0x 0x40 0x 0x1
0x>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &gic 0 0 0 136 4>,
+ <0 0 0 2 &gic 0 0 0 137 4>,
+ <0 0 0 3 &gic 0 0 0 138 4>,
+ <0 0 0 4 &gic 0 0 0 139 4>;
+ msi-parent = <&v2m_0>;
+ };
};
&memtimer {
--
2.6.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] mtd: brcmnand: Fix pointer type-cast in brcmnand_write()
Correct me if I remember it wrong, but I thought this patch has already
been merged by Brian?
Thanks,
Ray
On 10/16/2015 2:08 AM, Anup Patel wrote:
> We should always type-cast pointer to "long" or "unsigned long"
> because size of pointer is same as machine word size. This will
> avoid pointer type-cast issues on both 32bit and 64bit systems.
>
> This patch fixes pointer type-cast issue in brcmnand_write()
> as-per above info.
>
> Signed-off-by: Anup Patel
> Reviewed-by: Vikram Prakash
> Reviewed-by: Ray Jui
> Reviewed-by: Scott Branden
> ---
> drivers/mtd/nand/brcmnand/brcmnand.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
> b/drivers/mtd/nand/brcmnand/brcmnand.c
> index fddb795..4cba03d 100644
> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> @@ -1544,9 +1544,9 @@ static int brcmnand_write(struct mtd_info *mtd, struct
> nand_chip *chip,
>
> dev_dbg(ctrl->dev, "write %llx <- %p\n", (unsigned long long)addr, buf);
>
> - if (unlikely((u32)buf & 0x03)) {
> + if (unlikely((unsigned long)buf & 0x03)) {
> dev_warn(ctrl->dev, "unaligned buffer: %p\n", buf);
> - buf = (u32 *)((u32)buf & ~0x03);
> + buf = (u32 *)((unsigned long)buf & ~0x03);
> }
>
> brcmnand_wp(mtd, 0);
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] pinctrl: sunxi: Add irq pinmuxing to sun6i "r" pincontroller
On Fri, Oct 16, 2015 at 09:46:12AM +0200, Hans de Goede wrote: > Add pinmuxing for external interrupt functionality through the > sun6i "r" pincontroller. > > Signed-off-by: Hans de Goede Acked-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
