* Re: [PATCH 1/3] Documentation: dt: Add TI SCI clock driver
From: Rob Herring @ 2016-11-18 17:20 UTC (permalink / raw)
To: Tero Kristo
Cc: linux-clk, Michael Turquette, Stephen Boyd, Santosh Shilimkar,
Nishanth Menon, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org
In-Reply-To: <41c58712-bc00-ed05-9d1d-42e31397a70c@ti.com>
On Mon, Oct 31, 2016 at 7:50 AM, Tero Kristo <t-kristo@ti.com> wrote:
> On 30/10/16 22:41, Rob Herring wrote:
>>
>> On Fri, Oct 21, 2016 at 03:45:59PM +0300, Tero Kristo wrote:
>>>
>>> Add a clock implementation, TI SCI clock, that will hook to the common
>>> clock framework, and allow each clock to be controlled via TI SCI
>>> protocol.
>>>
>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>> ---
>>> .../devicetree/bindings/clock/ti,sci-clk.txt | 37
>>> ++++++++++++++++++++++
>>> MAINTAINERS | 1 +
>>> 2 files changed, 38 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>>> b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>>> new file mode 100644
>>> index 0000000..bfc3ca4
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>>> @@ -0,0 +1,37 @@
>>> +Texas Instruments TI-SCI Clocks
>>> +===============================
>>> +
>>> +All clocks on Texas Instruments' SoCs that contain a System Controller,
>>> +are only controlled by this entity. Communication between a host
>>> processor
>>> +running an OS and the System Controller happens through a protocol known
>>> +as TI-SCI[1]. This clock implementation plugs into the common clock
>>> +framework and makes use of the TI-SCI protocol on clock API requests.
>>> +
>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>> +
>>> +Required properties:
>>> +-------------------
>>> +- compatible: Must be "ti,k2g-sci-clk"
>>> +- #clock-cells: Shall be 2.
>>> + In clock consumers, this cell represents the device ID and clock ID
>>> + exposed by the PM firmware. The assignments can be found in the header
>>> + files <dt-bindings/genpd/<soc>.h> (which covers the device IDs) and
>>> + <dt-bindings/clock/<soc>.h> (which covers the clock IDs), where <soc>
>>> + is the SoC involved, for example 'k2g'.
>>> +
>>> +Examples:
>>> +--------
>>> +
>>> +pmmc: pmmc {
>>> + compatible = "ti,k2g-sci";
>>> +
>>> + k2g_clks: k2g_clks {
>>
>>
>> Use "clocks" for node name instead.
>>
>>> + compatible = "ti,k2g-sci-clk";
>>
>>
>> I'm starting to think all these child nodes for SCI are pointless. Is
>> there any reason why the parent node can't be the clock provider (along
>> with all the other providers it acks as)?
>
>
> I believe the only reason to keep them separate is to have kernel side of
> things modular. If we have separate nodes, the drivers can be probed
> separately.
>
> If not, we need to build one huge blob with all the features in it, so the
> main driver can probe everything in one go, with annoying back-and-forth
> callbacks in place (assuming we still want to keep stuff somehow modular.)
Since when is DT the only way to create a device? The main driver can
create devices for all the sub-functions like clocks. This is the same
as MFDs which have been done both ways.
Rob
^ permalink raw reply
* Re: [PATCH v8] mwifiex: parse device tree node for PCIe
From: Rob Herring @ 2016-11-18 17:06 UTC (permalink / raw)
To: Kalle Valo
Cc: Amitkumar Karwar, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
Cathy Luo, Nishant Sarmukadam, rajatja-hpIqsD4AKlfQT0dZR+AlfA,
briannorris-hpIqsD4AKlfQT0dZR+AlfA,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA, Xinming Hu
In-Reply-To: <87oa1coj1m.fsf-5ukZ45wKbUHoml4zekdYB16hYfS7NtTn@public.gmane.org>
On Fri, Nov 18, 2016 at 06:21:41PM +0200, Kalle Valo wrote:
> Amitkumar Karwar <akarwar-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org> writes:
>
> > From: Xinming Hu <huxm-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
> >
> > This patch derives device tree node from pcie bus layer framework.
> > Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
> > marvell-8xxx.txt) to accommodate PCIe changes.
> >
> > Signed-off-by: Xinming Hu <huxm-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
> > Signed-off-by: Rajat Jain <rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> > Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > Signed-off-by: Amitkumar Karwar <akarwar-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
>
> [...]
>
> > @@ -10,6 +10,8 @@ Required properties:
> > - compatible : should be one of the following:
> > * "marvell,sd8897"
> > * "marvell,sd8997"
> > + * "pci11ab,2b42"
> > + * "pci1b4b,2b42"
>
> Are these correct? In v6 Rob said:
Yes, Marvell has 2 vendor IDs it turns out.
>
> "I think I already said this, but you have the vendor and product IDs
> reversed."
>
> https://patchwork.kernel.org/patch/9390225/
>
> --
> Kalle Valo
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v8] mwifiex: parse device tree node for PCIe
From: Rob Herring @ 2016-11-18 17:06 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Cathy Luo,
Nishant Sarmukadam, rajatja-hpIqsD4AKlfQT0dZR+AlfA,
briannorris-hpIqsD4AKlfQT0dZR+AlfA,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA, Xinming Hu
In-Reply-To: <1479472624-22340-1-git-send-email-akarwar-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
On Fri, Nov 18, 2016 at 06:07:04PM +0530, Amitkumar Karwar wrote:
> From: Xinming Hu <huxm-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
>
> This patch derives device tree node from pcie bus layer framework.
> Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
> marvell-8xxx.txt) to accommodate PCIe changes.
>
> Signed-off-by: Xinming Hu <huxm-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Rajat Jain <rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Amitkumar Karwar <akarwar-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
> ---
> v2: Included vendor and product IDs in compatible strings for PCIe
> chipsets(Rob Herring)
> v3: Patch is created using -M option so that it will only include diff of
> original and renamed files(Rob Herring)
> Resend v3: Resending the patch because I missed to include device tree mailing
> while sending v3.
> v4: Fix error handling, also move-on even if no device tree node is present.
> v5: Update commit log to include memory leak, return -EINVAL instead of -1.
> v6: Remove an unnecessary error print, fix typo in commit log
> v7: a) Earlier versions of this patch claims to have a change which fixes "memory
> leak". But it actually introduces double-free problem. That change is removed
> here(Brian Norris)
> b) Cosmetic change in bindings documentation(Rob Herring)
> s/marvell/Marvell/
> s/sdio\/pcie/SDIO\/PCIE/
> v8: Same as v7. I had missed to CC device tree mailing list in v7. Correcting this
> in v8.
> ---
> .../{marvell-sd8xxx.txt => marvell-8xxx.txt} | 8 +++++---
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> drivers/net/wireless/marvell/mwifiex/pcie.c | 24 ++++++++++++++++++++++
> drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 ++-
> 3 files changed, 31 insertions(+), 4 deletions(-)
> rename Documentation/devicetree/bindings/net/wireless/{marvell-sd8xxx.txt => marvell-8xxx.txt} (91%)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Gabriele Paoloni @ 2016-11-18 17:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com,
benh@kernel.crashing.org, catalin.marinas@arm.com,
liviu.dudau@arm.com, Linuxarm, lorenzo.pieralisi@arm.com,
xuwei (O), Jason Gunthorpe, linux-serial@vger.kernel.org,
linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
minyard@acm.org, will.deacon@arm.com, John Garry, zourongrong@
In-Reply-To: <2364530.A9QSbaqvfm@wuerfel>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: 18 November 2016 16:35
> To: Gabriele Paoloni
> Cc: linux-arm-kernel@lists.infradead.org; mark.rutland@arm.com;
> benh@kernel.crashing.org; catalin.marinas@arm.com; liviu.dudau@arm.com;
> Linuxarm; lorenzo.pieralisi@arm.com; xuwei (O); Jason Gunthorpe; linux-
> serial@vger.kernel.org; linux-pci@vger.kernel.org;
> devicetree@vger.kernel.org; minyard@acm.org; will.deacon@arm.com; John
> Garry; zourongrong@gmail.com; robh+dt@kernel.org; bhelgaas@go og
> le.com; kantyzc@163.com; zhichang.yuan02@gmail.com; T homas Petazzoni;
> linux-kernel@vger.kernel.org; Yuanzhichang; olof@lixom.net
> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> Hip06
>
> On Friday, November 18, 2016 4:18:07 PM CET Gabriele Paoloni wrote:
> > From: Arnd Bergmann [mailto:arnd@arndb.de]
> > > On Friday, November 18, 2016 12:53:08 PM CET Gabriele Paoloni
> wrote:
> > > > From: Arnd Bergmann [mailto:arnd@arndb.de]
> > > > > On Friday, November 18, 2016 12:07:28 PM CET Gabriele Paoloni
> > > > > The easiest change compared to the v5 code would be to walk
> > > > > a linked list of 'struct extio_ops' structures rather than
> > > > > assuming there is only ever one of them. I think one of the
> > > > > earlier versions actually did this.
> > > >
> > > > Right but if my understanding is correct if we live in a multi-
> > > > domain I/O space world when you have an input addr in the I/O
> > > > accessors this addr can be duplicated (for example for the
> standard
> > > > PCI IO domain and for our special LPC domain).
> > > > So effectively even if you walk a linked list there is a problem
> > > > of disambiguation...am I right?
> > >
> > > No, unlike the PCI memory space, the PIO addresses are not
> > > usually distinct, i.e. every PCI bus has its own 64K I/O
> > > addresses starting at zero. We linearize them into the
> > > Linux I/O space using the per-domain io_offset value.
> >
> > I am going to summarize my understanding here below:
> >
> > It seems to me that what is linearized is the virtual address
> > space associated to the IO address space. This address space
> > goes from PCI_IOBASE to (PCI_IOBASE + IO_SPACE_LIMIT).
> >
> > The I/O accessors perform rd/wr operation on this address
> > space using a port IO token.
> >
> > Each token map into a cpu physical address range
> > Each cpu physical address range maps to a bus address range
> > if the bus controller specifies a range property.
> >
> > Devices under a bus controller specify the bus addresses that
> > they operate on in their reg property.
> >
> > So each device can use the same bus addresses under two
> > separate bus controllers as long as the bus controller
> > use the range properties to map the same bus range to different
> > cpu address range.
>
> Sounds all correct to me so far, yes.
>
> > > For the ISA/LPC spaces there are only 4k of addresses, they
> > > the bus addresses always overlap, but we can trivially
> > > figure out the bus address from Linux I/O port number
> > > by subtracting the start of the range.
> >
> > Are you saying that our LPC controller should specify a
> > range property to map bus addresses into a cpu address range?
>
> No. There is not CPU address associated with it, because it's
> not memory mapped.
>
> Instead, we need to associate a bus address with a logical
> Linux port number, both in of_address_to_resource and
> in inb()/outb().
I think this is effectively what we are doing so far with patch 2/3.
The problem with this patch is that we are carving out a "forbidden"
IO tokens range that goes from 0 to PCIBIOS_MIN_IO.
I think that the proper solution would be to have the LPC driver to
set the carveout threshold used in pci_register_io_range(),
pci_pio_to_address(), pci_address_to_pio(), but this would impose
a probe dependency on the LPC itself that should be probed before
the PCI controller (or before any other devices calling these
functions...)
>
> > > > > Another option the IA64 approach mentioned in another subthread
> > > > > today, looking up the operations based on an index from the
> > > > > upper bits of the port number. If we do this, we probably
> > > > > want to do that for all PIO access and replace the entire
> > > > > virtual address remapping logic with that. I think Bjorn
> > > > > in the past argued in favor of such an approach, while I
> > > > > advocated the current scheme for simplicity based on how
> > > > > every I/O space these days is just memory mapped (which now
> > > > > turned out to be false, both on powerpc and arm64).
> > > >
> > > > This seems really complex...I am a bit worried that possibly
> > > > we end up in having the maintainers saying that it is not worth
> > > > to re-invent the world just for this special LPC device...
> > >
> > > It would clearly be a rather invasive change, but the
> > > end-result isn't necessarily more complex than what we
> > > have today, as we'd kill off the crazy pci_pio_to_address()
> > > and pci_address_to_pio() hacks in address translation.
> >
> > I have to look better into this...can you provide me a reference
> > to the Bjorn argument in favor of this approach?
>
> The thread seems to have been pci: Introduce pci_register_io_range()
> helper function, e.g. in https://lkml.org/lkml/2014/7/8/969
Ok many thanks I am going to look at it
>
> > > > To be honest with you I would keep things simple for this
> > > > LPC and introduce more complex reworks later if more devices
> > > > need to be introduced.
> > > >
> > > > What if we stick on a single domain now where we introduce a
> > > > reserved threshold for the IO space (say INDIRECT_MAX_IO).
> > >
> > > I said having a single domain is fine, but I still don't
> > > like the idea of reserving low port numbers for this hack,
> > > it would mean that the numbers change for everyone else.
> >
> > I don't get this much...I/O tokens that are passed to the I/O
> > accessors are not fixed anyway and they vary depending on the order
> > of adding ranges to io_range_list...so I don't see a big issue
> > with this...
>
> On machines with a legacy devices behind the PCI bridge,
> there may still be a reason to have the low I/O port range
> reserved for the primary bus, e.g. to get a VGA text console
> to work.
>
> On powerpc, this is called the "primary" PCI host, i.e. the
> only one that is allowed to have an ISA bridge.
Yes but
1) isn't the PCI controller range property that defines how IO bus address
map into physical CPU addresses?
2) How can you guarantee that the cpu range associated with this
IO bus range is the first to be registered in pci_register_io_range()?
( i.e. are you saying that they are just relying on the fact that it is the
only IO range in the system and by chance the IO tokens and corresponding
bus addresses are the same? )
Thanks
Gab
>
> Arnd
^ permalink raw reply
* Re: [PATCH v3 3/5] i2c: designware: Add slave definitions
From: Rob Herring @ 2016-11-18 17:01 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Luis Oliveira, wsa-z923LK4zBo2bacvFa/9K2g,
mark.rutland-5wv7dgnIgG8, jarkko.nikula-VuQAYsv1563Yd54FQh9/CA,
mika.westerberg-VuQAYsv1563Yd54FQh9/CA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w,
Joao.Pinto-HKixBCOQz3hWk0Htik3J/w,
CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <1479472552.22212.23.camel-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On Fri, Nov 18, 2016 at 02:35:52PM +0200, Andy Shevchenko wrote:
> On Fri, 2016-11-18 at 11:19 +0000, Luis Oliveira wrote:
> > - Add slave defintitions to i2c-designware-core
> > - Changes in Kconfig to auto-enable I2C_SLAVE when compiling the
> > modules
> > - Add compatible string to designware-core.txt explaining the
> > devicetree bindings
> >
>
>
> > --- a/Documentation/devicetree/bindings/i2c/i2c-designware.txt
> > +++ b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
> > @@ -2,7 +2,9 @@
> >
> > Required properties :
> >
> > - - compatible : should be "snps,designware-i2c"
> > + - compatible : should be:
> > + - "snps,designware-i2c" to setup the hardware block as I2C master.
> > + - "snps,designware-i2c-slave" to setup the hardware block as I2C
> > slave.
>
> Not sure about this one.
>
> Compatible string is more generic than list of modes. Basically you have
> to add a property which selects mode.
Yes, agreed. And come up with a common property.
> DT people's ACK is a must for this change.
>
>
> --- a/drivers/i2c/busses/Kconfig
> > +++ b/drivers/i2c/busses/Kconfig
> > @@ -470,6 +470,7 @@ config I2C_DESIGNWARE_CORE
> > config I2C_DESIGNWARE_PLATFORM
> > tristate "Synopsys DesignWare Platform"
> > select I2C_DESIGNWARE_CORE
> > + select I2C_SLAVE
> >
>
> Common rule, generic dependencies usually go first
>
> select I2C_SLAVE
> select I2C_DESIGNWARE_CORE
>
> --
> Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH v2 1/7] dt-bindings: document devicetree bindings for mux-gpio
From: Peter Rosin @ 2016-11-18 16:59 UTC (permalink / raw)
To: Rob Herring
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang, Mark Rutland,
Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Arnd Bergmann, Greg Kroah-Hartman,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161118153528.tl24bp5xjwpjppk6@rob-hp-laptop>
On 2016-11-18 16:35, Rob Herring wrote:
> On Thu, Nov 17, 2016 at 10:48:03PM +0100, Peter Rosin wrote:
>> ---
>> .../devicetree/bindings/misc/mux-gpio.txt | 79 ++++++++++++++++++++++
>> 1 file changed, 79 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/misc/mux-gpio.txt
>>
>> diff --git a/Documentation/devicetree/bindings/misc/mux-gpio.txt b/Documentation/devicetree/bindings/misc/mux-gpio.txt
>> new file mode 100644
>> index 000000000000..73699a37824f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/misc/mux-gpio.txt
>> @@ -0,0 +1,79 @@
>> +GPIO-based multiplexer controller bindings
>> +
>> +Define what GPIO pins are used to control a multiplexer. Or several
>> +multiplexers, if the same pins control more than one multiplexer.
>
> I think this makes sense in your case, but I think it is too complicated
> for a non-shared case. Perhaps mux-gpios should be used directly (i.e.
> in the adc-mux node) and control-muxes only used for the shared case.
>
> Part of me feels like you are working around in DT the GPIO subsystem
> limitation that it can't share GPIO lines. Either this could be fixed
> in some way in the GPIO subsystem, or the mux subsys could deal with it.
> You just have to look up if you already have a mux registered for the
> same GPIOs. Of course, that may make the mux subsys pretty much GPIO
> only, but I'm having a hard time thinking how you would have shared
> muxes that are not GPIO controlled. Any other control would be
> integrated into the mux itself.
But if someone wants to mux an adc line with a mux that is some kind of
integrated i2c device, you'd have to add extra code to the iio muxer
driver to handle that case. Or fork it. Or build something like the
i2c muxer infrastructure and separate out the mux control in small
drivers and handle the generic iio muxing centrally. But then someone
else uses that i2c device to instead mux an i2c bus, and you'd end up
with code duplication when that same muxer control code is added under
drivers/i2c/muxes.
With the proposed solution, this is unified.
I'd just hate to see drivers for muxers added under drivers/i2c/muxes
that do little more that control a mux that happens to be used to mux
an i2c bus, but are generic muxers that could equally well mux something
else. Even if the control is integrated into the mux, what the mux is
actually used for should perhaps not determine where its driver should
live.
Anyway, I don't know what to make with your suggestion, I just don't
see the path forward (not enough experience with the kernel and/or gpio
code). And it would be a limited solution (GPIO only,a s you say) so it
doesn't feel right.
Is there perhaps some way to keep the complicated shared case work as
is (or equivalently, the exact details are not important), and also
provide a simpler in-node thingy to glue a mux control to a consumer
w/o pointing to it with a phandle, but still have the same mux driver
handle both cases? No, I'm not a devicetree guru, so I don't see a
solution for that either, but maybe someone else does?
Perhaps the consumer could look for the mux control in first the
phandle, as in my proposal. If not found, it could also look for
a mux provider bound to child node.
adc-mux {
compatible = "iio-mux";
io-channels = <&adc 0>;
io-channel-names = "parent";
mux-control {
compatible = "mux-gpio";
mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
<&pioA 1 GPIO_ACTIVE_HIGH>;
};
#address-cells = <1>;
#size-cells = <0>;
sync-1@0 {
reg = <0>;
};
/* ... */
};
Or perhaps look in a parent node:
mux-control {
compatible = "mux-gpio";
mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
<&pioA 1 GPIO_ACTIVE_HIGH>;
adc-mux {
compatible = "iio-mux";
io-channels = <&adc 0>;
io-channel-names = "parent";
#address-cells = <1>;
#size-cells = <0>;
sync-1@0 {
reg = <0>;
};
/* ... */
};
};
With the last suggestion, you could have multiple children of the
mux-control node for the complicated case where it controls more
than one mux. Not too bad? Hmm, what does the driver for the
mux-control node have to do to have drivers tied to its children?
Maybe this last layout should be the only thing supported? Good
enough for me anyway...
Cheers,
Peter
PS. I will take care of the other comments for the next round.
^ permalink raw reply
* [PATCH v2 2/2] DW DMAC: add multi-block property to device tree
From: Eugeniy Paltsev @ 2016-11-18 16:53 UTC (permalink / raw)
To: devicetree
Cc: robh+dt, mark.rutland, linux-kernel, andriy.shevchenko,
vinod.koul, dmaengine, linux-snps-arc, Eugeniy Paltsev
In-Reply-To: <1479487989-24543-1-git-send-email-Eugeniy.Paltsev@synopsys.com>
Several versions of DW DMAC have multi block transfers hardware
support. Hardware support of multi block transfers is disabled
by default if we use DT to configure DMAC and software emulation
of multi block transfers used instead.
Add multi-block property, so it is possible to enable hardware
multi block transfers (if present) via DT.
Switch from per device is_nollp variable to multi_block array
to be able enable/disable multi block transfers separately per
channel.
Update DT documentation.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
---
Documentation/devicetree/bindings/dma/snps-dma.txt | 2 ++
drivers/dma/dw/core.c | 2 +-
drivers/dma/dw/platform.c | 5 +++++
include/linux/platform_data/dma-dw.h | 4 ++--
4 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
index 0f55832..03d6d6d 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -27,6 +27,8 @@ Optional properties:
that services interrupts for this device
- is_private: The device channels should be marked as private and not for by the
general purpose DMA channel allocator. False if not passed.
+- multi-block: Multi block transfers supported by hardware per AHB master.
+ 0 (default): not supported, 1: supported.
Example:
diff --git a/drivers/dma/dw/core.c b/drivers/dma/dw/core.c
index c2c0a61..f2a3d06 100644
--- a/drivers/dma/dw/core.c
+++ b/drivers/dma/dw/core.c
@@ -1569,7 +1569,7 @@ int dw_dma_probe(struct dw_dma_chip *chip)
(dwc_params >> DWC_PARAMS_MBLK_EN & 0x1) == 0;
} else {
dwc->block_size = pdata->block_size;
- dwc->nollp = pdata->is_nollp;
+ dwc->nollp = pdata->multi_block[i];
}
}
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index aa7a5c1..b262fd3 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -152,6 +152,11 @@ dw_dma_parse_dt(struct platform_device *pdev)
pdata->data_width[tmp] = BIT(arr[tmp] & 0x07);
}
+ if (!of_property_read_u32_array(np, "multi-block", arr, nr_masters)) {
+ for (tmp = 0; tmp < nr_masters; tmp++)
+ pdata->multi_block[tmp] = arr[tmp];
+ }
+
return pdata;
}
#else
diff --git a/include/linux/platform_data/dma-dw.h b/include/linux/platform_data/dma-dw.h
index 5f0e11e..0773bb4 100644
--- a/include/linux/platform_data/dma-dw.h
+++ b/include/linux/platform_data/dma-dw.h
@@ -40,19 +40,18 @@ struct dw_dma_slave {
* @is_private: The device channels should be marked as private and not for
* by the general purpose DMA channel allocator.
* @is_memcpy: The device channels do support memory-to-memory transfers.
- * @is_nollp: The device channels does not support multi block transfers.
* @chan_allocation_order: Allocate channels starting from 0 or 7
* @chan_priority: Set channel priority increasing from 0 to 7 or 7 to 0.
* @block_size: Maximum block size supported by the controller
* @nr_masters: Number of AHB masters supported by the controller
* @data_width: Maximum data width supported by hardware per AHB master
* (in bytes, power of 2)
+ * @multi_block: Multi block transfers supported by hardware per AHB master.
*/
struct dw_dma_platform_data {
unsigned int nr_channels;
bool is_private;
bool is_memcpy;
- bool is_nollp;
#define CHAN_ALLOCATION_ASCENDING 0 /* zero to seven */
#define CHAN_ALLOCATION_DESCENDING 1 /* seven to zero */
unsigned char chan_allocation_order;
@@ -62,6 +61,7 @@ struct dw_dma_platform_data {
unsigned int block_size;
unsigned char nr_masters;
unsigned char data_width[DW_DMA_MAX_NR_MASTERS];
+ unsigned char multi_block[DW_DMA_MAX_NR_MASTERS];
};
#endif /* _PLATFORM_DATA_DMA_DW_H */
--
2.5.5
^ permalink raw reply related
* [PATCH v2 1/2] DW DMAC: enable memory-to-memory transfers support
From: Eugeniy Paltsev @ 2016-11-18 16:53 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Eugeniy Paltsev
In-Reply-To: <1479487989-24543-1-git-send-email-Eugeniy.Paltsev-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
All known devices, which use DT for configuration, support
memory-to-memory transfers. So enable it by default, if we read
configuration from DT.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
---
drivers/dma/dw/platform.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c
index 5bda0eb..aa7a5c1 100644
--- a/drivers/dma/dw/platform.c
+++ b/drivers/dma/dw/platform.c
@@ -129,6 +129,12 @@ dw_dma_parse_dt(struct platform_device *pdev)
if (of_property_read_bool(np, "is_private"))
pdata->is_private = true;
+ /*
+ * All known devices, which use DT for configuration, support
+ * memory-to-memory transfers. So enable it by default.
+ */
+ pdata->is_memcpy = true;
+
if (!of_property_read_u32(np, "chan_allocation_order", &tmp))
pdata->chan_allocation_order = (unsigned char)tmp;
--
2.5.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 0/2] DW DMAC: update device tree
From: Eugeniy Paltsev @ 2016-11-18 16:53 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Eugeniy Paltsev
It wasn't possible to enable some features like
memory-to-memory transfers or multi block transfers via DT.
It is fixed by these patches.
Changes for v2:
* I thought about is_memcpy DT property: all known devices, which
use DT for configuration, support memory-to-memory transfers.
So we don't need to read it from DT. So enable it by default,
if we read configuration from DT.
* Use "multi-block" instead of "hw-llp" name to be more clear.
* Move adding DT property and adding documentation for this
property to one patch.
Eugeniy Paltsev (2):
DW DMAC: enable memory-to-memory transfers support
DW DMAC: add multi-block property to device tree
Documentation/devicetree/bindings/dma/snps-dma.txt | 2 ++
drivers/dma/dw/core.c | 2 +-
drivers/dma/dw/platform.c | 11 +++++++++++
include/linux/platform_data/dma-dw.h | 4 ++--
4 files changed, 16 insertions(+), 3 deletions(-)
--
2.5.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 6/6] ARM: dts: am57xx-beagle-x15-common: enable etnaviv
From: Rob Herring @ 2016-11-18 16:42 UTC (permalink / raw)
To: Nishanth Menon
Cc: Robert Nelson, tony-4v6yS6AI5VpBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Julien,
Tomi Valkeinen
In-Reply-To: <e69a797c-bec3-2243-5c19-9d7633092369-l0cyMroinI0@public.gmane.org>
On Thu, Nov 17, 2016 at 08:56:18PM -0600, Nishanth Menon wrote:
> On 11/17/2016 08:44 PM, Robert Nelson wrote:
> again.. a short commit message at least please? :)
>
> > Signed-off-by: Robert Nelson <robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > CC: Julien <jboulnois-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > CC: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
> > CC: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
> > CC: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> > ---
> > arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
> > index 6df7829..3bc47be 100644
> > --- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
> > +++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
> > @@ -97,6 +97,12 @@
> > #cooling-cells = <2>;
> > };
> >
> > + gpu-subsystem {
> A) do we want to make things clear that this is gpu subsystem for gc320?
No.
> B) How about other platforms that could equally reuse?
Better yet, get rid of this nonsense. You are defining a wrapper to
group 1 nodes. Yes, I know this is what the driver wants, but you should
be able to make it deal with this situation and only have a gc320 node.
> > + compatible = "ti,gc320-gpu-subsystem";
> > + cores = <&bb2d>;
> > + status = "okay";
> > + };
> > +
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver
From: Bjorn Andersson @ 2016-11-18 16:40 UTC (permalink / raw)
To: Vinod Koul
Cc: Peter Griffin, linux-arm-kernel, linux-kernel, kernel, ohad,
patrice.chotard, lee.jones, dmaengine, devicetree,
linux-remoteproc
In-Reply-To: <20161117095252.GC2698@localhost>
On Thu 17 Nov 01:52 PST 2016, Vinod Koul wrote:
> On Wed, Nov 16, 2016 at 10:36:46PM -0800, Bjorn Andersson wrote:
> > On Sun 13 Nov 21:18 PST 2016, Vinod Koul wrote:
> >
> > > On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote:
> > > > >
> > > > > As you now make changes to the entire remoteproc Kconfig file, rather
> > > > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> > > > > without providing Linus with a messy merge conflict.
> > > > >
> > > > > So the remoteproc parts now has to go through my tree.
> > > >
> > > > OK, I think the best approach is for Vinod to create an immutable
> > > > branch with the entire fdma series on, and then both of you merge that branch into
> > > > your respective trees.
> > >
> > > my topic/st_fdma is immutable branch. You cna merge it, if you need a signed
> > > tag, please do let me know
> > >
> >
> > Hi Vinod,
> >
> > It looks like you reverted the wrong Kconfig fix, the one I objected to
> > was the change in drivers/remoteproc, not the one in drivers/dma.
> >
> > The ST_FMDA depends on functions exposed by REMOTEPROC and
> > ST_SLIM_REMOTEPROC, the latter in turn depends on REMOTEPROC, which you
> > guys made user selectable - and as such should not be selected - but I
> > think we should move forward and get everything merged and then we can
> > go back and figure out how this should be addressed (or left alone?).
> >
> > I have merged "topic/st_fdma" into rproc-next, so that I can fix up the
> > now broken drivers/remoteproc/Kconfig.
> >
> > We do however both need to revert the revert or there will be link
> > errors if you build the dma driver with remoteproc=n. If you do this I
> > can merge the topic once more and we'll keep the set of changes in sync.
>
> Oops my bad, thanks for letting me know. I have reverted this now and
> pushing out. Please do let me know if this was fine
>
Thanks for the update Vinod, I've merged in your updated branch into
mine, so now we should be good.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-11-18 16:34 UTC (permalink / raw)
To: Gabriele Paoloni
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org,
catalin.marinas-5wv7dgnIgG8@public.gmane.org,
liviu.dudau-5wv7dgnIgG8@public.gmane.org, Linuxarm,
lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org, xuwei (O),
Jason Gunthorpe,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
minyard-HInyCGIudOg@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org, John Garry, zourongrong
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F921858@lhreml507-mbx>
On Friday, November 18, 2016 4:18:07 PM CET Gabriele Paoloni wrote:
> From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> > On Friday, November 18, 2016 12:53:08 PM CET Gabriele Paoloni wrote:
> > > From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> > > > On Friday, November 18, 2016 12:07:28 PM CET Gabriele Paoloni
> > > > The easiest change compared to the v5 code would be to walk
> > > > a linked list of 'struct extio_ops' structures rather than
> > > > assuming there is only ever one of them. I think one of the
> > > > earlier versions actually did this.
> > >
> > > Right but if my understanding is correct if we live in a multi-
> > > domain I/O space world when you have an input addr in the I/O
> > > accessors this addr can be duplicated (for example for the standard
> > > PCI IO domain and for our special LPC domain).
> > > So effectively even if you walk a linked list there is a problem
> > > of disambiguation...am I right?
> >
> > No, unlike the PCI memory space, the PIO addresses are not
> > usually distinct, i.e. every PCI bus has its own 64K I/O
> > addresses starting at zero. We linearize them into the
> > Linux I/O space using the per-domain io_offset value.
>
> I am going to summarize my understanding here below:
>
> It seems to me that what is linearized is the virtual address
> space associated to the IO address space. This address space
> goes from PCI_IOBASE to (PCI_IOBASE + IO_SPACE_LIMIT).
>
> The I/O accessors perform rd/wr operation on this address
> space using a port IO token.
>
> Each token map into a cpu physical address range
> Each cpu physical address range maps to a bus address range
> if the bus controller specifies a range property.
>
> Devices under a bus controller specify the bus addresses that
> they operate on in their reg property.
>
> So each device can use the same bus addresses under two
> separate bus controllers as long as the bus controller
> use the range properties to map the same bus range to different
> cpu address range.
Sounds all correct to me so far, yes.
> > For the ISA/LPC spaces there are only 4k of addresses, they
> > the bus addresses always overlap, but we can trivially
> > figure out the bus address from Linux I/O port number
> > by subtracting the start of the range.
>
> Are you saying that our LPC controller should specify a
> range property to map bus addresses into a cpu address range?
No. There is not CPU address associated with it, because it's
not memory mapped.
Instead, we need to associate a bus address with a logical
Linux port number, both in of_address_to_resource and
in inb()/outb().
> > > > Another option the IA64 approach mentioned in another subthread
> > > > today, looking up the operations based on an index from the
> > > > upper bits of the port number. If we do this, we probably
> > > > want to do that for all PIO access and replace the entire
> > > > virtual address remapping logic with that. I think Bjorn
> > > > in the past argued in favor of such an approach, while I
> > > > advocated the current scheme for simplicity based on how
> > > > every I/O space these days is just memory mapped (which now
> > > > turned out to be false, both on powerpc and arm64).
> > >
> > > This seems really complex...I am a bit worried that possibly
> > > we end up in having the maintainers saying that it is not worth
> > > to re-invent the world just for this special LPC device...
> >
> > It would clearly be a rather invasive change, but the
> > end-result isn't necessarily more complex than what we
> > have today, as we'd kill off the crazy pci_pio_to_address()
> > and pci_address_to_pio() hacks in address translation.
>
> I have to look better into this...can you provide me a reference
> to the Bjorn argument in favor of this approach?
The thread seems to have been pci: Introduce pci_register_io_range()
helper function, e.g. in https://lkml.org/lkml/2014/7/8/969
> > > To be honest with you I would keep things simple for this
> > > LPC and introduce more complex reworks later if more devices
> > > need to be introduced.
> > >
> > > What if we stick on a single domain now where we introduce a
> > > reserved threshold for the IO space (say INDIRECT_MAX_IO).
> >
> > I said having a single domain is fine, but I still don't
> > like the idea of reserving low port numbers for this hack,
> > it would mean that the numbers change for everyone else.
>
> I don't get this much...I/O tokens that are passed to the I/O
> accessors are not fixed anyway and they vary depending on the order
> of adding ranges to io_range_list...so I don't see a big issue
> with this...
On machines with a legacy devices behind the PCI bridge,
there may still be a reason to have the low I/O port range
reserved for the primary bus, e.g. to get a VGA text console
to work.
On powerpc, this is called the "primary" PCI host, i.e. the
only one that is allowed to have an ISA bridge.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC 2/6] drm/etnaviv: allow building etnaviv on omap devices
From: Rob Herring @ 2016-11-18 16:33 UTC (permalink / raw)
To: Robert Nelson
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Christian Gmeiner, Russell King, Lucas Stach
In-Reply-To: <20161118024436.13447-2-robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Nov 17, 2016 at 08:44:32PM -0600, Robert Nelson wrote:
> Signed-off-by: Robert Nelson <robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Christian Gmeiner <christian.gmeiner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> CC: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> ---
> drivers/gpu/drm/etnaviv/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
> index 2cde7a5..b776f41 100644
> --- a/drivers/gpu/drm/etnaviv/Kconfig
> +++ b/drivers/gpu/drm/etnaviv/Kconfig
> @@ -2,7 +2,7 @@
> config DRM_ETNAVIV
> tristate "ETNAVIV (DRM support for Vivante GPU IP cores)"
> depends on DRM
> - depends on ARCH_MXC || ARCH_DOVE
> + depends on ARCH_MXC || ARCH_DOVE || ARCH_OMAP2PLUS
Why not just drop this line. Then it will get better build testing, too.
> select SHMEM
> select TMPFS
> select IOMMU_API
> --
> 2.10.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] clk: qcom: smd-rpmcc: Add msm8974 clocks
From: Bjorn Andersson @ 2016-11-18 16:33 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: linux-clk, devicetree, linux-kernel, linux-arm-msm, linux-soc,
Georgi Djakov
This adds all RPM based clocks for msm8974, except cxo and
gfx3d_clk_src.
Tested-by: Georgi Djakov <georgi.djakov@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Changes since v1:
- Fixed the screwed up indentation
.../devicetree/bindings/clock/qcom,rpmcc.txt | 1 +
drivers/clk/qcom/clk-smd-rpm.c | 71 ++++++++++++++++++++++
include/dt-bindings/clock/qcom,rpmcc.h | 40 +++++++++++-
3 files changed, 110 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
index 87d3714b956a..a7235e9e1c97 100644
--- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
@@ -11,6 +11,7 @@ Required properties :
compatible "qcom,rpmcc" should be also included.
"qcom,rpmcc-msm8916", "qcom,rpmcc"
+ "qcom,rpmcc-msm8974", "qcom,rpmcc"
"qcom,rpmcc-apq8064", "qcom,rpmcc"
- #clock-cells : shall contain 1
diff --git a/drivers/clk/qcom/clk-smd-rpm.c b/drivers/clk/qcom/clk-smd-rpm.c
index a27013dbc0aa..c1c1e7b5be64 100644
--- a/drivers/clk/qcom/clk-smd-rpm.c
+++ b/drivers/clk/qcom/clk-smd-rpm.c
@@ -462,8 +462,79 @@ static const struct rpm_smd_clk_desc rpm_clk_msm8916 = {
.num_clks = ARRAY_SIZE(msm8916_clks),
};
+/* msm8974 */
+DEFINE_CLK_SMD_RPM(msm8974, pnoc_clk, pnoc_a_clk, QCOM_SMD_RPM_BUS_CLK, 0);
+DEFINE_CLK_SMD_RPM(msm8974, snoc_clk, snoc_a_clk, QCOM_SMD_RPM_BUS_CLK, 1);
+DEFINE_CLK_SMD_RPM(msm8974, cnoc_clk, cnoc_a_clk, QCOM_SMD_RPM_BUS_CLK, 2);
+DEFINE_CLK_SMD_RPM(msm8974, mmssnoc_ahb_clk, mmssnoc_ahb_a_clk, QCOM_SMD_RPM_BUS_CLK, 3);
+DEFINE_CLK_SMD_RPM(msm8974, bimc_clk, bimc_a_clk, QCOM_SMD_RPM_MEM_CLK, 0);
+DEFINE_CLK_SMD_RPM(msm8974, gfx3d_clk_src, gfx3d_a_clk_src, QCOM_SMD_RPM_MEM_CLK, 1);
+DEFINE_CLK_SMD_RPM(msm8974, ocmemgx_clk, ocmemgx_a_clk, QCOM_SMD_RPM_MEM_CLK, 2);
+DEFINE_CLK_SMD_RPM_QDSS(msm8974, qdss_clk, qdss_a_clk, QCOM_SMD_RPM_MISC_CLK, 1);
+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, cxo_d0, cxo_d0_a, 1);
+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, cxo_d1, cxo_d1_a, 2);
+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, cxo_a0, cxo_a0_a, 4);
+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, cxo_a1, cxo_a1_a, 5);
+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, cxo_a2, cxo_a2_a, 6);
+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, diff_clk, diff_a_clk, 7);
+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, div_clk1, div_a_clk1, 11);
+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, div_clk2, div_a_clk2, 12);
+DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(msm8974, cxo_d0_pin, cxo_d0_a_pin, 1);
+DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(msm8974, cxo_d1_pin, cxo_d1_a_pin, 2);
+DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(msm8974, cxo_a0_pin, cxo_a0_a_pin, 4);
+DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(msm8974, cxo_a1_pin, cxo_a1_a_pin, 5);
+DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(msm8974, cxo_a2_pin, cxo_a2_a_pin, 6);
+
+static struct clk_smd_rpm *msm8974_clks[] = {
+ [RPM_SMD_PNOC_CLK] = &msm8974_pnoc_clk,
+ [RPM_SMD_PNOC_A_CLK] = &msm8974_pnoc_a_clk,
+ [RPM_SMD_SNOC_CLK] = &msm8974_snoc_clk,
+ [RPM_SMD_SNOC_A_CLK] = &msm8974_snoc_a_clk,
+ [RPM_SMD_CNOC_CLK] = &msm8974_cnoc_clk,
+ [RPM_SMD_CNOC_A_CLK] = &msm8974_cnoc_a_clk,
+ [RPM_SMD_MMSSNOC_AHB_CLK] = &msm8974_mmssnoc_ahb_clk,
+ [RPM_SMD_MMSSNOC_AHB_A_CLK] = &msm8974_mmssnoc_ahb_a_clk,
+ [RPM_SMD_BIMC_CLK] = &msm8974_bimc_clk,
+ [RPM_SMD_BIMC_A_CLK] = &msm8974_bimc_a_clk,
+ [RPM_SMD_OCMEMGX_CLK] = &msm8974_ocmemgx_clk,
+ [RPM_SMD_OCMEMGX_A_CLK] = &msm8974_ocmemgx_a_clk,
+ [RPM_SMD_QDSS_CLK] = &msm8974_qdss_clk,
+ [RPM_SMD_QDSS_A_CLK] = &msm8974_qdss_a_clk,
+ [RPM_SMD_CXO_D0] = &msm8974_cxo_d0,
+ [RPM_SMD_CXO_D0_A] = &msm8974_cxo_d0_a,
+ [RPM_SMD_CXO_D1] = &msm8974_cxo_d1,
+ [RPM_SMD_CXO_D1_A] = &msm8974_cxo_d1_a,
+ [RPM_SMD_CXO_A0] = &msm8974_cxo_a0,
+ [RPM_SMD_CXO_A0_A] = &msm8974_cxo_a0_a,
+ [RPM_SMD_CXO_A1] = &msm8974_cxo_a1,
+ [RPM_SMD_CXO_A1_A] = &msm8974_cxo_a1_a,
+ [RPM_SMD_CXO_A2] = &msm8974_cxo_a2,
+ [RPM_SMD_CXO_A2_A] = &msm8974_cxo_a2_a,
+ [RPM_SMD_DIFF_CLK] = &msm8974_diff_clk,
+ [RPM_SMD_DIFF_A_CLK] = &msm8974_diff_a_clk,
+ [RPM_SMD_DIV_CLK1] = &msm8974_div_clk1,
+ [RPM_SMD_DIV_A_CLK1] = &msm8974_div_a_clk1,
+ [RPM_SMD_DIV_CLK2] = &msm8974_div_clk2,
+ [RPM_SMD_DIV_A_CLK2] = &msm8974_div_a_clk2,
+ [RPM_SMD_CXO_D0_PIN] = &msm8974_cxo_d0_pin,
+ [RPM_SMD_CXO_D0_A_PIN] = &msm8974_cxo_d0_a_pin,
+ [RPM_SMD_CXO_D1_PIN] = &msm8974_cxo_d1_pin,
+ [RPM_SMD_CXO_D1_A_PIN] = &msm8974_cxo_d1_a_pin,
+ [RPM_SMD_CXO_A0_PIN] = &msm8974_cxo_a0_pin,
+ [RPM_SMD_CXO_A0_A_PIN] = &msm8974_cxo_a0_a_pin,
+ [RPM_SMD_CXO_A1_PIN] = &msm8974_cxo_a1_pin,
+ [RPM_SMD_CXO_A1_A_PIN] = &msm8974_cxo_a1_a_pin,
+ [RPM_SMD_CXO_A2_PIN] = &msm8974_cxo_a2_pin,
+ [RPM_SMD_CXO_A2_A_PIN] = &msm8974_cxo_a2_a_pin,
+};
+
+static const struct rpm_smd_clk_desc rpm_clk_msm8974 = {
+ .clks = msm8974_clks,
+ .num_clks = ARRAY_SIZE(msm8974_clks),
+};
static const struct of_device_id rpm_smd_clk_match_table[] = {
{ .compatible = "qcom,rpmcc-msm8916", .data = &rpm_clk_msm8916 },
+ { .compatible = "qcom,rpmcc-msm8974", .data = &rpm_clk_msm8974 },
{ }
};
MODULE_DEVICE_TABLE(of, rpm_smd_clk_match_table);
diff --git a/include/dt-bindings/clock/qcom,rpmcc.h b/include/dt-bindings/clock/qcom,rpmcc.h
index 5924cdb71336..96b63c00249e 100644
--- a/include/dt-bindings/clock/qcom,rpmcc.h
+++ b/include/dt-bindings/clock/qcom,rpmcc.h
@@ -14,7 +14,7 @@
#ifndef _DT_BINDINGS_CLK_MSM_RPMCC_H
#define _DT_BINDINGS_CLK_MSM_RPMCC_H
-/* apq8064 */
+/* RPM clocks */
#define RPM_PXO_CLK 0
#define RPM_PXO_A_CLK 1
#define RPM_CXO_CLK 2
@@ -38,7 +38,7 @@
#define RPM_SFPB_CLK 20
#define RPM_SFPB_A_CLK 21
-/* msm8916 */
+/* SMD RPM clocks */
#define RPM_SMD_XO_CLK_SRC 0
#define RPM_SMD_XO_A_CLK_SRC 1
#define RPM_SMD_PCNOC_CLK 2
@@ -65,5 +65,41 @@
#define RPM_SMD_RF_CLK1_A_PIN 23
#define RPM_SMD_RF_CLK2_PIN 24
#define RPM_SMD_RF_CLK2_A_PIN 25
+#define RPM_SMD_PNOC_CLK 26
+#define RPM_SMD_PNOC_A_CLK 27
+#define RPM_SMD_CNOC_CLK 28
+#define RPM_SMD_CNOC_A_CLK 29
+#define RPM_SMD_MMSSNOC_AHB_CLK 30
+#define RPM_SMD_MMSSNOC_AHB_A_CLK 31
+#define RPM_SMD_GFX3D_CLK_SRC 32
+#define RPM_SMD_GFX3D_A_CLK_SRC 33
+#define RPM_SMD_OCMEMGX_CLK 34
+#define RPM_SMD_OCMEMGX_A_CLK 35
+#define RPM_SMD_CXO_D0 36
+#define RPM_SMD_CXO_D0_A 37
+#define RPM_SMD_CXO_D1 38
+#define RPM_SMD_CXO_D1_A 39
+#define RPM_SMD_CXO_A0 40
+#define RPM_SMD_CXO_A0_A 41
+#define RPM_SMD_CXO_A1 42
+#define RPM_SMD_CXO_A1_A 43
+#define RPM_SMD_CXO_A2 44
+#define RPM_SMD_CXO_A2_A 45
+#define RPM_SMD_DIV_CLK1 46
+#define RPM_SMD_DIV_A_CLK1 47
+#define RPM_SMD_DIV_CLK2 48
+#define RPM_SMD_DIV_A_CLK2 49
+#define RPM_SMD_DIFF_CLK 50
+#define RPM_SMD_DIFF_A_CLK 51
+#define RPM_SMD_CXO_D0_PIN 52
+#define RPM_SMD_CXO_D0_A_PIN 53
+#define RPM_SMD_CXO_D1_PIN 54
+#define RPM_SMD_CXO_D1_A_PIN 55
+#define RPM_SMD_CXO_A0_PIN 56
+#define RPM_SMD_CXO_A0_A_PIN 57
+#define RPM_SMD_CXO_A1_PIN 58
+#define RPM_SMD_CXO_A1_A_PIN 59
+#define RPM_SMD_CXO_A2_PIN 60
+#define RPM_SMD_CXO_A2_A_PIN 61
#endif
--
2.5.0
^ permalink raw reply related
* Re: [PATCH] clk: qcom: smd-rpm: Add msm8974 clocks
From: Bjorn Andersson @ 2016-11-18 16:32 UTC (permalink / raw)
To: Georgi Djakov
Cc: Michael Turquette, Stephen Boyd, linux-clk, devicetree,
linux-kernel, linux-arm-msm, linux-soc
In-Reply-To: <3c57fe94-e6b3-d884-9c80-aa26e5ef9fde@linaro.org>
On Thu 17 Nov 07:53 PST 2016, Georgi Djakov wrote:
> On 11/15/2016 08:54 AM, Bjorn Andersson wrote:
> >This adds all RPM based clocks for msm8974 except cxo and gfx3d_clk_src.
> >
> >Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> >---
> > .../devicetree/bindings/clock/qcom,rpmcc.txt | 1 +
> > drivers/clk/qcom/clk-smd-rpm.c | 71 ++++++++++++++++++++++
> > include/dt-bindings/clock/qcom,rpmcc.h | 40 +++++++++++-
> > 3 files changed, 110 insertions(+), 2 deletions(-)
> >
> >diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
> >index 87d3714b956a..a7235e9e1c97 100644
> >--- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
> >+++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
> >@@ -11,6 +11,7 @@ Required properties :
> > compatible "qcom,rpmcc" should be also included.
> >
> > "qcom,rpmcc-msm8916", "qcom,rpmcc"
> >+ "qcom,rpmcc-msm8974", "qcom,rpmcc"
> > "qcom,rpmcc-apq8064", "qcom,rpmcc"
> >
> > - #clock-cells : shall contain 1
> >diff --git a/drivers/clk/qcom/clk-smd-rpm.c b/drivers/clk/qcom/clk-smd-rpm.c
> >index a27013dbc0aa..b8fcac6f2f87 100644
> >--- a/drivers/clk/qcom/clk-smd-rpm.c
> >+++ b/drivers/clk/qcom/clk-smd-rpm.c
> >@@ -462,8 +462,79 @@ static const struct rpm_smd_clk_desc rpm_clk_msm8916 = {
> > .num_clks = ARRAY_SIZE(msm8916_clks),
> > };
> >
> >+/* msm8974 */
> >+DEFINE_CLK_SMD_RPM(msm8974, pnoc_clk, pnoc_a_clk, QCOM_SMD_RPM_BUS_CLK, 0);
> >+DEFINE_CLK_SMD_RPM(msm8974, snoc_clk, snoc_a_clk, QCOM_SMD_RPM_BUS_CLK, 1);
> >+DEFINE_CLK_SMD_RPM(msm8974, cnoc_clk, cnoc_a_clk, QCOM_SMD_RPM_BUS_CLK, 2);
> >+DEFINE_CLK_SMD_RPM(msm8974, mmssnoc_ahb_clk, mmssnoc_ahb_a_clk, QCOM_SMD_RPM_BUS_CLK, 3);
> >+DEFINE_CLK_SMD_RPM(msm8974, bimc_clk, bimc_a_clk, QCOM_SMD_RPM_MEM_CLK, 0);
> >+DEFINE_CLK_SMD_RPM(msm8974, gfx3d_clk_src, gfx3d_a_clk_src, QCOM_SMD_RPM_MEM_CLK, 1);
> >+DEFINE_CLK_SMD_RPM(msm8974, ocmemgx_clk, ocmemgx_a_clk, QCOM_SMD_RPM_MEM_CLK, 2);
> >+DEFINE_CLK_SMD_RPM_QDSS(msm8974, qdss_clk, qdss_a_clk, QCOM_SMD_RPM_MISC_CLK, 1);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, cxo_d0, cxo_d0_a, 1);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, cxo_d1, cxo_d1_a, 2);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, cxo_a0, cxo_a0_a, 4);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, cxo_a1, cxo_a1_a, 5);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, cxo_a2, cxo_a2_a, 6);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, diff_clk, diff_a_clk, 7);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, div_clk1, div_a_clk1, 11);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, div_clk2, div_a_clk2, 12);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(msm8974, cxo_d0_pin, cxo_d0_a_pin, 1);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(msm8974, cxo_d1_pin, cxo_d1_a_pin, 2);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(msm8974, cxo_a0_pin, cxo_a0_a_pin, 4);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(msm8974, cxo_a1_pin, cxo_a1_a_pin, 5);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(msm8974, cxo_a2_pin, cxo_a2_a_pin, 6);
> >+
> >+static struct clk_smd_rpm *msm8974_clks[] = {
> >+ [RPM_SMD_PNOC_CLK] = &msm8974_pnoc_clk,
> >+ [RPM_SMD_PNOC_A_CLK] = &msm8974_pnoc_a_clk,
> >+ [RPM_SMD_SNOC_CLK] = &msm8974_snoc_clk,
> >+ [RPM_SMD_SNOC_A_CLK] = &msm8974_snoc_a_clk,
> >+ [RPM_SMD_CNOC_CLK] = &msm8974_cnoc_clk,
> >+ [RPM_SMD_CNOC_A_CLK] = &msm8974_cnoc_a_clk,
> >+ [RPM_SMD_MMSSNOC_AHB_CLK] = &msm8974_mmssnoc_ahb_clk,
> >+ [RPM_SMD_MMSSNOC_AHB_A_CLK] = &msm8974_mmssnoc_ahb_a_clk,
> >+ [RPM_SMD_BIMC_CLK] = &msm8974_bimc_clk,
> >+ [RPM_SMD_BIMC_A_CLK] = &msm8974_bimc_a_clk,
> >+ [RPM_SMD_OCMEMGX_CLK] = &msm8974_ocmemgx_clk,
> >+ [RPM_SMD_OCMEMGX_A_CLK] = &msm8974_ocmemgx_a_clk,
> >+ [RPM_SMD_QDSS_CLK] = &msm8974_qdss_clk,
> >+ [RPM_SMD_QDSS_A_CLK] = &msm8974_qdss_a_clk,
> >+ [RPM_SMD_CXO_D0] = &msm8974_cxo_d0,
> >+ [RPM_SMD_CXO_D0_A] = &msm8974_cxo_d0_a,
> >+ [RPM_SMD_CXO_D1] = &msm8974_cxo_d1,
> >+ [RPM_SMD_CXO_D1_A] = &msm8974_cxo_d1_a,
> >+ [RPM_SMD_CXO_A0] = &msm8974_cxo_a0,
> >+ [RPM_SMD_CXO_A0_A] = &msm8974_cxo_a0_a,
> >+ [RPM_SMD_CXO_A1] = &msm8974_cxo_a1,
> >+ [RPM_SMD_CXO_A1_A] = &msm8974_cxo_a1_a,
> >+ [RPM_SMD_CXO_A2] = &msm8974_cxo_a2,
>
> There are some extra tabs above. Otherwise looks fine:
> Tested-by: Georgi Djakov <georgi.djakov@linaro.org>
>
Doesn't look like I can blame this on the tools...I'll send an update.
Thanks for taking a look!
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: Add Macnica Americas vendor prefix
From: Dinh Nguyen @ 2016-11-18 16:25 UTC (permalink / raw)
To: Dinh Nguyen
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Dinh Nguyen,
Rob Herring, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20161101153632.6844-1-dinguyen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Hi Rob,
On Tue, Nov 1, 2016 at 10:36 AM, Dinh Nguyen <dinguyen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> Add a vendor prefix for the Macnica company.
> http://http://www.macnica.com
>
> Signed-off-by: Dinh Nguyen <dinguyen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index f0a48ea..81674f2 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -158,6 +158,7 @@ lg LG Corporation
> linux Linux-specific binding
> lltc Linear Technology Corporation
> lsi LSI Corp. (LSI Logic)
> +macnica Macnica Americas
> marvell Marvell Technology Group Ltd.
> maxim Maxim Integrated Products
> meas Measurement Specialties
> --
> 2.8.3
Just a gentle ping.
Thanks,
Dinh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v8] mwifiex: parse device tree node for PCIe
From: Kalle Valo @ 2016-11-18 16:21 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Cathy Luo,
Nishant Sarmukadam, rajatja-hpIqsD4AKlfQT0dZR+AlfA,
briannorris-hpIqsD4AKlfQT0dZR+AlfA,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA, Xinming Hu
In-Reply-To: <1479472624-22340-1-git-send-email-akarwar-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
Amitkumar Karwar <akarwar-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org> writes:
> From: Xinming Hu <huxm-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
>
> This patch derives device tree node from pcie bus layer framework.
> Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
> marvell-8xxx.txt) to accommodate PCIe changes.
>
> Signed-off-by: Xinming Hu <huxm-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Rajat Jain <rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Amitkumar Karwar <akarwar-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
[...]
> @@ -10,6 +10,8 @@ Required properties:
> - compatible : should be one of the following:
> * "marvell,sd8897"
> * "marvell,sd8997"
> + * "pci11ab,2b42"
> + * "pci1b4b,2b42"
Are these correct? In v6 Rob said:
"I think I already said this, but you have the vendor and product IDs
reversed."
https://patchwork.kernel.org/patch/9390225/
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Gabriele Paoloni @ 2016-11-18 16:18 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel@lists.infradead.org
Cc: mark.rutland@arm.com, benh@kernel.crashing.org,
catalin.marinas@arm.com, liviu.dudau@arm.com, Linuxarm,
lorenzo.pieralisi@arm.com, xuwei (O), Jason Gunthorpe,
linux-serial@vger.kernel.org, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, minyard@acm.org, will.deacon@arm.com,
John Garry, zourongrong@gmail.com, robh+dt@kernel.org
In-Reply-To: <2271602.GoSoby0zHK@wuerfel>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: 18 November 2016 13:43
> To: linux-arm-kernel@lists.infradead.org
> Cc: Gabriele Paoloni; mark.rutland@arm.com; benh@kernel.crashing.org;
> catalin.marinas@arm.com; liviu.dudau@arm.com; Linuxarm;
> lorenzo.pieralisi@arm.com; xuwei (O); Jason Gunthorpe; linux-
> serial@vger.kernel.org; linux-pci@vger.kernel.org;
> devicetree@vger.kernel.org; minyard@acm.org; will.deacon@arm.com; John
> Garry; zourongrong@gmail.com; robh+dt@kernel.org; bhelgaas@go og
> le.com; kantyzc@163.com; zhichang.yuan02@gmail.com; Thomas Petazzoni;
> linux-kernel@vger.kernel.org; Yuanzhichang; olof@lixom.net
> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> Hip06
>
> On Friday, November 18, 2016 12:53:08 PM CET Gabriele Paoloni wrote:
> > From: Arnd Bergmann [mailto:arnd@arndb.de]
> > > On Friday, November 18, 2016 12:07:28 PM CET Gabriele Paoloni
> wrote:
> > > > > I think there is no need to change a) here, we have
> PCIBIOS_MIN_IO
> > > > > today and even if we don't need it, there is no obvious
> downside.
> > > > > I would also argue that we can ignore b) for the discussion of
> > > > > the HiSilicon LPC driver, we just need to assign some range
> > > > > of logical addresses to each domain.
> > > > >
> > > > > That means solving c) is the important problem here, and it
> > > > > shouldn't be so hard. We can do this either with a single
> > > > > special domain as in the v5 patch series, or by generalizing it
> > > > > so that any I/O space mapping gets looked up through the device
> > > > > pointer of the bus master.
> > > >
> > > > I am not very on the "generalized" multi-domain solution...
> > > > Currently the IO accessors prototypes have an unsigned long addr
> > > > as input parameter. If we live in a multi-domain IO system
> > > > how can we distinguish inside the accessor which domain addr
> > > > belongs to?
> > >
> > > The easiest change compared to the v5 code would be to walk
> > > a linked list of 'struct extio_ops' structures rather than
> > > assuming there is only ever one of them. I think one of the
> > > earlier versions actually did this.
> >
> > Right but if my understanding is correct if we live in a multi-
> > domain I/O space world when you have an input addr in the I/O
> > accessors this addr can be duplicated (for example for the standard
> > PCI IO domain and for our special LPC domain).
> > So effectively even if you walk a linked list there is a problem
> > of disambiguation...am I right?
>
> No, unlike the PCI memory space, the PIO addresses are not
> usually distinct, i.e. every PCI bus has its own 64K I/O
> addresses starting at zero. We linearize them into the
> Linux I/O space using the per-domain io_offset value.
I am going to summarize my understanding here below:
It seems to me that what is linearized is the virtual address
space associated to the IO address space. This address space
goes from PCI_IOBASE to (PCI_IOBASE + IO_SPACE_LIMIT).
The I/O accessors perform rd/wr operation on this address
space using a port IO token.
Each token map into a cpu physical address range
Each cpu physical address range maps to a bus address range
if the bus controller specifies a range property.
Devices under a bus controller specify the bus addresses that
they operate on in their reg property.
So each device can use the same bus addresses under two
separate bus controllers as long as the bus controller
use the range properties to map the same bus range to different
cpu address range.
>
> For the ISA/LPC spaces there are only 4k of addresses, they
> the bus addresses always overlap, but we can trivially
> figure out the bus address from Linux I/O port number
> by subtracting the start of the range.
Are you saying that our LPC controller should specify a
range property to map bus addresses into a cpu address range?
>
> > > Another option the IA64 approach mentioned in another subthread
> > > today, looking up the operations based on an index from the
> > > upper bits of the port number. If we do this, we probably
> > > want to do that for all PIO access and replace the entire
> > > virtual address remapping logic with that. I think Bjorn
> > > in the past argued in favor of such an approach, while I
> > > advocated the current scheme for simplicity based on how
> > > every I/O space these days is just memory mapped (which now
> > > turned out to be false, both on powerpc and arm64).
> >
> > This seems really complex...I am a bit worried that possibly
> > we end up in having the maintainers saying that it is not worth
> > to re-invent the world just for this special LPC device...
>
> It would clearly be a rather invasive change, but the
> end-result isn't necessarily more complex than what we
> have today, as we'd kill off the crazy pci_pio_to_address()
> and pci_address_to_pio() hacks in address translation.
I have to look better into this...can you provide me a reference
to the Bjorn argument in favor of this approach?
>
> > To be honest with you I would keep things simple for this
> > LPC and introduce more complex reworks later if more devices
> > need to be introduced.
> >
> > What if we stick on a single domain now where we introduce a
> > reserved threshold for the IO space (say INDIRECT_MAX_IO).
>
> I said having a single domain is fine, but I still don't
> like the idea of reserving low port numbers for this hack,
> it would mean that the numbers change for everyone else.
I don't get this much...I/O tokens that are passed to the I/O
accessors are not fixed anyway and they vary depending on the order
of adding ranges to io_range_list...so I don't see a big issue
with this...
>
> > We define INDIRECT_MAX_IO as 0 in "include/linux/extio.h" and
> > we define INDIRECT_MAX_IO as 0x1000 in "arch/arm64/include/asm/io.h"
> >
> > So effectively this threshold can change according to the
> > architecture and so far we only define it for ARM64 as we need
> > it for ARM64...
>
> I liked the idea of having it done in asm-generic/io.h (in an ifdef)
> and lib/*.c under an as someone suggested earlier. There is nothing
> ARM64 specific in the implementation.
Correct and ideally if the INDIRECT_MAX_IO approach was taken then we
should define INDIRECT_MAX_IO for any architecture that can support the
special LPC devices. We would define it for ARM64 just because LPC
is used in our case under ARM64; the idea was to leave other architecture
to define their own ones as needed...but probably this is wrong and
we should have defined this for all the architectures.
Many thanks
Gab
>
> Arnd
^ permalink raw reply
* Re: [PATCH V3 1/4] Documentation: pv88080: Move binding document
From: Rob Herring @ 2016-11-18 15:38 UTC (permalink / raw)
To: Eric Jeong
Cc: DEVICETREE, LINUX-KERNEL, Mark Rutland, Alexandre Courbot,
LINUX-GPIO, Lee Jones, Liam Girdwood, Linus Walleij, Mark Brown,
Support Opensource
In-Reply-To: <8d6dc516374bf2c1cf0841aa68a888bca33413a0.1479429347.git.eric.jeong@diasemi.com>
On Fri, Nov 18, 2016 at 09:35:46AM +0900, Eric Jeong wrote:
>
> From: Eric Jeong <eric.jeong.opensource@diasemi.com>
>
> The change is to move pv88080 binding document
> from the regulator directory to mfd binding directory
> for PV88080 PMIC MFD support.
> And, GPIO properties are added.
>
>
> Signed-off-by: Eric Jeong <eric.jeong.opensource@diasemi.com>
>
> ---
> This patch applies against linux-next and next-20161117
>
> Hi,
>
> Change since PATCH V2
> - Added property and description for gpio
>
> Change since PATCH V1
> - Patch separated from PATCH V1
>
> Regards,
> Eric Jeong, Dialog Semiconductor Ltd.
>
>
> .../bindings/{regulator => mfd}/pv88080.txt | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
> rename Documentation/devicetree/bindings/{regulator => mfd}/pv88080.txt (79%)
>
> diff --git a/Documentation/devicetree/bindings/regulator/pv88080.txt b/Documentation/devicetree/bindings/mfd/pv88080.txt
> similarity index 79%
> rename from Documentation/devicetree/bindings/regulator/pv88080.txt
> rename to Documentation/devicetree/bindings/mfd/pv88080.txt
> index e6e4b9c8..7e24f95 100644
> --- a/Documentation/devicetree/bindings/regulator/pv88080.txt
> +++ b/Documentation/devicetree/bindings/mfd/pv88080.txt
> @@ -1,4 +1,4 @@
> -* Powerventure Semiconductor PV88080 Voltage Regulator
> +* Powerventure Semiconductor PV88080 PMIC
>
> Required properties:
> - compatible: Must be one of the following, depending on the
> @@ -16,8 +16,15 @@ Required properties:
> standard binding for regulators; see regulator.txt.
> BUCK1, BUCK2, BUCK3 and HVBUCK.
>
> +- gpio-controller: Marks the device node as a GPIO controller.
> +- #gpio-cells: Should be 2. See gpio.txt in this directory
> + for a description of the cells format.
> +
> Optional properties:
> +- ngpios : Number of in-use slots of available slots for GPIO.
> + Maximum is 2.
> - Any optional property defined in regulator.txt
> + and gpio.txt for more information.
>
> Example:
>
> @@ -27,6 +34,13 @@ Example:
> interrupt-parent = <&gpio>;
> interrupts = <24 24>;
>
> + gpioex {
gpio-controller {
> + compatible = "pvs,pv88080-gpio";
Is this documented?
> + gpio-controller;
> + #gpio-cells = <2>;
> + ngpios = <2>;
> + };
> +
> regulators {
> BUCK1 {
> regulator-name = "buck1";
> --
> end-of-patch for PATCH V3
>
^ permalink raw reply
* Re: [PATCH v2 2/3] hwmon: ltc2990: add devicetree binding
From: Tom Levens @ 2016-11-18 15:36 UTC (permalink / raw)
To: Rob Herring
Cc: Tom Levens, linux-0h96xk9xTtrk1uMJSBkQmQ, jdelvare-IBi9RG/b67k,
mark.rutland-5wv7dgnIgG8, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-hwmon-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161118145035.ir46ohk5uqaln6kp@rob-hp-laptop>
Hi Rob,
Thanks for taking the time to look at this patch.
On Fri, 18 Nov 2016, Rob Herring wrote:
> On Thu, Nov 17, 2016 at 01:10:15PM +0100, Tom Levens wrote:
>> Add a devicetree binding for the ltc2990 hwmon driver.
>>
>> Signed-off-by: Tom Levens <tom.levens-vJEk5272eHo@public.gmane.org>
>> ---
>> .../devicetree/bindings/hwmon/ltc2990.txt | 28 ++++++++++++++++++++
>> 1 files changed, 28 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/hwmon/ltc2990.txt
>>
>> diff --git a/Documentation/devicetree/bindings/hwmon/ltc2990.txt b/Documentation/devicetree/bindings/hwmon/ltc2990.txt
>> new file mode 100644
>> index 0000000..e4040e0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwmon/ltc2990.txt
>> @@ -0,0 +1,28 @@
>> +ltc2990
>> +
>> +Required properties:
>> +- compatible: Must be "lltc,ltc2990"
>> +- reg: I2C slave address
>> +
>> +Optional properties:
>> +- lltc,mode:
>
> What determines the mode? If this is something a user will want to
> control, then it should be a sysfs attr rather than DT prop. If the
> board design dictates then DT is the right place.
It is based on the external connections of the chip. So, I would say that
it is board specific.
> 'mode' is a bit vague, 'lltc,meas-mode' perhaps.
Sure thing.
There is also one question which came up in the thread for the patch 3 of
this patchset. The full mode for this chip is actually made of two logical
values which are written to the bits 4..3 and 2..0 of the register. This
version of the patch only configures one of the values, but for the next
version we would like to configure both. While combining them into a
single integer value would be possible, they are defined as two values in
the datasheet. Therefore, I propose using an array, such as:
lltc,meas-mode = <7 3>;
This would set the mode[2..0]=7 and mode[4..3]=3.
What do you think of this? Or should this be split into two properties?
However, in this case I struggle come up with names for the properties.
The datasheet, helpfully, calls both the fields "mode" and there is no
clear difference in their function as both control which measurements are
available.
Thanks,
>> +A Sets the chip's measurement mode, defaults to <6> if unset.
>> +
>> + The following measurements are available in each mode:
>> +
>> + 0: V1, V2, TR2
>> + 1: V1-V2, TR2
>> + 2: V1-V2, V3, V4
>> + 3: TR1, V3, V4
>> + 4: TR1, V3-V4
>> + 5: TR1, TR2
>> + 6: V1-V2, V3-V4
>> + 7: V1, V2, V3, V4
>> +
>> +Example:
>> +
>> +ltc2990@4c {
>> + compatible = "lltc,ltc2990";
>> + reg = <0x4c>;
>> + lltc,mode = <7>;
>> +};
>> --
>> 1.7.1
>>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH v2 1/7] dt-bindings: document devicetree bindings for mux-gpio
From: Rob Herring @ 2016-11-18 15:35 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel, Wolfram Sang, Mark Rutland, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Arnd Bergmann, Greg Kroah-Hartman, linux-i2c, devicetree,
linux-iio
In-Reply-To: <1479419289-17553-2-git-send-email-peda@axentia.se>
On Thu, Nov 17, 2016 at 10:48:03PM +0100, Peter Rosin wrote:
> ---
> .../devicetree/bindings/misc/mux-gpio.txt | 79 ++++++++++++++++++++++
> 1 file changed, 79 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/mux-gpio.txt
>
> diff --git a/Documentation/devicetree/bindings/misc/mux-gpio.txt b/Documentation/devicetree/bindings/misc/mux-gpio.txt
> new file mode 100644
> index 000000000000..73699a37824f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/mux-gpio.txt
> @@ -0,0 +1,79 @@
> +GPIO-based multiplexer controller bindings
> +
> +Define what GPIO pins are used to control a multiplexer. Or several
> +multiplexers, if the same pins control more than one multiplexer.
I think this makes sense in your case, but I think it is too complicated
for a non-shared case. Perhaps mux-gpios should be used directly (i.e.
in the adc-mux node) and control-muxes only used for the shared case.
Part of me feels like you are working around in DT the GPIO subsystem
limitation that it can't share GPIO lines. Either this could be fixed
in some way in the GPIO subsystem, or the mux subsys could deal with it.
You just have to look up if you already have a mux registered for the
same GPIOs. Of course, that may make the mux subsys pretty much GPIO
only, but I'm having a hard time thinking how you would have shared
muxes that are not GPIO controlled. Any other control would be
integrated into the mux itself.
> +
> +Required properties:
> +- compatible : "mux-gpio"
> +- mux-gpios : list of gpios used to control the multiplexer, least
> + significant bit first.
> +
> +Optional properties:
> +- idle-state : if present, the state the mux will have when idle.
Needs some detail on what the value is. One bit per gpio? One cell per
gpio?
> +
> +Example:
> + control_mux: control-adc-mux {
> + compatible = "mux-gpio";
> +
> + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
> + <&pioA 1 GPIO_ACTIVE_HIGH>;
> + };
> +
> + adc-mux {
> + compatible = "iio-mux";
> + io-channels = <&adc 0>;
> + io-channel-names = "parent";
> +
> + control-muxes = <&control_mux>;
This is a common name? It should be in a common mux binding doc.
> + control-mux-names = "mux";
I think this can be dropped at least until you have more than 1.
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + sync-1@0 {
> + reg = <0>;
> + };
> +
> + in@1 {
> + reg = <1>;
> + };
> +
> + out@2 {
> + reg = <2>;
> + };
> +
> + sync-2@3 {
> + reg = <3>;
> + };
> + };
> +
> + i2c-mux {
> + compatible = "i2c-mux-simple,mux-locked";
> + i2c-parent = <&i2c1>;
> +
> + control-muxes = <&control_mux>;
> + control-mux-names = "mux";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + i2c@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ssd1307: oled@3c {
> + /* ... */
> + };
> + };
> +
> + i2c@3 {
> + reg = <3>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pca9555: pca9555@20 {
> + /* ... */
> + };
> + };
> + };
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH 2/2] backlight: arcxcnn: devicetree bindings for ArticSand devices
From: Olimpiu Dejeu @ 2016-11-18 15:17 UTC (permalink / raw)
To: robh
Cc: lee.jones, linux-kernel, linux-fbdev, devicetree, jingoohan1,
Olimpiu Dejeu
Re-submission of arcxcnn backlight driver addressing the naming convention
concerns raised by Rob H. Note that all the device tree properties are
determined by the board design or IC EPROM settings and are not intended
to be user adjustable.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Olimpiu Dejeu <olimpiu@arcticsand.com>
---
.../bindings/leds/backlight/arcxcnn_bl.txt | 31 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
diff --git a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
new file mode 100644
index 0000000..a7b6ff2
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
@@ -0,0 +1,33 @@
+Binding for ArcticSand arc2c0608 LED driver
+
+Required properties:
+- compatible: should be "arc,arc2c0608"
+- reg: slave address
+
+Optional properties:
+- default-brightness: brightness value on boot, value from: 0-4095
+- label: The name of the backlight device
+ See Documentation/devicetree/bindings/leds/common.txt
+- led-sources: List of enabled channels from 0 to 5.
+ See Documentation/devicetree/bindings/leds/common.txt
+
+- arc,led-config-0: setting for register ILED_CONFIG_0
+- arc,led-config-1: setting for register ILED_CONFIG_1
+- arc,dim-freq: PWM mode frequence setting (bits [3:0] used)
+- arc,comp-config: setting for register CONFIG_COMP
+- arc,filter-config: setting for register FILTER_CONFIG
+- arc,trim-config: setting for register IMAXTUNE
+
+Note: Optional properties not specified will default to values in IC EPROM
+
+Example:
+
+arc2c0608@30 {
+ compatible = "arc,arc2c0608";
+ reg = <0x30>;
+ default-brightness = <500>;
+ label = "lcd-backlight";
+ linux,default-trigger = "backlight";
+ led-sources = <0 1 2 5>;
+};
+
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] backlight: arcxcnn: add support for ArticSand devices
From: Olimpiu Dejeu @ 2016-11-18 15:17 UTC (permalink / raw)
To: robh-DgEjT+Ai2ygdnm+yROfE0A
Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
jingoohan1-Re5JQEeQqe8AvxtiuMwx3w, Olimpiu Dejeu
Re-submission of arcxcnn backlight driver addressing the naming convention
concerns raised by Rob H.
Signed-off-by: Olimpiu Dejeu <olimpiu-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>
---
drivers/video/backlight/Kconfig | 7 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/arcxcnn_bl.c | 541 +++++++++++++++++++++++++++++++++++
include/linux/i2c/arcxcnn.h | 67 +++++
4 files changed, 616 insertions(+)
create mode 100644 drivers/video/backlight/arcxcnn_bl.c
create mode 100644 include/linux/i2c/arcxcnn.h
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 5ffa4b4..4e1d2ad 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -460,6 +460,13 @@ config BACKLIGHT_BD6107
help
If you have a Rohm BD6107 say Y to enable the backlight driver.
+config BACKLIGHT_ARCXCNN
+ tristate "Backlight driver for the Arctic Sands ARCxCnnnn family"
+ depends on I2C
+ help
+ If you have an ARCxCnnnn family backlight say Y to enable
+ the backlight driver.
+
endif # BACKLIGHT_CLASS_DEVICE
endif # BACKLIGHT_LCD_SUPPORT
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 16ec534..8905129 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -55,3 +55,4 @@ obj-$(CONFIG_BACKLIGHT_SKY81452) += sky81452-backlight.o
obj-$(CONFIG_BACKLIGHT_TOSA) += tosa_bl.o
obj-$(CONFIG_BACKLIGHT_TPS65217) += tps65217_bl.o
obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
+obj-$(CONFIG_BACKLIGHT_ARCXCNN) += arcxcnn_bl.o
diff --git a/drivers/video/backlight/arcxcnn_bl.c b/drivers/video/backlight/arcxcnn_bl.c
new file mode 100644
index 0000000..1dad680
--- /dev/null
+++ b/drivers/video/backlight/arcxcnn_bl.c
@@ -0,0 +1,541 @@
+/*
+ * Backlight driver for ArcticSand ARC_X_C_0N_0N Devices
+ *
+ * Copyright 2016 ArcticSand, Inc.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/i2c.h>
+#include <linux/backlight.h>
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/pwm.h>
+#include <linux/regulator/consumer.h>
+
+#include "linux/i2c/arcxcnn.h"
+
+#define ARCXCNN_CMD (0x00) /* Command Register */
+#define ARCXCNN_CMD_STDBY (0x80) /* I2C Standby */
+#define ARCXCNN_CMD_RESET (0x40) /* Reset */
+#define ARCXCNN_CMD_BOOST (0x10) /* Boost */
+#define ARCXCNN_CMD_OVP_MASK (0x0C) /* --- Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_XXV (0x0C) /* <rsvrd> Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_20V (0x08) /* 20v Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_24V (0x04) /* 24v Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_31V (0x00) /* 31.4v Over Voltage Threshold */
+#define ARCXCNN_CMD_EXT_COMP (0x01) /* part (0) or full (1) external comp */
+
+#define ARCXCNN_CONFIG (0x01) /* Configuration */
+#define ARCXCNN_STATUS1 (0x02) /* Status 1 */
+#define ARCXCNN_STATUS2 (0x03) /* Status 2 */
+#define ARCXCNN_FADECTRL (0x04) /* Fading Control */
+#define ARCXCNN_ILED_CONFIG (0x05) /* ILED Configuration */
+
+#define ARCXCNN_LEDEN (0x06) /* LED Enable Register */
+#define ARCXCNN_LEDEN_ISETEXT (0x80) /* Full-scale current set externally */
+#define ARCXCNN_LEDEN_MASK (0x3F) /* LED string enables */
+#define ARCXCNN_LEDEN_LED1 (0x01)
+#define ARCXCNN_LEDEN_LED2 (0x02)
+#define ARCXCNN_LEDEN_LED3 (0x04)
+#define ARCXCNN_LEDEN_LED4 (0x08)
+#define ARCXCNN_LEDEN_LED5 (0x10)
+#define ARCXCNN_LEDEN_LED6 (0x20)
+
+#define ARCXCNN_WLED_ISET_LSB (0x07) /* LED ISET LSB (in upper nibble) */
+#define ARCXCNN_WLED_ISET_MSB (0x08) /* LED ISET MSB (8 bits) */
+
+#define ARCXCNN_DIMFREQ (0x09)
+#define ARCXCNN_COMP_CONFIG (0x0A)
+#define ARCXCNN_FILT_CONFIG (0x0B)
+#define ARCXCNN_IMAXTUNE (0x0C)
+
+#define DEFAULT_BL_NAME "arctic_bl"
+#define MAX_BRIGHTNESS 4095
+
+static int s_no_reset_on_remove;
+module_param_named(noreset, s_no_reset_on_remove, int, 0644);
+MODULE_PARM_DESC(noreset, "No reset on module removal");
+
+static int s_ibright = 60;
+module_param_named(ibright, s_ibright, int, 0644);
+MODULE_PARM_DESC(ibright, "Initial brightness (when no plat data)");
+
+static int s_iledstr = 0x3F;
+module_param_named(iledstr, s_iledstr, int, 0644);
+MODULE_PARM_DESC(iledstr, "Initial LED String (when no plat data)");
+
+static int s_retries = 2; /* 1 == only one try */
+module_param_named(retries, s_retries, int, 0644);
+MODULE_PARM_DESC(retries, "I2C retries attempted");
+
+enum arcxcnn_brightness_ctrl_mode {
+ PWM_BASED = 1,
+ REGISTER_BASED,
+};
+
+struct arcxcnn;
+
+struct arcxcnn {
+ char chipname[64];
+ enum arcxcnn_chip_id chip_id;
+ enum arcxcnn_brightness_ctrl_mode mode;
+ struct i2c_client *client;
+ struct backlight_device *bl;
+ struct device *dev;
+ struct arcxcnn_platform_data *pdata;
+ struct pwm_device *pwm;
+ struct regulator *supply; /* regulator for VDD input */
+};
+
+static int arcxcnn_write_byte(struct arcxcnn *lp, u8 reg, u8 data)
+{
+ s32 ret = -1;
+ int att;
+
+ for (att = 0; att < s_retries; att++) {
+ ret = i2c_smbus_write_byte_data(lp->client, reg, data);
+ if (ret >= 0)
+ return 0;
+ }
+ return ret;
+}
+
+static u8 arcxcnn_read_byte(struct arcxcnn *lp, u8 reg)
+{
+ int val;
+ int att;
+
+ for (att = 0; att < s_retries; att++) {
+ val = i2c_smbus_read_byte_data(lp->client, reg);
+ if (val >= 0)
+ return (u8)val;
+ }
+ return 0;
+}
+
+static int arcxcnn_update_bit(struct arcxcnn *lp, u8 reg, u8 mask, u8 data)
+{
+ int ret, att;
+ u8 tmp;
+
+ for (att = 0, ret = -1; att < s_retries; att++) {
+ ret = i2c_smbus_read_byte_data(lp->client, reg);
+ if (ret >= 0)
+ break;
+ }
+ if (ret < 0) {
+ dev_err(lp->dev, "failed to read 0x%.2x\n", reg);
+ return ret;
+ }
+
+ tmp = (u8)ret;
+ tmp &= ~mask;
+ tmp |= data & mask;
+
+ return arcxcnn_write_byte(lp, reg, tmp);
+}
+
+static int arcxcnn_set_brightness(struct arcxcnn *lp, u32 brightness)
+{
+ int ret;
+ u8 val;
+
+ val = (brightness & 0xF) << 4;
+ ret = arcxcnn_write_byte(lp, ARCXCNN_WLED_ISET_LSB, val);
+ if (ret < 0)
+ return ret;
+ val = (brightness >> 4);
+ ret = arcxcnn_write_byte(lp, ARCXCNN_WLED_ISET_MSB, val);
+ return ret;
+}
+
+static int arcxcnn_bl_update_status(struct backlight_device *bl)
+{
+ struct arcxcnn *lp = bl_get_data(bl);
+ u32 brightness = bl->props.brightness;
+
+ if (bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
+ brightness = 0;
+
+ /* set brightness */
+ if (lp->mode == PWM_BASED)
+ ; /* via pwm */
+ else if (lp->mode == REGISTER_BASED)
+ arcxcnn_set_brightness(lp, brightness);
+
+ /* set power-on/off/save modes */
+ if (bl->props.power == 0)
+ /* take out of standby */
+ arcxcnn_update_bit(lp, ARCXCNN_CMD, ARCXCNN_CMD_STDBY, 0);
+ else
+ /* 1-3 == power save, 4 = off
+ * place in low-power standby mode
+ */
+ arcxcnn_update_bit(lp, ARCXCNN_CMD,
+ ARCXCNN_CMD_STDBY, ARCXCNN_CMD_STDBY);
+ return 0;
+}
+
+static const struct backlight_ops arcxcnn_bl_ops = {
+ .options = BL_CORE_SUSPENDRESUME,
+ .update_status = arcxcnn_bl_update_status,
+};
+
+static int arcxcnn_backlight_register(struct arcxcnn *lp)
+{
+ struct backlight_device *bl;
+ struct backlight_properties props;
+ struct arcxcnn_platform_data *pdata = lp->pdata;
+ const char *name = pdata->name ? : DEFAULT_BL_NAME;
+
+ memset(&props, 0, sizeof(props));
+ props.type = BACKLIGHT_PLATFORM;
+ props.max_brightness = MAX_BRIGHTNESS;
+
+ if (pdata->initial_brightness > props.max_brightness)
+ pdata->initial_brightness = props.max_brightness;
+
+ props.brightness = pdata->initial_brightness;
+
+ bl = devm_backlight_device_register(lp->dev, name, lp->dev, lp,
+ &arcxcnn_bl_ops, &props);
+ if (IS_ERR(bl))
+ return PTR_ERR(bl);
+
+ lp->bl = bl;
+
+ return 0;
+}
+
+static ssize_t arcxcnn_get_chip_id(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct arcxcnn *lp = dev_get_drvdata(dev);
+
+ return scnprintf(buf, PAGE_SIZE, "%s\n", lp->chipname);
+}
+
+static ssize_t arcxcnn_get_led_str(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct arcxcnn *lp = dev_get_drvdata(dev);
+
+ return scnprintf(buf, PAGE_SIZE, "%02X\n", lp->pdata->led_str);
+}
+
+static ssize_t arcxcnn_set_led_str(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t len)
+{
+ struct arcxcnn *lp = dev_get_drvdata(dev);
+ unsigned long ledstr;
+
+ if (kstrtoul(buf, 0, &ledstr))
+ return 0;
+
+ if (ledstr != lp->pdata->led_str) {
+ /* don't allow 0 for ledstr, use power to turn all off */
+ if (ledstr == 0)
+ return 0;
+ lp->pdata->led_str = ledstr & 0x3F;
+ arcxcnn_update_bit(lp, ARCXCNN_LEDEN,
+ ARCXCNN_LEDEN_MASK, lp->pdata->led_str);
+ }
+ return len;
+}
+
+static ssize_t arcxcnn_get_bl_ctl_mode(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct arcxcnn *lp = dev_get_drvdata(dev);
+ char *strmode = NULL;
+
+ if (lp->mode == PWM_BASED)
+ strmode = "pwm based";
+ else if (lp->mode == REGISTER_BASED)
+ strmode = "register based";
+
+ return scnprintf(buf, PAGE_SIZE, "%s\n", strmode);
+}
+
+static DEVICE_ATTR(chip_id, 0444, arcxcnn_get_chip_id, NULL);
+static DEVICE_ATTR(led_str, 0664, arcxcnn_get_led_str, arcxcnn_set_led_str);
+static DEVICE_ATTR(bl_ctl_mode, 0444, arcxcnn_get_bl_ctl_mode, NULL);
+
+static struct attribute *arcxcnn_attributes[] = {
+ &dev_attr_chip_id.attr,
+ &dev_attr_led_str.attr,
+ &dev_attr_bl_ctl_mode.attr,
+ NULL,
+};
+
+static const struct attribute_group arcxcnn_attr_group = {
+ .attrs = arcxcnn_attributes,
+};
+
+#ifdef CONFIG_OF
+static int arcxcnn_parse_dt(struct arcxcnn *lp)
+{
+ struct device *dev = lp->dev;
+ struct device_node *node = dev->of_node;
+ u32 prog_val, num_entry, sources[6];
+ int ret;
+
+ if (!node) {
+ dev_err(dev, "no platform data.\n");
+ return -EINVAL;
+ }
+ lp->pdata->led_config_0_set = false;
+ lp->pdata->led_config_1_set = false;
+ lp->pdata->dim_freq_set = false;
+ lp->pdata->comp_config_set = false;
+ lp->pdata->filter_config_set = false;
+ lp->pdata->trim_config_set = false;
+
+ ret = of_property_read_string(node, "label", &lp->pdata->name);
+ if (ret < 0)
+ lp->pdata->name = NULL;
+
+ ret = of_property_read_u32(node, "default-brightness", &prog_val);
+ if (ret < 0)
+ prog_val = s_ibright;
+ lp->pdata->initial_brightness = prog_val;
+ if (lp->pdata->initial_brightness > MAX_BRIGHTNESS)
+ lp->pdata->initial_brightness = MAX_BRIGHTNESS;
+
+ ret = of_property_read_u32(node, "arc,led-config-0", &prog_val);
+ if (ret == 0) {
+ lp->pdata->led_config_0 = (u8)prog_val;
+ lp->pdata->led_config_0_set = true;
+ }
+ ret = of_property_read_u32(node, "arc,led-config-1", &prog_val);
+ if (ret == 0) {
+ lp->pdata->led_config_1 = (u8)prog_val;
+ lp->pdata->led_config_1_set = true;
+ }
+ ret = of_property_read_u32(node, "arc,dim-freq", &prog_val);
+ if (ret == 0) {
+ lp->pdata->dim_freq = (u8)prog_val;
+ lp->pdata->dim_freq_set = true;
+ }
+ ret = of_property_read_u32(node, "arc,comp-config", &prog_val);
+ if (ret == 0) {
+ lp->pdata->comp_config = (u8)prog_val;
+ lp->pdata->comp_config_set = true;
+ }
+ ret = of_property_read_u32(node, "arc,filter-config", &prog_val);
+ if (ret == 0) {
+ lp->pdata->filter_config = (u8)prog_val;
+ lp->pdata->filter_config_set = true;
+ }
+ ret = of_property_read_u32(node, "arc,trim-config", &prog_val);
+ if (ret == 0) {
+ lp->pdata->trim_config = (u8)prog_val;
+ lp->pdata->trim_config_set = true;
+ }
+ ret = of_property_count_u32_elems(node, "led-sources");
+ if (ret < 0)
+ lp->pdata->led_str = 0x3F;
+ else {
+ num_entry = ret;
+ if (num_entry > 6)
+ num_entry = 6;
+
+ ret = of_property_read_u32_array(node, "led-sources", sources,
+ num_entry);
+ if (ret < 0) {
+ dev_err(dev, "led-sources node is invalid.\n");
+ return -EINVAL;
+ }
+
+ lp->pdata->led_str = 0;
+ while (num_entry > 0)
+ lp->pdata->led_str |= (1 << sources[--num_entry]);
+ }
+ return 0;
+}
+#else
+static int arcxcnn_parse_dt(struct arcxcnn *lp)
+{
+ return -EINVAL;
+}
+#endif
+
+static int arcxcnn_probe(struct i2c_client *cl, const struct i2c_device_id *id)
+{
+ struct arcxcnn *lp;
+ int ret;
+ u8 regval;
+ u16 chipid;
+
+ if (!i2c_check_functionality(cl->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
+ return -EIO;
+
+ lp = devm_kzalloc(&cl->dev, sizeof(*lp), GFP_KERNEL);
+ if (!lp)
+ return -ENOMEM;
+
+ lp->client = cl;
+ lp->dev = &cl->dev;
+ lp->chip_id = id->driver_data;
+ lp->pdata = dev_get_platdata(&cl->dev);
+
+ if (!lp->pdata) {
+ lp->pdata = devm_kzalloc(lp->dev,
+ sizeof(*lp->pdata), GFP_KERNEL);
+ if (!lp->pdata)
+ return -ENOMEM;
+
+ /* no platform data, parse the device-tree for info. if there
+ * is no device tree entry, we are being told we exist because
+ * user-land said so, so make up the info we need
+ */
+ ret = arcxcnn_parse_dt(lp);
+ if (ret < 0) {
+ /* no device tree, use defaults based on module params
+ */
+ lp->pdata->led_config_0_set = false;
+ lp->pdata->led_config_1_set = false;
+ lp->pdata->dim_freq_set = false;
+ lp->pdata->comp_config_set = false;
+ lp->pdata->filter_config_set = false;
+ lp->pdata->trim_config_set = false;
+
+ lp->pdata->name = NULL;
+ lp->pdata->initial_brightness = s_ibright;
+ lp->pdata->led_str = s_iledstr;
+ }
+ }
+
+ if (lp->pdata->dim_freq_set)
+ lp->mode = PWM_BASED;
+ else
+ lp->mode = REGISTER_BASED;
+
+ i2c_set_clientdata(cl, lp);
+
+ /* read device ID */
+ regval = arcxcnn_read_byte(lp, 0x1E);
+ chipid = regval;
+ chipid <<= 8;
+ regval = arcxcnn_read_byte(lp, 0x1F);
+ chipid |= regval;
+
+ /* make sure it belongs to this driver
+ * TODO - handle specific ids
+ */
+ if (chipid != 0x02A5) {
+ #if 1
+ dev_info(&cl->dev, "Chip Id is %04X\n", chipid);
+ #else
+ dev_err(&cl->dev, "%04X is not ARC2C\n", chipid);
+ return -ENODEV;
+ #endif
+ }
+ /* reset the device */
+ arcxcnn_write_byte(lp, ARCXCNN_CMD, ARCXCNN_CMD_RESET);
+
+ /* set initial brightness */
+ arcxcnn_set_brightness(lp, lp->pdata->initial_brightness);
+
+ /* if fadectrl set in DT, set the value directly, else leave default */
+ if (lp->pdata->led_config_0_set)
+ arcxcnn_write_byte(lp, ARCXCNN_FADECTRL,
+ lp->pdata->led_config_0);
+
+ /* if iled config set in DT, set the value, else internal mode */
+ if (lp->pdata->led_config_1_set)
+ arcxcnn_write_byte(lp, ARCXCNN_ILED_CONFIG,
+ lp->pdata->led_config_1);
+ else
+ arcxcnn_write_byte(lp, ARCXCNN_ILED_CONFIG, 0x57);
+
+ /* other misc DT settings */
+ if (lp->pdata->dim_freq_set)
+ arcxcnn_write_byte(lp, ARCXCNN_FADECTRL, lp->pdata->dim_freq);
+ if (lp->pdata->comp_config_set)
+ arcxcnn_write_byte(lp, ARCXCNN_COMP_CONFIG,
+ lp->pdata->comp_config);
+ if (lp->pdata->filter_config_set)
+ arcxcnn_write_byte(lp, ARCXCNN_FILT_CONFIG,
+ lp->pdata->filter_config);
+ if (lp->pdata->trim_config_set)
+ arcxcnn_write_byte(lp, ARCXCNN_IMAXTUNE,
+ lp->pdata->trim_config);
+
+ /* set initial LED Strings */
+ arcxcnn_update_bit(lp, ARCXCNN_LEDEN,
+ ARCXCNN_LEDEN_MASK, lp->pdata->led_str);
+
+ snprintf(lp->chipname, sizeof(lp->chipname),
+ "%s-%04X", id->name, chipid);
+
+ ret = arcxcnn_backlight_register(lp);
+ if (ret) {
+ dev_err(lp->dev,
+ "failed to register backlight. err: %d\n", ret);
+ return ret;
+ }
+
+ ret = sysfs_create_group(&lp->dev->kobj, &arcxcnn_attr_group);
+ if (ret) {
+ dev_err(lp->dev, "failed to register sysfs. err: %d\n", ret);
+ return ret;
+ }
+
+ backlight_update_status(lp->bl);
+ return 0;
+}
+
+static int arcxcnn_remove(struct i2c_client *cl)
+{
+ struct arcxcnn *lp = i2c_get_clientdata(cl);
+
+ if (!s_no_reset_on_remove) {
+ /* disable all strings */
+ arcxcnn_write_byte(lp, ARCXCNN_LEDEN, 0x00);
+ /* reset the device */
+ arcxcnn_write_byte(lp, ARCXCNN_CMD, ARCXCNN_CMD_RESET);
+ }
+ lp->bl->props.brightness = 0;
+ backlight_update_status(lp->bl);
+ if (lp->supply)
+ regulator_disable(lp->supply);
+ sysfs_remove_group(&lp->dev->kobj, &arcxcnn_attr_group);
+
+ return 0;
+}
+
+static const struct of_device_id arcxcnn_dt_ids[] = {
+ { .compatible = "arc,arc2c0608" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, arcxcnn_dt_ids);
+
+/* Note that the device/chip ID is not fixed in silicon so
+ * auto-probing of these devices on the bus is most likely
+ * not possible, use device tree to set i2c bus address
+ */
+static const struct i2c_device_id arcxcnn_ids[] = {
+ {"arc2c0608", ARC2C0608},
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, arcxcnn_ids);
+
+static struct i2c_driver arcxcnn_driver = {
+ .driver = {
+ .name = "arcxcnn_bl",
+ .of_match_table = of_match_ptr(arcxcnn_dt_ids),
+ },
+ .probe = arcxcnn_probe,
+ .remove = arcxcnn_remove,
+ .id_table = arcxcnn_ids,
+};
+
+module_i2c_driver(arcxcnn_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Brian Dodge <bdodge09-1ViLX0X+lBJBDgjK7y7TUQ@public.gmane.org>");
+MODULE_DESCRIPTION("ARCXCNN Backlight driver");
diff --git a/include/linux/i2c/arcxcnn.h b/include/linux/i2c/arcxcnn.h
new file mode 100644
index 0000000..1c681dd
--- /dev/null
+++ b/include/linux/i2c/arcxcnn.h
@@ -0,0 +1,67 @@
+/*
+ * Backlight driver for ArcticSand ARC2C0608 Backlight Devices
+ *
+ * Copyright 2016 ArcticSand, Inc.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#ifndef _ARCXCNN_H
+#define _ARCXCNN_H
+
+enum arcxcnn_chip_id {
+ ARC2C0608
+};
+
+enum arcxcnn_brightness_source {
+ ARCXCNN_PWM_ONLY,
+ ARCXCNN_I2C_ONLY = 2,
+};
+
+#define ARCXCNN_MAX_PROGENTRIES 48 /* max a/v pairs for custom */
+
+/**
+ * struct arcxcnn_platform_data
+ * @name : Backlight driver name. If it is not defined, default name is set.
+ * @initial_brightness : initial value of backlight brightness
+ * @led_str : initial LED string enables, upper bit is global on/off
+ * @led_config_0 : fading speed (period between intensity steps)
+ * @led_config_1 : misc settings, see datasheet
+ * @dim_freq : pwm dimming frequency if in pwm mode
+ * @comp_config : misc config, see datasheet
+ * @filter_config: RC/PWM filter config, see datasheet
+ * @trim_config : full scale current trim, see datasheet
+ * @led_config_0_set : the value in led_config_0 is valid
+ * @led_config_1_set : the value in led_config_1 is valid
+ * @dim_freq_set : the value in dim_freq is valid
+ * @comp_config_set : the value in comp_config is valid
+ * @filter_config_set : the value in filter_config is valid
+ * @trim_config_set : the value in trim_config is valid
+ *
+ * the _set flags are used to indicate that the value was explicitly set
+ * in the device tree or platform data. settings not set are left as default
+ * power-on default values of the chip except for led_str and led_config_1
+ * which are set by the driver (led_str is specified indirectly in the
+ * device tree via "led-sources")
+ */
+struct arcxcnn_platform_data {
+ const char *name;
+ u16 initial_brightness;
+ u8 led_str;
+
+ u8 led_config_0;
+ u8 led_config_1;
+ u8 dim_freq;
+ u8 comp_config;
+ u8 filter_config;
+ u8 trim_config;
+
+ bool led_config_0_set;
+ bool led_config_1_set;
+ bool dim_freq_set;
+ bool comp_config_set;
+ bool filter_config_set;
+ bool trim_config_set;
+};
+
+#endif
--
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 v2 5/8] dt-bindings: mfd: Provide human readable defines for TPS65217 interrupts
From: Tony Lindgren @ 2016-11-18 15:10 UTC (permalink / raw)
To: Lee Jones
Cc: Milo Kim, bcousson, linux-omap, devicetree, linux-arm-kernel,
linux-kernel, Robert Nelson
In-Reply-To: <20161118145353.GE2301@dell.home>
* Lee Jones <lee.jones@linaro.org> [161118 06:51]:
> On Fri, 28 Oct 2016, Milo Kim wrote:
>
> > TPS65217 supports three interrupt sources. This patch enables assigning
> > each IRQ number in the charger and power button node. Then corresponding
> > IRQ will be requested by each driver.
> >
> > Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
> > ---
> > include/dt-bindings/mfd/tps65217.h | 26 ++++++++++++++++++++++++++
> > 1 file changed, 26 insertions(+)
> > create mode 100644 include/dt-bindings/mfd/tps65217.h
> >
> > diff --git a/include/dt-bindings/mfd/tps65217.h b/include/dt-bindings/mfd/tps65217.h
> > new file mode 100644
> > index 0000000..cafb9e6
> > --- /dev/null
> > +++ b/include/dt-bindings/mfd/tps65217.h
> > @@ -0,0 +1,26 @@
> > +/*
> > + * This header provides macros for TI TPS65217 DT bindings.
> > + *
> > + * Copyright (C) 2016 Texas Instruments
> > + *
> > + * 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.
> > + *
> > + * You should have received a copy of the GNU General Public License along with
> > + * this program. If not, see <http://www.gnu.org/licenses/>.
> > + */
> > +
> > +#ifndef __DT_BINDINGS_TPS65217_H__
> > +#define __DT_BINDINGS_TPS65217_H__
> > +
> > +#define TPS65217_IRQ_USB 0
> > +#define TPS65217_IRQ_AC 1
> > +#define TPS65217_IRQ_PB 2
>
> What are "AC" and "PB". Seeing as these are meant to be "human
> readable", let's make them more human friendly.
Good idea. Milo, please do an incremental single follow-up patch as
I already have applied this and the dts changes using it.
Regards,
Tony
^ permalink raw reply
* [RESEND PATCH v1] ARM: dts: stm32f429: Add missing USART3 pin config to STM32F469I-DISCO board
From: Bruno Meirelles Herrera @ 2016-11-18 15:10 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, mcoquelin.stm32, alexandre.torgue
Cc: devicetree, linux-kernel, linux-arm-kernel, Bruno Herrera
Including new STM32 maintainer. Rebased at stm32-dt-for-v4.10-1 and
stm32-dt-for-v4.10-2 branches. It fix the port/pin initialization in
case boot-loader does not configure/initialize the pins.
Fixing line wrapping from last patch
This patch adds USART3 pin configuration on PB10/PA11 pins
for STM32F469I-DISCO board.
Signed-off-by: Bruno Herrera <bruherrera@gmail.com>
---
arch/arm/boot/dts/stm32f429.dtsi | 13 +++++++++++++
arch/arm/boot/dts/stm32f469-disco.dts | 2 ++
2 files changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index e4dae0e..1b8b105 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -316,6 +316,19 @@
};
};
+ usart3_pins_a: usart3@0 {
+ pins1 {
+ pinmux = <STM32F429_PB10_FUNC_USART3_TX>;
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux = <STM32F429_PB11_FUNC_USART3_RX>;
+ bias-disable;
+ };
+ };
+
usbotg_hs_pins_a: usbotg_hs@0 {
pins {
pinmux = <STM32F429_PH4_FUNC_OTG_HS_ULPI_NXT>,
diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
index 8877c00..75f4303 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -79,5 +79,7 @@
};
&usart3 {
+ pinctrl-0 = <&usart3_pins_a>;
+ pinctrl-names = "default";
status = "okay";
};
--
2.9.3 (Apple Git-75)
^ 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