* Re: [PATCH v4 6/7] IIO: add STM32 timer trigger driver
From: Benjamin Gaignard @ 2016-12-06 15:19 UTC (permalink / raw)
To: Lee Jones
Cc: robh+dt, Mark Rutland, alexandre.torgue, devicetree,
Linux Kernel Mailing List, Thierry Reding, linux-pwm,
Jonathan Cameron, knaack.h, Lars-Peter Clausen,
Peter Meerwald-Stadler, linux-iio, linux-arm-kernel,
Fabrice Gasnier, Gerald Baeza, Arnaud Pouliquen, Linus Walleij,
Linaro Kernel Mailman List, Benjamin Gaignard
In-Reply-To: <20161206131635.GJ25385@dell.home>
[snip]
>> +
>> +static const char * const triggers0[] = {
>> + TIM1_TRGO, TIM1_CH1, TIM1_CH2, TIM1_CH3, TIM1_CH4, NULL,
>> +};
>> +
>> +static const char * const triggers1[] = {
>> + TIM2_TRGO, TIM2_CH1, TIM2_CH2, TIM2_CH3, TIM2_CH4, NULL,
>> +};
>> +
>> +static const char * const triggers2[] = {
>> + TIM3_TRGO, TIM3_CH1, TIM3_CH2, TIM3_CH3, TIM3_CH4, NULL,
>> +};
>> +
>> +static const char * const triggers3[] = {
>> + TIM4_TRGO, TIM4_CH1, TIM4_CH2, TIM4_CH3, TIM4_CH4, NULL,
>> +};
>> +
>> +static const char * const triggers4[] = {
>> + TIM5_TRGO, TIM5_CH1, TIM5_CH2, TIM5_CH3, TIM5_CH4, NULL,
>> +};
>> +
>> +static const char * const triggers5[] = {
>> + TIM6_TRGO, NULL,
>> +};
>> +
>> +static const char * const triggers6[] = {
>> + TIM7_TRGO, NULL,
>> +};
>> +
>> +static const char * const triggers7[] = {
>> + TIM8_TRGO, TIM8_CH1, TIM8_CH2, TIM8_CH3, TIM8_CH4, NULL,
>> +};
>> +
>> +static const char * const triggers8[] = {
>> + TIM9_TRGO, TIM9_CH1, TIM9_CH2, NULL,
>> +};
>> +
>> +static const char * const triggers9[] = {
>> + TIM12_TRGO, TIM12_CH1, TIM12_CH2, NULL,
>> +};
>> +
>> +static const void *triggers_table[] = {
>> + triggers0,
>> + triggers1,
>> + triggers2,
>> + triggers3,
>> + triggers4,
>> + triggers5,
>> + triggers6,
>> + triggers7,
>> + triggers8,
>> + triggers9,
>> +};
>
> What about:
>
> static const char * const triggers[][] = {
> { TIM1_TRGO, TIM1_CH1, TIM1_CH2, TIM1_CH3, TIM1_CH4, NULL },
> { TIM2_TRGO, TIM2_CH1, TIM2_CH2, TIM2_CH3, TIM2_CH4, NULL },
> { TIM3_TRGO, TIM3_CH1, TIM3_CH2, TIM3_CH3, TIM3_CH4, NULL },
> { TIM4_TRGO, TIM4_CH1, TIM4_CH2, TIM4_CH3, TIM4_CH4, NULL },
> { TIM5_TRGO, TIM5_CH1, TIM5_CH2, TIM5_CH3, TIM5_CH4, NULL },
> { TIM6_TRGO, NULL },
> { TIM7_TRGO, NULL },
> { TIM8_TRGO, TIM8_CH1, TIM8_CH2, TIM8_CH3, TIM8_CH4, NULL },
> { TIM9_TRGO, TIM9_CH1, TIM9_CH2, NULL },
> { TIM12_TRGO, TIM12_CH1, TIM12_CH2, NULL }
> };
I can't because the second dimension of the array isn't fix.
I could have between 2 and 6 elements per row... to create a dual dimension
array I would have to add NULL entries like that:
#define MAX_TRIGGERS 6
static const void *triggers_table[][MAX_TRIGGERS] = {
{ TIM1_TRGO, TIM1_CH1, TIM1_CH2, TIM1_CH3, TIM1_CH4, NULL,},
{ TIM2_TRGO, TIM2_CH1, TIM2_CH2, TIM2_CH3, TIM2_CH4, NULL,},
{ TIM3_TRGO, TIM3_CH1, TIM3_CH2, TIM3_CH3, TIM3_CH4, NULL,},
{ TIM4_TRGO, TIM4_CH1, TIM4_CH2, TIM4_CH3, TIM4_CH4, NULL,},
{ TIM5_TRGO, TIM5_CH1, TIM5_CH2, TIM5_CH3, TIM5_CH4, NULL,},
{ TIM6_TRGO, NULL, NULL, NULL, NULL, NULL,},
{ TIM7_TRGO, NULL, NULL, NULL, NULL, NULL,},
{ TIM8_TRGO, TIM8_CH1, TIM8_CH2, TIM8_CH3, TIM8_CH4, NULL,},
{ TIM9_TRGO, TIM9_CH1, TIM9_CH2, NULL, NULL, NULL,},
{ TIM12_TRGO, TIM12_CH1, TIM12_CH2, NULL, NULL, NULL,},
};
>> +static const char * const valids0[] = {
>> + TIM5_TRGO, TIM2_TRGO, TIM4_TRGO, TIM3_TRGO, NULL,
>> +};
>> +
>> +static const char * const valids1[] = {
>> + TIM1_TRGO, TIM8_TRGO, TIM3_TRGO, TIM4_TRGO, NULL,
>> +};
>> +
>> +static const char * const valids2[] = {
>> + TIM1_TRGO, TIM8_TRGO, TIM5_TRGO, TIM4_TRGO, NULL,
>> +};
>> +
>> +static const char * const valids3[] = {
>> + TIM1_TRGO, TIM2_TRGO, TIM3_TRGO, TIM8_TRGO, NULL,
>> +};
>> +
>> +static const char *const valids4[] = {
>> + TIM2_TRGO, TIM3_TRGO, TIM4_TRGO, TIM8_TRGO, NULL,
>> +};
>> +
>> +static const char * const valids7[] = {
>> + TIM1_TRGO, TIM2_TRGO, TIM4_TRGO, TIM5_TRGO, NULL,
>> +};
>> +
>> +static const char * const valids8[] = {
>> + TIM2_TRGO, TIM3_TRGO, NULL,
>> +};
>> +
>> +static const char * const valids9[] = {
>> + TIM4_TRGO, TIM5_TRGO, NULL,
>> +};
>> +
>> +static const void *valids_table[] = {
>> + valids0,
>> + valids1,
>> + valids2,
>> + valids3,
>> + valids4,
>> + NULL,
>> + NULL,
>> + valids7,
>> + valids8,
>> + valids9,
>> +};
>
> Same here.
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Icenowy Zheng @ 2016-12-06 15:16 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree@vger.kernel.org, Vishnu Patekar,
Arnd Bergmann, linux-doc@vger.kernel.org, André Przywara,
Jonathan Corbet, linux-kernel, Russell King, Hans de Goede,
Chen-Yu Tsai, "linux-arm-kernel@lists.infradead.org"
In-Reply-To: <20161206080056.23jpd4e7eeuhuyiq@lukather>
06.12.2016, 16:01, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> On Mon, Dec 05, 2016 at 07:01:46PM +0800, Icenowy Zheng wrote:
>> 05.12.2016, 17:40, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
>> > On Mon, Dec 05, 2016 at 04:59:44PM +0800, Icenowy Zheng wrote:
>> >> 2016年12月5日 16:52于 Maxime Ripard <maxime.ripard@free-electrons.com>写道:
>> >> >
>> >> > On Fri, Dec 02, 2016 at 10:22:30PM +0800, Icenowy Zheng wrote:
>> >> > >
>> >> > >
>> >> > > 01.12.2016, 17:36, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
>> >> > > > On Mon, Nov 28, 2016 at 12:29:07AM +0000, André Przywara wrote:
>> >> > > >> > Something more interesting happened.
>> >> > > >> >
>> >> > > >> > Xunlong made a add-on board for Orange Pi Zero, which exposes the
>> >> > > >> > two USB Controllers exported at expansion bus as USB Type-A
>> >> > > >> > connectors.
>> >> > > >> >
>> >> > > >> > Also it exposes a analog A/V jack and a microphone.
>> >> > > >> >
>> >> > > >> > Should I enable {e,o}hci{2.3} in the device tree?
>> >> > > >>
>> >> > > >> Actually we should do this regardless of this extension board. The USB
>> >> > > >> pins are not multiplexed and are exposed on user accessible pins (just
>> >> > > >> not soldered, but that's a detail), so I think they qualify for DT
>> >> > > >> enablement. And even if a user can't use them, it doesn't hurt to have
>> >> > > >> them (since they are not multiplexed).
>> >> > > >
>> >> > > > My main concern about this is that we'll leave regulators enabled by
>> >> > > > default, for a minority of users. And that minority will prevent to do
>> >> > > > a proper power management when the times come since we'll have to keep
>> >> > > > that behaviour forever.
>> >> > >
>> >> > > I think these users can add a 'fdt set /xxx/xxx status "disabled" ' .
>> >> >
>> >> > You can't ask that from the majority of users. These users will take
>> >> > debian or fedora, install it, and expect everything to work
>> >> > properly. I would make the opposite argument actually. If someone is
>> >> > knowledgeable enough to solder the USB pins a connector, then (s)he'll
>> >> > be able to make that u-boot call.
>> >>
>> >> Now (s)he do not need soldering.
>> >>
>> >> (S)he needs only paying $1.99 more to Xunlong to get the expansion
>> >> board, and insert it on the OPi Zero.
>> >
>> > Which is going to require an overlay anyway, so we could have the USB
>> > bits in there too.
>>
>> If so, I think the [PATCH -next v3 2/2] is ready to be merged ;-)
>
> I meant enabling the USB in the overlay, you enabled it in the base DT.
I enabled only usb1 in the base DT.
The USBs on the expansion board is usb2/3, and usb1 is an onboard USB connector.
It should of course be enabled ;-)
And to mention: this usb's Vbus is also directly connected to DCIN.
(There's no regulator at 5.0V on orange pi Zero)
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] misc: atmel-ssc: register as sound DAI if #sound-dai-cells is present
From: Rob Herring @ 2016-12-06 15:16 UTC (permalink / raw)
To: Peter Rosin
Cc: Mark Rutland, devicetree, alsa-devel, Arnd Bergmann,
Greg Kroah-Hartman, Takashi Iwai, Nicolas Ferre, linux-kernel,
Liam Girdwood, Mark Brown, netdev, Jaroslav Kysela,
linux-arm-kernel
In-Reply-To: <1480593549-6464-2-git-send-email-peda@axentia.se>
On Thu, Dec 01, 2016 at 12:59:08PM +0100, Peter Rosin wrote:
> The SSC is currently not usable with the ASoC simple-audio-card, as
> every SSC audio user has to build a platform driver that may do as
> little as calling atmel_ssc_set_audio/atmel_ssc_put_audio (which
> allocates the SSC and registers a DAI with the ASoC subsystem).
>
> So, have that happen automatically, if the #sound-dai-cells property
> is present in devicetree, which it has to be anyway for simple audio
> card to work.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> .../devicetree/bindings/misc/atmel-ssc.txt | 2 +
Acked-by: Rob Herring <robh@kernel.org>
> drivers/misc/atmel-ssc.c | 50 ++++++++++++++++++++++
> include/linux/atmel-ssc.h | 1 +
> 3 files changed, 53 insertions(+)
^ permalink raw reply
* Re: [PATCH v3 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node
From: Bartosz Golaszewski @ 2016-12-06 15:06 UTC (permalink / raw)
To: Sekhar Nori
Cc: Mark Rutland, linux-devicetree, Kevin Hilman, Michael Turquette,
Jyri Sarha, Russell King, Rob Herring, LKML, Peter Ujfalusi,
Tomi Valkeinen, linux-drm, Frank Rowand, arm-soc,
Laurent Pinchart
In-Reply-To: <e6d7870b-e9fd-242f-0e74-5bae2d2b27f1@ti.com>
2016-12-06 16:03 GMT+01:00 Sekhar Nori <nsekhar@ti.com>:
> On Tuesday 06 December 2016 06:32 PM, Bartosz Golaszewski wrote:
>> 2016-12-05 13:49 GMT+01:00 Tomi Valkeinen <tomi.valkeinen@ti.com>:
>>> On 29/11/16 13:57, Bartosz Golaszewski wrote:
>>>> Add the dumb-vga-dac node to the board DT together with corresponding
>>>> ports and vga connector. This allows to retrieve the edid info from
>>>> the display automatically.
>>>>
>>>
>>> It's a bit difficult to follow this as there's been so many patches
>>> going around. But I take the above is the LCDC node in the base da850
>>> dtsi file? In that case, what is the display_in supposed to present?
>>> It's the first node in the "display chain", so it has no input.
>>>
>>> Also, don't touch da850.dtsi here, just add the "ports" node in the
>>> da850-lcdk.dts file.
>>>
>>> If the da850.dtsi has not been merged yet, I'd change the name of the
>>> lcdc node to something else than "display". It's rather vague. If it's
>>> named "lcdc", reading da850-lcdk.dts becomes much easier, as you'll
>>> refer to "lcdc".
>>>
>>
>> The node is already in Sekhar's branch.
>
> The node name should be 'display' as thats the ePAPR 1.1 generic name
> recommendation. The label is also set to 'display' though and that can
> be changed to lcdc.
>
> A pre-patch to fix that before we modify the node further is welcome.
>
> Thanks,
> Sekhar
I'll include this in v5 together with the change requested by Laurent.
Thanks,
Bartosz
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node
From: Sekhar Nori @ 2016-12-06 15:03 UTC (permalink / raw)
To: Bartosz Golaszewski, Tomi Valkeinen
Cc: Mark Rutland, linux-devicetree, David Airlie, Kevin Hilman,
Michael Turquette, Russell King, linux-drm, LKML, Rob Herring,
Jyri Sarha, Frank Rowand, arm-soc, Laurent Pinchart
In-Reply-To: <CAMpxmJUDyZmokJsf=RdP1DwzA_4Xc+Oh3SuSg_OenQOO5mqLvw@mail.gmail.com>
On Tuesday 06 December 2016 06:32 PM, Bartosz Golaszewski wrote:
> 2016-12-05 13:49 GMT+01:00 Tomi Valkeinen <tomi.valkeinen@ti.com>:
>> On 29/11/16 13:57, Bartosz Golaszewski wrote:
>>> Add the dumb-vga-dac node to the board DT together with corresponding
>>> ports and vga connector. This allows to retrieve the edid info from
>>> the display automatically.
>>>
>>
>> It's a bit difficult to follow this as there's been so many patches
>> going around. But I take the above is the LCDC node in the base da850
>> dtsi file? In that case, what is the display_in supposed to present?
>> It's the first node in the "display chain", so it has no input.
>>
>> Also, don't touch da850.dtsi here, just add the "ports" node in the
>> da850-lcdk.dts file.
>>
>> If the da850.dtsi has not been merged yet, I'd change the name of the
>> lcdc node to something else than "display". It's rather vague. If it's
>> named "lcdc", reading da850-lcdk.dts becomes much easier, as you'll
>> refer to "lcdc".
>>
>
> The node is already in Sekhar's branch.
The node name should be 'display' as thats the ePAPR 1.1 generic name
recommendation. The label is also set to 'display' though and that can
be changed to lcdc.
A pre-patch to fix that before we modify the node further is welcome.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH v5 11/14] ASoC: add simple-graph-card document
From: Rob Herring @ 2016-12-06 15:03 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Mark Brown, Linux-ALSA, Liam Girdwood, Simon, Laurent, Guennadi,
Grant Likely, Frank Rowand, Linux-DT, Linux-Kernel
In-Reply-To: <87h96hc1us.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
On Mon, Dec 5, 2016 at 6:57 PM, Kuninori Morimoto
<kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
>
> Hi Rob
>
>> I'd expect the top level node to be the card node that knows how to find
>> all the components. The graph should reflect the data flow. For example,
>> the data goes to audio DSP to I2S host to codec to amp.
>
> Do you mean, is this OK for OF graph ?
Yes, something like this.
> in driver point of view, "I2S" is sound card here.
Well, that seems odd to me because I2S should just be the h/w block
that interfaces to I2S/SSI signals. I'd expect you still have a card
node that references these nodes. Maybe it just references the DSP and
then you walk the graph from there to find the I2S controller and
codec.
>
> I2S {
> port {
> i2s-dsp: endpoint {
> remote-endpoint = <&dsp>;
> }
> i2s-codec: endpoint {
> remote-endpoint = <&codec>;
> }
> }
> }
>
> DSP {
> port {
> dsp: endpoint {
> remote-endpoint = <&i2s-dsp>;
> }
> }
> }
>
> Codec {
> port {
> codec: endpoint {
> remote-endpoint = <&i2s-codec>;
> }
> }
> }
--
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 00/16] FSI device driver introduction
From: christopher.lee.bostic-Re5JQEeQqe8AvxtiuMwx3w @ 2016-12-06 15:01 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, jk-mnsaURCQ41sdnm+yROfE0A,
gustavo.padovan-ZGY8ohtN/8pPYcu2f3hruQ,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
daniel.vetter-/w4YWyX8dFk, dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
afd-l0cyMroinI0, sre-DgEjT+Ai2ygdnm+yROfE0A,
mturquette-rdvid1DuHRBWk0Htik3J/w,
j.anaszewski-Sze3O3UU22JBDgjK7y7TUQ,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ, mst-H+wXaHxf7aLQT0dZR+AlfA,
yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A,
krzk-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: joel-U3u1mxZcP9KHXe+LvDLADg, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
zahrens-r/Jw6+rmf7HQT0dZR+AlfA, xxpetri-tA70FqPdS9bQT0dZR+AlfA,
Chris Bostic, andrew-zrmu5oMJ5Fs, alistair-Y4h6yKqj69EXC2x5gXVKYQ,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r
From: Chris Bostic <cbostic-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Introduction of the IBM 'Flexible Support Interface' (FSI) bus device
driver. FSI is a high fan out serial bus consisting of a clock and a serial
data line capable of running at speeds up to 166 MHz.
This set provides the basic framework to add FSI extensions to the
Linux bus and device models. Master specific implementations are
defined to utilize the core FSI function.
In Linux, we have a core FSI "bus type", along with drivers for FSI
masters and engines.
The FSI master drivers expose a read/write interface to the bus address
space. The master drivers are under drivers/fsi/fsi-master-*.c.
The core handles probing and discovery of slaves and slave
engines, using those read/write interfaces. It is responsible for
creating the endpoint Linux devices corresponding to the discovered
engines on each slave.
Slave engines are identified by an 'engine' type, and an optional
version. Engine, a.k.a. client, drivers are matched and bound to these
engines during discovery.
This patch set does not include extended FSI function such as:
* Hub master support
* Cascaded master support
* Application layer hot plug notification
* Application layer FSI bus status interface
Common FSI terminology:
* Master
Controller of the FSI bus. Only the master is allowed to control the
clock line and is the initiator of all transactions on a bus.
* Slave
The receiver or target of a master initiated transaction. The slave
cannot initiate communications on a bus and must respond to any
master requests for data.
* CFAM
Stands for Common Field replaceable unit Access Macro. A CFAM is an
ASIC residing in any device requiring FSI communications. CFAMs
consist of an array of hardware 'engines' used for various purposes.
I2C masters, UARTs, General Purpose IO hardware are common types of
these engines.
* Configuration Space / Table
A table contained at the beginning of each CFAM address space.
This table lists information such as the CFAM's ID, which engine types
and versions it has available, as well as its addressing range.
* FSI Engine driver
A device driver that registers with the FSI core so that it can access
devices it owns on an FSI bus.
Chris Bostic (5):
drivers/fsi: Set up links for slave communication
drivers/fsi: Set slave SMODE to init communication
drivers/fsi: Add master unscan
drivers/fsi: Add documentation for GPIO bindings
drivers/fsi: Add GPIO based FSI master
Jeremy Kerr (11):
drivers/fsi: Add empty fsi bus definitions
drivers/fsi: Add device & driver definitions
drivers/fsi: add driver to device matches
drivers/fsi: Add fsi master definition
drivers/fsi: Add fake master driver
drivers/fsi: Add slave definition
drivers/fsi: Add empty master scan
drivers/fsi: Add crc4 helpers
drivers/fsi: Implement slave initialisation
drivers/fsi: scan slaves & register devices
drivers/fsi: Add device read/write/peek functions
.../devicetree/bindings/fsi/fsi-master-gpio.txt | 21 +
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/fsi/Kconfig | 29 ++
drivers/fsi/Makefile | 4 +
drivers/fsi/fsi-core.c | 514 +++++++++++++++++++
drivers/fsi/fsi-master-fake.c | 95 ++++
drivers/fsi/fsi-master-gpio.c | 552 +++++++++++++++++++++
drivers/fsi/fsi-master.h | 62 +++
include/linux/fsi.h | 60 +++
10 files changed, 1340 insertions(+)
create mode 100644 Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt
create mode 100644 drivers/fsi/Kconfig
create mode 100644 drivers/fsi/Makefile
create mode 100644 drivers/fsi/fsi-core.c
create mode 100644 drivers/fsi/fsi-master-fake.c
create mode 100644 drivers/fsi/fsi-master-gpio.c
create mode 100644 drivers/fsi/fsi-master.h
create mode 100644 include/linux/fsi.h
--
1.8.2.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
^ permalink raw reply
* Re: [PATCH v2 1/2] devicetree: i2c-hid: Add Wacom digitizer + regulator support
From: Rob Herring @ 2016-12-06 14:56 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Brian Norris, Jiri Kosina, Caesar Wang,
open list:ARM/Rockchip SoC..., linux-input@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Dmitry Torokhov, Mark Rutland, Doug Anderson
In-Reply-To: <20161206084803.GR1280@mail.corp.redhat.com>
On Tue, Dec 6, 2016 at 2:48 AM, Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
> On Dec 05 2016 or thereabouts, Rob Herring wrote:
>> On Thu, Dec 01, 2016 at 09:24:50AM -0800, Brian Norris wrote:
>> > Hi Benjamin and Rob,
>> >
>> > On Thu, Dec 01, 2016 at 03:34:34PM +0100, Benjamin Tissoires wrote:
>> > > On Nov 30 2016 or thereabouts, Brian Norris wrote:
>> > > > From: Caesar Wang <wxt@rock-chips.com>
>> > > >
>> > > > Add a compatible string and regulator property for Wacom W9103
>> > > > digitizer. Its VDD supply may need to be enabled before using it.
>> > > >
>> > > > Signed-off-by: Caesar Wang <wxt@rock-chips.com>
>> > > > Cc: Rob Herring <robh+dt@kernel.org>
>> > > > Cc: Jiri Kosina <jikos@kernel.org>
>> > > > Cc: linux-input@vger.kernel.org
>> > > > Signed-off-by: Brian Norris <briannorris@chromium.org>
>> > > > ---
>> > > > v1 was a few months back. I finally got around to rewriting it based on
>> > > > DT binding feedback.
>> > > >
>> > > > v2:
>> > > > * add compatible property for wacom
>> > > > * name the regulator property specifically (VDD)
>> > > >
>> > > > Documentation/devicetree/bindings/input/hid-over-i2c.txt | 6 +++++-
>> > > > 1 file changed, 5 insertions(+), 1 deletion(-)
>> > > >
>> > > > diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.txt b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
>> > > > index 488edcb264c4..eb98054e60c9 100644
>> > > > --- a/Documentation/devicetree/bindings/input/hid-over-i2c.txt
>> > > > +++ b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
>> > > > @@ -11,12 +11,16 @@ If this binding is used, the kernel module i2c-hid will handle the communication
>> > > > with the device and the generic hid core layer will handle the protocol.
>> > > >
>> > > > Required properties:
>> > > > -- compatible: must be "hid-over-i2c"
>> > > > +- compatible: must be "hid-over-i2c", or a device-specific string like:
>> > > > + * "wacom,w9013"
>> > >
>> > > NACK on this one.
>> > >
>> > > After re-reading the v1 submission I realized Rob asked for this change,
>> > > but I strongly disagree.
>> > >
>> > > HID over I2C is a generic protocol, in the same way HID over USB is. We
>> > > can not start adding device specifics here, this is opening the can of
>> > > worms. If the device is a HID one, nothing else should matter. The rest
>> > > (description of the device, name, etc...) is all provided by the
>> > > protocol.
>> >
>> > I should have spoken up when Rob made the suggestion, because I more or
>> > less agree with Benjamin here. I don't really see why this needs to have
>> > a specialized compatible string, as the property is still fairly
>> > generic, and the entire device handling is via a generic protocol. The
>> > fact that we manage its power via a regulator is not very
>> > device-specific.
>>
>> It doesn't matter that the protocol is generic. The device attached and
>> the implementation is not. Implementations have been known to have
>> bugs/quirks (generally speaking, not HID over I2C in particular). There
>> are also things outside the scope of what is 'hid-over-i2c' like what's
>> needed to power-on the device which this patch clearly show.
>
> Yes, there are bugs, quirks, even with HID. But the HID declares within
> the protocol the Vendor ID and the Product ID, which means once we pass
> the initial "device is ready" step and can do a single i2c write/read,
> we don't give a crap about device tree anymore.
>
> This is just about setting the device in shape so that it can answer a
> single write/read.
>
>>
>> This is no different than a panel attached via LVDS, eDP, etc., or
>> USB/PCIe device hard-wired on a board. They all use standard protocols
>> and all need additional data to describe them. Of course, adding a
>> single property for a delay would not be a big deal, but it's never
>> ending. Next you need multiple supplies, GPIO controls, mutiple
>> delays... This has been discussed to death already. As Thierry Reding
>> said, you're not special[1].
>
> I can somewhat understand what you mean. The official specification is
> for ACPI. And ACPI allows to calls various settings while querying the
> _STA method for instance. So in the ACPI world, we don't need to care
> about regulators or GPIOs because the OEM deals with this in its own
> blob.
>
> Now, coming back to our issue. We are not special, maybe, if he says so.
> But this really feels like a design choice between putting the burden on
> device tree and OEMs or in the module maintainers. And I'd rather have
> the OEM deal with their device than me having to update the module for
> each generations of hardware. Indeed, this looks like an "endless"
> amount of quirks, but I'd rather have this endless amount of quirks than
> having to maintain an endless amount of list of new devices that behaves
> the same way. We are talking here about "wacom,w9013", but then comes
> "wacom,w9014" and we need to upgrade the kernel.
No. If the w9014 can claim compatibility with then w9013, then you
don't need a kernel change. The DT should list the w9014 AND w9013,
but the kernel only needs to know about the w9013. That is until there
is some difference which is why the DT should list w9014 to start
with.
If you don't have any power control to deal with, then the kernel can
always just match on "hid-over-i2c" compatible.
> I have dealt with that for the wacom modules for years, and this is
> definitively not a good solution.
>
> And one additional caveat of this solution is the time between the
> release of the new device and its readiness in the hands of the
> consumer. You need to push a patch upstream, then backport it or wait
> for it to come to your distribution. While if there is a device tree
> specific quirk, you just read the spec of the device and applies it to
> your device tree and you are good to go.
>
> So no, I don't buy this. If hardware makers want to have fancy way of
> initializing their devices, we can cope with those, but I don't want to
> do the Device Tree job in a kernel module were you need to recompile it
> each time a new device appears.
>
>>
>> Now if you want to make 'hid-over-i2c' a fallback to 'wacom,w9013', I'm
>> fine with that.
>
> I agree to have some sort of quirks in the i2c-hid module, but
> definitively not a list of devices with a specific initialization
> sequence. Device Tree has also been introduced to remove the specific
> platform devices, and you are basically asking us to go back there,
> which I don't want.
That is not correct. DT does not abstract the h/w to hide
implementation details like ACPI does with AML code. We still have
specific platform drivers and always will. DT is about removing the
board files and describing connections between devices.
Rob
^ permalink raw reply
* Re: [RESEND/PATCH v6 3/3] clk: qcom: Add A53 clock driver
From: Georgi Djakov @ 2016-12-06 14:47 UTC (permalink / raw)
To: Bjorn Andersson, Stephen Boyd
Cc: mturquette, linux-clk, linux-kernel, linux-arm-msm, devicetree,
Rob Herring
In-Reply-To: <20161205212644.GB30492@tuxbot>
On 12/05/2016 11:26 PM, Bjorn Andersson wrote:
> On Mon 14 Nov 14:21 PST 2016, Stephen Boyd wrote:
>
>> On 11/11, Georgi Djakov wrote:
>>> On 11/03/2016 08:28 PM, Bjorn Andersson wrote:
> [..]
>>>> I'm in favour of us inventing a kicker API and it's found outside out
>>>> use cases as well (e.g. virtio/rpmsg).
>>>>
>>
>> I'd rather we did this kicker API as well. That way we don't need
>> to make a syscon and a simple-mfd to get software to work
>> properly. Don't other silicon vendors need a kicker API as well?
>> How are they kicking remote processors in other places? GPIOs?
>>
>
> In remoteproc I have two of these:
> 1) da8xx_remoteproc ioremaps a register and writes a bit in it (looks
> similar to the downstream Qualcomm way)
>
> 2) omap_remoteproc acquires a mbox channel, in which it writes a
> virtqueue id to kick the remote.
>
> So one of the two cases could have used such mechanism.
>
I also see the potential users of such API mostly in the
remoteproc/rpmgs subsystems.
> We could write up a Qualcomm specific "kicker" and probe the mailing
> list regarding the interest in making that generic (i.e. changing the
> names in the API and DT binding).
Yes, i am planing to do this.
>
> The sucky part is that I believe we have most of our kickers in place
> already so rpm, smd, smp2p, smsm etc would all need to support both
> mechanisms.
Agree.. we have to keep compatibility with existing dtbs.
Thanks,
Georgi
^ permalink raw reply
* Re: [PATCH] dts: sun8i-h3: correct UART3 pin definitions
From: Maxime Ripard @ 2016-12-06 14:31 UTC (permalink / raw)
To: arm-DgEjT+Ai2ygdnm+yROfE0A, jorik-U9/BOH3cVv3CLqq/8VZgpA
Cc: wens-jdAy2FN1RRM, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161206142710.6450-1-jorik-U9/BOH3cVv3CLqq/8VZgpA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 873 bytes --]
Hi Arnd, Olof,
On Tue, Dec 06, 2016 at 03:27:10PM +0100, jorik-U9/BOH3cVv3CLqq/8VZgpA@public.gmane.org wrote:
> From: Jorik Jonker <jorik-U9/BOH3cVv3CLqq/8VZgpA@public.gmane.org>
>
> In a previous commit, I made a copy/paste error in the pinmux
> definitions of UART3: PG{13,14} instead of PA{13,14}. This commit takes
> care of that. I have tested this commit on Orange Pi PC and Orange Pi
> Plus, and it works for these boards.
>
> Fixes: e3d11d3c45c5 ("dts: sun8i-h3: add pinmux definitions for
> UART2-3")
>
> Signed-off-by: Jorik Jonker <jorik-U9/BOH3cVv3CLqq/8VZgpA@public.gmane.org>
Could you please queue that patch for 4.9, with
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: sun8i: Specify memblock for Nano Pi M1
From: Milo Kim @ 2016-12-06 14:28 UTC (permalink / raw)
To: Maxime Ripard; +Cc: Chen-Yu Tsai, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20161206140025.hnlhnsouvohxweou@lukather>
On 12/06/2016 11:00 PM, Maxime Ripard wrote:
> No, we need a recent U-Boot in order to boot, and such a uboot will
> setup the memory node anyway.
Got it. Thanks! Please just ignore my patches.
Best regards,
Milo
^ permalink raw reply
* [PATCH] dts: sun8i-h3: correct UART3 pin definitions
From: jorik @ 2016-12-06 14:27 UTC (permalink / raw)
To: arm, maxime.ripard, wens
Cc: mark.rutland, devicetree, linux, linux-kernel, linux-sunxi,
robh+dt, linux-arm-kernel, Jorik Jonker
From: Jorik Jonker <jorik@kippendief.biz>
In a previous commit, I made a copy/paste error in the pinmux
definitions of UART3: PG{13,14} instead of PA{13,14}. This commit takes
care of that. I have tested this commit on Orange Pi PC and Orange Pi
Plus, and it works for these boards.
Fixes: e3d11d3c45c5 ("dts: sun8i-h3: add pinmux definitions for
UART2-3")
Signed-off-by: Jorik Jonker <jorik@kippendief.biz>
---
arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 75a8654..f4ba088 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -410,7 +410,7 @@
};
uart3_pins: uart3 {
- allwinner,pins = "PG13", "PG14";
+ allwinner,pins = "PA13", "PA14";
allwinner,function = "uart3";
allwinner,drive = <SUN4I_PINCTRL_10_MA>;
allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
--
2.9.3
^ permalink raw reply related
* Re: [PATCH 2/3] crypto: brcm: Add Broadcom SPU driver
From: Mark Rutland @ 2016-12-06 14:18 UTC (permalink / raw)
To: Rob Rice
Cc: Herbert Xu, David S. Miller, Rob Herring,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Ray Jui, Scott Branden,
Jon Mason, bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
Catalin Marinas, Will Deacon,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Steve Lin
In-Reply-To: <1480536453-24781-3-git-send-email-rob.rice-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Wed, Nov 30, 2016 at 03:07:32PM -0500, Rob Rice wrote:
> +static const struct of_device_id bcm_spu_dt_ids[] = {
> + {
> + .compatible = "brcm,spum-crypto",
> + .data = &spum_ns2_types,
> + },
> + {
> + .compatible = "brcm,spum-nsp-crypto",
> + .data = &spum_nsp_types,
> + },
> + {
> + .compatible = "brcm,spu2-crypto",
> + .data = &spu2_types,
> + },
> + {
> + .compatible = "brcm,spu2-v2-crypto",
> + .data = &spu2_v2_types,
> + },
These last two weren't in the binding document.
> + { /* sentinel */ }
> +};
> +
> +MODULE_DEVICE_TABLE(of, bcm_spu_dt_ids);
> +
> +static int spu_dt_read(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct spu_hw *spu = &iproc_priv.spu;
> + struct device_node *dn = pdev->dev.of_node;
> + struct resource *spu_ctrl_regs;
> + const struct of_device_id *match;
> + struct spu_type_subtype *matched_spu_type;
> + void __iomem *spu_reg_vbase[MAX_SPUS];
> + int i;
> + int err;
> +
> + if (!of_device_is_available(dn)) {
> + dev_crit(dev, "SPU device not available");
> + return -ENODEV;
> + }
How can this happen?
> + /* Count number of mailbox channels */
> + spu->num_chan = of_count_phandle_with_args(dn, "mboxes", "#mbox-cells");
> + dev_dbg(dev, "Device has %d SPU channels", spu->num_chan);
> +
> + match = of_match_device(of_match_ptr(bcm_spu_dt_ids), dev);
> + matched_spu_type = (struct spu_type_subtype *)match->data;
This cast usn't necessary.
> + spu->spu_type = matched_spu_type->type;
> + spu->spu_subtype = matched_spu_type->subtype;
> +
> + /* Read registers and count number of SPUs */
> + i = 0;
> + while ((i < MAX_SPUS) && ((spu_ctrl_regs =
> + platform_get_resource(pdev, IORESOURCE_MEM, i)) != NULL)) {
> + dev_dbg(dev,
> + "SPU %d control register region res.start = %#x, res.end = %#x",
> + i,
> + (unsigned int)spu_ctrl_regs->start,
> + (unsigned int)spu_ctrl_regs->end);
> +
> + spu_reg_vbase[i] = devm_ioremap_resource(dev, spu_ctrl_regs);
> + if (IS_ERR(spu_reg_vbase[i])) {
> + err = PTR_ERR(spu_reg_vbase[i]);
> + dev_err(&pdev->dev, "Failed to map registers: %d\n",
> + err);
> + spu_reg_vbase[i] = NULL;
> + return err;
> + }
> + i++;
> + }
These *really* sound like independent devices. There are no shared
registers, and each has its own mbox.
Why do we group them like this?
Thanks,
Mark.
--
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 1/3] crypto: brcm: DT documentation for Broadcom SPU driver
From: Mark Rutland @ 2016-12-06 14:06 UTC (permalink / raw)
To: Rob Rice
Cc: Herbert Xu, David S. Miller, Rob Herring, linux-crypto,
devicetree, linux-kernel, Ray Jui, Scott Branden, Jon Mason,
bcm-kernel-feedback-list, Catalin Marinas, Will Deacon,
linux-arm-kernel, Steve Lin
In-Reply-To: <1480536453-24781-2-git-send-email-rob.rice@broadcom.com>
On Wed, Nov 30, 2016 at 03:07:31PM -0500, Rob Rice wrote:
> Device tree documentation for Broadcom Secure Processing Unit
> (SPU) crypto driver.
>
> Signed-off-by: Steve Lin <steven.lin1@broadcom.com>
> Signed-off-by: Rob Rice <rob.rice@broadcom.com>
> ---
> .../devicetree/bindings/crypto/brcm,spu-crypto.txt | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
>
> diff --git a/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt b/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
> new file mode 100644
> index 0000000..e5fe942
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
> @@ -0,0 +1,25 @@
> +The Broadcom Secure Processing Unit (SPU) driver supports symmetric
> +cryptographic offload for Broadcom SoCs with SPU hardware. A SoC may have
> +multiple SPU hardware blocks.
Bindings shound describe *hardware*, not *drivers*. Please drop mention
of the driver, and just decribe the hardware.
> +Required properties:
> +- compatible : Should be "brcm,spum-crypto" for devices with SPU-M hardware
> + (e.g., Northstar2) or "brcm,spum-nsp-crypto" for the Northstar Plus variant
> + of the SPU-M hardware.
> +
> +- reg: Should contain SPU registers location and length.
> +- mboxes: A list of mailbox channels to be used by the kernel driver. Mailbox
> +channels correspond to DMA rings on the device.
> +
> +Example:
> + spu-crypto@612d0000 {
> + compatible = "brcm,spum-crypto";
> + reg = <0 0x612d0000 0 0x900>, /* SPU 0 control regs */
> + <0 0x612f0000 0 0x900>, /* SPU 1 control regs */
> + <0 0x61310000 0 0x900>, /* SPU 2 control regs */
> + <0 0x61330000 0 0x900>; /* SPU 3 control regs */
The above didn't mention there were several register sets, and the
comment beside each makes them sound like they're separate SPU
instances, so I don't think it makes sense to group them as one node.
What's going on here?
> + mboxes = <&pdc0 0>,
> + <&pdc1 0>,
> + <&pdc2 0>,
> + <&pdc3 0>;
Does each mbox correspond to one of the SPUs above? Or is there a shared
pool?
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH] dts: sun8i-h3: correct UART3 pin definitions
From: Maxime Ripard @ 2016-12-06 14:05 UTC (permalink / raw)
To: jorik-U9/BOH3cVv3CLqq/8VZgpA
Cc: wens-jdAy2FN1RRM, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, arm-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <20161204122948.11921-1-jorik-U9/BOH3cVv3CLqq/8VZgpA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 917 bytes --]
Hi Jorik,
On Sun, Dec 04, 2016 at 01:29:48PM +0100, jorik-U9/BOH3cVv3CLqq/8VZgpA@public.gmane.org wrote:
> From: Jorik Jonker <jorik-U9/BOH3cVv3CLqq/8VZgpA@public.gmane.org>
>
> In a previous commit, I made a copy/paste error in the pinmux
> definitions of UART3: PG{13,14} instead of PA{13,14}. This commit takes
> care of that. I have tested this commit on Orange Pi PC and Orange Pi
> Plus, and it works for these boards.
>
> Fixes: e3d11d3c45c5 ("dts: sun8i-h3: add pinmux definitions for
> UART2-3")
>
> Signed-off-by: Jorik Jonker <jorik-U9/BOH3cVv3CLqq/8VZgpA@public.gmane.org>
Thanks!
This looks like a late fix for the current release which comes to an
end. Can you resend it with arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org as a recipient, so that the
ARM SoC maintainers can apply it directly?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v4 1/7] MFD: add bindings for STM32 General Purpose Timer driver
From: Benjamin Gaignard @ 2016-12-06 14:02 UTC (permalink / raw)
To: Lee Jones
Cc: robh+dt, Mark Rutland, alexandre.torgue, devicetree,
Linux Kernel Mailing List, Thierry Reding, linux-pwm,
Jonathan Cameron, knaack.h, Lars-Peter Clausen,
Peter Meerwald-Stadler, linux-iio, linux-arm-kernel,
Fabrice Gasnier, Gerald Baeza, Arnaud Pouliquen, Linus Walleij,
Linaro Kernel Mailman List, Benjamin Gaignard
In-Reply-To: <20161206130048.GH25385@dell.home>
[snip]
>
> I'm not going to push too hard, but I still thing "advanced-control"
> would suit better, since this is not *just* a timer. In fact, the
> parent device (the MFD) doesn't have any timer functionality. That's
> what "timer@0" does.
>
> The IP is called "Advanced Control" in the datasheet, no?
In datasheet only timers 1 and 8 are called "advanced-control" timers
Timers 2 to 5 and 9 to 14 are called "general purpose" timers.
Timers 6 and 7 are named "basic" timers.
I have ask around in ST and it seems that "general purpose" name was the
best to describe all the timers, so I would like to keep using it.
>
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-gptimer";
>> + reg = <0x40010000 0x400>;
>> + clocks = <&rcc 0 160>;
>> + clock-names = "clk_int";
>> +
>> + pwm@0 {
>> + compatible = "st,stm32-pwm";
>> + pinctrl-0 = <&pwm1_pins>;
>> + pinctrl-names = "default";
>> + };
>> +
>> + timer@0 {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <0>;
>> + };
>> + };
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 1/3] iio: adc: add device tree bindings for Qualcomm PM8xxx ADCs
From: Peter Meerwald-Stadler @ 2016-12-06 14:00 UTC (permalink / raw)
To: Linus Walleij
Cc: Jonathan Cameron, linux-iio, devicetree, linux-arm-kernel,
linux-arm-msm, Ivan T . Ivanov, Andy Gross, Bjorn Andersson,
Stephen Boyd
In-Reply-To: <1481032253-27019-1-git-send-email-linus.walleij@linaro.org>
> This adds the device tree bindings for the Qualcomm PM8xxx
> ADCs. This is based on the existing DT bindings for the
> SPMI ADC so there are hopefully no controversial features.
nitpicking below
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-arm-msm@vger.kernel.org
> Cc: Ivan T. Ivanov <iivanov.xz@gmail.com>
> Cc: Andy Gross <andy.gross@linaro.org>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Stephen Boyd <sboyd@codeaurora.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> .../bindings/iio/adc/qcom,pm8xxx-xoadc.txt | 160 +++++++++++++++++++++
> 1 file changed, 160 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> new file mode 100644
> index 000000000000..6e51e3e74b88
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> @@ -0,0 +1,160 @@
> +Qualcomm's PM8xxx voltage XOADC
> +
> +The Qualcomm PM8xxx PMICs contain a HK/XO ADC (Housekeeping/Chrystal
crystal
> +oscillator ADC) encompass PM8018, PM8038, PM8058, PM8917 and PM8921.
encompassing
> +
> +Required properties:
> +
> +- compatible: should be one of:
> + "qcom,pm8018-adc"
> + "qcom,pm8038-adc"
> + "qcom,pm8058-adc"
> + "qcom,pm8917-adc"
> + "qcom,pm8921-adc"
> +
> +- reg: should contain the ADC base address in the PMIC, typically
> + 0x197.
> +
> +The following required properties are standard for IO channels, see
> +iio-bindings.txt for more details:
> +
> +- #address-cells: should be set to <1>
> +
> +- #size-cells: should be set to <0>
> +
> +- #io-channel-cells: should be set to <1>
> +
> +- interrupts: should refer to the parent PMIC interrupt controller
> + and reference the proper ADC interrupt.
> +
> +Required subnodes:
> +
> +The ADC channels are configured as subnodes of the ADC. Since some of
> +them are used for calibrating the ADC, these nodes are compulsory:
> +
> +ref_625mv {
> + reg = <0x0c>;
> +};
> +
> +ref_1250mv {
> + reg = <0x0d>;
> +};
> +
> +ref_muxoff {
> + reg = <0x0f>;
> +};
> +
> +These three nodes are used for absolute and ratiometric calibration
> +and only need to have these reg values: they are by hardware defined
they are by hardware definition 1:1 ratio converters that sample ...
> +to be 1:1 ratio converters that sample 625, 1250 and 0 V and create
milliV
or 0.625, 1.250 V
> +an interpolation calibration for all other ADCs.
> +
> +Optional subnodes: any channels other than channel 0x0c, 0x0d and
> +0x0f are optional.
> +
> +Required channel node properties:
> +
> +- reg: should contain the hardware channel number in the range
> + 0 .. 0x0f (4 bits). The hardware only supports 16 channels.
> +
> +Optional channel node properties:
> +
> +- qcom,decimation:
> + Value type: <u32>
> + Definition: This parameter is used to decrease ADC sampling rate.
> + Quicker measurements can be made by reducing decimation ratio.
> + Valid values are 512, 1024, 2048, 4096.
> + If property is not found, default value of 512 will be used.
> +
> +- qcom,ratiometric:
> + Value type: <empty>
> + Definition: Channel calibration type. If this property is specified
> + VADC will use the VDD reference (1.8V) and GND for channel
> + calibration. If property is not found, channel will be
> + calibrated with 0.625V and 1.25V reference channels, also
> + known as absolute calibration.
> +
> +- qcom,ratiometric-ref:
> + Value type: <u32>
> + Definition: The reference voltage pair when using ratiometric
> + calibration:
> + 0 = XO_IN/XOADC_GND
> + 1 = PMIC_IN/XOADC_GND
> + 2 = PMIC_IN/BMS_CSP
> + 3 (invalid)
> + 4 = XOADC_GND/XOADC_GND
> + 5 = XOADC_VREF/XOADC_GND
> +
> +Example:
> +
> +xoadc: xoadc@197 {
> + compatible = "qcom,pm8058-adc";
> + reg = <0x197>;
> + interrupt-parent = <&pm8058>;
> + interrupts = <76 1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #io-channel-cells = <1>;
> +
> + vcoin {
> + reg = <0x00>;
> + };
> + vbat {
> + reg = <0x01>;
> + };
> + dcin {
> + reg = <0x02>;
> + };
> + ichg {
> + reg = <0x03>;
> + };
> + vph_pwr {
> + reg = <0x04>;
> + };
> + mpp5 {
> + reg = <0x05>;
> + };
> + mpp6 {
> + reg = <0x06>;
> + };
> + mpp7 {
> + reg = <0x07>;
> + };
> + mpp8 {
> + reg = <0x08>;
> + };
> + mpp9 {
> + reg = <0x09>;
> + };
> + usb_vbus {
> + reg = <0x0a>;
> + };
> + die_temp {
> + reg = <0x0b>;
> + };
> + ref_625mv {
> + reg = <0x0c>;
> + };
> + ref_1250mv {
> + reg = <0x0d>;
> + };
> + ref_325mv {
> + reg = <0x0e>;
> + };
> + ref_muxoff {
> + reg = <0x0f>;
> + };
> +};
> +
> +
> +/* IIO client node */
> +iio-hwmon {
> + compatible = "iio-hwmon";
> + io-channels = <&xoadc 0x01>, /* Battery */
> + <&xoadc 0x02>, /* DC in (charger) */
> + <&xoadc 0x04>, /* VPH the main system voltage */
> + <&xoadc 0x0b>, /* Die temperature */
> + <&xoadc 0x0c>, /* Reference voltage 1.25V */
> + <&xoadc 0x0d>, /* Reference voltage 0.625V */
> + <&xoadc 0x0e>; /* Reference voltage 0.325V */
> +};
>
--
Peter Meerwald-Stadler
+43-664-2444418 (mobile)
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: sun8i: Specify memblock for Nano Pi M1
From: Maxime Ripard @ 2016-12-06 14:00 UTC (permalink / raw)
To: Milo Kim
Cc: Chen-Yu Tsai, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <9607940c-1ca9-bb49-291e-ddc7e77546be-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]
On Tue, Dec 06, 2016 at 04:23:57PM +0900, Milo Kim wrote:
> On 12/05/2016 05:09 PM, Maxime Ripard wrote:
> > On Mon, Dec 05, 2016 at 11:00:31AM +0900, Milo Kim wrote:
> > > The board has DDR3 512MB. This patch helps scanning the memory and
> > > adding memblock through the DT.
> > >
> > > Signed-off-by: Milo Kim <woogyom.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > ---
> > > arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts | 5 +++++
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
> > > index ec63d10..be3668f 100644
> > > --- a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
> > > +++ b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
> > > @@ -45,6 +45,11 @@
> > > / {
> > > model = "FriendlyArm NanoPi M1";
> > > compatible = "friendlyarm,nanopi-m1", "allwinner,sun8i-h3";
> > > +
> > > + memory@40000000 {
> > > + device_type = "memory";
> > > + reg = <0x40000000 0x20000000>;
> > > + };
> >
> > U-boot will fill that up, so there's no need to put it there.
>
> Right, my intention was adding memblock through the DT whether the bootload
> does or not. However I'm not sure the situation (missing memblock in u-boot)
> could really happen.
No, we need a recent U-Boot in order to boot, and such a uboot will
setup the memory node anyway.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH 1/3] iio: adc: add device tree bindings for Qualcomm PM8xxx ADCs
From: Linus Walleij @ 2016-12-06 13:50 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio-u79uwXL29TY76Z2rM5mHXA
Cc: Linus Walleij, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Ivan T . Ivanov, Andy Gross,
Bjorn Andersson, Stephen Boyd
This adds the device tree bindings for the Qualcomm PM8xxx
ADCs. This is based on the existing DT bindings for the
SPMI ADC so there are hopefully no controversial features.
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Ivan T. Ivanov <iivanov.xz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Andy Gross <andy.gross-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
.../bindings/iio/adc/qcom,pm8xxx-xoadc.txt | 160 +++++++++++++++++++++
1 file changed, 160 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
new file mode 100644
index 000000000000..6e51e3e74b88
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
@@ -0,0 +1,160 @@
+Qualcomm's PM8xxx voltage XOADC
+
+The Qualcomm PM8xxx PMICs contain a HK/XO ADC (Housekeeping/Chrystal
+oscillator ADC) encompass PM8018, PM8038, PM8058, PM8917 and PM8921.
+
+Required properties:
+
+- compatible: should be one of:
+ "qcom,pm8018-adc"
+ "qcom,pm8038-adc"
+ "qcom,pm8058-adc"
+ "qcom,pm8917-adc"
+ "qcom,pm8921-adc"
+
+- reg: should contain the ADC base address in the PMIC, typically
+ 0x197.
+
+The following required properties are standard for IO channels, see
+iio-bindings.txt for more details:
+
+- #address-cells: should be set to <1>
+
+- #size-cells: should be set to <0>
+
+- #io-channel-cells: should be set to <1>
+
+- interrupts: should refer to the parent PMIC interrupt controller
+ and reference the proper ADC interrupt.
+
+Required subnodes:
+
+The ADC channels are configured as subnodes of the ADC. Since some of
+them are used for calibrating the ADC, these nodes are compulsory:
+
+ref_625mv {
+ reg = <0x0c>;
+};
+
+ref_1250mv {
+ reg = <0x0d>;
+};
+
+ref_muxoff {
+ reg = <0x0f>;
+};
+
+These three nodes are used for absolute and ratiometric calibration
+and only need to have these reg values: they are by hardware defined
+to be 1:1 ratio converters that sample 625, 1250 and 0 V and create
+an interpolation calibration for all other ADCs.
+
+Optional subnodes: any channels other than channel 0x0c, 0x0d and
+0x0f are optional.
+
+Required channel node properties:
+
+- reg: should contain the hardware channel number in the range
+ 0 .. 0x0f (4 bits). The hardware only supports 16 channels.
+
+Optional channel node properties:
+
+- qcom,decimation:
+ Value type: <u32>
+ Definition: This parameter is used to decrease ADC sampling rate.
+ Quicker measurements can be made by reducing decimation ratio.
+ Valid values are 512, 1024, 2048, 4096.
+ If property is not found, default value of 512 will be used.
+
+- qcom,ratiometric:
+ Value type: <empty>
+ Definition: Channel calibration type. If this property is specified
+ VADC will use the VDD reference (1.8V) and GND for channel
+ calibration. If property is not found, channel will be
+ calibrated with 0.625V and 1.25V reference channels, also
+ known as absolute calibration.
+
+- qcom,ratiometric-ref:
+ Value type: <u32>
+ Definition: The reference voltage pair when using ratiometric
+ calibration:
+ 0 = XO_IN/XOADC_GND
+ 1 = PMIC_IN/XOADC_GND
+ 2 = PMIC_IN/BMS_CSP
+ 3 (invalid)
+ 4 = XOADC_GND/XOADC_GND
+ 5 = XOADC_VREF/XOADC_GND
+
+Example:
+
+xoadc: xoadc@197 {
+ compatible = "qcom,pm8058-adc";
+ reg = <0x197>;
+ interrupt-parent = <&pm8058>;
+ interrupts = <76 1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #io-channel-cells = <1>;
+
+ vcoin {
+ reg = <0x00>;
+ };
+ vbat {
+ reg = <0x01>;
+ };
+ dcin {
+ reg = <0x02>;
+ };
+ ichg {
+ reg = <0x03>;
+ };
+ vph_pwr {
+ reg = <0x04>;
+ };
+ mpp5 {
+ reg = <0x05>;
+ };
+ mpp6 {
+ reg = <0x06>;
+ };
+ mpp7 {
+ reg = <0x07>;
+ };
+ mpp8 {
+ reg = <0x08>;
+ };
+ mpp9 {
+ reg = <0x09>;
+ };
+ usb_vbus {
+ reg = <0x0a>;
+ };
+ die_temp {
+ reg = <0x0b>;
+ };
+ ref_625mv {
+ reg = <0x0c>;
+ };
+ ref_1250mv {
+ reg = <0x0d>;
+ };
+ ref_325mv {
+ reg = <0x0e>;
+ };
+ ref_muxoff {
+ reg = <0x0f>;
+ };
+};
+
+
+/* IIO client node */
+iio-hwmon {
+ compatible = "iio-hwmon";
+ io-channels = <&xoadc 0x01>, /* Battery */
+ <&xoadc 0x02>, /* DC in (charger) */
+ <&xoadc 0x04>, /* VPH the main system voltage */
+ <&xoadc 0x0b>, /* Die temperature */
+ <&xoadc 0x0c>, /* Reference voltage 1.25V */
+ <&xoadc 0x0d>, /* Reference voltage 0.625V */
+ <&xoadc 0x0e>; /* Reference voltage 0.325V */
+};
--
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 v3 1/2] dt-bindings: Document the hi3660 reset bindings
From: Philipp Zabel @ 2016-12-06 13:42 UTC (permalink / raw)
To: Zhangfei Gao
Cc: Rob Herring, Arnd Bergmann, haojian.zhuang-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480989092-31847-2-git-send-email-zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Am Dienstag, den 06.12.2016, 09:51 +0800 schrieb Zhangfei Gao:
> Add DT bindings documentation for hi3660 SoC reset controller.
>
> Signed-off-by: Zhangfei Gao <zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> .../bindings/reset/hisilicon,hi3660-reset.txt | 36 ++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
>
> diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
> new file mode 100644
> index 0000000..178e478
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
> @@ -0,0 +1,36 @@
> +Hisilicon System Reset Controller
> +======================================
> +
> +Please also refer to reset.txt in this directory for common reset
> +controller binding usage.
> +
> +The reset controller registers are part of the system-ctl block on
> +hi3660 SoC.
> +
> +Required properties:
> +- compatible: should be
> + "hisilicon,hi3660-reset"
> +- #reset-cells: 2, see below
> +- hisi,rst-syscon: phandle of the reset's syscon.
> +
> +Example:
> + iomcu: iomcu@ffd7e000 {
> + compatible = "hisilicon,hi3660-iomcu", "syscon";
> + reg = <0x0 0xffd7e000 0x0 0x1000>;
> + };
> +
> + iomcu_rst: iomcu_rst_controller {
> + compatible = "hisilicon,hi3660-reset";
> + hisi,rst-syscon = <&iomcu>;
> + #reset-cells = <2>;
> + };
> +
> +Specifying reset lines connected to IP modules
> +==============================================
> +example:
> +
> + i2c0: i2c@..... {
> + ...
> + resets = <&iomcu_rst 0x20 3>; /* offset: 0x20; bit: 3 */
Should this mention somewhere what register the offset is supposed to
point to? This is the address offset to the set register, with the
corresponding clear register being placed at offset + 4.
> + ...
> + };
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node
From: Laurent Pinchart @ 2016-12-06 13:42 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Kevin Hilman, Michael Turquette, Sekhar Nori, Rob Herring,
Frank Rowand, Mark Rutland, Peter Ujfalusi, Russell King, LKML,
arm-soc, linux-drm, linux-devicetree, Jyri Sarha, Tomi Valkeinen,
David Airlie
In-Reply-To: <1481030026-7329-2-git-send-email-bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Hi Bartosz,
Thank you for the patch.
On Tuesday 06 Dec 2016 14:13:45 Bartosz Golaszewski wrote:
> Add the dumb-vga-dac node to the board DT together with corresponding
> ports and vga connector. This allows to retrieve the edid info from
> the display automatically.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> arch/arm/boot/dts/da850-lcdk.dts | 69 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850-lcdk.dts
> b/arch/arm/boot/dts/da850-lcdk.dts index afcb482..ca437c1 100644
> --- a/arch/arm/boot/dts/da850-lcdk.dts
> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> @@ -51,6 +51,51 @@
> system-clock-frequency = <24576000>;
> };
> };
> +
> + vga-bridge {
> + compatible = "dumb-vga-dac";
Please don't. The board uses a THS8135, which has a few control signals.
They're not used on this board so you can certainly rely on the dumb-vga-dac
driver, but you should not use that compatible string. You should instead add
DT bindings for ti,ths8135 and add that compatible string to the dumb-vga-dac
driver.
The rest looks good to me.
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + vga_bridge_in: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&display_out_vga>;
> + };
> + };
> +
> + port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + vga_bridge_out: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&vga_con_in>;
> + };
> + };
> + };
> + };
> +
> + vga {
> + compatible = "vga-connector";
> +
> + ddc-i2c-bus = <&i2c0>;
> +
> + port {
> + vga_con_in: endpoint {
> + remote-endpoint = <&vga_bridge_out>;
> + };
> + };
> + };
> };
>
> &pmx_core {
> @@ -236,3 +281,27 @@
> &memctrl {
> status = "okay";
> };
> +
> +&display {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_pins>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + display_out: port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> + };
> + };
> +};
> +
> +&display_out {
> + display_out_vga: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&vga_bridge_in>;
> + };
> +};
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 09/13] net: ethernet: ti: cpts: rework initialization/deinitialization
From: Richard Cochran @ 2016-12-06 13:40 UTC (permalink / raw)
To: Grygorii Strashko
Cc: David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA, Mugunthan V N,
Sekhar Nori, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Murali Karicheri, Wingman Kwok,
Thomas Gleixner
In-Reply-To: <20161205200525.16664-10-grygorii.strashko-l0cyMroinI0@public.gmane.org>
On Mon, Dec 05, 2016 at 02:05:21PM -0600, Grygorii Strashko wrote:
> @@ -372,34 +354,27 @@ void cpts_tx_timestamp(struct cpts *cpts, struct sk_buff *skb)
> }
> EXPORT_SYMBOL_GPL(cpts_tx_timestamp);
>
> -int cpts_register(struct device *dev, struct cpts *cpts,
> - u32 mult, u32 shift)
> +int cpts_register(struct cpts *cpts)
> {
> int err, i;
>
> - cpts->info = cpts_info;
> - spin_lock_init(&cpts->lock);
> -
> - cpts->cc.read = cpts_systim_read;
> - cpts->cc.mask = CLOCKSOURCE_MASK(32);
> - cpts->cc_mult = mult;
> - cpts->cc.mult = mult;
> - cpts->cc.shift = shift;
> -
> INIT_LIST_HEAD(&cpts->events);
> INIT_LIST_HEAD(&cpts->pool);
> for (i = 0; i < CPTS_MAX_EVENTS; i++)
> list_add(&cpts->pool_data[i].list, &cpts->pool);
>
> - cpts_clk_init(dev, cpts);
> + clk_enable(cpts->refclk);
> +
> cpts_write32(cpts, CPTS_EN, control);
> cpts_write32(cpts, TS_PEND_EN, int_enable);
>
> + /* reinitialize cc.mult to original value as it can be modified
> + * by cpts_ptp_adjfreq().
> + */
> + cpts->cc.mult = cpts->cc_mult;
This still isn't quite right. First of all, you shouldn't clobber the
learned cc.mult value in cpts_register(). Presumably, if PTP had been
run on this port before, then the learned frequency is approximately
correct, and it should be left alone.
[ BTW, resetting the timecounter here makes no sense either. Why
reset the clock just because the interface goes down? ]
Secondly, you have made the initialization order of these fields hard
to follow. With the whole series applied:
probe()
cpts_create()
cpts_of_parse()
{
/* Set cc_mult but not cc.mult! */
set cc_mult
set cc.shift
}
cpts_calc_mult_shift()
{
/* Set them both. */
cpts->cc_mult = mult;
cpts->cc.mult = mult;
cpts->cc.shift = shift;
}
/* later on */
cpts_register()
cpts->cc.mult = cpts->cc_mult;
There is no need for such complexity. Simply set cc.mult in
cpts_create() _once_, immediately after the call to
cpts_calc_mult_shift().
You can remove the assignment from cpts_calc_mult_shift() and
cpts_register().
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [resend v2: PATCH 1/2] dt-bindings: Document the hi3660 reset bindings
From: Philipp Zabel @ 2016-12-06 13:40 UTC (permalink / raw)
To: Rob Herring
Cc: Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
zhangfei, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161205234028.niukdkygbdni5gvm@rob-hp-laptop>
Am Montag, den 05.12.2016, 17:40 -0600 schrieb Rob Herring:
> On Fri, Dec 02, 2016 at 03:10:13PM +0100, Philipp Zabel wrote:
> > Am Freitag, den 02.12.2016, 13:32 +0100 schrieb Arnd Bergmann:
> > > On Friday, December 2, 2016 8:21:33 AM CET zhangfei wrote:
> > > > Hi, Arnd
> > > >
> > > > On 2016年12月01日 20:05, Arnd Bergmann wrote:
> > > > > On Thursday, December 1, 2016 8:48:40 AM CET Zhangfei Gao wrote:
> > > > >> + hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
> > > > >> + 0x20 0x10 /* 1: i2c1 */
> > > > >> + 0x20 0x20 /* 2: i2c2 */
> > > > >> + 0x20 0x8000000>; /* 3: i2c6 */
> > > > >> + };
> > > > >> +
> > > > >> +Specifying reset lines connected to IP modules
> > > > >> +==============================================
> > > > >> +example:
> > > > >> +
> > > > >> + i2c0: i2c@..... {
> > > > >> + ...
> > > > >> + resets = <&iomcu_rst 0>;
> > > > >> + ...
> > > > >> + };
> > > > > I don't really like this approach, since now the information is
> > > > > in two places. Why not put the data into the reset specifier
> > > > > directly when it is used?
> >
> > From my point of view, with the binding above, all reset controller
> > register/bit layout information is in a single place and can be easily
> > compared to a list in the reference manual, whereas with your suggestion
> > the description of the reset controller register layout is spread
> > throughout one or even several dtsi files.
>
> Which can be solved by tools.
True.
> > Also, since no two reset controllers are exactly the same, we get a
> > proliferation of different slightly phandle argument meanings.
>
> phandle args are supposed to be specific to the phandle it points to.
> Otherwise, we'd never need more than 1 cell and everything could be a
> lookup table.
What I mean is that the clk bindings mostly use <&label index> or
<&label type index> phandles, not <&label register-offset bit-offset>
phandles. Usually the bindings don't spread information about the
register layout of the clock controller throughout the device tree,
because that is contained in the driver, as determined by the compatible
property. I assumed the same should be true for reset controllers, if
possible.
> > > > Any example, still not understand.
> > > > They are consumer and provider.
> > >
> > > I mean in the i2c node, have
> > >
> > > i2c0: i2c@..... {
> > > ...
> > > resets = <&iomcu_rst 0x20 0x8>;
> > > ...
> > > }
> >
> > There already are a few drivers that use this, and I fear people having
> > to change their bindings because new flags are needed that have not been
> > previously thought of.
>
> Drivers that use what?
Drivers that use <&label register-offset bit-offset> phandles instead of
<&label index> phandles.
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [resend v2: PATCH 1/2] dt-bindings: Document the hi3660 reset bindings
From: Philipp Zabel @ 2016-12-06 13:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, zhangfei,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <3449091.bg2i6Oq5SM@wuerfel>
Am Freitag, den 02.12.2016, 23:11 +0100 schrieb Arnd Bergmann:
> On Friday, December 2, 2016 3:10:13 PM CET Philipp Zabel wrote:
> > Am Freitag, den 02.12.2016, 13:32 +0100 schrieb Arnd Bergmann:
> > > On Friday, December 2, 2016 8:21:33 AM CET zhangfei wrote:
> > > > On 2016年12月01日 20:05, Arnd Bergmann wrote:
> > > > > On Thursday, December 1, 2016 8:48:40 AM CET Zhangfei Gao wrote:
> > > > >> + hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
> > > > >> + 0x20 0x10 /* 1: i2c1 */
> > > > >> + 0x20 0x20 /* 2: i2c2 */
> > > > >> + 0x20 0x8000000>; /* 3: i2c6 */
> > > > >> + };
> > > > >> +
> > > > >> +Specifying reset lines connected to IP modules
> > > > >> +==============================================
> > > > >> +example:
> > > > >> +
> > > > >> + i2c0: i2c@..... {
> > > > >> + ...
> > > > >> + resets = <&iomcu_rst 0>;
> > > > >> + ...
> > > > >> + };
> > > > > I don't really like this approach, since now the information is
> > > > > in two places. Why not put the data into the reset specifier
> > > > > directly when it is used?
> >
> > From my point of view, with the binding above, all reset controller
> > register/bit layout information is in a single place and can be easily
> > compared to a list in the reference manual, whereas with your suggestion
> > the description of the reset controller register layout is spread
> > throughout one or even several dtsi files.
> > Also, since no two reset controllers are exactly the same, we get a
> > proliferation of different slightly phandle argument meanings.
>
> There is no reason for this to be any different from other subsystems
> that all do it the same way: interrupts, gpios, dma, clk, ... all
> define #foo-cells to be used for addressing uniform things,
> and the data is only in the reference, so that the node that
> describes the controller needs no knowledge of what it's being
> used for.
For most of those bindings the knowledge about which register and bit
position(s) correspond to the handles resides in the driver.
> One exception is the case (often on clk bindings) where the register
> layout is anything but uniform
The register layout is very non-uniform for many reset controllers. Some
share the same register space with some of those clock controllers.
> and every input line has a completely different behavior.
I can't argue that the behavior is non-uniform for the sane reset
controllers though, most of them have just a single bit, for most
of them all reset lines behave the same.
> For that case, we define our own numbering
> system in the driver and hardcode those tables there.
>
> This reset driver does not seem to belong into that category though.
Yes. From what has been shown so far, it seems that in this case, while
the resets are distributed sparsely, the relative layout (set/clear
registers right next to each other) is uniform.
> Even if it did, we putting information about the controller into
> its own node is redundant as the driver already identifies the
> register layout by the compatible string.
Indeed I would prefer the driver to carry the register layout tables
instead of putting this information into the device tree at all.
> > > > Any example, still not understand.
> > > > They are consumer and provider.
> > >
> > > I mean in the i2c node, have
> > >
> > > i2c0: i2c@..... {
> > > ...
> > > resets = <&iomcu_rst 0x20 0x8>;
> > > ...
> > > }
> >
> > There already are a few drivers that use this, and I fear people having
> > to change their bindings because new flags are needed that have not been
> > previously thought of.
>
> It rarely happens on other subsystems, and the binding can
> always specify different behavior depending on #reset-cells.
I recognize I am biased here. So feel free to ignore this point.
What I'd like to make sure is that we have thought about and are happy
to spread (partial) information about the reset controller register
layout throughout the device tree like this.
regards
Philipp
--
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 v3 1/2] dt-bindings: drm/bridge: adv7511: Add regulator bindings
From: Mark Brown @ 2016-12-06 13:20 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: devicetree, linux-arm-msm, dri-devel, Bjorn Andersson
In-Reply-To: <3208429.mJrxuV2Nx6@avalon>
[-- Attachment #1.1: Type: text/plain, Size: 1141 bytes --]
On Tue, Dec 06, 2016 at 02:46:55PM +0200, Laurent Pinchart wrote:
> On Tuesday 06 Dec 2016 10:05:17 Mark Brown wrote:
> > On Mon, Dec 05, 2016 at 11:16:22PM +0200, Laurent Pinchart wrote:
> > > This has been discussed previously, and Rob agreed that if the datasheet
> > > recommends to power all supplies from the same regulator we can take that
> > > as a good hint that a single supply should be enough. In the very
> > No, don't do this - introducing special snowflake bindings just makes
> > things more complex at the system level and tells everyone else that
> > they too can have special snowflake bindings. Someone should be able to
> > connect up the regulators based purely on a schematic. Just describe
> > the hardware, it's just one extra line in the DT per regulator.
> There are power supply pin that have different names but documented as having
> to be connected to the same supply. I really see no point in having multiple
> regulators for them.
The tiny amount of extra typing involved doesn't seem like much of a
cost for keeping things consistent with every other regulator user out
there.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
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