* Re: [PATCH 2/2] memory: ti-emif-sram: introduce relocatable suspend/resume handlers
From: Russell King - ARM Linux @ 2017-04-05 13:59 UTC (permalink / raw)
To: Tony Lindgren
Cc: Rob Herring, Santosh Shilimkar, linux-arm-kernel, linux-omap,
linux-kernel, devicetree, Keerthy J, Dave Gerlach
In-Reply-To: <20170404161151.GS10760@atomide.com>
On Tue, Apr 04, 2017 at 09:11:52AM -0700, Tony Lindgren wrote:
> Russell,
>
> * Dave Gerlach <d-gerlach@ti.com> [170328 13:57]:
> > Certain SoCs like Texas Instruments AM335x and AM437x require parts
> > of the EMIF PM code to run late in the suspend sequence from SRAM,
> > such as saving and restoring the EMIF context and placing the memory
> > into self-refresh.
> >
> > One requirement for these SoCs to suspend and enter its lowest power
> > mode, called DeepSleep0, is that the PER power domain must be shut off.
> > Because the EMIF (DDR Controller) resides within this power domain, it
> > will lose context during a suspend operation, so we must save it so we
> > can restore once we resume. However, we cannot execute this code from
> > external memory, as it is not available at this point, so the code must
> > be executed late in the suspend path from SRAM.
> >
> > This patch introduces a ti-emif-sram driver that includes several
> > functions written in ARM ASM that are relocatable so the PM SRAM
> > code can use them. It also allocates a region of writable SRAM to
> > be used by the code running in the executable region of SRAM to save
> > and restore the EMIF context. It can export a table containing the
> > absolute addresses of the available PM functions so that other SRAM
> > code can branch to them. This code is required for suspend/resume on
> > AM335x and AM437x to work.
> >
> > In addition to this, to be able to share data structures between C and
> > the ti-emif-sram-pm assembly code, we can automatically generate all of
> > the C struct member offsets and sizes as macros by making use of the ARM
> > asm-offsets file. In the same header that we define our data structures
> > in we also define all the macros in an inline function and by adding a
> > call to this in the asm_offsets file all macros are properly generated
> > and available to the assembly code without cluttering up the asm-offsets
> > file.
> >
> > Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> > ---
> > arch/arm/kernel/asm-offsets.c | 6 +
> > drivers/memory/Kconfig | 10 ++
> > drivers/memory/Makefile | 4 +
> > drivers/memory/emif.h | 17 ++
> > drivers/memory/ti-emif-pm.c | 295 ++++++++++++++++++++++++++++++++++
> > drivers/memory/ti-emif-sram-pm.S | 334 +++++++++++++++++++++++++++++++++++++++
> > include/linux/ti-emif-sram.h | 143 +++++++++++++++++
> > 7 files changed, 809 insertions(+)
> > create mode 100644 drivers/memory/ti-emif-pm.c
> > create mode 100644 drivers/memory/ti-emif-sram-pm.S
> > create mode 100644 include/linux/ti-emif-sram.h
> >
> > diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
> > index 608008229c7d..d728b5660e36 100644
> > --- a/arch/arm/kernel/asm-offsets.c
> > +++ b/arch/arm/kernel/asm-offsets.c
> > @@ -28,6 +28,7 @@
> > #include <asm/vdso_datapage.h>
> > #include <asm/hardware/cache-l2x0.h>
> > #include <linux/kbuild.h>
> > +#include <linux/ti-emif-sram.h>
> >
> > /*
> > * Make sure that the compiler and target are compatible.
> > @@ -183,5 +184,10 @@ int main(void)
> > #ifdef CONFIG_VDSO
> > DEFINE(VDSO_DATA_SIZE, sizeof(union vdso_data_store));
> > #endif
> > +#if defined(CONFIG_SOC_AM33XX) || defined(CONFIG_SOC_AM43XX)
> > + BLANK();
> > + ti_emif_offsets();
> > +#endif
> > +
> > return 0;
> > }
>
> Does the above look OK to you?
I'm not going to comment on this yet, but I'll instead comment on the
newly appeared sram_exec_copy() stuff.
So, a few years ago, we went to significant effort in ARM land to come
up with a way to _safely_ copy assembler from the kernel into SRAM,
because copying code to SRAM that is compiled in thumb mode and then
executing it is _not_ as simple as memcpy(), cast the pointer to a
function pointer, and then call the function pointer.
The SRAM stuff throws all that out, instead preferring the dumb memcpy()
approach.
This needs resolving, and I'd like to see it resolved to the satisfaction
of architecture maintainers before we progress any further down this
route.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [Query] DT warnings with ranges and sub-nodes
From: Sudeep Holla @ 2017-04-05 13:58 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree@vger.kernel.org, Lorenzo Pieralisi, Liviu Dudau,
linux-arm-kernel@lists.infradead.org, Sudeep Holla
Hi Rob,
I am seeing some warning in juno DTS files. I would like to get your
feedback on how to resolve them.
Warning messages:
Warning (simple_bus_reg): Node /smb@8000000/motherboard/flash@0,00000000
simple-bus unit address format error, expected "0"
Warning (simple_bus_reg): Node
/smb@8000000/motherboard/ethernet@2,00000000 simple-bus unit address
format error, expected "200000000"
Warning (simple_bus_reg): Node
/smb@8000000/motherboard/iofpga@3,00000000 simple-bus unit address
format error, expected "300000000"
We have
smb@8000000 {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0 0x08000000 0x04000000>,
<1 0 0 0x14000000 0x04000000>,
<2 0 0 0x18000000 0x04000000>,
<3 0 0 0x1c000000 0x04000000>,
<4 0 0 0x0c000000 0x04000000>,
<5 0 0 0x10000000 0x04000000>;
...
flash@0,00000000 {
...
};
ethernet@2,00000000 {
...
};
iofpga@3,00000000 {
...
};
};
All of which are @offset 0x0 in their respective ranges.
How do we specify the range as well as the offset ? Does the below
look like correct way of fixing those warnings ?
flash@0
ethernet@200000000
iofpga@300000000
Or can I ignore these warning as I see the syntax to be correct as
provided in example in ePAPR(page 99 under Appendix B1 Ebony Device
Tree). Sorry if I have missed to follow any other thread on the same.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1
From: Javier Martinez Canillas @ 2017-04-05 13:55 UTC (permalink / raw)
To: Philipp Zabel
Cc: Mark Rutland, andrew-ct.chen, minghsiu.tsai, Nick Dyer,
songjun.wu, Hans Verkuil, Steve Longerbeam, Pavel Machek,
robert.jarzmik, devel, Markus Heiser, Laurent Pinchart, shuah,
Russell King - ARM Linux, Geert Uytterhoeven, Steve Longerbeam,
Linux Media Mailing List, devicetree@vger.kernel.org,
Sakari Ailus, Arnd Bergmann, Mauro Carvalho Chehab, Benoit Parrot,
Rob Herring, horms+r
In-Reply-To: <1491384859.2381.51.camel@pengutronix.de>
Hello Philipp,
On Wed, Apr 5, 2017 at 5:34 AM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> On Wed, 2017-04-05 at 09:21 +0100, Russell King - ARM Linux wrote:
[snip]
> I think the output part is accurate, as the audio pad is an artifact of
> an unrelated change. I'm not so sure about the VBI pad, but I think that
> shouldn't exist either. The input pad, on the other hand, not having any
> of graph representation in the device tree seems a bit strange. There
Agreed, there should be a OF graph representation (and also a MC
representation) of the input PADs.
The tvp5150 driver currently has hardcoded as input TVP5150_COMPOSITE1
(AIP1B), so it won't work for a board that has the composite connector
wired to TVP5150_COMPOSITE0 (AIP1A) neither will work for S-Video
(AIP1A + AIP1B).
> was a custom binding for the inputs, that got quickly reverted:
> https://patchwork.kernel.org/patch/8395521/
>
Yes, that was my first attempt to have input connector support for
tvp5150. The patches were merged without a detailed review of the DT
bindings and latter were found to be wrong. Instead of having a driver
specific DT binding, a generic binding that could be used by any
device should be defined.
The latest proposal was [0] but that was also found to be inadequate.
After a lot of discussion on #v4l, the best approach we could come
with was something like like [1]. But I was busy with other stuff and
never found time to do the driver changes.
By the way, only the DT bindings portion from the first approach got
reverted but the patch reverting the driver changes never made to
mainline. Could you please test if [2] doesn't cause any issues to you
so the left over can be finally removed?
> regards
> Philipp
>
[0]: https://lkml.org/lkml/2016/4/12/983
[1]: https://hastebin.com/kadagidino.diff
[2]: https://patchwork.kernel.org/patch/9472623/
Best regards,
Javier
^ permalink raw reply
* Re: [PATCH 07/16] regulator: madera-micsupp: Mic supply for Cirrus Logic Madera codecs
From: Richard Fitzgerald @ 2017-04-05 13:53 UTC (permalink / raw)
To: Mark Brown
Cc: gnurou, alsa-devel, jason, devicetree, linus.walleij, patches,
linux-kernel, linux-gpio, robh+dt, tglx, lee.jones
In-Reply-To: <20170405134054.kz3j56vza4pqki75@sirena.org.uk>
On Wed, 2017-04-05 at 14:40 +0100, Mark Brown wrote:
> On Wed, Apr 05, 2017 at 11:07:55AM +0100, Richard Fitzgerald wrote:
> > The adds a driver for the microphone supply regulator on Cirrus Logic
> > Madera class codecs.
>
> Again, this appears to have only data and minor code style changes
> relative to the existing arizona driver - is there no opportunity for
> code sharing here?
I'll have a look at how it would work out.
My thought was that these two regulator drivers are so small it wasn't
worth creating an entanglement between arizona and madera for so little
code.
^ permalink raw reply
* Re: [PATCH net-next] macb: Add hardware PTP support.
From: David Miller @ 2017-04-05 13:43 UTC (permalink / raw)
To: rafalo
Cc: devicetree, netdev, richardcochran, nicolas.ferre, linux-kernel,
harinikatakamlinux, Andrei.Pistirica, harini.katakam,
linux-arm-kernel
In-Reply-To: <1491225015-25553-1-git-send-email-rafalo@cadence.com>
From: Rafal Ozieblo <rafalo@cadence.com>
Date: Mon, 3 Apr 2017 14:10:15 +0100
> This patch is based on original Harini's patch and Andrei's patch,
> implemented in aseparate file to ease the review/maintanance
> and integration with other platforms.
>
> In case that macb is compiled as a module, it has been renamed to
> cadence-macb.ko to avoid naming confusion in Makefile.
>
> This driver does support GEM-GXL:
> - Enable HW time stamp
> - Register ptp clock framework
> - Initialize PTP related registers
> - Updated dma buffer descriptor read/write mechanism
> - HW time stamp on the PTP Ethernet packets are received using the
> SO_TIMESTAMPING API. Where timers are obtained from the dma buffer
> descriptors
> - Added tsu_clk to device tree
>
> Note: Patch on net-next, on April 3rd.
> Signed-off-by: Rafal Ozieblo <rafalo@cadence.com>
This patch does too many things at one time. Each entry in that list
of changes above should be a separate change, all posted together as
a group as a proper patch series.
Thank you.
^ permalink raw reply
* Re: [PATCH 07/16] regulator: madera-micsupp: Mic supply for Cirrus Logic Madera codecs
From: Mark Brown @ 2017-04-05 13:40 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: gnurou, alsa-devel, jason, devicetree, linus.walleij, patches,
linux-kernel, linux-gpio, robh+dt, tglx, lee.jones
In-Reply-To: <1491386884-30689-8-git-send-email-rf@opensource.wolfsonmicro.com>
[-- Attachment #1.1: Type: text/plain, Size: 320 bytes --]
On Wed, Apr 05, 2017 at 11:07:55AM +0100, Richard Fitzgerald wrote:
> The adds a driver for the microphone supply regulator on Cirrus Logic
> Madera class codecs.
Again, this appears to have only data and minor code style changes
relative to the existing arizona driver - is there no opportunity for
code sharing here?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH V7 0/4] phy: USB and PCIe phy drivers for Qcom chipsets
From: Kishon Vijay Abraham I @ 2017-04-05 13:38 UTC (permalink / raw)
To: Vivek Gautam, robh+dt
Cc: mark.rutland, devicetree, linux-arm-msm, linux-usb, sboyd,
linux-kernel, bjorn.andersson, srinivas.kandagatla,
linux-arm-kernel
In-Reply-To: <1491395558-16902-1-git-send-email-vivek.gautam@codeaurora.org>
Hi Vivek,
On Wednesday 05 April 2017 06:02 PM, Vivek Gautam wrote:
> This patch series adds couple of PHY drivers for Qualcomm chipsets.
> a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
> b) qcom-qmp phy driver: that is a combo phy providing support for
> USB3, PCIe, UFS and few other controllers.
>
> The patches are based on next branch of linux-phy tree.
>
> These patches have been tested on Dragon board db820c hardware with
> required set of dt patches and the patches to get rpm up on msm8996.
> Couple of other patches [1, 2] fixing DMA config for XHCI are also
> pulled in for testing.
> A branch based on torvald's master is available in github [3].
I get a bunch of checkpatch errors/warnings when I run checkpatch with --strict
option. Those look simple enough to be fixed. Can you respin your series fixing
those?
Thanks
Kishon
>
> Changes since v6:
> - Rebased on phy/next and *not* including phy grouping series[4].
> - qusb2-phy: addressed Stephen's comment.
> - Dropped pm8994_s2 corner regulator from QUSB2 phy bindings.
> - qmp-phy: none on functionality side.
>
> Changes since v5:
> - Addressed review comments from Bjorn:
> - Removed instances of readl/wirtel_relaxed calls from the drivers.
> Instead, using simple readl/writel. Inserting a readl after a writel
> to ensure the write is through to the device.
> - Replaced regulator handling with regulator_bulk_** apis. This helps
> in cutting down a lot of regulator handling code.
> - Fixed minor return statements.
>
> Changes since v4:
> - Addressed comment to add child nodes for qmp phy driver. Each phy lane
> now has a separate child node under the main qmp node.
> - Modified the clock and reset initialization and enable methods.
> Different phys - pcie, usb and later ufs, have varying number of clocks
> and resets that are mandatory. So adding provision for clocks and reset
> lists helps in requesting all mandatory resources for individual phys
> and handle their failure cases accordingly.
>
> Changes since v3:
> - Addressed review comments given by Rob and Stephen for qusb2 phy
> and qmp phy bindings respectively.
> - Addressed review comments given by Stephen and Bjorn for qmp phy driver.
>
> Changes since v2:
> - Addressed review comments given by Rob and Stephen for bindings.
> - Addressed the review comments given by Stephen for the qusb2 and qmp
> phy drivers.
>
> Changes since v1:
> - Moved device tree binding documentation to separate patches, as suggested
> by Rob.
> - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
> given by Rob.
> - Addressed review comments from Kishon.
> - Addressed review comments from Srinivas for QMP phy driver.
> - Addressed kbuild warning.
>
> Please see individual patches for detailed changelogs.
>
> [1] https://patchwork.kernel.org/patch/9567767/
> [2] https://patchwork.kernel.org/patch/9567779/
> [3] https://github.com/vivekgautam1/linux/tree/linux-v4.11-rc5-qmp-phy-db820c
> [4] https://lkml.org/lkml/2017/3/20/407
>
> Vivek Gautam (4):
> dt-bindings: phy: Add support for QUSB2 phy
> phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
> dt-bindings: phy: Add support for QMP phy
> phy: qcom-qmp: new qmp phy driver for qcom-chipsets
>
> .../devicetree/bindings/phy/qcom-qmp-phy.txt | 106 ++
> .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 43 +
> drivers/phy/Kconfig | 18 +
> drivers/phy/Makefile | 2 +
> drivers/phy/phy-qcom-qmp.c | 1153 ++++++++++++++++++++
> drivers/phy/phy-qcom-qusb2.c | 491 +++++++++
> 6 files changed, 1813 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
> create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
> create mode 100644 drivers/phy/phy-qcom-qmp.c
> create mode 100644 drivers/phy/phy-qcom-qusb2.c
>
^ permalink raw reply
* Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2
From: Kishon Vijay Abraham I @ 2017-04-05 13:34 UTC (permalink / raw)
To: Raviteja Garimella
Cc: Mark Rutland, devicetree, Scott Branden, Jon Mason, Ray Jui,
Will Deacon, linux-kernel, Rob Herring, BCM Kernel Feedback,
Catalin Marinas, linux-arm-kernel
In-Reply-To: <CAEHZuqMpHMDMVL6XMxrSPC3zeXZ=-Wx=xTSON_CruXnVC5PsdA@mail.gmail.com>
Hi Ravi,
On Wednesday 05 April 2017 06:30 PM, Raviteja Garimella wrote:
> Hi Kishon,
>
> On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>> Hi,
>>
>> On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
>>> This is driver for USB DRD Phy used in Broadcom's Northstar2
>>> SoC. The phy can be configured to be in Device mode or Host
>>> mode based on the type of cable connected to the port. The
>>> driver registers to extcon framework to get appropriate
>>> connect events for Host/Device cables connect/disconnect
>>> states based on VBUS and ID interrupts.
>>
>> $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
>> Northstar2.
>>
>
> Will do.
>
>> Sorry for not letting you know this earlier. But I feel the design of the
>> driver should be changed. Extcon shouldn't be used here. The extcon
>> notifications should be sent to the consumer driver and the consumer driver
>> should be responsible for invoking the phy ops.
>>
>
> The consumer drivers here would be a UDC driver (USB device
> controller), EHCI and OHCI host controller drivers.
> I was already suggested in UDC driver review to deal with extcon in Phy driver.
>
> This phy connects to 2 host controllers, and one device controller.
> That's the design in Broadcom Northstar2
> platform. The values of the VBUS and ID pins of this port are
> determined based on the type of the cable (device cable
> or host cable). And. phy has to be configured accordingly.
>
>> The phy ops being invoked during extcon events doesn't look right.
>
> Could you please elaborate on the concern, so that we can think of
> mitigating those issues in this driver?
> Since we are dealing with phy init/shutdown in this driver itself, are
> you okay with moving the extcon handling code
> out of phy ops ?
yeah, For e.g., ns2_drd_phy_init is part of phy_ops and is being invoked from
extcon events too. Can a phy which is initialized by a phy consumer (say your
UDC invokes phy_init) can be shutdown by an extcon event?
Maybe a clear explanation of when phy_ops here will be invoked and when it will
set using extcon events might help.
Thanks
Kishon
^ permalink raw reply
* Re: [PATCH 06/16] regulator: madera-ldo1: LDO1 driver for Cirrus Logic Madera codecs
From: Mark Brown @ 2017-04-05 13:28 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: gnurou, alsa-devel, jason, devicetree, linus.walleij, patches,
linux-kernel, linux-gpio, robh+dt, tglx, lee.jones
In-Reply-To: <1491386884-30689-7-git-send-email-rf@opensource.wolfsonmicro.com>
[-- Attachment #1.1: Type: text/plain, Size: 279 bytes --]
On Wed, Apr 05, 2017 at 11:07:54AM +0100, Richard Fitzgerald wrote:
> This patch adds a driver for the internal LDO1 regulator on
> some Cirrus Logic Madera class codecs.
There appear to be only data differences to the existing arizona driver,
is it possible to share the code?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [PATCH 1/3] gpio - Add EXAR XRA1403 SPI GPIO expander driver
From: Han, Nandor (GE Healthcare) @ 2017-04-05 13:24 UTC (permalink / raw)
To: Linus Walleij
Cc: Alexandre Courbot, Rob Herring, Mark Rutland,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Malinen, Semi (GE Healthcare)
In-Reply-To: <CACRpkdZB_cxqw0=M4YOhcwdZe7BxJtVKA290yGH-jxPU2MDgBg@mail.gmail.com>
> -----Original Message-----
> From: Linus Walleij [mailto:linus.walleij@linaro.org]
> Sent: 29 March 2017 05:07
> To: Han, Nandor (GE Healthcare) <nandor.han@ge.com>
> Cc: Alexandre Courbot <gnurou@gmail.com>; Rob Herring <robh+dt@kernel.org>; Mark Rutland
> <mark.rutland@arm.com>; linux-gpio@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> Malinen, Semi (GE Healthcare) <semi.malinen@ge.com>
> Subject: EXT: Re: [PATCH 1/3] gpio - Add EXAR XRA1403 SPI GPIO expander driver
>
> On Mon, Mar 27, 2017 at 8:23 AM, Nandor Han <nandor.han@ge.com> wrote:
>
> > This is a simple driver that provides a /sys/class/gpio
> > interface for controlling and configuring the GPIO lines.
>
> Use the gpio tools in tools/gpio, use the characcter device.
> Do not use sysfs. Change this to reference the tools.
>
> > It does not provide support for chip select or interrupts.
> >
> > Signed-off-by: Nandor Han <nandor.han@ge.com>
> > Signed-off-by: Semi Malinen <semi.malinen@ge.com>
> (...)
> > +exar Exar Corporation
>
> Send this as a separate patch to the DT bindings maintainer
> (Rob Herring.)
>
OK. I will create a separate patch with this one.
I guess is not an issue to send all the patches to Rob as well.
<snip>
> > +
> > + ret = xra1403_get_byte(xra, addr + (bit > 7));
> > + if (ret < 0)
> > + return ret;
> > +
> > + return !!(ret & BIT(bit % 8));
> > +}
>
> This looks like it can use regmap-spi right off, do you agree?
>
Yes. Using regmap-spi will definitely improve the code readability and reduce boilerplate.
Done.
> git grep devm_regmap_init_spi
> should give you some examples of how to use it.
>
> If it's not off-the shelf regmap drivers like
> drivers/iio/pressure/mpl115_spi.c
> give examples of how to make more elaborate custom
> SPI transfers with regmap.
>
Thanks, I did check other drivers as examples.
Not that I needed for this driver, but ...mpl115_spi.c doesn't seem to
use regmap (checked on next-20170327)
<snip>
> > +
> > + if (value != ret) {
> > + tx[0] = addr << 1;
> > + tx[1] = value;
> > + ret = spi_write(xra->spi, tx, sizeof(tx));
> > + } else {
> > + ret = 0;
> > + }
> > +
> > +out_unlock:
> > + mutex_unlock(&xra->lock);
> > +
> > + return ret;
> > +}
>
> Classical mask-and-set implementation right?
> With regmap this becomes simply regmap_update_bits(map, addr, mask, set)
>
True. :)
<snip>
> > + /* bring the chip out of reset */
> > + reset_gpio = gpiod_get_optional(&spi->dev, "reset", GPIOD_OUT_LOW);
> > + if (IS_ERR(reset_gpio))
> > + dev_warn(&spi->dev, "could not get reset-gpios\n");
> > + else if (reset_gpio)
> > + gpiod_put(reset_gpio);
>
> I don't think you should put it, other than in the remove()
> function and in that case you need to have it in the
> state container.
Can you please be more explicit here.
Currently I'm trying to bring the device out from reset in case reset GPIO is provided.
I don't see how this could be done in remove() :)
>
> > + mutex_init(&xra->lock);
> > +
> > + xra->chip.direction_input = xra1403_direction_input;
> > + xra->chip.direction_output = xra1403_direction_output;
>
> Please implement .get_direction(). This is very nice to have.
>
Done
> > +static int xra1403_remove(struct spi_device *spi)
> > +{
> > + struct xra1403 *xra = spi_get_drvdata(spi);
> > +
> > + gpiochip_remove(&xra->chip);
>
> Use devm_gpiochip_add_data() and this remove is not
> needed at all.
>
True. Done
<snip>
> > +subsys_initcall(xra1403_init);
> > +
> > +static void __exit xra1403_exit(void)
> > +{
> > + spi_unregister_driver(&xra1403_driver);
> > +}
> > +module_exit(xra1403_exit);
>
> This seems like tricksy. Just module_spi_driver()
> should be fine don't you think?
Yeah. TBH I don't have a strong reason why module_spi_driver init level shouldn't be enough.
Done.
Regards,
Nandor
^ permalink raw reply
* Re: [PATCH v2 2/2] of/pci: Fix memory leak in of_pci_get_host_bridge_resources
From: Rob Herring @ 2017-04-05 13:21 UTC (permalink / raw)
To: jeffy
Cc: Bjorn Helgaas, Dmitry Torokhov, linux-kernel@vger.kernel.org,
toshi.kani, Shawn Lin, Brian Norris, Doug Anderson, Frank Rowand,
devicetree@vger.kernel.org
In-Reply-To: <58E454CF.7050501@rock-chips.com>
On Tue, Apr 4, 2017 at 9:22 PM, jeffy <jeffy.chen@rock-chips.com> wrote:
> Hi Bjorn,
>
>
> On 04/05/2017 03:18 AM, Bjorn Helgaas wrote:
>>
>> On Thu, Mar 23, 2017 at 5:58 PM, Dmitry Torokhov <dtor@chromium.org>
>> wrote:
>>>
>>> On Thu, Mar 23, 2017 at 3:07 PM, Rob Herring <robh@kernel.org> wrote:
>>>>
>>>> On Thu, Mar 23, 2017 at 3:12 AM, Jeffy Chen <jeffy.chen@rock-chips.com>
>>>> wrote:
>>>>>
>>>>> Currently we only free the allocated resource struct when error.
>>>>> This would cause memory leak after pci_free_resource_list.
>>>>> - pci_add_resource(resources, bus_range);
>>>>> + *window->res = res;
>>>>
>>>>
>>>> Well, now this seems racy. You add a blank resource to the list first
>>>> and then fill it in.
>>>>
>>>
>>> Huh? There is absolutely no guarantees for concurrent access here.
>>> pcI_add_resource_offset() first adds a resource and then modifies
>>> offset. Here we add an empty resource and then fill it in.
>>
>>
>> I don't really like this pattern either. Even if there's no actual
>> racy behavior, it takes more analysis than necessary to figure that
>> out.
>>
>> pci_add_resource_offset() allocates a resource list entry, sets the
>> offset, then adds it to the list. It doesn't update a resource entry
>> that might be visible to anybody else. Here we do update a resource
>> that is already visible to others because it's already on the list.
>
> i was following ./drivers/pnp/resource.c, but i'm agree this is not a good
> way.
>
> i'll upload a new version to fix this in another way. more ideas:
> 1/ pass a struct device to of_pci_get_host_bridge_resources and use
> devm_kzalloc
I would pick this one of the 3 options or...
> 2/ add a new type of flags(or reuse IORESOURCE_AUTO) to tell
> pci_free_resource_list to kfree them)
> 3/ add new helpers of of_pci_add_resource[_offset] to alloc empty res, fill
> it, add to list.
2 other options:
Add a function to undo everything that
of_pci_get_host_bridge_resources does. Then every caller of
of_pci_get_host_bridge_resources should have a call to that function.
Or maybe you can add a pci_free_resource_list_and_resources (needs a
better name) to free both resources and list. Then audit all the
current callers of pci_free_resource_list and determine which one's
can be changed (maybe it is all of them).
Rob
^ permalink raw reply
* [PATCH v2 3/3] soc: imx: gpc: add workaround for i.MX6QP to the GPC PD driver
From: Lucas Stach @ 2017-04-05 13:19 UTC (permalink / raw)
To: Shawn Guo
Cc: Fabio Estevam, Dong Aisheng, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
patchwork-lst-bIcnvbaLZ9MEGnE8C9+IrQ,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <20170405131909.16880-1-l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On i.MX6QP, due to hardware erratum ERR009619, the PRE clocks may be
stalled during the power up sequencing of the PU power domain. As this
may lead to a complete loss of display output, the recommended
workaround is to keep the PU domain enabled during normal system
operation.
Implement this by rejecting the domain power down request on the
affected SoC.
Signed-off-by: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
v2:
- use domain index define
- switch to domain flags
- switch to positive logic
---
drivers/soc/imx/gpc.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
index d4ebb325b558..47e7aa963dbb 100644
--- a/drivers/soc/imx/gpc.c
+++ b/drivers/soc/imx/gpc.c
@@ -36,6 +36,8 @@
#define GPC_CLK_MAX 6
+#define PGC_DOMAIN_FLAG_NO_PD BIT(0)
+
struct imx_pm_domain {
struct generic_pm_domain base;
struct regmap *regmap;
@@ -45,6 +47,7 @@ struct imx_pm_domain {
unsigned int reg_offs;
signed char cntr_pdn_bit;
unsigned int ipg_rate_mhz;
+ unsigned int flags;
};
static inline struct imx_pm_domain *
@@ -59,6 +62,9 @@ static int imx6_pm_domain_power_off(struct generic_pm_domain *genpd)
int iso, iso2sw;
u32 val;
+ if (pd->flags & PGC_DOMAIN_FLAG_NO_PD)
+ return -EBUSY;
+
/* Read ISO and ISO2SW power down delays */
regmap_read(pd->regmap, pd->reg_offs + GPC_PGC_PUPSCR_OFFS, &val);
iso = val & 0x3f;
@@ -272,18 +278,27 @@ static struct imx_pm_domain imx_gpc_domains[] = {
struct imx_gpc_dt_data {
int num_domains;
+ bool err009619_present;
};
static const struct imx_gpc_dt_data imx6q_dt_data = {
.num_domains = 2,
+ .err009619_present = false,
+};
+
+static const struct imx_gpc_dt_data imx6qp_dt_data = {
+ .num_domains = 2,
+ .err009619_present = true,
};
static const struct imx_gpc_dt_data imx6sl_dt_data = {
.num_domains = 3,
+ .err009619_present = false,
};
static const struct of_device_id imx_gpc_dt_ids[] = {
{ .compatible = "fsl,imx6q-gpc", .data = &imx6q_dt_data },
+ { .compatible = "fsl,imx6qp-gpc", .data = &imx6qp_dt_data },
{ .compatible = "fsl,imx6sl-gpc", .data = &imx6sl_dt_data },
{ }
};
@@ -381,6 +396,11 @@ static int imx_gpc_probe(struct platform_device *pdev)
return ret;
}
+ /* Disable PU power down in normal operation if ERR009619 is present */
+ if (of_id_data->err009619_present)
+ imx_gpc_domains[GPC_PGC_DOMAIN_PU].flags |=
+ PGC_DOMAIN_FLAG_NO_PD;
+
if (!pgc_node) {
ret = imx_gpc_old_dt_init(&pdev->dev, regmap,
of_id_data->num_domains);
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 2/3] dt-bindings: imx-gpc: add i.MX6 QuadPlus compatible
From: Lucas Stach @ 2017-04-05 13:19 UTC (permalink / raw)
To: Shawn Guo
Cc: Fabio Estevam, Dong Aisheng, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
patchwork-lst-bIcnvbaLZ9MEGnE8C9+IrQ,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <20170405131909.16880-1-l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
While the GPC on i.MX6QP is mostly comptible to the i.MX6Q one,
the QuadPlus requires special workarounds for hardware erratum
ERR009619.
Signed-off-by: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/power/fsl,imx-gpc.txt | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
index 416e12c6755a..181d2cc6f054 100644
--- a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
+++ b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
@@ -5,7 +5,10 @@ The i.MX6 General Power Control (GPC) block contains DVFS load tracking
counters and Power Gating Control (PGC).
Required properties:
-- compatible: Should be "fsl,imx6q-gpc" or "fsl,imx6sl-gpc"
+- compatible: Should be one of the following:
+ - fsl,imx6q-gpc
+ - fsl,imx6qp-gpc
+ - fsl,imx6sl-gpc
- reg: should be register base and length as documented in the
datasheet
- interrupts: Should contain one interrupt specifier for the GPC interrupt
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 1/3] soc: imx: gpc: add defines for domain index
From: Lucas Stach @ 2017-04-05 13:19 UTC (permalink / raw)
To: Shawn Guo
Cc: Fabio Estevam, Dong Aisheng, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
patchwork-lst-bIcnvbaLZ9MEGnE8C9+IrQ,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
Makes referencing a specfic domain in the driver code
less error prone.
Signed-off-by: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
v2: new patch
---
drivers/soc/imx/gpc.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
index 4294287e5f6c..d4ebb325b558 100644
--- a/drivers/soc/imx/gpc.c
+++ b/drivers/soc/imx/gpc.c
@@ -235,6 +235,10 @@ static struct platform_driver imx_pgc_power_domain_driver = {
};
builtin_platform_driver(imx_pgc_power_domain_driver)
+#define GPC_PGC_DOMAIN_ARM 0
+#define GPC_PGC_DOMAIN_PU 1
+#define GPC_PGC_DOMAIN_DISPLAY 2
+
static struct genpd_power_state imx6_pm_domain_pu_state = {
.power_off_latency_ns = 25000,
.power_on_latency_ns = 2000000,
@@ -340,7 +344,7 @@ static int imx_gpc_old_dt_init(struct device *dev, struct regmap *regmap,
genpd_err:
for (i = 0; i < num_domains; i++)
pm_genpd_remove(&imx_gpc_domains[i].base);
- imx_pgc_put_clocks(&imx_gpc_domains[1]);
+ imx_pgc_put_clocks(&imx_gpc_domains[GPC_PGC_DOMAIN_PU]);
clk_err:
return ret;
}
@@ -441,12 +445,12 @@ static int imx_gpc_remove(struct platform_device *pdev)
if (!of_get_child_by_name(pdev->dev.of_node, "pgc")) {
of_genpd_del_provider(pdev->dev.of_node);
- ret = pm_genpd_remove(&imx_gpc_domains[1].base);
+ ret = pm_genpd_remove(&imx_gpc_domains[GPC_PGC_DOMAIN_PU].base);
if (ret)
return ret;
- imx_pgc_put_clocks(&imx_gpc_domains[1]);
+ imx_pgc_put_clocks(&imx_gpc_domains[GPC_PGC_DOMAIN_PU]);
- ret = pm_genpd_remove(&imx_gpc_domains[0].base);
+ ret = pm_genpd_remove(&imx_gpc_domains[GPC_PGC_DOMAIN_ARM].base);
if (ret)
return ret;
}
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 2/2] i2c: mux: ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
From: michael.hennerich-OyLXuOCK7orQT0dZR+AlfA @ 2017-04-05 13:07 UTC (permalink / raw)
To: wsa-z923LK4zBo2bacvFa/9K2g, peda-koto5C5qi+TLoDKTGw+V6w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Michael Hennerich
In-Reply-To: <1491397671-14675-1-git-send-email-michael.hennerich-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
From: Michael Hennerich <michael.hennerich-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
This patch adds support for the Analog Devices / Linear Technology
LTC4306 and LTC4305 4/2 Channel I2C Bus Multiplexer/Switches.
The LTC4306 optionally provides two general purpose input/output pins
(GPIOs) that can be configured as logic inputs, opendrain outputs or
push-pull outputs via the generic GPIOLIB framework.
Signed-off-by: Michael Hennerich <michael.hennerich-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
---
Changes since v1:
- Sort makefile entries
- Sort driver includes
- Use proper defines
- Miscellaneous coding style fixups
- Rename mux select callback
- Revise i2c-mux-idle-disconnect handling
- Add ENABLE GPIO handling on error and device removal.
- Remove surplus of_match_device call.
Changes since v2:
- Stop double error reporting (i2c_mux_add_adapter)
- Change subject
- Split dt bindings to separate patch
Changes since v3:
- Change subject and add spaces
- Convert to I2C_MUX_LOCKED
- Convert to regmap
- Remove local register cache
- Restore previous ENABLE GPIO handling
- Initially pulse ENABLE low
- Eliminate i2c client struct in driver state structure
- Simplify error return path
- Misc minor cleanups
---
MAINTAINERS | 8 +
drivers/i2c/muxes/Kconfig | 11 ++
drivers/i2c/muxes/Makefile | 1 +
drivers/i2c/muxes/i2c-mux-ltc4306.c | 310 ++++++++++++++++++++++++++++++++++++
4 files changed, 330 insertions(+)
create mode 100644 drivers/i2c/muxes/i2c-mux-ltc4306.c
diff --git a/MAINTAINERS b/MAINTAINERS
index c776906..9a27a19 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7698,6 +7698,14 @@ S: Maintained
F: Documentation/hwmon/ltc4261
F: drivers/hwmon/ltc4261.c
+LTC4306 I2C MULTIPLEXER DRIVER
+M: Michael Hennerich <michael.hennerich-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
+W: http://ez.analog.com/community/linux-device-drivers
+L: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
+S: Supported
+F: drivers/i2c/muxes/i2c-mux-ltc4306.c
+F: Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
+
LTP (Linux Test Project)
M: Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
M: Cyril Hrubis <chrubis-AlSwsSmVLrQ@public.gmane.org>
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 10b3d17..41153b4 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -30,6 +30,17 @@ config I2C_MUX_GPIO
This driver can also be built as a module. If so, the module
will be called i2c-mux-gpio.
+config I2C_MUX_LTC4306
+ tristate "LTC LTC4306/5 I2C multiplexer"
+ select GPIOLIB
+ select REGMAP_I2C
+ help
+ If you say yes here you get support for the LTC LTC4306 or LTC4305
+ I2C mux/switch devices.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-mux-ltc4306.
+
config I2C_MUX_PCA9541
tristate "NXP PCA9541 I2C Master Selector"
help
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index 9948fa4..ff7618c 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_I2C_ARB_GPIO_CHALLENGE) += i2c-arb-gpio-challenge.o
obj-$(CONFIG_I2C_DEMUX_PINCTRL) += i2c-demux-pinctrl.o
obj-$(CONFIG_I2C_MUX_GPIO) += i2c-mux-gpio.o
+obj-$(CONFIG_I2C_MUX_LTC4306) += i2c-mux-ltc4306.o
obj-$(CONFIG_I2C_MUX_MLXCPLD) += i2c-mux-mlxcpld.o
obj-$(CONFIG_I2C_MUX_PCA9541) += i2c-mux-pca9541.o
obj-$(CONFIG_I2C_MUX_PCA954x) += i2c-mux-pca954x.o
diff --git a/drivers/i2c/muxes/i2c-mux-ltc4306.c b/drivers/i2c/muxes/i2c-mux-ltc4306.c
new file mode 100644
index 0000000..7d34434
--- /dev/null
+++ b/drivers/i2c/muxes/i2c-mux-ltc4306.c
@@ -0,0 +1,310 @@
+/*
+ * Linear Technology LTC4306 and LTC4305 I2C multiplexer/switch
+ *
+ * Copyright (C) 2017 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2.
+ *
+ * Based on: i2c-mux-pca954x.c
+ *
+ * Datasheet: http://cds.linear.com/docs/en/datasheet/4306.pdf
+ */
+
+#include <linux/device.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
+#include <linux/gpio/driver.h>
+#include <linux/i2c-mux.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+#define LTC4305_MAX_NCHANS 2
+#define LTC4306_MAX_NCHANS 4
+
+#define LTC_REG_STATUS 0x0
+#define LTC_REG_CONFIG 0x1
+#define LTC_REG_MODE 0x2
+#define LTC_REG_SWITCH 0x3
+
+#define LTC_DOWNSTREAM_ACCL_EN BIT(6)
+#define LTC_UPSTREAM_ACCL_EN BIT(7)
+
+#define LTC_GPIO_ALL_INPUT 0xC0
+#define LTC_SWITCH_MASK 0xF0
+
+enum ltc_type {
+ ltc_4305,
+ ltc_4306,
+};
+
+struct chip_desc {
+ u8 nchans;
+ u8 num_gpios;
+};
+
+struct ltc4306 {
+ struct regmap *regmap;
+ struct gpio_chip gpiochip;
+ const struct chip_desc *chip;
+};
+
+static const struct chip_desc chips[] = {
+ [ltc_4305] = {
+ .nchans = LTC4305_MAX_NCHANS,
+ },
+ [ltc_4306] = {
+ .nchans = LTC4306_MAX_NCHANS,
+ .num_gpios = 2,
+ },
+};
+
+static bool ltc4306_is_volatile_reg(struct device *dev, unsigned int reg)
+{
+ return (reg == LTC_REG_CONFIG) ? true : false;
+}
+
+static const struct regmap_config ltc4306_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = LTC_REG_SWITCH,
+ .volatile_reg = ltc4306_is_volatile_reg,
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static int ltc4306_gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+ struct ltc4306 *data = gpiochip_get_data(chip);
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(data->regmap, LTC_REG_CONFIG, &val);
+ if (ret < 0)
+ return ret;
+
+ return (val & BIT(1 - offset));
+}
+
+static void ltc4306_gpio_set(struct gpio_chip *chip, unsigned int offset,
+ int value)
+{
+ struct ltc4306 *data = gpiochip_get_data(chip);
+
+ regmap_update_bits(data->regmap, LTC_REG_CONFIG, BIT(5 - offset),
+ value ? BIT(5 - offset) : 0);
+}
+
+static int ltc4306_gpio_direction_input(struct gpio_chip *chip,
+ unsigned int offset)
+{
+ struct ltc4306 *data = gpiochip_get_data(chip);
+
+ return regmap_update_bits(data->regmap, LTC_REG_MODE,
+ BIT(7 - offset), BIT(7 - offset));
+}
+
+static int ltc4306_gpio_direction_output(struct gpio_chip *chip,
+ unsigned int offset, int value)
+{
+ struct ltc4306 *data = gpiochip_get_data(chip);
+
+ ltc4306_gpio_set(chip, offset, value);
+ return regmap_update_bits(data->regmap, LTC_REG_MODE,
+ BIT(7 - offset), 0);
+}
+
+static int ltc4306_gpio_set_config(struct gpio_chip *chip,
+ unsigned int offset, unsigned long config)
+{
+ struct ltc4306 *data = gpiochip_get_data(chip);
+ unsigned int val;
+
+ switch (pinconf_to_config_param(config)) {
+ case PIN_CONFIG_DRIVE_OPEN_DRAIN:
+ val = 0;
+ break;
+ case PIN_CONFIG_DRIVE_PUSH_PULL:
+ val = BIT(4 - offset);
+ break;
+ default:
+ return -ENOTSUPP;
+ }
+
+ return regmap_update_bits(data->regmap, LTC_REG_MODE,
+ BIT(4 - offset), val);
+}
+
+static int ltc4306_gpio_init(struct ltc4306 *data)
+{
+ struct device *dev = regmap_get_device(data->regmap);
+
+ if (!data->chip->num_gpios)
+ return 0;
+
+ data->gpiochip.label = dev_name(dev);
+ data->gpiochip.base = -1;
+ data->gpiochip.ngpio = data->chip->num_gpios;
+ data->gpiochip.parent = dev;
+ data->gpiochip.can_sleep = true;
+ data->gpiochip.direction_input = ltc4306_gpio_direction_input;
+ data->gpiochip.direction_output = ltc4306_gpio_direction_output;
+ data->gpiochip.get = ltc4306_gpio_get;
+ data->gpiochip.set = ltc4306_gpio_set;
+ data->gpiochip.set_config = ltc4306_gpio_set_config;
+ data->gpiochip.owner = THIS_MODULE;
+
+ /* gpiolib assumes all GPIOs default input */
+ regmap_write(data->regmap, LTC_REG_MODE, LTC_GPIO_ALL_INPUT);
+
+ return devm_gpiochip_add_data(dev, &data->gpiochip, data);
+}
+
+static int ltc4306_select_mux(struct i2c_mux_core *muxc, u32 chan)
+{
+ struct ltc4306 *data = i2c_mux_priv(muxc);
+
+ return regmap_update_bits(data->regmap, LTC_REG_SWITCH,
+ LTC_SWITCH_MASK, BIT(7 - chan));
+}
+
+static int ltc4306_deselect_mux(struct i2c_mux_core *muxc, u32 chan)
+{
+ struct ltc4306 *data = i2c_mux_priv(muxc);
+
+ return regmap_update_bits(data->regmap, LTC_REG_SWITCH,
+ LTC_SWITCH_MASK, 0);
+}
+
+static const struct i2c_device_id ltc4306_id[] = {
+ { "ltc4305", ltc_4305 },
+ { "ltc4306", ltc_4306 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, ltc4306_id);
+
+static const struct of_device_id ltc4306_of_match[] = {
+ { .compatible = "lltc,ltc4305", .data = &chips[ltc_4305] },
+ { .compatible = "lltc,ltc4306", .data = &chips[ltc_4306] },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ltc4306_of_match);
+
+static int ltc4306_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct i2c_adapter *adap = to_i2c_adapter(client->dev.parent);
+ struct device_node *of_node = client->dev.of_node;
+ struct i2c_mux_core *muxc;
+ struct ltc4306 *data;
+ struct gpio_desc *gpio;
+ bool idle_disc = false;
+ int num, ret;
+
+ if (of_node)
+ idle_disc = of_property_read_bool(of_node,
+ "i2c-mux-idle-disconnect");
+
+ muxc = i2c_mux_alloc(adap, &client->dev,
+ LTC4306_MAX_NCHANS, sizeof(*data),
+ I2C_MUX_LOCKED, ltc4306_select_mux,
+ idle_disc ? ltc4306_deselect_mux : NULL);
+ if (!muxc)
+ return -ENOMEM;
+ data = i2c_mux_priv(muxc);
+
+ i2c_set_clientdata(client, muxc);
+
+ data->regmap = devm_regmap_init_i2c(client, <c4306_regmap_config);
+ if (IS_ERR(data->regmap)) {
+ ret = PTR_ERR(data->regmap);
+ dev_err(&client->dev, "Failed to allocate register map: %d\n",
+ ret);
+ return ret;
+ }
+
+ /* Reset and enable the mux if an enable GPIO is specified. */
+ gpio = devm_gpiod_get_optional(&client->dev, "enable", GPIOD_OUT_LOW);
+ if (IS_ERR(gpio))
+ return PTR_ERR(gpio);
+
+ if (gpio) {
+ udelay(1);
+ gpiod_set_value(gpio, 1);
+ }
+
+ /*
+ * Write the mux register at addr to verify
+ * that the mux is in fact present. This also
+ * initializes the mux to disconnected state.
+ */
+ if (regmap_write(data->regmap, LTC_REG_SWITCH, 0) < 0) {
+ dev_warn(&client->dev, "probe failed\n");
+ return -ENODEV;
+ }
+
+ if (of_node) {
+ unsigned int val = 0;
+
+ data->chip = of_device_get_match_data(&client->dev);
+
+ if (of_property_read_bool(of_node,
+ "ltc,downstream-accelerators-enable"))
+ val |= LTC_DOWNSTREAM_ACCL_EN;
+
+ if (of_property_read_bool(of_node,
+ "ltc,upstream-accelerators-enable"))
+ val |= LTC_UPSTREAM_ACCL_EN;
+
+ if (regmap_write(data->regmap, LTC_REG_CONFIG, val) < 0)
+ return -ENODEV;
+ } else {
+ data->chip = &chips[id->driver_data];
+ }
+
+ ret = ltc4306_gpio_init(data);
+ if (ret < 0)
+ return ret;
+
+ /* Now create an adapter for each channel */
+ for (num = 0; num < data->chip->nchans; num++) {
+ ret = i2c_mux_add_adapter(muxc, 0, num, 0);
+ if (ret) {
+ i2c_mux_del_adapters(muxc);
+ return ret;
+ }
+ }
+
+ dev_info(&client->dev,
+ "registered %d multiplexed busses for I2C switch %s\n",
+ num, client->name);
+
+ return 0;
+}
+
+static int ltc4306_remove(struct i2c_client *client)
+{
+ struct i2c_mux_core *muxc = i2c_get_clientdata(client);
+
+ i2c_mux_del_adapters(muxc);
+
+ return 0;
+}
+
+static struct i2c_driver ltc4306_driver = {
+ .driver = {
+ .name = "ltc4306",
+ .of_match_table = of_match_ptr(ltc4306_of_match),
+ },
+ .probe = ltc4306_probe,
+ .remove = ltc4306_remove,
+ .id_table = ltc4306_id,
+};
+
+module_i2c_driver(ltc4306_driver);
+
+MODULE_AUTHOR("Michael Hennerich <michael.hennerich-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>");
+MODULE_DESCRIPTION("Linear Technology LTC4306, LTC4305 I2C mux/switch driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: i2c: mux: ltc4306: Add dt-bindings for I2C multiplexer/switch
From: michael.hennerich-OyLXuOCK7orQT0dZR+AlfA @ 2017-04-05 13:07 UTC (permalink / raw)
To: wsa-z923LK4zBo2bacvFa/9K2g, peda-koto5C5qi+TLoDKTGw+V6w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Michael Hennerich
From: Michael Hennerich <michael.hennerich-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
This patch adds support for the Analog Devices / Linear Technology
LTC4306 and LTC4305 4/2 Channel I2C Bus Multiplexer/Switches.
The LTC4306 optionally provides two general purpose input/output pins
(GPIOs) that can be configured as logic inputs, opendrain outputs or
push-pull outputs via the generic GPIOLIB framework.
Signed-off-by: Michael Hennerich <michael.hennerich-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/i2c/i2c-mux-ltc4306.txt | 61 ++++++++++++++++++++++
1 file changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
new file mode 100644
index 0000000..1e98c6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
@@ -0,0 +1,61 @@
+* Linear Technology / Analog Devices I2C bus switch
+
+Required Properties:
+
+ - compatible: Must contain one of the following.
+ "lltc,ltc4305", "lltc,ltc4306"
+ - reg: The I2C address of the device.
+
+ The following required properties are defined externally:
+
+ - Standard I2C mux properties. See i2c-mux.txt in this directory.
+ - I2C child bus nodes. See i2c-mux.txt in this directory.
+
+Optional Properties:
+
+ - enable-gpios: Reference to the GPIO connected to the enable input.
+ - i2c-mux-idle-disconnect: Boolean; if defined, forces mux to disconnect all
+ children in idle state. This is necessary for example, if there are several
+ multiplexers on the bus and the devices behind them use same I2C addresses.
+ - 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 ../gpio/gpio.txt for more information.
+ - ltc,downstream-accelerators-enable: Enables the rise time accelerators
+ on the downstream port.
+ - ltc,upstream-accelerators-enable: Enables the rise time accelerators
+ on the upstream port.
+
+Example:
+
+ ltc4306: i2c-mux@4a {
+ compatible = "lltc,ltc4306";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4a>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ eeprom@50 {
+ compatible = "at,24c02";
+ reg = <0x50>;
+ };
+ };
+
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ eeprom@50 {
+ compatible = "at,24c02";
+ reg = <0x50>;
+ };
+ };
+ };
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 2/3] arm64: allwinner: a64: add USB0 OHCI/EHCI related devicetree parts
From: Maxime Ripard @ 2017-04-05 13:05 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Kishon Vijay Abraham I,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170405125053.6170-3-icenowy-h8G6r0blFSE@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]
On Wed, Apr 05, 2017 at 08:50:52PM +0800, Icenowy Zheng wrote:
> As we added USB0 route auto switching support for A64, add related
> device tree parts to the A64 DTSI file (EHCI0/OHCI0 controllers and the
> pmu0 memory area for PHY).
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 1c64ea2d23f9..a8916df99048 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -179,8 +179,10 @@
> usbphy: phy@01c19400 {
> compatible = "allwinner,sun50i-a64-usb-phy";
> reg = <0x01c19400 0x14>,
> + <0x01c1a800 0x4>,
> <0x01c1b800 0x4>;
> reg-names = "phy_ctrl",
> + "pmu0",
Again, this needs to be split apart, and sent for 4.11.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2
From: Raviteja Garimella @ 2017-04-05 13:00 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Mark Rutland, devicetree, Scott Branden, Jon Mason, Ray Jui,
Will Deacon, linux-kernel, Rob Herring, BCM Kernel Feedback,
Catalin Marinas, linux-arm-kernel
In-Reply-To: <8aa2cc42-6fdc-5574-4449-f05f6d5cbd38@ti.com>
Hi Kishon,
On Wed, Apr 5, 2017 at 4:30 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> Hi,
>
> On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
>> This is driver for USB DRD Phy used in Broadcom's Northstar2
>> SoC. The phy can be configured to be in Device mode or Host
>> mode based on the type of cable connected to the port. The
>> driver registers to extcon framework to get appropriate
>> connect events for Host/Device cables connect/disconnect
>> states based on VBUS and ID interrupts.
>
> $patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
> Northstar2.
>
Will do.
> Sorry for not letting you know this earlier. But I feel the design of the
> driver should be changed. Extcon shouldn't be used here. The extcon
> notifications should be sent to the consumer driver and the consumer driver
> should be responsible for invoking the phy ops.
>
The consumer drivers here would be a UDC driver (USB device
controller), EHCI and OHCI host controller drivers.
I was already suggested in UDC driver review to deal with extcon in Phy driver.
This phy connects to 2 host controllers, and one device controller.
That's the design in Broadcom Northstar2
platform. The values of the VBUS and ID pins of this port are
determined based on the type of the cable (device cable
or host cable). And. phy has to be configured accordingly.
> The phy ops being invoked during extcon events doesn't look right.
Could you please elaborate on the concern, so that we can think of
mitigating those issues in this driver?
Since we are dealing with phy init/shutdown in this driver itself, are
you okay with moving the extcon handling code
out of phy ops ?
Thanks,
Ravi
>
> Thanks
> Kishon
^ permalink raw reply
* Re: [PATCH 1/3] dt: bindings: add pmu0 regs for USB PHYs on Allwinner H3/V3s/A64
From: Kishon Vijay Abraham I @ 2017-04-05 12:58 UTC (permalink / raw)
To: Icenowy Zheng, Rob Herring, Maxime Ripard, Chen-Yu Tsai
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170405125053.6170-2-icenowy-h8G6r0blFSE@public.gmane.org>
On Wednesday 05 April 2017 06:20 PM, Icenowy Zheng wrote:
> From: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>
> Allwinner H3/V3s/A64 SoCs have a special USB PHY0 that can route to two
> controllers: one is MUSB and the other is a EHCI/OHCI pair.
>
> When it's routed to EHCI/OHCI pair, it will needs a "pmu0" regs to
> tweak, like other EHCI/OHCI pairs in Allwinner SoCs.
>
> Add this to the binding of USB PHYs on Allwinner H3/V3s/A64.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
> ---
>
> Kishon, could you push this to 4.11?
Is this for the patch titled "phy: sun4i-usb: add support for V3s USB PHY" that
was added during the last merge window.
this patch looks simpler enough to be merged in this -rc cycle. However it
depends on Greg KH.
Thanks
Kishon
>
> Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> index e42334258185..005bc22938ff 100644
> --- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> @@ -15,6 +15,7 @@ Required properties:
> - reg : a list of offset + length pairs
> - reg-names :
> * "phy_ctrl"
> + * "pmu0" for H3, V3s and A64
> * "pmu1"
> * "pmu2" for sun4i, sun6i or sun7i
> - #phy-cells : from the generic phy bindings, must be 1
>
^ permalink raw reply
* [PATCH 3/3] arm64: allwinner: a64: enable EHCI0/OHCI0 controller for Pine64
From: Icenowy Zheng @ 2017-04-05 12:50 UTC (permalink / raw)
To: Rob Herring, Maxime Ripard, Chen-Yu Tsai, Kishon Vijay Abraham I
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170405125053.6170-1-icenowy-h8G6r0blFSE@public.gmane.org>
The upper USB port of Pine64 board is connected to the SoC's USB0 port,
which can now switch from the MUSB controller to the EHCI/OHCI pair.
Enable the EHCI/OHCI pair in the Pine64 device tree.
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index c680ed385da3..4782add50b94 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -66,6 +66,10 @@
};
};
+&ehci0 {
+ status = "okay";
+};
+
&ehci1 {
status = "okay";
};
@@ -91,6 +95,10 @@
status = "okay";
};
+&ohci0 {
+ status = "okay";
+};
+
&ohci1 {
status = "okay";
};
--
2.12.2
^ permalink raw reply related
* [PATCH 2/3] arm64: allwinner: a64: add USB0 OHCI/EHCI related devicetree parts
From: Icenowy Zheng @ 2017-04-05 12:50 UTC (permalink / raw)
To: Rob Herring, Maxime Ripard, Chen-Yu Tsai, Kishon Vijay Abraham I
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170405125053.6170-1-icenowy-h8G6r0blFSE@public.gmane.org>
As we added USB0 route auto switching support for A64, add related
device tree parts to the A64 DTSI file (EHCI0/OHCI0 controllers and the
pmu0 memory area for PHY).
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 1c64ea2d23f9..a8916df99048 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -179,8 +179,10 @@
usbphy: phy@01c19400 {
compatible = "allwinner,sun50i-a64-usb-phy";
reg = <0x01c19400 0x14>,
+ <0x01c1a800 0x4>,
<0x01c1b800 0x4>;
reg-names = "phy_ctrl",
+ "pmu0",
"pmu1";
clocks = <&ccu CLK_USB_PHY0>,
<&ccu CLK_USB_PHY1>;
@@ -194,6 +196,28 @@
#phy-cells = <1>;
};
+ ehci0: usb@01c1a000 {
+ compatible = "allwinner,sun50i-a64-ehci", "generic-ehci";
+ reg = <0x01c1a000 0x100>;
+ interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_OHCI0>,
+ <&ccu CLK_BUS_EHCI0>,
+ <&ccu CLK_USB_OHCI0>;
+ resets = <&ccu RST_BUS_OHCI0>,
+ <&ccu RST_BUS_EHCI0>;
+ status = "disabled";
+ };
+
+ ohci0: usb@01c1a400 {
+ compatible = "allwinner,sun50i-a64-ohci", "generic-ohci";
+ reg = <0x01c1a400 0x100>;
+ interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_OHCI0>,
+ <&ccu CLK_USB_OHCI0>;
+ resets = <&ccu RST_BUS_OHCI0>;
+ status = "disabled";
+ };
+
ehci1: usb@01c1b000 {
compatible = "allwinner,sun50i-a64-ehci", "generic-ehci";
reg = <0x01c1b000 0x100>;
--
2.12.2
^ permalink raw reply related
* [PATCH 1/3] dt: bindings: add pmu0 regs for USB PHYs on Allwinner H3/V3s/A64
From: Icenowy Zheng @ 2017-04-05 12:50 UTC (permalink / raw)
To: Rob Herring, Maxime Ripard, Chen-Yu Tsai, Kishon Vijay Abraham I
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170405125053.6170-1-icenowy-h8G6r0blFSE@public.gmane.org>
From: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
Allwinner H3/V3s/A64 SoCs have a special USB PHY0 that can route to two
controllers: one is MUSB and the other is a EHCI/OHCI pair.
When it's routed to EHCI/OHCI pair, it will needs a "pmu0" regs to
tweak, like other EHCI/OHCI pairs in Allwinner SoCs.
Add this to the binding of USB PHYs on Allwinner H3/V3s/A64.
Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
---
Kishon, could you push this to 4.11?
Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
index e42334258185..005bc22938ff 100644
--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -15,6 +15,7 @@ Required properties:
- reg : a list of offset + length pairs
- reg-names :
* "phy_ctrl"
+ * "pmu0" for H3, V3s and A64
* "pmu1"
* "pmu2" for sun4i, sun6i or sun7i
- #phy-cells : from the generic phy bindings, must be 1
--
2.12.2
^ permalink raw reply related
* [PATCH 0/3] Allwinner A64 EHCI0/OHCI0 devicetree change
From: Icenowy Zheng @ 2017-04-05 12:50 UTC (permalink / raw)
To: Rob Herring, Maxime Ripard, Chen-Yu Tsai, Kishon Vijay Abraham I
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
This patchset contains devicetree parts of the EHCI0/OHCI0 controllers
on A64 SoC.
The first patch is a devicetree binding change, which has been planned
for 4.12; however, as Maxime Ripard suggested, it should go in 4.11
as it's part of the device's description.
The second patch added pmu0 regs and EHCI/OHCI controllers for USB0.
The third patch enabled EHCI0/OHCI0 for Pine64 board.
This patchset should go in 4.11 as Maxime Ripard suggested.
Icenowy Zheng (3):
dt: bindings: add pmu0 regs for USB PHYs on Allwinner H3/V3s/A64
arm64: allwinner: a64: add USB0 OHCI/EHCI related devicetree parts
arm64: allwinner: a64: enable EHCI0/OHCI0 controller for Pine64
.../devicetree/bindings/phy/sun4i-usb-phy.txt | 1 +
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 8 ++++++++
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 24 ++++++++++++++++++++++
3 files changed, 33 insertions(+)
--
2.12.2
^ permalink raw reply
* [PATCH 0/3] XRA1403,gpio - add XRA1403 gpio expander driver
From: Han, Nandor (GE Healthcare) @ 2017-04-05 12:46 UTC (permalink / raw)
To: Linus Walleij
Cc: Alexandre Courbot, Rob Herring, Mark Rutland,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CACRpkdZ-wD5SwBNtSPceV-mwJiAAU_03obk3Gv97kz0MzX7RLw@mail.gmail.com>
> -----Original Message-----
> From: Linus Walleij [mailto:linus.walleij@linaro.org]
> Sent: 29 March 2017 04:51
> To: Han, Nandor (GE Healthcare) <nandor.han@ge.com>
> Cc: Alexandre Courbot <gnurou@gmail.com>; Rob Herring <robh+dt@kernel.org>; Mark Rutland
> <mark.rutland@arm.com>; linux-gpio@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: EXT: Re: [PATCH 0/3] XRA1403,gpio - add XRA1403 gpio expander driver
>
<snip>
> Do *NOT* use the sysfs for testing GPIO.
> This is being phased out.
>
> Use the tools in tools/gpio/* so that you exercise the
> character device instead of the old deprecated ABI.
>
Thanks Linus, really good and helpful comments.
I agree that make more sense to test with tools/gpio/*.
> Yours,
> Linus Walleij
^ permalink raw reply
* [PATCH 2/3] of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle
From: Nicholas Piggin @ 2017-04-05 12:37 UTC (permalink / raw)
To: Michael Ellerman, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Nicholas Piggin, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
Benjamin Herrenschmidt, Frank Rowand, Rob Herring
In-Reply-To: <20170405123706.6081-1-npiggin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Introduce primitives for FDT parsing. These will be used for powerpc
cpufeatures node scanning, which has quite complex structure but should
be processed early.
Signed-off-by: Nicholas Piggin <npiggin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/of/fdt.c | 39 +++++++++++++++++++++++++++++++++++++++
include/linux/of_fdt.h | 6 ++++++
2 files changed, 45 insertions(+)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index e5ce4b59e162..a45854fe5156 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -754,6 +754,37 @@ int __init of_scan_flat_dt(int (*it)(unsigned long node,
}
/**
+ * of_scan_flat_dt_subnodes - scan sub-nodes of a node call callback on each.
+ * @it: callback function
+ * @data: context data pointer
+ *
+ * This function is used to scan sub-nodes of a node.
+ */
+int __init of_scan_flat_dt_subnodes(unsigned long node,
+ int (*it)(unsigned long node,
+ const char *uname,
+ void *data),
+ void *data)
+{
+ const void *blob = initial_boot_params;
+ const char *pathp;
+ int offset, rc = 0;
+
+ offset = node;
+ for (offset = fdt_first_subnode(blob, offset);
+ offset >= 0 && !rc;
+ offset = fdt_next_subnode(blob, offset)) {
+
+ pathp = fdt_get_name(blob, offset, NULL);
+ if (*pathp == '/')
+ pathp = kbasename(pathp);
+ rc = it(offset, pathp, data);
+ }
+ return rc;
+}
+
+
+/**
* of_get_flat_dt_subnode_by_name - get the subnode by given name
*
* @node: the parent node
@@ -812,6 +843,14 @@ int __init of_flat_dt_match(unsigned long node, const char *const *compat)
return of_fdt_match(initial_boot_params, node, compat);
}
+/**
+ * of_get_flat_dt_prop - Given a node in the flat blob, return the phandle
+ */
+uint32_t __init of_get_flat_dt_phandle(unsigned long node)
+{
+ return fdt_get_phandle(initial_boot_params, node);
+}
+
struct fdt_scan_status {
const char *name;
int namelen;
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index 271b3fdf0070..1dfbfd0d8040 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -54,6 +54,11 @@ extern char __dtb_end[];
extern int of_scan_flat_dt(int (*it)(unsigned long node, const char *uname,
int depth, void *data),
void *data);
+extern int of_scan_flat_dt_subnodes(unsigned long node,
+ int (*it)(unsigned long node,
+ const char *uname,
+ void *data),
+ void *data);
extern int of_get_flat_dt_subnode_by_name(unsigned long node,
const char *uname);
extern const void *of_get_flat_dt_prop(unsigned long node, const char *name,
@@ -62,6 +67,7 @@ extern int of_flat_dt_is_compatible(unsigned long node, const char *name);
extern int of_flat_dt_match(unsigned long node, const char *const *matches);
extern unsigned long of_get_flat_dt_root(void);
extern int of_get_flat_dt_size(void);
+extern uint32_t of_get_flat_dt_phandle(unsigned long node);
extern int early_init_dt_scan_chosen(unsigned long node, const char *uname,
int depth, void *data);
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox