* Re: [PATCH 2/2] dt-bindings: power: sbs-battery: re-document "ti,bq20z75"
From: Rhyland Klein @ 2018-06-01 16:14 UTC (permalink / raw)
To: Brian Norris, Sebastian Reichel
Cc: linux-kernel, Rob Herring, linux-pm, devicetree, Alexandru Stan,
Guenter Roeck, Doug Anderson
In-Reply-To: <20180601003252.42810-2-briannorris@chromium.org>
On 5/31/2018 8:32 PM, Brian Norris wrote:
> This compatible property was documented before the driver was renamed to
> "SBS" (see commit e57f1b68c406 ("devicetree-bindings: Propagate
> bq20z75->sbs rename to dt bindings")). The driver has continued to
> support this property as an alternative to "sbs,sbs-battery", and
> because we've noticed there are some lingering TI specifics (in the
> manufacturer-specific portion of the SBS spec), we'd like to start using
> this property again to differentiate.
>
> Cc: Rhyland Klein <rklein@nvidia.com>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> .../devicetree/bindings/power/supply/sbs_sbs-battery.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt b/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt
> index c40e8926facf..a7a9c3366f82 100644
> --- a/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt
> +++ b/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt
> @@ -2,7 +2,7 @@ SBS sbs-battery
> ~~~~~~~~~~
>
> Required properties :
> - - compatible : "sbs,sbs-battery"
> + - compatible : "sbs,sbs-battery" or "ti,bq20z75"
>
> Optional properties :
> - sbs,i2c-retry-count : The number of times to retry i2c transactions on i2c
>
Acked-by: Rhyland Klein <rklein@nvidia.com>
--
nvpublic
^ permalink raw reply
* Re: [RFC PATCH 1/8] dts: binding: coresight: Document graph bindings
From: Mathieu Poirier @ 2018-06-01 16:14 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: linux-arm-kernel, sudeep.holla, robh, mark.rutland, frowand.list,
matt.sealey, charles.garcia-tobin, john.horley, mike.leach,
coresight, linux-kernel, devicetree
In-Reply-To: <1527858967-16047-2-git-send-email-suzuki.poulose@arm.com>
On Fri, Jun 01, 2018 at 02:16:00PM +0100, Suzuki K Poulose wrote:
> Before we updat the bindings, document the current graph bindings
s/updat/update
> and usage of additional properties.
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> .../devicetree/bindings/arm/coresight.txt | 28 ++++++++++++++++++----
> 1 file changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
> index 15ac8e8..bd36e40 100644
> --- a/Documentation/devicetree/bindings/arm/coresight.txt
> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
> @@ -52,9 +52,7 @@ its hardware characteristcs.
> clocks the core of that coresight component. The latter clock
> is optional.
>
> - * port or ports: The representation of the component's port
> - layout using the generic DT graph presentation found in
> - "bindings/graph.txt".
> + * port or ports: see "Graph bindings for Coresight" below
>
> * Additional required properties for System Trace Macrocells (STM):
> * reg: along with the physical base address and length of the register
> @@ -71,7 +69,7 @@ its hardware characteristcs.
> AMBA markee):
> - "arm,coresight-replicator"
>
> - * port or ports: same as above.
> + * port or ports: see "Graph bindings for Coresight" below.
>
> * Optional properties for ETM/PTMs:
>
> @@ -86,6 +84,28 @@ its hardware characteristcs.
> * arm,buffer-size: size of contiguous buffer space for TMC ETR
> (embedded trace router)
>
> +Graph bindings for Coresight
> +-------------------------------
> +
> +Coresight components are interconnected to create a data path for the flow of
> +trace data generated from the "sources" to their collection points "sink". Each
Over 80 characters.
> +coresight component must describe the "input" and "output" connections.
> +The connections must be described via generic DT graph bindings as described
> +by the "bindings/graph.txt", where each "port" along with an "endpoint" component
Same here.
> +represents a hardware port and the connection.
> +
> +Since it is possible to have multiple connections for any coresight component with
And here.
> +a specific direction of data flow, each connection must define the following
> +properties to uniquely identify the connection details.
> +
> + * Direction of the data flow w.r.t the component :
> + Each input port must have the following property defined at the "endpoint"
> + for the port.
> + "slave-mode"
> +
> + * Hardware Port number at the component:
> + - The hardware port number is assumed to be the address of the "port" component.
And here.
Moveover this patches doesn't apply to my next tree.
> +
>
> Example:
>
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH 06/15] drm/sun4i: tcon: Add support for tcon-top
From: Chen-Yu Tsai @ 2018-06-01 16:19 UTC (permalink / raw)
To: Maxime Ripard
Cc: Jernej Škrabec, Rob Herring, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
In-Reply-To: <20180601152949.tmw7aitfoo536nxs@flea>
On Fri, Jun 1, 2018 at 8:29 AM, Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> On Thu, May 31, 2018 at 07:54:08PM +0200, Jernej Škrabec wrote:
>> Dne četrtek, 31. maj 2018 ob 11:21:33 CEST je Maxime Ripard napisal(a):
>> > On Thu, May 24, 2018 at 03:01:09PM -0700, Chen-Yu Tsai wrote:
>> > > >> > > + if (tcon->quirks->needs_tcon_top) {
>> > > >> > > + struct device_node *np;
>> > > >> > > +
>> > > >> > > + np = of_parse_phandle(dev->of_node, "allwinner,tcon-top",
>> > > >> > > 0);
>> > > >> > > + if (np) {
>> > > >> > > + struct platform_device *pdev;
>> > > >> > > +
>> > > >> > > + pdev = of_find_device_by_node(np);
>> > > >> > > + if (pdev)
>> > > >> > > + tcon->tcon_top =
>> > > >> > > platform_get_drvdata(pdev);
>> > > >> > > + of_node_put(np);
>> > > >> > > +
>> > > >> > > + if (!tcon->tcon_top)
>> > > >> > > + return -EPROBE_DEFER;
>> > > >> > > + }
>> > > >> > > + }
>> > > >> > > +
>> > > >> >
>> > > >> > I might have missed it, but I've not seen the bindings additions for
>> > > >> > that property. This shouldn't really be done that way anyway, instead
>> > > >> > of using a direct phandle, you should be using the of-graph, with the
>> > > >> > TCON-top sitting where it belongs in the flow of data.
>> > > >>
>> > > >> Just to answer to the first question, it did describe it in "[PATCH
>> > > >> 07/15] dt- bindings: display: sun4i-drm: Add R40 HDMI pipeline".
>> > > >>
>> > > >> As why I designed it that way - HW representation could be described
>> > > >> that way> >>
>> > > >> (ASCII art makes sense when fixed width font is used to view it):
>> > > >> / LCD0/LVDS0
>> > > >>
>> > > >> / TCON-LCD0
>> > > >>
>> > > >> | \ MIPI DSI
>> > > >>
>> > > >> mixer0 |
>> > > >>
>> > > >> \ / TCON-LCD1 - LCD1/LVDS1
>> > > >>
>> > > >> TCON-TOP
>> > > >>
>> > > >> / \ TCON-TV0 - TVE0/RGB
>> > > >>
>> > > >> mixer1 | \
>> > > >>
>> > > >> | TCON-TOP - HDMI
>> > > >> |
>> > > >> | /
>> > > >>
>> > > >> \ TCON-TV1 - TVE1/RGB
>> > > >>
>> > > >> This is a bit simplified, since there is also TVE-TOP, which is
>> > > >> responsible
>> > > >> for sharing 4 DACs between both TVE encoders. You can have two TV outs
>> > > >> (PAL/ NTSC) or TVE0 as TV out and TVE1 as RGB or vice versa. It even
>> > > >> seems that you can arbitrarly choose which DAC is responsible for
>> > > >> which signal, so there is a ton of possible end combinations, but I'm
>> > > >> not 100% sure.
>> > > >>
>> > > >> Even though I wrote TCON-TOP twice, this is same unit in HW. R40 manual
>> > > >> suggest more possibilities, although some of them seem wrong, like RGB
>> > > >> feeding from LCD TCON. That is confirmed to be wrong when checking BSP
>> > > >> code.
>> > > >>
>> > > >> Additionally, TCON-TOP comes in the middle of TVE0 and LCD0, TVE1 and
>> > > >> LCD1 for pin muxing, although I'm not sure why is that needed at all,
>> > > >> since according to R40 datasheet, TVE0 and TVE1 pins are dedicated and
>> > > >> not on PORT D and PORT H, respectively, as TCON-TOP documentation
>> > > >> suggest. However, HSYNC and PSYNC lines might be shared between TVE
>> > > >> (when it works in RGB mode) and LCD. But that is just my guess since
>> > > >> I'm not really familiar with RGB and LCD interfaces.
>> > > >>
>> > > >> I'm really not sure what would be the best representation in OF-graph.
>> > > >> Can you suggest one?
>> > > >
>> > > > Rob might disagree on this one, but I don't see anything wrong with
>> > > > having loops in the graph. If the TCON-TOP can be both the input and
>> > > > output of the TCONs, then so be it, and have it described that way in
>> > > > the graph.
>> > > >
>> > > > The code is already able to filter out nodes that have already been
>> > > > added to the list of devices we need to wait for in the component
>> > > > framework, so that should work as well.
>> > > >
>> > > > And we'd need to describe TVE-TOP as well, even though we don't have a
>> > > > driver for it yet. That will simplify the backward compatibility later
>> > > > on.
>> > >
>> > > I'm getting the feeling that TCON-TOP / TVE-TOP is the glue layer that
>> > > binds everything together, and provides signal routing, kind of like
>> > > DE-TOP on A64. So the signal mux controls that were originally found
>> > > in TCON0 and TVE0 were moved out.
>> > >
>> > > The driver needs to know about that, but the graph about doesn't make
>> > > much sense directly. Without looking at the manual, I understand it to
>> > > likely be one mux between the mixers and TCONs, and one between the
>> > > TCON-TVs and HDMI. Would it make more sense to just have the graph
>> > > connections between the muxed components, and remove TCON-TOP from
>> > > it, like we had in the past? A phandle could be used to reference
>> > > the TCON-TOP for mux controls, in addition to the clocks and resets.
>> > >
>> > > For TVE, we would need something to represent each of the output pins,
>> > > so the device tree can actually describe what kind of signal, be it
>> > > each component of RGB/YUV or composite video, is wanted on each pin,
>> > > if any. This is also needed on the A20 for the Cubietruck, so we can
>> > > describe which pins are tied to the VGA connector, and which one does
>> > > R, G, or B.
>> >
>> > I guess we'll see how the DT maintainers feel about this, but my
>> > impression is that the OF graph should model the flow of data between
>> > the devices. If there's a mux somewhere, then the data is definitely
>> > going through it, and as such it should be part of the graph.
>>
>> I concur, but I spent few days thinking how to represent this sanely in graph,
>> but I didn't find any good solution. I'll represent here my idea and please
>> tell your opinion before I start implementing it.
>>
>> First, let me be clear that mixer0 and mixer1 don't have same capabilities
>> (different number of planes, mixer0 supports writeback, mixer1 does not,
>> etc.). Thus, it does matter which mixer is connected to which TCON/encoder.
>> mixer0 is meant to be connected to main display and mixer1 to auxiliary. That
>> obviously depends on end system.
>>
>> So, TCON TOP has 3 muxes, which have to be represented in graph. Two of them
>> are for mixer/TCON relationship (each of them 1 input and 4 possible outputs)
>> and one for TV TCON/HDMI pair selection (2 possible inputs, 1 output).
>>
>> According to current practice in sun4i-drm driver, graph has to have port 0,
>> representing input and port 1, representing output. This would mean that graph
>> looks something like that:
>>
>> tcon_top: tcon-top@1c70000 {
>> compatible = "allwinner,sun8i-r40-tcon-top";
>> ...
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> tcon_top_in: port@0 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> reg = <0>;
>>
>> tcon_top_in_mixer0: endpoint@0 {
>> reg = <0>;
>> remote-endpoint = <&mixer0_out_tcon_top>;
>> };
>>
>> tcon_top_in_mixer1: endpoint@1 {
>> reg = <1>;
>> remote-endpoint = <&mixer1_out_tcon_top>;
>> };
>>
>> tcon_top_in_tcon_tv: endpoint@2 {
>> reg = <2>;
>> // here is HDMI input connection, part of board DTS
>> remote-endpoint = <board specific phandle to TV TCON output>;
>> };
>> };
>>
>> tcon_top_out: port@1 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> reg = <1>;
>>
>> tcon_top_out_tcon0: endpoint@0 {
>> reg = <0>;
>> // here is mixer0 output connection, part of board DTS
>> remote-endpoint = <board specific phandle to TCON>;
>> };
>>
>> tcon_top_out_tcon1: endpoint@1 {
>> reg = <1>;
>> // here is mixer1 output connection, part of board DTS
>> remote-endpoint = <board specific phandle to TCON>;
>> };
>>
>> tcon_top_out_hdmi: endpoint@2 {
>> reg = <2>;
>> remote-endpoint = <&hdmi_in_tcon_top>;
>> };
>> };
>> };
>> };
>
> IIRC, each port is supposed to be one route for the data, so we would
> have multiple ports, one for the mixers in input and for the tcon in
> output, and one for the TCON in input and for the HDMI/TV in
> output. Rob might correct me here.
>
>> tcon_tv0: lcd-controller@1c73000 {
>> compatible = "allwinner,sun8i-r40-tcon-tv-0";
>> ...
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> tcon_tv0_in: port@0 {
>> reg = <0>;
>>
>> tcon_tv0_in_tcon_top: endpoint {
>> // endpoint depends on board, part of board DTS
>> remote-endpoint = <phandle to one of tcon_top_out_tcon>;
>
> Just curious, what would be there?
>
>> };
>> };
>>
>> tcon_tv0_out: port@1 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> reg = <1>;
>>
>> // endpoints to TV TOP and TCON TOP HDMI input
>> ...
>> };
>> };
>> };
>>
>> tcon_tv1: lcd-controller@1c74000 {
>> compatible = "allwinner,sun8i-r40-tcon-tv-1";
>> ...
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> tcon_tv1_in: port@0 {
>> reg = <0>;
>>
>> tcon_tv1_in_tcon_top: endpoint {
>> // endpoint depends on board, part of board DTS
>> remote-endpoint = <phandle to one of tcon_top_out_tcon>;
>> };
>> };
>>
>> tcon_tv1_out: port@1 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> reg = <1>;
>>
>> // endpoints to TV TOP and TCON TOP HDMI input
>> ...
>> };
>> };
>> };
>>
>> tcon_lcd0 and tcon_lcd1 would have similar connections, except that for
>> outputs would be LCD or LVDS panels or MIPI DSI encoder.
>>
>> Please note that each TCON (there are 4 of them) would need to have unique
>> compatible and have HW index stored in quirks data. It would be used by TCON
>> TOP driver for configuring muxes.
>
> Can't we use the port/endpoint ID instead? If the mux is the only
> thing that changes, the compatible has no reason to. It's the same IP,
> and the only thing that changes is something that is not part of that
> IP.
I agree. Endpoint IDs should provide that information. I'm still not
sure How to encode multiple in/out mux groups in a device node though.
ChenYu
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v3 0/8] gnss: add new GNSS subsystem
From: Pavel Machek @ 2018-06-01 16:26 UTC (permalink / raw)
To: Johan Hovold
Cc: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Andreas Kemnade,
Arnd Bergmann, H . Nikolaus Schaller, Marcel Holtmann,
Sebastian Reichel, Tony Lindgren, linux-kernel, devicetree
In-Reply-To: <20180601122217.GB13775@localhost>
[-- Attachment #1: Type: text/plain, Size: 5507 bytes --]
Hi!
> > So you have serial line + pm + protocol type. Nothing GNSS specific
> > really, it would be useful to (for example) say this is modem with AT
> > commands. Or this is QMI modem.
>
> It's a matter of finding the right abstraction level. A user space
> location service will now have easy access to the class of devices it
> cares about, without having to go through a list of other random devices
> which happen to use a similar underlying interface (e.g. a modem or
> whatever).
udev solves device discovery pretty well; I don't think that's good
thing to optimize for.
(And.. I'd really prefer /dev/nmeaX and /dev/sirfX in that situation;
and yes that makes it _even easier_ for location service to find right devices).
> Point is, you can't write a subsystem for everything. If it later turns
> out some part of the code can be shared internally, fine.
True. But you can pick reasonable name for the subsystem :-).
> > > Finally, the GNSS subsystem is clearly not serial (as in UART) specific
> > > and works just as fine with I2C, SPI, USB, iomem, rproc or whatever
> > > interface the GNSS uses.
> >
> > Ok, true. It is "we pass tty-like data across". Again, it would be
> > useful for AT commands, too, and yes, they go over serials and usbs
> > and more, too.
>
> Modems and GNSS devices would have different characteristics for buffers
> and throughput for starters.
>
> The GNSS interface uses a synchronous writes for commands to the
> receiver, something which may not be appropriate for an outgoing data
> channel, for example.
Well, these days AT modems really have separate channels for commands
and data.
> As mentioned in the cover letter, we may eventually want to add support
> for some kinds of configuration from within the kernel (e.g. protocol
> and line speed changes).
I believe we'll eventually want "real" GPS drivers, with common
interface. input was in this situation before...
>
> > > > This will never handle devices like Nokia N900, where GPS is connected
> > > > over netlink.
> > >
> > > Marcel already suggested adding a ugnss interface, which would allow
> > > feeding GNSS data through the generic GNSS interface from user space for
> > > use cases where it's not (yet) feasible to implement a kernel
> > > driver.
> >
> > Yes, and ugnss would be at wrong layer for N900. First, lets take a
> > look at N900 gps driver:
> > https://github.com/postmarketOS/gps-nokia-n900
> >
> > Got it? I'll eventually like to see it in the kernel, but your "GNSS"
> > subsystem is unsuitable for it, as it does not talk well-known
> > protocol.
>
> Seriously? If you can't be arsed to summarise your use case, why would I
> bother reading your random user space code?
You are trying to push subsystem to kernel. I believe asking you to do
little research is not unexpected.
Anyway, it is trivial binary protocol over packets that are used for
modem communication. Handling it is like 40? lines of code.
> > I'd like to see "datapipe" devices (what you currently call GNSS) and
> > "gps" devices, which would have common interface to the userland.
>
> You keep talking about this "gps" interface, which based on your
> earlier comments I assume you mean a NMEA 0183 interface? Again,
> converting a vendor-specific binary protocol may not be feasible. Please
> try to be more be specific.
I'm pretty sure we should have one protocol for communicating position
data to userland. I don't want to go into details at the moment, as
they are not important at the moment (and we could spend lot of time
discussing details).
NMEA would not be my first choice, really. I'd propose something very
similar to existing /dev/input/eventX, but with wider data types.
> > N900 would not have any datapipe devices, but would have /dev/gps0
> > exposing common GPS interface.
> >
> > Droid4 would have /dev/datapipe0 (usb, AT protocol), /dev/datapipe1
> > (usb, QMI protocol), /dev/datapipe2 (gsmtty over serial, custom AT
> > protocol), /dev/datapipe3 (gsmtty over serial, NMEA wrapped in AT
> > protocol) (and more, it is complex hardware). And if we really wanted,
> > we'd have /dev/gps0, too, exposing common GPS interface.
> >
> > Your devices would have /dev/datapipe0 with sirf or ublox or nmea
> > protocol. In we really wanted, we'd have /dev/gps0, too, again,
> > exposing common GPS interface.
>
> This does not seem like the right abstraction level and doesn't appear
> to provide much more than what we currently have with ttys.
I don't see what you are saying here. I've described your proposal but
replaced /dev/gnss0 with /dev/datapipe0.
> > I believe we really want to use your code for AT commands, too. And we
> > really should keep GNSS/GPS names for future layer that actually
> > provides single interface for userland.
>
> Specifics, please. What would such an interface look like? I'm pretty
> sure, we do not want to move every GNSS middleware protocol handler into
> the kernel.
Maybe we don't want to move _every_ GNSS protocol handler into kernel,
but I'm pretty sure we need to move _some_ of them there. It is
certainly best place for Nokia N900's protocol.
And I'm trying to make sure we have suitable names available when that
happens.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/8] gnss: add new GNSS subsystem
From: H. Nikolaus Schaller @ 2018-06-01 16:37 UTC (permalink / raw)
To: Pavel Machek
Cc: Johan Hovold, Greg Kroah-Hartman, Rob Herring, Mark Rutland,
Andreas Kemnade, Arnd Bergmann, Marcel Holtmann,
Sebastian Reichel, Tony Lindgren, linux-kernel, devicetree
In-Reply-To: <20180601162645.GA30792@amd>
Hi Pavel,
> Am 01.06.2018 um 18:26 schrieb Pavel Machek <pavel@ucw.cz>:
>
> NMEA would not be my first choice, really. I'd propose something very
> similar to existing /dev/input/eventX, but with wider data types.
Since even Rome wasn't built in a day, my first choice is NMEA, but I am
open to anything on higher level to come second.
What about iio?
It is quite flexible and extensible and GNSS coordinates are a not very
different from accelerometer, gyroscope or compass data as all of them
describe the position and orientation, maybe speed of the device these
things are built into (at least for mobile devices).
--hns
^ permalink raw reply
* Re: [PATCH v3 2/5] gpio: syscon: rockchip: add GPIO_MUTE support for rk3328
From: Rob Herring @ 2018-06-01 17:03 UTC (permalink / raw)
To: Levin
Cc: open list:ARM/Rockchip SoC..., Wayne Chou, Heiko Stuebner,
devicetree, Linus Walleij, linux-kernel@vger.kernel.org,
open list:GPIO SUBSYSTEM, Mark Rutland,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <0d08ba26-77f2-6c42-8fb1-214aaf6085e9@t-chip.com.cn>
On Thu, May 31, 2018 at 9:05 PM, Levin <djw@t-chip.com.cn> wrote:
> Hi Rob,
>
>
> On 2018-05-31 10:45 PM, Rob Herring wrote:
>>
>> On Wed, May 30, 2018 at 10:27 PM, <djw@t-chip.com.cn> wrote:
>>>
>>> From: Levin Du <djw@t-chip.com.cn>
>>>
>>> In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec
>>> mute control, can also be used for general purpose. It is manipulated by
>>> the GRF_SOC_CON10 register.
>>>
>>> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>>>
>>> ---
>>>
>>> Changes in v3:
>>> - Change from general gpio-syscon to specific rk3328-gpio-mute
>>>
>>> Changes in v2:
>>> - Rename gpio_syscon10 to gpio_mute in doc
>>>
>>> Changes in v1:
>>> - Refactured for general gpio-syscon usage for Rockchip SoCs.
>>> - Add doc rockchip,gpio-syscon.txt
>>>
>>> .../bindings/gpio/rockchip,rk3328-gpio-mute.txt | 28
>>> +++++++++++++++++++
>>> drivers/gpio/gpio-syscon.c | 31
>>> ++++++++++++++++++++++
>>> 2 files changed, 59 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>> b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>> new file mode 100644
>>> index 0000000..10bc632
>>> --- /dev/null
>>> +++
>>> b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-gpio-mute.txt
>>> @@ -0,0 +1,28 @@
>>> +Rockchip RK3328 GPIO controller dedicated for the GPIO_MUTE pin.
>>> +
>>> +In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec
>>> mute
>>> +control, can also be used for general purpose. It is manipulated by the
>>> +GRF_SOC_CON10 register.
>>> +
>>> +Required properties:
>>> +- compatible: Should contain "rockchip,rk3328-gpio-mute".
>>> +- gpio-controller: Marks the device node as a gpio controller.
>>> +- #gpio-cells: Should be 2. The first cell is the pin number and
>>> + the second cell is used to specify the gpio polarity:
>>> + 0 = Active high,
>>> + 1 = Active low.
>>> +
>>> +Example:
>>> +
>>> + grf: syscon@ff100000 {
>>> + compatible = "rockchip,rk3328-grf", "syscon",
>>> "simple-mfd";
>>> +
>>> + gpio_mute: gpio-mute {
>>
>> Node names should be generic:
>>
>> gpio {
>>
>> This also means you can't add another GPIO node in the future and
>> you'll have to live with "rockchip,rk3328-gpio-mute" covering more
>> than 1 GPIO if you do need to add more GPIOs.
>
>
> As the first line describes, this GPIO controller is dedicated for the
> GPIO_MUTE pin.
> There's only one GPIO pin in the GRF_SOC_CON10 register. Therefore the
> gpio_mute
> name is proper IMHO.
It's how many GPIOs in the GRF, not this register. What I'm saying is
when you come along later to add another GPIO in the GRF, you had
better just add it to this same node. I'm not going to accept another
GPIO controller node within the GRF. You have the cells to support
more than 1, so it would only be a driver change. The compatible
string would then not be ideally named at that point. But compatible
strings are just unique identifiers, so it doesn't really matter what
the string is.
I'm being told both "this is the only GPIO" and "the GRF has too many
different functions for us to tell you what they all are". So which is
it?
Rob
^ permalink raw reply
* Re: [PATCH v8 2/4] dt-bindings: Add bindings for SPI NAND devices
From: Boris Brezillon @ 2018-06-01 17:09 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Pawel Moll, Ian Campbell, Richard Weinberger, Kumar Gala,
Rob Herring, linux-spi, Marek Vasut, Mark Brown, MTD Maling List,
Miquel Raynal, Brian Norris, David Woodhouse
In-Reply-To: <CAMuHMdUyPoDA-7+OT_yT-g7kA+zae8Sjo6PYRFTFfFkQetUqnA@mail.gmail.com>
Hi Geert,
On Fri, 1 Jun 2018 16:42:26 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Boris,
>
> I became interested after reading the cover letter...
>
> On Fri, Jun 1, 2018 at 3:13 PM, Boris Brezillon
> <boris.brezillon@bootlin.com> wrote:
> > Add bindings for SPI NAND chips.
> >
> > Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
>
> Thanks for your patch!
And thanks for reviewing it ;-).
>
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/spi-nand.txt
> > @@ -0,0 +1,27 @@
> > +SPI NAND flash
> > +
> > +Required properties:
> > +- compatible: should be "spi-nand"
> > +- reg: should encode the chip-select line used to access the NAND chip
> > +
> > +Optional properties
> > +- spi-max-frequency: maximum frequency of the SPI bus the chip can operate at.
> > + This should encode board limitations (i.e. max freq can't
> > + be achieved due to crosstalk on IO lines).
> > + When unspecified, the driver assumes the chip can run at
> > + the max frequency defined in the spec (information
> > + extracted chip detection time).
>
> This is a standard property according to
> Documentation/devicetree/bindings/spi/spi-bus.txt. Can't you just refer
> to that file, or just omit it, as it applies to all SPI slaves anyway?
The thing is, the maximum frequency supported by a SPI NAND is directly
encoded in the NAND device ID and can be auto-detected. Why should we
define spi-max-frequency in the DT when we can automatically detect
this information? The only reason one might want to override
spi-max-frequency is when the board design impose such restrictions,
hence the precision I give here.
>
> > +- spi-tx-bus-width: The bus width (number of data wires) that is used for MOSI.
> > + Only encodes the board constraints (i.e. when not all IO
> > + signals are routed on the board). Device constraints are
> > + extracted when detecting the chip, and controller
> > + constraints are exposed by the SPI mem controller. If this
> > + property is missing that means no constraint at the board
> > + level.
> > +- spi-rx-bus-width: The bus width (number of data wires) that is used for MISO.
> > + Only encodes the board constraints (i.e. when not all IO
> > + signals are routed on the board). Device constraints are
> > + extracted when detecting the chip, and controller
> > + constraints are exposed by the SPI mem controller. If this
> > + property is missing that means no constraint at the board
> > + level.
>
> This does not match Documentation/devicetree/bindings/spi/spi-bus.txt,
> which says the default is 1.
Yes, I know.
>
> As these properties are handled by the SPI core in of_spi_parse_dt, why
> would you want to deviate?
Because, again, this information can be extracted from the NAND ID, and
the only reason we might want to override the information extracted
from the NAND ID is when the board design adds extra restrictions
(like, only 2 SIO lines wired on the 4 available).
>
> Commenting to the question in the cover letter: what would be the
> purpose of spi-max-bus-width?
Defining how many IO lines are wired on the board design. If this
property is missing we would assume all IO lines are wired and the
restrictions would be negotiated between the controller and the device
without requiring explicit description in the DT.
Regards,
Boris
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v4 5/6] clk: bd71837: Add driver for BD71837 PMIC clock
From: Stephen Boyd @ 2018-06-01 17:11 UTC (permalink / raw)
Cc: Matti Vaittinen, broonie, lee.jones, lgirdwood, mark.rutland,
mazziesaccount, mturquette, robh+dt, linux-clk, devicetree,
linux-kernel, mikko.mutanen, heikki.haikola
In-Reply-To: <20180601073156.GC5150@localhost.localdomain>
Quoting Matti Vaittinen (2018-06-01 00:31:56)
> First of all - Thanks for looking at this!
>
> On Thu, May 31, 2018 at 08:10:39AM -0700, Stephen Boyd wrote:
> > Quoting Matti Vaittinen (2018-05-30 01:43:19)
> > > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> > > index 41492e980ef4..4b045699bb5e 100644
> > > --- a/drivers/clk/Kconfig
> > > +++ b/drivers/clk/Kconfig
> > > @@ -279,6 +279,15 @@ config COMMON_CLK_STM32H7
> > > ---help---
> > > Support for stm32h7 SoC family clocks
> > >
> > > +config COMMON_CLK_BD71837
> > > + tristate "Clock driver for ROHM BD71837 PMIC MFD"
> > > + depends on MFD_BD71837
> > > + depends on I2C=y
> >
> > Why depend on I2C=y?
>
> I added this because the PMIC is connected via i2c. But as you ask this
> - and as you probably knew my answer - I guess this is not correct. So
> I guess depends on MFD_BD71837 should be sufficient and the MFD portion
> should hide the fact we sit on I2C? If this is the case - I will remove
> this.
Sounds right.
> >
> > > +
> > > +static int bd71837_clk_set(struct clk_hw *hw, int status)
> > > +{
> > > + struct bd71837_clk *c = container_of(hw, struct bd71837_clk, hw);
> > > +
> > > + return bd71837_update_bits(c->mfd, c->reg, c->mask, status);
> > > +}
> > > +
> > > +static void bd71837_clk_disable(struct clk_hw *hw)
> > > +{
> > > + int rv;
> > > + struct bd71837_clk *c = container_of(hw, struct bd71837_clk, hw);
> > > +
> > > + rv = bd71837_clk_set(hw, 0);
> > > + if (rv)
> > > + dev_err(&c->pdev->dev, "Failed to disable 32K clk (%d)\n", rv);
> >
> > Why is a disable error message more important than an enable error
> > message? Please drop this message and rely on callers to indicate if
> > enabling their clk didn't work for some reason.
>
> Reason is that the disable function is not returning error. So if I drop
> the print there will be no indication of error, right?
I'm not sure anyone cares if disable fails, which is why we have it
marked as void. The end user probably can't do anything about it, and it
isn't actually causing some sort of problem besides lost power so if you
really want to keep it please move it to dev_dbg(), or just remove it
and add it in when you're debugging.
>
> >
> > > +}
> > > +
> > > +static unsigned long bd71837_clk_recalc_rate(struct clk_hw *hw,
> > > + unsigned long parent_rate)
> > > +{
> > > + struct bd71837_clk *c = container_of(hw, struct bd71837_clk, hw);
> > > +
> > > + return c->rate;
> >
> > Recalc rate should read the hardware instead of returning a cached rate
> > unless it can't actually read hardware.
>
> We can't read the rate from HW. And actually, as this is fixed rate
> clock generator - is the recalc_rate needed at all?
Yes recalc_rate is still needed in this case. Thanks for pointing it
out. This is fine.
>
> >
> > > + if (!c)
> > > + goto err_out;
> > > +
> > > + c->reg = BD71837_REG_OUT32K;
> > > + c->mask = BD71837_OUT32K_EN;
> > > + c->rate = BD71837_CLK_RATE;
> >
> > Is the plan to have more clks supported by this driver in the future?
> > Because right now it seems to make a structure up and then hardcode the
> > members for a single clk so I'm not sure why those registers aren't just
> > hardcoded in the clk_ops functions that use them.
>
> (At least) one more chip from this series is coming and I am planning to
> support it with this driver. I am not sure if the registers will stay
> the same. Hence I rather not hardcode the register values.
Ok.
>
> >
> > > + of_property_read_string_index(pdev->dev.of_node,
> > > + "clock-output-names", 0,
> > > + &init.name);
> > > +
> > > + c->hw.init = &init;
> > > +
> > > + errstr = "failed to register 32K clk";
> >
> > The 'errstr' thing is not standard. Please just call dev_err() directly
> > with the string you want to print. And consider not printing anything at
> > all.
>
> I think this technique is actually used in many places at net side. I
> guess i have adobted this habit from some netlink message handling code.
> I can change this to in-place prints if it fits environment better
> though.
Ok.
>
> >
> > > + rval = clk_hw_register(&pdev->dev, &c->hw);
> > > + if (rval)
> > > + goto err_free;
> > > +
> > > + errstr = "failed to register clkdev for bd71837";
> > > + rval = clk_hw_register_clkdev(&c->hw, init.name, NULL);
> >
> > Are you using the clkdev lookup? Or this is just added for backup
> > purposes? If this is a mostly DT driver then please drop this part of
> > the patch and rely on of_clk_hw_add_provider() to handle the lookup
> > instead.
>
> I did this because this is how I get the clk_get to work in my test
> driver. Problem is that I don't know how this clock is going to be used
> - and I lack of knowledge how these things are usually done. I don't
> know the clock consumer code so this was best I could think of. But if
> this is not how things are usually handled I can remove the clkdev and
> rely on of_clk_add_hw_provider. Would this be correct then:
There isn't any example code inserted, but yes, usually clkdev is used
when a non-DT enabled platform wants to use the clk. That typically only
happens on x86 platforms because we don't have a way in ACPI to express
clk handles. If this is never used with an x86 platform then clkdev is
not needed. Either way, adding an OF provider would be good to support
DT platforms. Having a clkdev lookup would also be good to support
non-DT platforms.
^ permalink raw reply
* Re: [PATCH v9 01/15] ARM: Add Krait L2 register accessor functions
From: Stephen Boyd @ 2018-06-01 17:12 UTC (permalink / raw)
To: Bjorn Andersson, Sricharan R
Cc: robh, viresh.kumar, mark.rutland, mturquette, sboyd, linux,
andy.gross, david.brown, rjw, linux-arm-kernel, devicetree,
linux-kernel, linux-clk, linux-arm-msm, linux-soc, linux-pm,
linux
In-Reply-To: <9ca51832-6095-c8a5-1347-f57abf99e8f9@codeaurora.org>
Quoting Sricharan R (2018-06-01 06:20:37)
> Hi Stephen,
>
> On 5/31/2018 1:11 PM, Stephen Boyd wrote:
> >
> > Ok. One general comment is that it would be nice if the bindings for all
> > the nodes that are introduced included 'clocks' properties and also
> > maybe 'clock-names' properties for the clocks that are consumed by each
> > node. Right now, we hide those details from DT and rely on the string
> > names to hook the clk tree up for us. That sort of prevents us from
> > moving away from string easily, so I would just throw the clocks into
> > the binding right now and always have them there just in case we want to
> > use the binding to figure out the hierarchy in the future.
> >
>
> ok, understand that mostly. So will try to revamp those patches with
> the 'clocks' property in the binding added, reading them in the driver
> from DT.
Yeah. You don't even have to actually use the clocks property right now
from the drivers. Just add the properties in the binding.
^ permalink raw reply
* [PATCH v2 1/2] power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats
From: Brian Norris @ 2018-06-01 17:23 UTC (permalink / raw)
To: Sebastian Reichel
Cc: linux-kernel, Rob Herring, linux-pm, devicetree, Rhyland Klein,
Alexandru Stan, Guenter Roeck, Doug Anderson, Brian Norris
This driver was originally submitted for the TI BQ20Z75 battery IC
(commit a7640bfa10c5 ("power_supply: Add driver for TI BQ20Z75 gas gauge
IC")) and later renamed to express generic SBS support. While it's
mostly true that this driver implemented a standard SBS command set, it
takes liberties with the REG_MANUFACTURER_DATA register. This register
is specified in the SBS spec, but it doesn't make any mention of what
its actual contents are.
We've sort of noticed this optionality previously, with commit
17c6d3979e5b ("sbs-battery: make writes to ManufacturerAccess
optional"), where we found that some batteries NAK writes to this
register.
What this really means is that so far, we've just been lucky that most
batteries have either been compatible with the TI chip, or else at least
haven't reported highly-unexpected values.
For instance, one battery I have here seems to report either 0x0000 or
0x0100 to the MANUFACTURER_ACCESS_STATUS command -- while this seems to
match either Wake Up (bits[11:8] = 0000b) or Normal Discharge
(bits[11:8] = 0001b) status for the TI part [1], they don't seem to
actually correspond to real states (for instance, I never see 0101b =
Charge, even when charging).
On other batteries, I'm getting apparently random data in return, which
means that occasionally, we interpret this as "battery not present" or
"battery is not healthy".
All in all, it seems to be a really bad idea to make assumptions about
REG_MANUFACTURER_DATA, unless we already know what battery we're using.
Therefore, this patch reimplements the "present" and "health" checks to
the following on most SBS batteries:
1. HEALTH: report "unknown" -- I couldn't find a standard SBS command
that gives us much useful here
2. PRESENT: just send a REG_STATUS command; if it succeeds, then the
battery is present
Also, we stop sending MANUFACTURER_ACCESS_SLEEP to non-TI parts. I have
no proof that this is useful and supported.
If someone explicitly provided a 'ti,bq20z75' compatible property, then
we retain the existing TI command behaviors.
[1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
v2:
* don't stub out POWER_SUPPLY_PROP_PRESENT from sbs_data[]
* use if/else instead of switch/case
---
drivers/power/supply/sbs-battery.c | 54 +++++++++++++++++++++++++-----
1 file changed, 46 insertions(+), 8 deletions(-)
diff --git a/drivers/power/supply/sbs-battery.c b/drivers/power/supply/sbs-battery.c
index 83d7b4115857..8dea63464a3f 100644
--- a/drivers/power/supply/sbs-battery.c
+++ b/drivers/power/supply/sbs-battery.c
@@ -23,6 +23,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/power/sbs-battery.h>
#include <linux/power_supply.h>
#include <linux/slab.h>
@@ -156,6 +157,9 @@ static enum power_supply_property sbs_properties[] = {
POWER_SUPPLY_PROP_MODEL_NAME
};
+/* Supports special manufacturer commands from TI BQ20Z75 IC. */
+#define SBS_FLAGS_TI_BQ20Z75 BIT(0)
+
struct sbs_info {
struct i2c_client *client;
struct power_supply *power_supply;
@@ -168,6 +172,7 @@ struct sbs_info {
u32 poll_retry_count;
struct delayed_work work;
struct mutex mode_lock;
+ u32 flags;
};
static char model_name[I2C_SMBUS_BLOCK_MAX + 1];
@@ -315,6 +320,27 @@ static int sbs_status_correct(struct i2c_client *client, int *intval)
static int sbs_get_battery_presence_and_health(
struct i2c_client *client, enum power_supply_property psp,
union power_supply_propval *val)
+{
+ int ret;
+
+ if (psp == POWER_SUPPLY_PROP_PRESENT) {
+ /* Dummy command; if it succeeds, battery is present. */
+ ret = sbs_read_word_data(client, sbs_data[REG_STATUS].addr);
+ if (ret < 0)
+ val->intval = 0; /* battery disconnected */
+ else
+ val->intval = 1; /* battery present */
+ return 0;
+ } else { /* POWER_SUPPLY_PROP_HEALTH */
+ /* SBS spec doesn't have a general health command. */
+ val->intval = POWER_SUPPLY_HEALTH_UNKNOWN;
+ return 0;
+ }
+}
+
+static int sbs_get_ti_battery_presence_and_health(
+ struct i2c_client *client, enum power_supply_property psp,
+ union power_supply_propval *val)
{
s32 ret;
@@ -600,7 +626,12 @@ static int sbs_get_property(struct power_supply *psy,
switch (psp) {
case POWER_SUPPLY_PROP_PRESENT:
case POWER_SUPPLY_PROP_HEALTH:
- ret = sbs_get_battery_presence_and_health(client, psp, val);
+ if (client->flags & SBS_FLAGS_TI_BQ20Z75)
+ ret = sbs_get_ti_battery_presence_and_health(client,
+ psp, val);
+ else
+ ret = sbs_get_battery_presence_and_health(client, psp,
+ val);
if (psp == POWER_SUPPLY_PROP_PRESENT)
return 0;
break;
@@ -806,6 +837,7 @@ static int sbs_probe(struct i2c_client *client,
if (!chip)
return -ENOMEM;
+ chip->flags = (u32)(uintptr_t)of_device_get_match_data(&client->dev);
chip->client = client;
chip->enable_detection = false;
psy_cfg.of_node = client->dev.of_node;
@@ -915,12 +947,15 @@ static int sbs_suspend(struct device *dev)
if (chip->poll_time > 0)
cancel_delayed_work_sync(&chip->work);
- /*
- * Write to manufacturer access with sleep command.
- * Support is manufacturer dependend, so ignore errors.
- */
- sbs_write_word_data(client, sbs_data[REG_MANUFACTURER_DATA].addr,
- MANUFACTURER_ACCESS_SLEEP);
+ if (chip->flags & SBS_FLAGS_TI_BQ20Z75) {
+ /*
+ * Write to manufacturer access with sleep command.
+ * Support is manufacturer dependent, so ignore errors.
+ */
+ sbs_write_word_data(client,
+ sbs_data[REG_MANUFACTURER_DATA].addr,
+ MANUFACTURER_ACCESS_SLEEP);
+ }
return 0;
}
@@ -941,7 +976,10 @@ MODULE_DEVICE_TABLE(i2c, sbs_id);
static const struct of_device_id sbs_dt_ids[] = {
{ .compatible = "sbs,sbs-battery" },
- { .compatible = "ti,bq20z75" },
+ {
+ .compatible = "ti,bq20z75",
+ .data = (void *)SBS_FLAGS_TI_BQ20Z75,
+ },
{ }
};
MODULE_DEVICE_TABLE(of, sbs_dt_ids);
--
2.17.0.921.gf22659ad46-goog
^ permalink raw reply related
* [PATCH v2 2/2] dt-bindings: power: sbs-battery: re-document "ti,bq20z75"
From: Brian Norris @ 2018-06-01 17:24 UTC (permalink / raw)
To: Sebastian Reichel
Cc: linux-kernel, Rob Herring, linux-pm, devicetree, Rhyland Klein,
Alexandru Stan, Guenter Roeck, Doug Anderson, Brian Norris
In-Reply-To: <20180601172400.50737-1-briannorris@chromium.org>
This compatible property was documented before the driver was renamed to
"SBS" (see commit e57f1b68c406 ("devicetree-bindings: Propagate
bq20z75->sbs rename to dt bindings")). The driver has continued to
support this property as an alternative to "sbs,sbs-battery", and
because we've noticed there are some lingering TI specifics (in the
manufacturer-specific portion of the SBS spec), we'd like to start using
this property again to differentiate.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Rhyland Klein <rklein@nvidia.com>
---
v2: add Rhyland's Acked-by
---
.../devicetree/bindings/power/supply/sbs_sbs-battery.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt b/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt
index c40e8926facf..a7a9c3366f82 100644
--- a/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt
+++ b/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt
@@ -2,7 +2,7 @@ SBS sbs-battery
~~~~~~~~~~
Required properties :
- - compatible : "sbs,sbs-battery"
+ - compatible : "sbs,sbs-battery" or "ti,bq20z75"
Optional properties :
- sbs,i2c-retry-count : The number of times to retry i2c transactions on i2c
--
2.17.0.921.gf22659ad46-goog
^ permalink raw reply related
* Re: [PATCH 1/3] arm64: allwinner: a64: add R_I2C controller
From: Vasily Khoruzhick @ 2018-06-01 17:30 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Catalin Marinas, Will Deacon,
Chen-Yu Tsai, Rob Herring, arm-linux, Icenowy Zheng
In-Reply-To: <20180601091631.wqctilk55fcmggwv@flea>
On Fri, Jun 1, 2018 at 2:16 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> Hi,
>
> On Thu, May 31, 2018 at 11:28:59PM -0700, Vasily Khoruzhick wrote:
>> From: Icenowy Zheng <icenowy@aosc.io>
>>
>> Allwinner A64 has a I2C controller, which is in the R_ MMIO zone and has
>> two groups of pinmuxes on PL bank, so it's called R_I2C.
>>
>> Add support for this I2C controller and the pinmux which doesn't conflict
>> with RSB.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>
> You should have your SoB there.
OK, will do.
>> ---
>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> index 1b2ef28c42bd..b5e903ccf0ec 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> @@ -46,6 +46,7 @@
>> #include <dt-bindings/clock/sun8i-r-ccu.h>
>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>> #include <dt-bindings/reset/sun50i-a64-ccu.h>
>> +#include <dt-bindings/reset/sun8i-r-ccu.h>
>>
>> / {
>> interrupt-parent = <&gic>;
>> @@ -655,6 +656,17 @@
>> #reset-cells = <1>;
>> };
>>
>> + r_i2c: i2c@1f02400 {
>> + compatible = "allwinner,sun6i-a31-i2c";
>
> You should add an a64 compatible here
We don't have it for regular i2c, why should I add it here?
>> + reg = <0x01f02400 0x400>;
>> + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&r_ccu CLK_APB0_I2C>;
>> + resets = <&r_ccu RST_APB0_I2C>;
>> + status = "disabled";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + };
>> +
>> r_pio: pinctrl@1f02c00 {
>> compatible = "allwinner,sun50i-a64-r-pinctrl";
>> reg = <0x01f02c00 0x400>;
>> @@ -670,6 +682,11 @@
>> pins = "PL0", "PL1";
>> function = "s_rsb";
>> };
>> +
>> + r_i2c_pins_a: i2c-a {
>> + pins = "PL8", "PL9";
>> + function = "s_i2c";
>> + };
>
> This should be ordered by alphabetical order
OK
> If this is the only muxing option, you can also add it to the i2c DT
> node.
It's not the only option, but other option conflicts with rsb. Should
I still add it to i2c DT node?
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply
* Re: [PATCH 2/3] dts: sunxi: A64: Add PWM controllers
From: Vasily Khoruzhick @ 2018-06-01 17:31 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Catalin Marinas, Will Deacon,
Chen-Yu Tsai, Rob Herring, Andre Przywara, arm-linux
In-Reply-To: <20180601091816.klmc3nfzynxprcso@flea>
On Fri, Jun 1, 2018 at 2:18 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> On Thu, May 31, 2018 at 11:29:00PM -0700, Vasily Khoruzhick wrote:
>> From: Andre Przywara <andre.przywara@arm.com>
>>
>> The Allwinner A64 SoC features two PWM controllers, which are fully
>> compatible to the one used in the A13 and H3 chips.
>>
>> Add the nodes for the devices (one for the "normal" PWM, the other for
>> the one in the CPUS domain) and the pins their outputs are connected to.
>>
>> On the A64 the "normal" PWM is muxed together with one of the MDIO pins
>> used to communicate with the Ethernet PHY, so it won't be usable on many
>> boards. But the Pinebook laptop uses this pin for controlling the LCD
>> backlight.
>>
>> On Pine64 the CPUS PWM pin however is routed to the "RPi2" header,
>> at the same location as the PWM pin on the RaspberryPi.
>>
>> [vasily: fixed comment message as requested by Stefan Bruens]
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> on Pinebook (only the "normal" PWM)
>> Tested-by: Harald Geyer <harald@ccbib.org> on Teres-I (only the "normal" PWM)
>
> Same thing, you should have your SoB there. And I'm not sure the
> Tested-by format is valid. This information would be better in the
> commit log itself.
OK
>
>> ---
>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 28 +++++++++++++++++++
>> 1 file changed, 28 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> index b5e903ccf0ec..e94bfa8477f6 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> @@ -365,6 +365,11 @@
>> bias-pull-up;
>> };
>>
>> + pwm_pin: pwm_pin {
>> + pins = "PD22";
>> + function = "pwm";
>> + };
>> +
>
> Is there multiple options for that muxing? If not, add it to the PWM
> node by default.
OK
>
>> rmii_pins: rmii_pins {
>> pins = "PD10", "PD11", "PD13", "PD14", "PD17",
>> "PD18", "PD19", "PD20", "PD22", "PD23";
>> @@ -630,6 +635,15 @@
>> #interrupt-cells = <3>;
>> };
>>
>> + pwm: pwm@1c21400 {
>> + compatible = "allwinner,sun50i-a64-pwm",
>> + "allwinner,sun5i-a13-pwm";
>> + reg = <0x01c21400 0x400>;
>> + clocks = <&osc24M>;
>> + #pwm-cells = <3>;
>> + status = "disabled";
>> + };
>> +
>> rtc: rtc@1f00000 {
>> compatible = "allwinner,sun6i-a31-rtc";
>> reg = <0x01f00000 0x54>;
>> @@ -667,6 +681,15 @@
>> #size-cells = <0>;
>> };
>>
>> + r_pwm: pwm@1f03800 {
>> + compatible = "allwinner,sun50i-a64-pwm",
>> + "allwinner,sun5i-a13-pwm";
>> + reg = <0x01f03800 0x400>;
>> + clocks = <&osc24M>;
>> + #pwm-cells = <3>;
>> + status = "disabled";
>> + };
>> +
>> r_pio: pinctrl@1f02c00 {
>> compatible = "allwinner,sun50i-a64-r-pinctrl";
>> reg = <0x01f02c00 0x400>;
>> @@ -687,6 +710,11 @@
>> pins = "PL8", "PL9";
>> function = "s_i2c";
>> };
>> +
>> + r_pwm_pin: pwm {
>> + pins = "PL10";
>> + function = "s_pwm";
>> + };
>
> Ditto.
OK
>
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply
* Re: [PATCH v4 2/6] mfd: bd71837: Devicetree bindings for ROHM BD71837 PMIC
From: Rob Herring @ 2018-06-01 17:32 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Matti Vaittinen, Michael Turquette, Stephen Boyd, Mark Rutland,
Lee Jones, Liam Girdwood, Mark Brown, linux-clk, devicetree,
linux-kernel@vger.kernel.org, mikko.mutanen, heikki.haikola
In-Reply-To: <20180601062540.GB5150@localhost.localdomain>
On Fri, Jun 1, 2018 at 1:25 AM, Matti Vaittinen
<mazziesaccount@gmail.com> wrote:
> On Thu, May 31, 2018 at 09:07:24AM -0500, Rob Herring wrote:
>> On Thu, May 31, 2018 at 5:23 AM, Matti Vaittinen
>> <mazziesaccount@gmail.com> wrote:
>> > On Thu, May 31, 2018 at 10:17:17AM +0300, Matti Vaittinen wrote:
>> >> On Wed, May 30, 2018 at 10:01:29PM -0500, Rob Herring wrote:
>> >> > On Wed, May 30, 2018 at 11:42:03AM +0300, Matti Vaittinen wrote:
>> >> > > Document devicetree bindings for ROHM BD71837 PMIC MFD.
>> >> > > + - interrupts : The interrupt line the device is connected to.
>> >> > > + - interrupt-controller : Marks the device node as an interrupt controller.
>> >> >
>> >> > What sub blocks have interrupts?
>> >>
>> >> The PMIC can generate interrupts from events which cause it to reset.
>> >> Eg, irq from watchdog line change, power button pushes, reset request
>> >> via register interface etc. I don't know any generic handling for these
>> >> interrupts. In "normal" use-case this PMIC is powering the processor
>> >> where driver is running and I do not see reasonable handling because
>> >> power-reset is going to follow the irq.
>> >>
>> >
>> > Oh, but when reading this I understand that the interrupt-controller
>> > property should at least be optional.
>>
>> I don't think it should. The h/w either has an interrupt controller or
>> it doesn't.
>
> I hope this explains why I did this interrupt controller - please tell
> me if this is legitimate use-case and what you think of following:
>
> +Optional properties:
> + - interrupt-controller : Marks the device node as an interrupt controller.
> + BD71837MWV can report different power state change
> + events to other devices. Different events can be seen
> + as separate BD71837 domain interrupts.
To what other devices?
> + - #interrupt-cells : The number of cells to describe an IRQ should be 1.
> + The first cell is the IRQ number.
> + masks from ../interrupt-controller/interrupts.txt.
I'm still not clear. Generally in a PMIC, you'd define an interrupt
controller when there's a common set of registers to manage sub-block
interrupts (typical mask/unmask, ack regs) and the subblocks
themselves have control of masking/unmasking interrupts. If there's
not a need to have these 2 levels of interrupt handling, then you
don't really need to define an interrupt controller.
>
>> My concern is you added it but nothing uses it which tells
>> me your binding is incomplete. I'd rather see complete bindings even
>> if you don't have drivers.
>
> So this makes me wonder if my use-case for interrupt controller is
> valid. I thought making this PMIC as interrupt controller is a nice way
> of hiding the irq register and i2c access from other potential drivers
> using these interrupts. But as I don't know what could be the potential
> user for these irqs, I don't know how to complete binding. This is why I
> also thought of making this optional, so that the potential for using
> the interrupts would be there but it was not required when interrupts
> are not needed.
The only drivers getting these interrupts would be drivers for this
PMIC. Interrupts are handled by the driver owning the h/w that
generated the interrupt. I think that is the disconnect here.
Take a power button. We don't create a generic power button interrupt
and then have some generic power button interrupt handler. We have a
handler for specifically for that device and then it generates a power
button press event.
>> For example, as-is, there's not really any
>> need for the clocks child node. You can just make the parent a clock
>> provider.
>
> This sounds correct. I just lack of knowledge on how to handle clocks
> in "standard way" using the clock framework and this was a result of
> my first attempt. (Funny, I have written clk / synchronization drivers
> for work in the past but still I have no idea on how to do this in
> "standard way").
>
>> But we need a complete picture of the h/w to make that
>> determination.
>
> My attempt is to create generic driver for this PMIC. I would rather not
> limit it's use to any particular board/soc. The example binding is based
> on my test environment where I simply connected this PMIC break out
> board to beagle bone black. (I do also have a test board where i.MX8 and
> peripherials are powered by this PMIC but I rather not limit this driver
> to such single setup. Besides the linux running on that board is not
> 'standard')
That's how we design all the PMIC drivers. All the PMIC functions
should be exposed thru standard class APIs. Though many PMICs are
pretty tightly coupled to particular SoCs either by design or just
there's not a lot of boards to create any sort of matrix of
combinations.
> The PMIC itself just has this 32.768 KHz clock output. Clock can be
> enabled/disabled via register interface. I think this is intended to be
> used for RTC but I thought this driver does not need to care about that.
> I thought it is just a good idea to provide control via clk subsystem
> and to not make assumptions on use-cases in this driver.
Sure that is fine. No one is saying you shouldn't do that.
Rob
^ permalink raw reply
* Re: [PATCH v2 1/2] power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats
From: Guenter Roeck @ 2018-06-01 17:34 UTC (permalink / raw)
To: Brian Norris
Cc: Sebastian Reichel, linux-kernel, Rob Herring, linux-pm,
devicetree, Rhyland Klein, Alexandru Stan, Doug Anderson
In-Reply-To: <20180601172400.50737-1-briannorris@chromium.org>
On Fri, Jun 01, 2018 at 10:23:59AM -0700, Brian Norris wrote:
> This driver was originally submitted for the TI BQ20Z75 battery IC
> (commit a7640bfa10c5 ("power_supply: Add driver for TI BQ20Z75 gas gauge
> IC")) and later renamed to express generic SBS support. While it's
> mostly true that this driver implemented a standard SBS command set, it
> takes liberties with the REG_MANUFACTURER_DATA register. This register
> is specified in the SBS spec, but it doesn't make any mention of what
> its actual contents are.
>
> We've sort of noticed this optionality previously, with commit
> 17c6d3979e5b ("sbs-battery: make writes to ManufacturerAccess
> optional"), where we found that some batteries NAK writes to this
> register.
>
> What this really means is that so far, we've just been lucky that most
> batteries have either been compatible with the TI chip, or else at least
> haven't reported highly-unexpected values.
>
> For instance, one battery I have here seems to report either 0x0000 or
> 0x0100 to the MANUFACTURER_ACCESS_STATUS command -- while this seems to
> match either Wake Up (bits[11:8] = 0000b) or Normal Discharge
> (bits[11:8] = 0001b) status for the TI part [1], they don't seem to
> actually correspond to real states (for instance, I never see 0101b =
> Charge, even when charging).
>
> On other batteries, I'm getting apparently random data in return, which
> means that occasionally, we interpret this as "battery not present" or
> "battery is not healthy".
>
> All in all, it seems to be a really bad idea to make assumptions about
> REG_MANUFACTURER_DATA, unless we already know what battery we're using.
> Therefore, this patch reimplements the "present" and "health" checks to
> the following on most SBS batteries:
>
> 1. HEALTH: report "unknown" -- I couldn't find a standard SBS command
> that gives us much useful here
> 2. PRESENT: just send a REG_STATUS command; if it succeeds, then the
> battery is present
>
> Also, we stop sending MANUFACTURER_ACCESS_SLEEP to non-TI parts. I have
> no proof that this is useful and supported.
>
> If someone explicitly provided a 'ti,bq20z75' compatible property, then
> we retain the existing TI command behaviors.
>
> [1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> v2:
> * don't stub out POWER_SUPPLY_PROP_PRESENT from sbs_data[]
> * use if/else instead of switch/case
> ---
> drivers/power/supply/sbs-battery.c | 54 +++++++++++++++++++++++++-----
> 1 file changed, 46 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/power/supply/sbs-battery.c b/drivers/power/supply/sbs-battery.c
> index 83d7b4115857..8dea63464a3f 100644
> --- a/drivers/power/supply/sbs-battery.c
> +++ b/drivers/power/supply/sbs-battery.c
> @@ -23,6 +23,7 @@
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/of.h>
> +#include <linux/of_device.h>
> #include <linux/power/sbs-battery.h>
> #include <linux/power_supply.h>
> #include <linux/slab.h>
> @@ -156,6 +157,9 @@ static enum power_supply_property sbs_properties[] = {
> POWER_SUPPLY_PROP_MODEL_NAME
> };
>
> +/* Supports special manufacturer commands from TI BQ20Z75 IC. */
> +#define SBS_FLAGS_TI_BQ20Z75 BIT(0)
> +
> struct sbs_info {
> struct i2c_client *client;
> struct power_supply *power_supply;
> @@ -168,6 +172,7 @@ struct sbs_info {
> u32 poll_retry_count;
> struct delayed_work work;
> struct mutex mode_lock;
> + u32 flags;
> };
>
> static char model_name[I2C_SMBUS_BLOCK_MAX + 1];
> @@ -315,6 +320,27 @@ static int sbs_status_correct(struct i2c_client *client, int *intval)
> static int sbs_get_battery_presence_and_health(
> struct i2c_client *client, enum power_supply_property psp,
> union power_supply_propval *val)
> +{
> + int ret;
> +
> + if (psp == POWER_SUPPLY_PROP_PRESENT) {
> + /* Dummy command; if it succeeds, battery is present. */
> + ret = sbs_read_word_data(client, sbs_data[REG_STATUS].addr);
> + if (ret < 0)
> + val->intval = 0; /* battery disconnected */
> + else
> + val->intval = 1; /* battery present */
> + return 0;
> + } else { /* POWER_SUPPLY_PROP_HEALTH */
Static analyzers may complain that else after return is unnecessary.
Other than that
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> + /* SBS spec doesn't have a general health command. */
> + val->intval = POWER_SUPPLY_HEALTH_UNKNOWN;
> + return 0;
> + }
> +}
> +
> +static int sbs_get_ti_battery_presence_and_health(
> + struct i2c_client *client, enum power_supply_property psp,
> + union power_supply_propval *val)
> {
> s32 ret;
>
> @@ -600,7 +626,12 @@ static int sbs_get_property(struct power_supply *psy,
> switch (psp) {
> case POWER_SUPPLY_PROP_PRESENT:
> case POWER_SUPPLY_PROP_HEALTH:
> - ret = sbs_get_battery_presence_and_health(client, psp, val);
> + if (client->flags & SBS_FLAGS_TI_BQ20Z75)
> + ret = sbs_get_ti_battery_presence_and_health(client,
> + psp, val);
> + else
> + ret = sbs_get_battery_presence_and_health(client, psp,
> + val);
> if (psp == POWER_SUPPLY_PROP_PRESENT)
> return 0;
> break;
> @@ -806,6 +837,7 @@ static int sbs_probe(struct i2c_client *client,
> if (!chip)
> return -ENOMEM;
>
> + chip->flags = (u32)(uintptr_t)of_device_get_match_data(&client->dev);
> chip->client = client;
> chip->enable_detection = false;
> psy_cfg.of_node = client->dev.of_node;
> @@ -915,12 +947,15 @@ static int sbs_suspend(struct device *dev)
> if (chip->poll_time > 0)
> cancel_delayed_work_sync(&chip->work);
>
> - /*
> - * Write to manufacturer access with sleep command.
> - * Support is manufacturer dependend, so ignore errors.
> - */
> - sbs_write_word_data(client, sbs_data[REG_MANUFACTURER_DATA].addr,
> - MANUFACTURER_ACCESS_SLEEP);
> + if (chip->flags & SBS_FLAGS_TI_BQ20Z75) {
> + /*
> + * Write to manufacturer access with sleep command.
> + * Support is manufacturer dependent, so ignore errors.
> + */
> + sbs_write_word_data(client,
> + sbs_data[REG_MANUFACTURER_DATA].addr,
> + MANUFACTURER_ACCESS_SLEEP);
> + }
>
> return 0;
> }
> @@ -941,7 +976,10 @@ MODULE_DEVICE_TABLE(i2c, sbs_id);
>
> static const struct of_device_id sbs_dt_ids[] = {
> { .compatible = "sbs,sbs-battery" },
> - { .compatible = "ti,bq20z75" },
> + {
> + .compatible = "ti,bq20z75",
> + .data = (void *)SBS_FLAGS_TI_BQ20Z75,
> + },
> { }
> };
> MODULE_DEVICE_TABLE(of, sbs_dt_ids);
> --
> 2.17.0.921.gf22659ad46-goog
>
^ permalink raw reply
* Re: [PATCH v2 2/2] dt-bindings: power: sbs-battery: re-document "ti,bq20z75"
From: Guenter Roeck @ 2018-06-01 17:35 UTC (permalink / raw)
To: Brian Norris
Cc: Sebastian Reichel, linux-kernel, Rob Herring, linux-pm,
devicetree, Rhyland Klein, Alexandru Stan, Doug Anderson
In-Reply-To: <20180601172400.50737-2-briannorris@chromium.org>
On Fri, Jun 01, 2018 at 10:24:00AM -0700, Brian Norris wrote:
> This compatible property was documented before the driver was renamed to
> "SBS" (see commit e57f1b68c406 ("devicetree-bindings: Propagate
> bq20z75->sbs rename to dt bindings")). The driver has continued to
> support this property as an alternative to "sbs,sbs-battery", and
> because we've noticed there are some lingering TI specifics (in the
> manufacturer-specific portion of the SBS spec), we'd like to start using
> this property again to differentiate.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> Acked-by: Rhyland Klein <rklein@nvidia.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> v2: add Rhyland's Acked-by
> ---
> .../devicetree/bindings/power/supply/sbs_sbs-battery.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt b/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt
> index c40e8926facf..a7a9c3366f82 100644
> --- a/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt
> +++ b/Documentation/devicetree/bindings/power/supply/sbs_sbs-battery.txt
> @@ -2,7 +2,7 @@ SBS sbs-battery
> ~~~~~~~~~~
>
> Required properties :
> - - compatible : "sbs,sbs-battery"
> + - compatible : "sbs,sbs-battery" or "ti,bq20z75"
>
> Optional properties :
> - sbs,i2c-retry-count : The number of times to retry i2c transactions on i2c
> --
> 2.17.0.921.gf22659ad46-goog
>
^ permalink raw reply
* [PATCH v3 1/2] arm64: allwinner: a64: Add RTC clock to phandle 32kHz external oscillator
From: Jagan Teki @ 2018-06-01 17:35 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Michael Trimarchi, Icenowy Zheng
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Jagan Teki
Outside of SOC few chips need external clock source
through RTC example Wifi chip. So RTC clock nodes to
phandle 32kHz external oscillator.
prefix rtc- with clock-output-names defined in
dt-binding to avoid confusion with existing osc32k name.
Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
Changes for v3:
- squash of previous v2 patch
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 1b2ef28c42bd..82516aec4153 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -634,6 +634,9 @@
reg = <0x01f00000 0x54>;
interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+ clock-output-names = "rtc-osc32k", "rtc-osc32k-out";
+ clocks = <&osc32k>;
+ #clock-cells = <1>;
};
r_intc: interrupt-controller@1f00c00 {
--
2.14.3
^ permalink raw reply related
* [PATCH v3 2/2] arm64: allwinner: a64-amarula-relic: Enable AP6330 WiFi support
From: Jagan Teki @ 2018-06-01 17:35 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Michael Trimarchi, Icenowy Zheng
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Jagan Teki
In-Reply-To: <20180601173527.18051-1-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Enable AP6330 WiFi/BT combo chip on Amarula A64-Relic board:
- WiFi SDIO interface is connected to MMC1
- WiFi WL-PMU-EN pin connected to gpio PL2: attach to mmc-pwrseq
- WiFi WL-WAKE-AP pin connected to gpio PL3
- 32kHz external oscillator gate clock from RTC
Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
Changes for v3:
- move dtsi change in separate patch
Changes for v2:
- Move external rtc clock nodes into main rtc node definition
of sun50i-a64.dtsi
.../dts/allwinner/sun50i-a64-amarula-relic.dts | 31 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
index ce4a256ff086..eac4793c8502 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-amarula-relic.dts
@@ -21,12 +21,43 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+ wifi_pwrseq: wifi-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&rtc 1>;
+ clock-names = "ext_clock";
+ reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* WL-PMU-EN: PL2 */
+ };
};
&ehci0 {
status = "okay";
};
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+ vmmc-supply = <®_dcdc1>;
+ /*
+ * Schematic shows both dldo4 and eldo1 connected for vcc-io-wifi, but
+ * dldo4 connection shows DNP(Do Not Populate) and eldo1 connected with
+ * 0Ohm register to vcc-io-wifi so eldo1 is used.
+ */
+ vqmmc-supply = <®_eldo1>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+
+ brcmf: wifi@1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ interrupt-parent = <&r_pio>;
+ interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* WL-WAKE-AP: PL3 */
+ interrupt-names = "host-wake";
+ };
+};
+
&mmc2 {
pinctrl-names = "default";
pinctrl-0 = <&mmc2_pins>;
--
2.14.3
^ permalink raw reply related
* Re: [PATCH 3/3] arm64: dts: allwinner: add support for Pinebook
From: Vasily Khoruzhick @ 2018-06-01 17:37 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Catalin Marinas, Will Deacon,
Chen-Yu Tsai, Rob Herring, Icenowy Zheng, arm-linux
In-Reply-To: <20180601092346.g2iixqupumn7xo7r@flea>
On Fri, Jun 1, 2018 at 2:23 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> On Thu, May 31, 2018 at 11:29:01PM -0700, Vasily Khoruzhick wrote:
>> From: Icenowy Zheng <icenowy@aosc.xyz>
>>
>> Pinebook is a A64-based laptop produced by Pine64, with the following
>> peripherals:
>>
>> USB:
>> - Two external USB ports (one is directly connected to A64's OTG
>> controller, the other is under a internal hub connected to the host-only
>> controller.)
>> - USB HID keyboard and touchpad connected to the internal hub.
>> - USB UVC camera connected to the internal hub.
>>
>> Power-related:
>> - A DC IN jack connected to AXP803's DCIN pin.
>> - A Li-Polymer battery connected to AXP803's battery pins.
>>
>> Storage:
>> - An eMMC by Foresee on the main board (in the product revision of the
>> main board it's designed to be switchable).
>> - An external MicroSD card slot.
>>
>> Display:
>> - An eDP LCD panel (1366x768) connected via an ANX6345 RGB-eDP bridge.
>> - A mini HDMI port.
>>
>> Misc:
>> - A Hall sensor designed to detect the status of lid, connected to GPIO PL12.
>> - A headphone jack connected to the SoC's internal codec.
>> - A debug UART port muxed with headphone jack.
>>
>> This commit adds basical support for it.
>>
>> [vasily: squashed several commits into one, added simplefb node, added usbphy
>> to ehci0 and ohci0 nodes]
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
>> ---
>> arch/arm64/boot/dts/allwinner/Makefile | 1 +
>> .../dts/allwinner/sun50i-a64-pinebook.dts | 285 ++++++++++++++++++
>> 2 files changed, 286 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
>> index 8bebe7da5ed9..a8c6d0c6f2c5 100644
>> --- a/arch/arm64/boot/dts/allwinner/Makefile
>> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> @@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
>> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinebook.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>> new file mode 100644
>> index 000000000000..d952db217702
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinebook.dts
>> @@ -0,0 +1,285 @@
>> +/*
>> + * Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.xyz>
>> + * Copyright (C) 2018 Vasily Khoruzhick <anarsoul@gmail.com>
>> + *
>> + * SPDX-License-Identifier: (GPL-2.0 OR MIT)
>
> The SPDX tag should be the first one.
OK, but it's not in number of other dts files, e.g.
sun50i-a64-teres-i.dts or sun50i-h5-orangepi-zero-plus.dts
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "sun50i-a64.dtsi"
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/input/input.h>
>> +#include <dt-bindings/pwm/pwm.h>
>> +
>> +/ {
>> + model = "Pinebook";
>> + compatible = "pine64,pinebook", "allwinner,sun50i-a64";
>> +
>> + aliases {
>> + serial0 = &uart0;
>> + ethernet0 = &rtl8723cs;
>> + };
>> +
>> + backlight: backlight {
>> + compatible = "pwm-backlight";
>> + pwms = <&pwm 0 50000 0>;
>> + brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
>
> The perceived brightness should be increasing linearly. This usually
> means that you need an function close to a power of two sequence.
OK, I'll try, but no one complained so far.
>> + default-brightness-level = <2>;
>> + enable-gpios = <&pio 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> +
>> + framebuffer-lcd {
>> + panel-supply = <®_dc1sw>;
>> + dvdd25-supply = <®_dldo2>;
>> + dvdd12-supply = <®_fldo1>;
>> + };
>> + };
>> +
>> + gpio_keys {
>> + compatible = "gpio-keys";
>> +
>> + lid_switch {
>> + label = "Lid Switch";
>> + gpios = <&r_pio 0 12 GPIO_ACTIVE_LOW>; /* PL12 */
>> + linux,input-type = <EV_SW>;
>> + linux,code = <SW_LID>;
>> + linux,can-disable;
>> + };
>> + };
>> +
>> + reg_vcc3v3: vcc3v3 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "vcc3v3";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + };
>> +
>> + wifi_pwrseq: wifi_pwrseq {
>> + compatible = "mmc-pwrseq-simple";
>> + reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
>> + };
>> +};
>> +
>> +&ehci0 {
>> + phys = <&usbphy 0>;
>> + phy-names = "usb";
>> + status = "okay";
>> +};
>> +
>> +&ehci1 {
>> + status = "okay";
>> +};
>> +
>> +&mmc0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc0_pins>;
>> + vmmc-supply = <®_dcdc1>;
>> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
>> + cd-inverted;
>> + disable-wp;
>> + bus-width = <4>;
>> + status = "okay";
>> +};
>> +
>> +&mmc1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc1_pins>;
>> + vmmc-supply = <®_dldo4>;
>> + vqmmc-supply = <®_eldo1>;
>> + mmc-pwrseq = <&wifi_pwrseq>;
>> + bus-width = <4>;
>> + non-removable;
>> + status = "okay";
>> +
>> + rtl8723cs: wifi@1 {
>> + reg = <1>;
>> + };
>> +};
>> +
>> +&mmc2 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc2_pins>;
>> + vmmc-supply = <®_dcdc1>;
>> + vqmmc-supply = <®_eldo1>;
>> + bus-width = <8>;
>> + non-removable;
>> + cap-mmc-hw-reset;
>> + mmc-hs200-1_8v;
>> + status = "okay";
>> +};
>> +
>> +&ohci0 {
>> + phys = <&usbphy 0>;
>> + phy-names = "usb";
>> + status = "okay";
>> +};
>> +
>> +&ohci1 {
>> + status = "okay";
>> +};
>> +
>> +&pwm {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pwm_pin>;
>> + status = "okay";
>> +};
>> +
>> +&r_rsb {
>> + status = "okay";
>> +
>> + axp803: pmic@3a3 {
>> + compatible = "x-powers,axp803";
>> + reg = <0x3a3>;
>> + interrupt-parent = <&r_intc>;
>> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>> + };
>> +};
>> +
>> +/* The ANX6345 eDP-bridge is on r_i2c. There is no linux (mainline)
>> + * driver for this chip at the moment, the bootloader initializes it.
>> + * However it can be accessed with the i2c-dev driver from user space.
>> + */
>
> The comment format is wrong, and the part after r_i2c, about i2c-dev
> and the mainline support is not really relevant. The DT describes the
> hardware, and is used by several different projects that might or
> might not have i2c-dev, an interface similar, or might have or not a
> driver for the bridge.
Comment is identical to sun50i-a64-teres-i.dts (which was merged few
months ago).
I'll remove everything but first sentence.
>
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply
* Re: [PATCH v8 2/4] dt-bindings: Add bindings for SPI NAND devices
From: Geert Uytterhoeven @ 2018-06-01 17:40 UTC (permalink / raw)
To: Boris Brezillon
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Pawel Moll, Ian Campbell, Richard Weinberger, Kumar Gala,
Rob Herring, linux-spi, Marek Vasut, Mark Brown, MTD Maling List,
Miquel Raynal, Brian Norris, David Woodhouse
In-Reply-To: <20180601190902.17cf5f6f@bbrezillon>
Hi Boris,
On Fri, Jun 1, 2018 at 7:09 PM, Boris Brezillon
<boris.brezillon@bootlin.com> wrote:
> On Fri, 1 Jun 2018 16:42:26 +0200
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> On Fri, Jun 1, 2018 at 3:13 PM, Boris Brezillon
>> <boris.brezillon@bootlin.com> wrote:
>> > Add bindings for SPI NAND chips.
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/mtd/spi-nand.txt
>> > @@ -0,0 +1,27 @@
>> > +SPI NAND flash
>> > +
>> > +Required properties:
>> > +- compatible: should be "spi-nand"
>> > +- reg: should encode the chip-select line used to access the NAND chip
>> > +
>> > +Optional properties
>> > +- spi-max-frequency: maximum frequency of the SPI bus the chip can operate at.
>> > + This should encode board limitations (i.e. max freq can't
>> > + be achieved due to crosstalk on IO lines).
>> > + When unspecified, the driver assumes the chip can run at
>> > + the max frequency defined in the spec (information
>> > + extracted chip detection time).
>>
>> This is a standard property according to
>> Documentation/devicetree/bindings/spi/spi-bus.txt. Can't you just refer
>> to that file, or just omit it, as it applies to all SPI slaves anyway?
>
> The thing is, the maximum frequency supported by a SPI NAND is directly
> encoded in the NAND device ID and can be auto-detected. Why should we
> define spi-max-frequency in the DT when we can automatically detect
> this information? The only reason one might want to override
Because that's how we dealt with this traditionally. Or at least I thought so.
But include/linux/spi/spi.h says:
* @max_speed_hz: Maximum clock rate to be used with this chip
* (on this board); may be changed by the device's driver.
* The spi_transfer.speed_hz can override this for each transfer.
and many drivers seem to do so.
> spi-max-frequency is when the board design impose such restrictions,
> hence the precision I give here.
Which is exactly the meaning of the standard property, isn't it?
So I think it can just be omitted here anyway. If it's present, the SPI
core will make sure it's taken into account.
>> > +- spi-tx-bus-width: The bus width (number of data wires) that is used for MOSI.
>> > + Only encodes the board constraints (i.e. when not all IO
>> > + signals are routed on the board). Device constraints are
>> > + extracted when detecting the chip, and controller
>> > + constraints are exposed by the SPI mem controller. If this
>> > + property is missing that means no constraint at the board
>> > + level.
>> > +- spi-rx-bus-width: The bus width (number of data wires) that is used for MISO.
>> > + Only encodes the board constraints (i.e. when not all IO
>> > + signals are routed on the board). Device constraints are
>> > + extracted when detecting the chip, and controller
>> > + constraints are exposed by the SPI mem controller. If this
>> > + property is missing that means no constraint at the board
>> > + level.
>>
>> This does not match Documentation/devicetree/bindings/spi/spi-bus.txt,
>> which says the default is 1.
>
> Yes, I know.
>
>> As these properties are handled by the SPI core in of_spi_parse_dt, why
>> would you want to deviate?
>
> Because, again, this information can be extracted from the NAND ID, and
> the only reason we might want to override the information extracted
> from the NAND ID is when the board design adds extra restrictions
> (like, only 2 SIO lines wired on the 4 available).
In struct spi_device, this is specified using the SPI_[RT]_X_{DUAL,QUAD}
bits in the mode field. Documentation says:
* @mode: The spi mode defines how data is clocked out and in.
* This may be changed by the device's driver.
* The "active low" default for chipselect mode can be overridden
* (by specifying SPI_CS_HIGH) as can the "MSB first" default for
* each word in a transfer (by specifying SPI_LSB_FIRST).
So this may also be specified by the device driver, but it seems no driver
does so for the dual/quad bits, except for drivers/mtd/spi-nor/nxp-spifi.c
(for rx only).
But here we do have the generic SPI DT bindings saying the default is 1.
So personally, I wouldn't go for the option of the least surprise, and
don't deviate from the generic bindings.
>> Commenting to the question in the cover letter: what would be the
>> purpose of spi-max-bus-width?
>
> Defining how many IO lines are wired on the board design. If this
> property is missing we would assume all IO lines are wired and the
> restrictions would be negotiated between the controller and the device
> without requiring explicit description in the DT.
Which is exactly the meaning of the standard property, except for the
default of all vs. 1.
I'll have to defer to Mark (broonie) for his opinion about deviating from
the way this is handled traditionally, and assuming different defaults...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* [PATCH] arm: sun4i: Add support for Pengpod 1000 tablet
From: Bob Ham @ 2018-06-01 17:55 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai
Cc: Rob Herring, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
This is initial support for the Pengpod 1000 tablet. The display is
not currently working but the UART, SD card and USB all work fine.
Signed-off-by: Bob Ham <rah-2mWpNWY8JZLk1uMJSBkQmQ@public.gmane.org>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts | 232 +++++++++++++++++++++++++++
2 files changed, 233 insertions(+)
create mode 100644 arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ade7a38543dc..e6e93e7ffc8b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -893,6 +893,7 @@ dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-olinuxino-lime.dtb \
sun4i-a10-pcduino.dtb \
sun4i-a10-pcduino2.dtb \
+ sun4i-a10-pengpod-1000.dtb \
sun4i-a10-pov-protab2-ips9.dtb
dtb-$(CONFIG_MACH_SUN5I) += \
sun5i-a10s-auxtek-t003.dtb \
diff --git a/arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts b/arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts
new file mode 100644
index 000000000000..94560400114d
--- /dev/null
+++ b/arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts
@@ -0,0 +1,232 @@
+/*
+ * Copyright 2015 Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
+ * Copyright 2017 Robert Ham <rah-2mWpNWY8JZLk1uMJSBkQmQ@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun4i-a10.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pwm/pwm.h>
+
+/ {
+ model = "PengPod 1000";
+ compatible = "pengpod,1000", "allwinner,sun4i-a10";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&bl_en_pin_pengpod1000>;
+ pwms = <&pwm 0 50000 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+ default-brightness-level = <8>;
+ enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&codec {
+ status = "okay";
+};
+
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ axp209: pmic@34 {
+ compatible = "x-powers,axp209";
+ reg = <0x34>;
+ interrupts = <0>;
+ };
+};
+
+#include "axp209.dtsi"
+
+&i2c1 {
+ status = "okay";
+
+ mma7660: accelerometer@4c {
+ compatible = "fsl,mma7660";
+ reg = <0x4c>;
+ };
+};
+
+&i2c2 {
+ status = "okay";
+
+ ft5406ee8: touchscreen@38 {
+ compatible = "edt,edt-ft5406";
+ reg = <0x38>;
+ interrupt-parent = <&pio>;
+ interrupts = <7 21 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&touchscreen_pins>;
+ reset-gpios = <&pio 1 13 GPIO_ACTIVE_LOW>;
+ touchscreen-size-x = <1024>;
+ touchscreen-size-y = <600>;
+ touchscreen-swapped-x-y;
+ };
+};
+
+&mmc0 {
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
+ cd-inverted;
+ status = "okay";
+};
+
+&pio {
+ bl_en_pin_pengpod1000: bl_en_pin@0 {
+ pins = "PH7";
+ function = "gpio_out";
+ };
+
+ touchscreen_pins: touchscreen_pins@0 {
+ pins = "PB13";
+ function = "gpio_out";
+ };
+
+ usb0_id_detect_pin: usb0_id_detect_pin@0 {
+ pins = "PH4";
+ function = "gpio_in";
+ bias-pull-up;
+ };
+
+ usb0_vbus_detect_pin: usb0_vbus_detect_pin@0 {
+ pins = "PH5";
+ function = "gpio_in";
+ bias-pull-down;
+ };
+};
+
+&pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm0_pin>;
+ status = "okay";
+};
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-cpu";
+};
+
+®_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <1250000>;
+ regulator-max-microvolt = <1250000>;
+ regulator-name = "vdd-int-dll";
+};
+
+®_ldo1 {
+ regulator-name = "vdd-rtc";
+};
+
+®_ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "avcc";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&otg_sram {
+ status = "okay";
+};
+
+®_usb0_vbus {
+ status = "okay";
+};
+
+®_usb1_vbus {
+ status = "okay";
+};
+
+®_usb2_vbus {
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pb_pins>;
+ status = "okay";
+};
+
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbphy {
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
+ usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
+ usb0_vbus_det-gpio = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
+ usb0_vbus-supply = <®_usb0_vbus>;
+ usb1_vbus-supply = <®_usb1_vbus>;
+ usb2_vbus-supply = <®_usb2_vbus>;
+ status = "okay";
+};
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 2/3] clk: bcm: Update and add tingray clock entries
From: Ray Jui @ 2018-06-01 17:56 UTC (permalink / raw)
To: Rob Herring
Cc: Michael Turquette, Stephen Boyd, Mark Rutland, linux-clk,
linux-kernel, bcm-kernel-feedback-list, devicetree,
linux-arm-kernel, Pramod Kumar
In-Reply-To: <20180531162556.GA955@rob-hp-laptop>
Hi Rob,
On 5/31/2018 9:25 AM, Rob Herring wrote:
> On Fri, May 25, 2018 at 09:45:16AM -0700, Ray Jui wrote:
>> Update and add Stingray clock definitions and tables so they match the
>> binding document and the latest ASIC datasheet
>>
>> Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>> ---
>> drivers/clk/bcm/clk-sr.c | 135 ++++++++++++++++++++++++++++++++-----
>> include/dt-bindings/clock/bcm-sr.h | 24 +++++--
>
> This goes in the 1st patch.
Please help to confirm. You want 1st patch and 2nd patch to be combined
into a single patch?
Thanks.
>
>> 2 files changed, 137 insertions(+), 22 deletions(-)
^ permalink raw reply
* Re: [PATCH] arm: sun4i: Add support for Pengpod 1000 tablet
From: Jagan Teki @ 2018-06-01 18:16 UTC (permalink / raw)
To: rah-2mWpNWY8JZLk1uMJSBkQmQ, Maxime Ripard, Chen-Yu Tsai
Cc: Rob Herring, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180601175538.16716-1-rah-2mWpNWY8JZLk1uMJSBkQmQ@public.gmane.org>
On 06/01/2018 11:25 PM, Bob Ham wrote:
> This is initial support for the Pengpod 1000 tablet. The display is
> not currently working but the UART, SD card and USB all work fine.
>
> Signed-off-by: Bob Ham <rah-2mWpNWY8JZLk1uMJSBkQmQ@public.gmane.org>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts | 232 +++++++++++++++++++++++++++
> 2 files changed, 233 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index ade7a38543dc..e6e93e7ffc8b 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -893,6 +893,7 @@ dtb-$(CONFIG_MACH_SUN4I) += \
> sun4i-a10-olinuxino-lime.dtb \
> sun4i-a10-pcduino.dtb \
> sun4i-a10-pcduino2.dtb \
> + sun4i-a10-pengpod-1000.dtb \
> sun4i-a10-pov-protab2-ips9.dtb
> dtb-$(CONFIG_MACH_SUN5I) += \
> sun5i-a10s-auxtek-t003.dtb \
> diff --git a/arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts b/arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts
> new file mode 100644
> index 000000000000..94560400114d
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun4i-a10-pengpod-1000.dts
> @@ -0,0 +1,232 @@
> +/*
> + * Copyright 2015 Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> + * Copyright 2017 Robert Ham <rah-2mWpNWY8JZLk1uMJSBkQmQ@public.gmane.org>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file 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.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
We need to use SPDX-License for new dts files.
^ permalink raw reply
* [PATCH linux-next v5 00/13] PECI device driver introduction
From: Jae Hyun Yoo @ 2018-06-01 18:20 UTC (permalink / raw)
To: Alan Cox, Andrew Jeffery, Andrew Lunn, Andy Shevchenko,
Arnd Bergmann, Benjamin Herrenschmidt, Fengguang Wu, Greg KH,
Guenter Roeck, Haiyue Wang, James Feist, Jason M Biils,
Jean Delvare, Joel Stanley, Julia Cartwright, Miguel Ojeda,
Milton Miller II, Pavel Machek, Randy Dunlap,
Rob Herring <robh+dt@
Cc: linux-kernel, linux-doc, devicetree, linux-hwmon,
linux-arm-kernel, linux-aspeed, openbmc, Jae Hyun Yoo
Introduction of the Platform Environment Control Interface (PECI) bus
device driver. PECI is a one-wire bus interface that provides a
communication channel between an Intel processor and chipset components to
external monitoring or control devices. PECI is designed to support the
following sideband functions:
* Processor and DRAM thermal management
- Processor fan speed control is managed by comparing Digital Thermal
Sensor (DTS) thermal readings acquired via PECI against the
processor-specific fan speed control reference point, or TCONTROL. Both
TCONTROL and DTS thermal readings are accessible via the processor PECI
client. These variables are referenced to a common temperature, the TCC
activation point, and are both defined as negative offsets from that
reference.
- PECI based access to the processor package configuration space provides
a means for Baseboard Management Controllers (BMC) or other platform
management devices to actively manage the processor and memory power
and thermal features.
* Platform Manageability
- Platform manageability functions including thermal, power, and error
monitoring. Note that platform 'power' management includes monitoring
and control for both the processor and DRAM subsystem to assist with
data center power limiting.
- PECI allows read access to certain error registers in the processor MSR
space and status monitoring registers in the PCI configuration space
within the processor and downstream devices.
- PECI permits writes to certain registers in the processor PCI
configuration space.
* Processor Interface Tuning and Diagnostics
- Processor interface tuning and diagnostics capabilities
(Intel Interconnect BIST). The processors Intel Interconnect Built In
Self Test (Intel IBIST) allows for infield diagnostic capabilities in
the Intel UPI and memory controller interfaces. PECI provides a port to
execute these diagnostics via its PCI Configuration read and write
capabilities.
* Failure Analysis
- Output the state of the processor after a failure for analysis via
Crashdump.
PECI uses a single wire for self-clocking and data transfer. The bus
requires no additional control lines. The physical layer is a self-clocked
one-wire bus that begins each bit with a driven, rising edge from an idle
level near zero volts. The duration of the signal driven high depends on
whether the bit value is a logic '0' or logic '1'. PECI also includes
variable data transfer rate established with every message. In this way, it
is highly flexible even though underlying logic is simple.
The interface design was optimized for interfacing between an Intel
processor and chipset components in both single processor and multiple
processor environments. The single wire interface provides low board
routing overhead for the multiple load connections in the congested routing
area near the processor and chipset components. Bus speed, error checking,
and low protocol overhead provides adequate link bandwidth and reliability
to transfer critical device operating conditions and configuration
information.
This implementation provides the basic framework to add PECI extensions to
the Linux bus and device models. A hardware specific 'Adapter' driver can
be attached to the PECI bus to provide sideband functions described above.
It is also possible to access all devices on an adapter from userspace
through the /dev interface. A device specific 'Client' driver also can be
attached to the PECI bus so each processor client's features can be
supported by the 'Client' driver through an adapter connection in the bus.
This patch set includes Aspeed 24xx/25xx PECI driver and PECI
cputemp/dimmtemp drivers as the first implementation for both adapter and
client drivers on the PECI bus framework.
Please review.
Thanks,
-Jae
Changes since v4:
* Fixed an incorrect endianness handling in peci-aspeed.
* Added a comment to explain about the asm/intel-family.h inclusion.
* Added an MFD module to support multi-function PECI client devices.
Changes since v3:
* Made code more simple and compact.
* Removed unused header file inclusion.
* Fixed incorrect error return values and messages.
* Removed DTS margin temperature from the peci-cputemp.
* Made some magic numbers use defines.
* Moved peci_get_cpu_id() into peci-core as a common function.
* Replaced the cancel_delayed_work() call with a cancel_delayed_work_sync().
* Replaced AST and Aspeed uses with ASPEED.
* Simplified peci command timeout checking logic using
regmap_read_poll_timeout().
* Simplified endian swap codes using endian handling macros.
* Dropped regmap read/write error checking except for the first access.
* Added a PECI reset setting in the device tree node.
* Removed unnecessary sleep from the probe context.
* Removed IRQF_SHARED flag from irq request code in the ASPEED PECI driver.
* Fixed typos in documents.
* Combined peci-bus.txt, peci-adapter.txt and peci-client.txt into peci.txt.
* Fixed and swept documents to drop some incorrect or unnecessary
descriptions.
* Fixed device tree to make unit-address format use reg contents.
* Simplified bit manipulations using <linux/bitfield.h>.
* Made client CPU model checking use <asm/intel-family.h> if available.
* Modified adapter heap allocation method to use kobject reference count
based.
* Added the low-level PECI xfer IOCTL again to support the Redfish
requirement.
* Added PM domain attach/detach code.
* Added logic for device instantiation through sysfs.
* Fix a bug of interrupt status checking code in peci-aspeed driver.
Changes since v2:
* Divided peci-hwmon driver into two drivers, peci-cputemp and
peci-dimmtemp.
* Added generic dt binding documents for PECI bus, adapter and client.
* Removed in_atomic() call from the PECI core driver.
* Improved PECI commands masking logic.
* Added permission check logic for PECI ioctls.
* Removed unnecessary type casts.
* Fixed some invalid error return codes.
* Added the mark_updated() function to improve update interval checking
logic.
* Fixed a bug in populated DIMM checking function.
* Fixed some typo, grammar and style issues in documents.
* Rewrote hwmon drivers to use devm_hwmon_device_register_with_info API.
* Made peci_match_id() function as a static.
* Replaced a deprecated create_singlethread_workqueue() call with an
alloc_ordered_workqueue() call.
* Reordered local variable definitions in reversed xmas tree notation.
* Listed up client CPUs that can be supported by peci-cputemp and
peci-dimmtemp hwmon drivers.
* Added CPU generation detection logic which checks CPUID signature through
PECI connection.
* Improved interrupt handling logic in the Aspeed PECI adapter driver.
* Fixed SPDX license identifier style in header files.
* Changed some macros in peci.h to static inline functions.
* Dropped sleepable context checking code in peci-core.
* Adjusted rt_mutex protection scope in peci-core.
* Moved adapter->xfer() checking code into peci_register_adapter().
* Improved PECI command retry checking logic.
* Changed ioctl base from 'P' to 0xb6 to avoid confiliction and updated
ioctl-number.txt to reflect the ioctl number of PECI subsystem.
* Added a comment to describe PECI retry action.
* Simplified return code handling of peci_ioctl_ping().
* Changed type of peci_ioctl_fn[] to static const.
* Fixed range checking code for valid PECI commands.
* Fixed the error return code on invalid PECI commands.
* Fixed incorrect definitions of PECI ioctl and its handling logic.
Changes since v1:
* Additionally implemented a core driver to support PECI linux bus driver
model.
* Modified Aspeed PECI driver to make that to be an adapter driver in PECI
bus.
* Modified PECI hwmon driver to make that to be a client driver in PECI
bus.
* Simplified hwmon driver attribute labels and removed redundant strings.
* Removed core_nums from device tree setting of hwmon driver and modified
core number detection logic to check the resolved_core register in client
CPU's local PCI configuration area.
* Removed dimm_nums from device tree setting of hwmon driver and added
populated DIMM detection logic to support dynamic creation.
* Removed indexing gap on core temperature and DIMM temperature attributes.
* Improved hwmon registration and dynamic attribute creation logic.
* Fixed structure definitions in PECI uapi header to make that use __u8,
__u16 and etc.
* Modified wait_for_completion_interruptible_timeout error handling logic
in Aspeed PECI driver to deliver errors correctly.
* Removed low-level xfer command from ioctl and kept only high-level PECI
command suite as ioctls.
* Fixed I/O timeout logic in Aspeed PECI driver using ktime.
* Added a function into hwmon driver to simplify update delay checking.
* Added a function into hwmon driver to convert 10.6 to millidegree.
* Dropped non-standard attributes in hwmon driver.
* Fixed OF table for hwmon to make it indicate as a PECI client of Intel
CPU target.
* Added a maintainer of PECI subsystem into MAINTAINERS document.
Jae Hyun Yoo (13):
dt-bindings: Add a document of PECI subsystem
Documentation: ioctl: Add ioctl numbers for PECI subsystem
drivers/peci: Add support for PECI bus driver core
dt-bindings: Add a document of PECI adapter driver for ASPEED
AST24xx/25xx SoCs
ARM: dts: aspeed: peci: Add PECI node
drivers/peci: Add a PECI adapter driver for Aspeed AST24xx/AST25xx
dt-bindings: mfd: Add a document for PECI client mfd
drivers/mfd: Add PECI client mfd driver
dt-bindings: hwmon: Add documents for PECI hwmon client drivers
Documentation: hwmon: Add documents for PECI hwmon client drivers
drivers/hwmon: Add PECI cputemp driver
drivers/hwmon: Add PECI dimmtemp driver
Add maintainers for the PECI subsystem
.../bindings/hwmon/peci-cputemp.txt | 11 +
.../bindings/hwmon/peci-dimmtemp.txt | 13 +
.../devicetree/bindings/mfd/peci-client.txt | 23 +
.../devicetree/bindings/peci/peci-aspeed.txt | 57 +
.../devicetree/bindings/peci/peci.txt | 59 +
Documentation/hwmon/peci-cputemp | 78 +
Documentation/hwmon/peci-dimmtemp | 50 +
Documentation/ioctl/ioctl-number.txt | 2 +
MAINTAINERS | 12 +
arch/arm/boot/dts/aspeed-g4.dtsi | 26 +
arch/arm/boot/dts/aspeed-g5.dtsi | 26 +
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/hwmon/Kconfig | 28 +
drivers/hwmon/Makefile | 2 +
drivers/hwmon/peci-cputemp.c | 401 +++++
drivers/hwmon/peci-dimmtemp.c | 295 ++++
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile | 1 +
drivers/mfd/peci-client.c | 205 +++
drivers/peci/Kconfig | 40 +
drivers/peci/Makefile | 9 +
drivers/peci/peci-aspeed.c | 498 ++++++
drivers/peci/peci-core.c | 1439 +++++++++++++++++
include/linux/mfd/peci-client.h | 60 +
include/linux/peci.h | 104 ++
include/uapi/linux/peci-ioctl.h | 265 +++
27 files changed, 3718 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/peci-cputemp.txt
create mode 100644 Documentation/devicetree/bindings/hwmon/peci-dimmtemp.txt
create mode 100644 Documentation/devicetree/bindings/mfd/peci-client.txt
create mode 100644 Documentation/devicetree/bindings/peci/peci-aspeed.txt
create mode 100644 Documentation/devicetree/bindings/peci/peci.txt
create mode 100644 Documentation/hwmon/peci-cputemp
create mode 100644 Documentation/hwmon/peci-dimmtemp
create mode 100644 drivers/hwmon/peci-cputemp.c
create mode 100644 drivers/hwmon/peci-dimmtemp.c
create mode 100644 drivers/mfd/peci-client.c
create mode 100644 drivers/peci/Kconfig
create mode 100644 drivers/peci/Makefile
create mode 100644 drivers/peci/peci-aspeed.c
create mode 100644 drivers/peci/peci-core.c
create mode 100644 include/linux/mfd/peci-client.h
create mode 100644 include/linux/peci.h
create mode 100644 include/uapi/linux/peci-ioctl.h
--
2.17.0
^ permalink raw reply
* [PATCH linux-next v5 01/13] dt-bindings: Add a document of PECI subsystem
From: Jae Hyun Yoo @ 2018-06-01 18:21 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, devicetree, linux-kernel, openbmc
Cc: Jae Hyun Yoo, Andrew Jeffery, Joel Stanley
This commit adds a document of generic PECI bus, adapter and client
driver.
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Haiyue Wang <haiyue.wang@linux.intel.com>
Reviewed-by: James Feist <james.feist@linux.intel.com>
Reviewed-by: Vernon Mauery <vernon.mauery@linux.intel.com>
Cc: Andrew Jeffery <andrew@aj.id.au>
Cc: Joel Stanley <joel@jms.id.au>
---
.../devicetree/bindings/peci/peci.txt | 59 +++++++++++++++++++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/peci/peci.txt
diff --git a/Documentation/devicetree/bindings/peci/peci.txt b/Documentation/devicetree/bindings/peci/peci.txt
new file mode 100644
index 000000000000..8db2b1e56a01
--- /dev/null
+++ b/Documentation/devicetree/bindings/peci/peci.txt
@@ -0,0 +1,59 @@
+Generic device tree configuration for PECI buses
+================================================
+
+Required properties:
+- compatible : Should be "simple-bus".
+- #address-cells : Should be present if the device has sub-nodes.
+- #size-cells : Should be present if the device has sub-nodes.
+- ranges : Should contain PECI controller registers ranges.
+
+Example:
+ peci: peci@10000000 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x10000000 0x1000>;
+ };
+
+Generic device tree configuration for PECI adapters
+===================================================
+
+Required properties:
+- #address-cells : Should be <1>. Read more about client addresses below.
+- #size-cells : Should be <0>. Read more about client addresses below.
+
+The cells properties above define that an address of CPU clients of a PECI bus
+are described by a single value.
+
+Example:
+ peci0: peci-bus@0 {
+ compatible = "soc,soc-peci";
+ reg = <0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+Generic device tree configuration for PECI clients
+==================================================
+
+Required properties:
+- compatible : Should contain name of PECI client.
+- reg : Should contain address of a client CPU. Address range of CPU
+ clients is starting from 0x30 based on PECI specification.
+
+Example:
+ peci-bus@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ < more properties >
+
+ peci-client@30 {
+ compatible = "intel,peci-client";
+ reg = <0x30>;
+ };
+
+ peci-client@31 {
+ compatible = "intel,peci-client";
+ reg = <0x31>;
+ };
+ };
--
2.17.0
^ 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