* Re: [PATCH 5/7] ASoC: rockchip: rockchip-max98090: Add node for HDMI
From: Rob Herring @ 2019-07-09 20:01 UTC (permalink / raw)
To: Cheng-Yi Chiang
Cc: linux-kernel, Hans Verkuil, Bartlomiej Zolnierkiewicz,
Greg Kroah-Hartman, Philipp Zabel, Mark Brown, Liam Girdwood,
Takashi Iwai, Jaroslav Kysela, Russell King, Andrzej Hajda,
Laurent Pinchart, David Airlie, Daniel Vetter, Heiko Stuebner,
dianders, dgreid, tzungbi, linux-media, alsa-devel, dri-devel,
linux-arm-kernel
In-Reply-To: <20190603043251.226549-6-cychiang@chromium.org>
On Mon, Jun 03, 2019 at 12:32:49PM +0800, Cheng-Yi Chiang wrote:
> Let user specify HDMI node so machine driver can use it to let codec
> driver register callback on correct hdmi-notifier.
>
> Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
> ---
> Documentation/devicetree/bindings/sound/rockchip-max98090.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/sound/rockchip-max98090.txt b/Documentation/devicetree/bindings/sound/rockchip-max98090.txt
> index a805aa99ad75..dae57c14864e 100644
> --- a/Documentation/devicetree/bindings/sound/rockchip-max98090.txt
> +++ b/Documentation/devicetree/bindings/sound/rockchip-max98090.txt
> @@ -7,6 +7,7 @@ Required properties:
> connected to the CODEC
> - rockchip,audio-codec: The phandle of the MAX98090 audio codec
> - rockchip,headset-codec: The phandle of Ext chip for jack detection
> +- rockchip,hdmi: The phandle of HDMI node for HDMI jack detection
>
> Example:
>
> @@ -16,4 +17,5 @@ sound {
> rockchip,i2s-controller = <&i2s>;
> rockchip,audio-codec = <&max98090>;
> rockchip,headset-codec = <&headsetcodec>;
> + rockchip,hdmi= <&hdmi>;
space ^
With that,
Acked-by: Rob Herring <robh@kernel.org>
> };
> --
> 2.22.0.rc1.257.g3120a18244-goog
>
^ permalink raw reply
* [PATCH] spi: dt-bindings: spi-controller: remove unnecessary 'maxItems: 1' from reg
From: Rob Herring @ 2019-07-09 19:26 UTC (permalink / raw)
To: Mark Brown; +Cc: devicetree, linux-kernel, Maxime Ripard, linux-spi
Mixing array constraints like 'maxItems' and string or integer value
constraints like 'minimum' don't make sense. Also, with only value
constraints, it is implied we have a single value. So lets remove
'maxItems: 1'.
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-spi@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/spi/spi-controller.yaml | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml
index 876c0623f322..a02e2fe2bfb2 100644
--- a/Documentation/devicetree/bindings/spi/spi-controller.yaml
+++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml
@@ -73,7 +73,6 @@ patternProperties:
Compatible of the SPI device.
reg:
- maxItems: 1
minimum: 0
maximum: 256
description:
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] dt-bindings: arm: Convert RDA Micro board/soc bindings to json-schema
From: Rob Herring @ 2019-07-09 19:02 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: devicetree, Andreas Färber,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190709184459.GA11886@Mani-XPS-13-9360>
On Tue, Jul 9, 2019 at 12:45 PM Manivannan Sadhasivam
<manivannan.sadhasivam@linaro.org> wrote:
>
> On Tue, Jul 09, 2019 at 12:41:19PM -0600, Rob Herring wrote:
> > On Tue, Jul 9, 2019 at 12:29 PM Rob Herring <robh@kernel.org> wrote:
> > >
> > > On Tue, Jul 9, 2019 at 11:15 AM Manivannan Sadhasivam
> > > <manivannan.sadhasivam@linaro.org> wrote:
> > > >
> > > > Hi Rob,
> > > >
> > > > On Tue, Jun 18, 2019 at 03:22:28PM -0600, Rob Herring wrote:
> > > > > Convert RDA Micro SoC bindings to DT schema format using json-schema.
> > > > >
> > > > > Cc: "Andreas Färber" <afaerber@suse.de>
> > > > > Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > > > > Signed-off-by: Rob Herring <robh@kernel.org>
> > > > > ---
> > > > > Andreas, Update the license on this one too to dual licensed if you
> > > > > want.
> > > >
> > > > I'm fine with GPL-2.0. Since there isn't any other RDA specific patches
> > > > in my tree, you want to take this patch? Else I have to send the Pull
> > > > Request to ARM SoC folks with this patch alone.
> > >
> > > Okay, I can take it. The preference is actually dual licensed which is
> > > why I asked, but that can be done later.
> >
> > And is that an ack from you?
>
> Yes, here is the formal tag:
>
> Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>
> Also, Andreas asked to switch to Dual license for Actions platform since he
> is the maintainer of it. But for RDA he is not, so I don't think there will
> be a concern here (I'm fine with GPL-2.0).
It's authorship that matters and Andreas was the author on the
original file. The maintainer only has a say in what license they'll
accept.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 6/6] interconnect: Add OPP table support for interconnects
From: Saravana Kannan @ 2019-07-09 19:02 UTC (permalink / raw)
To: Vincent Guittot
Cc: Georgi Djakov, Rob Herring, Mark Rutland, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Rafael J. Wysocki, Sweeney, Sean,
daidavid1, Rajendra Nayak, sibis, Bjorn Andersson, Evan Green,
Android Kernel Team, open list:THERMAL,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel
In-Reply-To: <CAKfTPtBngOT__TfmHXmmim-b9YhExOOvwVRaxYM9g9M6ffr_zQ@mail.gmail.com>
On Tue, Jul 9, 2019 at 12:25 AM Vincent Guittot
<vincent.guittot@linaro.org> wrote:
>
> On Sun, 7 Jul 2019 at 23:48, Saravana Kannan <saravanak@google.com> wrote:
> >
> > On Thu, Jul 4, 2019 at 12:12 AM Vincent Guittot
> > <vincent.guittot@linaro.org> wrote:
> > >
> > > On Wed, 3 Jul 2019 at 23:33, Saravana Kannan <saravanak@google.com> wrote:
> > > >
> > > > On Tue, Jul 2, 2019 at 11:45 PM Vincent Guittot
> > > > <vincent.guittot@linaro.org> wrote:
> > > > >
> > > > > On Wed, 3 Jul 2019 at 03:10, Saravana Kannan <saravanak@google.com> wrote:
> > > > > >
> > > > > > Interconnect paths can have different performance points. Now that OPP
> > > > > > framework supports bandwidth OPP tables, add OPP table support for
> > > > > > interconnects.
> > > > > >
> > > > > > Devices can use the interconnect-opp-table DT property to specify OPP
> > > > > > tables for interconnect paths. And the driver can obtain the OPP table for
> > > > > > an interconnect path by calling icc_get_opp_table().
> > > > >
> > > > > The opp table of a path must come from the aggregation of OPP tables
> > > > > of the interconnect providers.
> > > >
> > > > The aggregation of OPP tables of the providers is certainly the
> > > > superset of what a path can achieve, but to say that OPPs for
> > > > interconnect path should match that superset is an oversimplification
> > > > of the reality in hardware.
> > > >
> > > > There are lots of reasons an interconnect path might not want to use
> > > > all the available bandwidth options across all the interconnects in
> > > > the route.
> > > >
> > > > 1. That particular path might not have been validated or verified
> > > > during the HW design process for some of the frequencies/bandwidth
> > > > combinations of the providers.
> > >
> > > All these constraint are provider's constraints and not consumer's one
> > >
> > > The consumer asks for a bandwidth according to its needs and then the
> > > providers select the optimal bandwidth of each interconnect after
> > > aggregating all the request and according to what OPP have been
> > > validated
> >
> > Not really. The screening can be a consumer specific issue. The
> > consumer IP itself might have some issue with using too low of a
> > bandwidth or bandwidth that's not within some range. It should not be
>
> How can an IP ask for not enough bandwidth ?
> It asks the needed bandwidth based on its requirements
The "enough bandwidth" is not always obvious. It's only for very
simple cases that you can calculate the required bandwidth. Even for
cases that you think might be "obvious/easy" aren't always easy.
For example, you'd think a display IP would have a fixed bandwidth
requirement for a fixed resolution screen. But that's far from the
truth. It can also change as the number of layers change per frame.
For video decoder/encoder, it depends on how well the frames compress
with a specific compression scheme.
So the "required" bandwidth is often a heuristic based on the IP
frequency or traffic measurement.
But that's not even the point I was making in this specific "bullet".
A hardware IP might be screen/verified with only certain bandwidth
levels. Or it might have hardware bugs that prevent it from using
lower bandwidths even though it's technically sufficient. We need a
way to capture that per path. This is not even a fictional case. This
has been true multiple times over widely used IPs.
> > the provider's job to take into account all the IP that might be
> > connected to the interconnects. If the interconnect HW itself didn't
>
> That's not what I'm saying. The provider knows which bandwidth the
> interconnect can provide as it is the ones which configures it. So if
> the interconnect has a finite number of bandwidth point based probably
> on the possible clock frequency and others config of the interconnect,
> it selects the best final config after aggregating the request of the
> consumer.
I completely agree with this. What you are stating above is how it
should work and that's the whole point of the interconnect framework.
But this is orthogonal to the point I'm making.
> > change, the provider driver shouldn't need to change. By your
> > definition, a provider driver will have to account for all the
> > possible bus masters that might be connected to it across all SoCs.
>
> you didn't catch my point
Same. I think we are talking over each other. Let me try again.
You are trying to describe how and interconnect provider and framework
should work. There's no disagreement there.
My point is that consumers might not want to or can not always use all
the available bandwidth levels offered by the providers. There can be
many reasons for that (which is what I listed in my earlier emails)
and we need a good and generic way to capture that so that everyone
isn't trying to invent their own property.
> > That's not good design nor is it scalable.
> >
> > > >
> > > > 2. Similarly during parts screening in the factory, some of the
> > > > combinations might not have been screened and can't be guaranteed
> > > > to work.
> > >
> > > As above, it's the provider's job to select the final bandwidth
> > > according to its constraint
> >
> > Same reply as above.
> >
> > > >
> > > > 3. Only a certain set of bandwidth levels might make sense to use from
> > > > a power/performance balance given the device using it. For example:
> > > > - The big CPU might not want to use some of the lower bandwidths
> > > > but the little CPU might want to.
> > > > - The big CPU might not want to use some intermediate bandwidth
> > > > points if they don't save a lot of power compared to a higher
> > > > bandwidth levels, but the little CPU might want to.
> > > > - The little CPU might never want to use the higher set of
> > > > bandwidth levels since they won't be power efficient for the use
> > > > cases that might run on it.
> > >
> > > These example are quite vague about the reasons why little might never
> > > want to use higher bandwidth.
> >
> > How is it vague? I just said because of power/performance balance.
> >
> > > But then, if little doesn't ask high bandwidth it will not use them.
> >
> > If you are running a heuristics based algorithm to pick bandwidth,
> > this is how it'll know NOT to use some of the bandwidth levels.
>
> so you want to set a bandwidth according to the cpu frequency which is
> what has been proposed in other thread
Nope, that's just one heuristic. Often times it's based on hardware
monitors measuring interconnect activity. If you go look at the SDM845
in a Pixel 3, almost nothing is directly tied to the CPU frequency.
Even if you are scaling bandwidth based on other hardware
measurements, you might want to avoid some bandwidth level provided by
the interconnect providers because it's suboptimal.
For example, when making bandwidth votes to accommodate the big CPUs,
you might never want to use some of the lower bandwidth levels because
they are not power efficient for any CPU frequency or any bandwidth
level. Because at those levels the memory/interconnect is so slow that
it has a non-trivial utilization increase (because the CPU is
stalling) of the big CPUs.
Again, this is completely different from what the providers/icc
framework does. Which is, once the request is made, they aggregate and
set the actual interconnect frequencies correctly.
> >
> > > >
> > > > 4. It might not make sense from a system level power perspective.
> > > > Let's take an example of a path S (source) -> A -> B -> C -> D
> > > > (destination).
> > > > - A supports only 2, 5, 7 and 10 GB/s. B supports 1, 2 ... 10 GB/s.
> > > > C supports 5 and 10 GB/s
> > > > - If you combine and list the superset of bandwidth levels
> > > > supported in that path, that'd be 1, 2, 3, ... 10 GB/s.
> > > > - Which set of bandwidth levels make sense will depend on the
> > > > hardware characteristics of the interconnects.
> > > > - If B is the biggest power sink, then you might want to use all 10
> > > > levels.
> > > > - If A is the biggest power sink, then you might want to use all 2,
> > > > 5 and 10 GB/s of the levels.
> > > > - If C is the biggest power sink then you might only want to use 5
> > > > and 10 GB/s
> > > > - The more hops and paths you get the more convoluted this gets.
> > > >
> > > > 5. The design of the interconnects themselves might have an impact on
> > > > which bandwidth levels are used.
> > > > - For example, the FIFO depth between two specific interconnects
> > > > might affect the valid bandwidth levels for a specific path.
> > > > - Say S1 -> A -> B -> D1, S2 -> C -> B -> D1 and S2 -> C -> D2 are
> > > > three paths.
> > > > - If C <-> B FIFO depth is small, then there might be a requirement
> > > > that C and B be closely performance matched to avoid system level
> > > > congestion due to back pressure.
> > > > - So S2 -> D1 path can't use all the bandwidth levels supported by
> > > > C-B combination.
> > > > - But S2 -> D2 can use all the bandwidth levels supported by C.
> > > > - And S1 -> D1 can use all the levels supported by A-B combination.
> > > >
> > >
> > > All the examples above makes sense but have to be handle by the
> > > provider not the consumer. The consumer asks for a bandwidth according
> > > to its constraints. Then the provider which is the driver that manages
> > > the interconnect IP, should manage all this hardware and platform
> > > specific stuff related to the interconnect IP in order to set the
> > > optimal bandwidth that fit both consumer constraint and platform
> > > specific configuration.
> >
> > Sure, but the provider itself can have interconnect properties to
> > indicate which other interconnects it's tied to. And the provider will
> > still need the interconnect-opp-table to denote which bandwidth levels
> > are sensible to use with each of its connections.
You seem to have missed this comment.
Thanks,
Saravana
> > So in some instances the interconnect-opp-table covers the needs of
> > purely consumers and in some instances purely providers. But in either
> > case, it's still needed to describe the hardware properly.
> >
> > -Saravana
> >
> > > > These are just some of the reasons I could recollect in a few minutes.
> > > > These are all real world cases I had to deal with in the past several
> > > > years of dealing with scaling interconnects. I'm sure vendors and SoCs
> > > > I'm not familiar with have other good reasons I'm not aware of.
> > > >
> > > > Trying to figure this all out by aggregating OPP tables of
> > > > interconnect providers just isn't feasible nor is it efficient. The
> > > > OPP tables for an interconnect path is describing the valid BW levels
> > > > supported by that path and verified in hardware and makes a lot of
> > > > sense to capture it clearly in DT.
> > > >
> > > > > So such kind of OPP table should be at
> > > > > provider level but not at path level.
> > > >
> > > > They can also use it if they want to, but they'll probably want to use
> > > > a frequency OPP table.
> > > >
> > > >
> > > > -Saravana
> > > >
> > > > >
> > > > > >
> > > > > > Signed-off-by: Saravana Kannan <saravanak@google.com>
> > > > > > ---
> > > > > > drivers/interconnect/core.c | 27 ++++++++++++++++++++++++++-
> > > > > > include/linux/interconnect.h | 7 +++++++
> > > > > > 2 files changed, 33 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
> > > > > > index 871eb4bc4efc..881bac80bc1e 100644
> > > > > > --- a/drivers/interconnect/core.c
> > > > > > +++ b/drivers/interconnect/core.c
> > > > > > @@ -47,6 +47,7 @@ struct icc_req {
> > > > > > */
> > > > > > struct icc_path {
> > > > > > size_t num_nodes;
> > > > > > + struct opp_table *opp_table;
> > > > > > struct icc_req reqs[];
> > > > > > };
> > > > > >
> > > > > > @@ -313,7 +314,7 @@ struct icc_path *of_icc_get(struct device *dev, const char *name)
> > > > > > {
> > > > > > struct icc_path *path = ERR_PTR(-EPROBE_DEFER);
> > > > > > struct icc_node *src_node, *dst_node;
> > > > > > - struct device_node *np = NULL;
> > > > > > + struct device_node *np = NULL, *opp_node;
> > > > > > struct of_phandle_args src_args, dst_args;
> > > > > > int idx = 0;
> > > > > > int ret;
> > > > > > @@ -381,10 +382,34 @@ struct icc_path *of_icc_get(struct device *dev, const char *name)
> > > > > > dev_err(dev, "%s: invalid path=%ld\n", __func__, PTR_ERR(path));
> > > > > > mutex_unlock(&icc_lock);
> > > > > >
> > > > > > + opp_node = of_parse_phandle(np, "interconnect-opp-table", idx);
> > > > > > + if (opp_node) {
> > > > > > + path->opp_table = dev_pm_opp_of_find_table_from_node(opp_node);
> > > > > > + of_node_put(opp_node);
> > > > > > + }
> > > > > > +
> > > > > > +
> > > > > > return path;
> > > > > > }
> > > > > > EXPORT_SYMBOL_GPL(of_icc_get);
> > > > > >
> > > > > > +/**
> > > > > > + * icc_get_opp_table() - Get the OPP table that corresponds to a path
> > > > > > + * @path: reference to the path returned by icc_get()
> > > > > > + *
> > > > > > + * This function will return the OPP table that corresponds to a path handle.
> > > > > > + * If the interconnect API is disabled, NULL is returned and the consumer
> > > > > > + * drivers will still build. Drivers are free to handle this specifically, but
> > > > > > + * they don't have to.
> > > > > > + *
> > > > > > + * Return: opp_table pointer on success. NULL is returned when the API is
> > > > > > + * disabled or the OPP table is missing.
> > > > > > + */
> > > > > > +struct opp_table *icc_get_opp_table(struct icc_path *path)
> > > > > > +{
> > > > > > + return path->opp_table;
> > > > > > +}
> > > > > > +
> > > > > > /**
> > > > > > * icc_set_bw() - set bandwidth constraints on an interconnect path
> > > > > > * @path: reference to the path returned by icc_get()
> > > > > > diff --git a/include/linux/interconnect.h b/include/linux/interconnect.h
> > > > > > index dc25864755ba..0c0bc55f0e89 100644
> > > > > > --- a/include/linux/interconnect.h
> > > > > > +++ b/include/linux/interconnect.h
> > > > > > @@ -9,6 +9,7 @@
> > > > > >
> > > > > > #include <linux/mutex.h>
> > > > > > #include <linux/types.h>
> > > > > > +#include <linux/pm_opp.h>
> > > > > >
> > > > > > /* macros for converting to icc units */
> > > > > > #define Bps_to_icc(x) ((x) / 1000)
> > > > > > @@ -28,6 +29,7 @@ struct device;
> > > > > > struct icc_path *icc_get(struct device *dev, const int src_id,
> > > > > > const int dst_id);
> > > > > > struct icc_path *of_icc_get(struct device *dev, const char *name);
> > > > > > +struct opp_table *icc_get_opp_table(struct icc_path *path);
> > > > > > void icc_put(struct icc_path *path);
> > > > > > int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw);
> > > > > >
> > > > > > @@ -49,6 +51,11 @@ static inline void icc_put(struct icc_path *path)
> > > > > > {
> > > > > > }
> > > > > >
> > > > > > +static inline struct opp_table *icc_get_opp_table(struct icc_path *path)
> > > > > > +{
> > > > > > + return NULL;
> > > > > > +}
> > > > > > +
> > > > > > static inline int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw)
> > > > > > {
> > > > > > return 0;
> > > > > > --
> > > > > > 2.22.0.410.gd8fdbe21b5-goog
> > > > > >
> > >
> > > --
> > > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com.
> > >
^ permalink raw reply
* Re: [linux,dev-5.1 v1] dt-bindings: gpio: aspeed: Add SGPIO support
From: Rob Herring @ 2019-07-09 18:53 UTC (permalink / raw)
To: Hongwei Zhang
Cc: devicetree, Joel Stanley, Andrew Jeffery, Linus Walleij,
Mark Rutland, linux-aspeed, linux-kernel@vger.kernel.org
In-Reply-To: <1562184069-22332-1-git-send-email-hongweiz@ami.com>
On Wed, Jul 3, 2019 at 2:01 PM Hongwei Zhang <hongweiz@ami.com> wrote:
>
> Add bindings to support SGPIO on AST2400 or AST2500.
>
> Signed-off-by: Hongwei Zhang <hongweiz@ami.com>
> ---
> .../devicetree/bindings/gpio/sgpio-aspeed.txt | 36 ++++++++++++++++++++++
Is this SGPIO as in the blinky lights for HDDs in servers? If so, that
has nothing to do with Linux GPIO subsystem.
BTW, You might want to look at Calxeda highbank SATA driver. It has a
bit-banged SGPIO interface using GPIO lines in it.
Rob
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm: Convert RDA Micro board/soc bindings to json-schema
From: Manivannan Sadhasivam @ 2019-07-09 18:44 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Andreas Färber,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_Jsq+=rAafEFq+3pUc3A35aLzf9gtgGzj1aheHzoQ+MSiO1Q@mail.gmail.com>
On Tue, Jul 09, 2019 at 12:41:19PM -0600, Rob Herring wrote:
> On Tue, Jul 9, 2019 at 12:29 PM Rob Herring <robh@kernel.org> wrote:
> >
> > On Tue, Jul 9, 2019 at 11:15 AM Manivannan Sadhasivam
> > <manivannan.sadhasivam@linaro.org> wrote:
> > >
> > > Hi Rob,
> > >
> > > On Tue, Jun 18, 2019 at 03:22:28PM -0600, Rob Herring wrote:
> > > > Convert RDA Micro SoC bindings to DT schema format using json-schema.
> > > >
> > > > Cc: "Andreas Färber" <afaerber@suse.de>
> > > > Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > > > Signed-off-by: Rob Herring <robh@kernel.org>
> > > > ---
> > > > Andreas, Update the license on this one too to dual licensed if you
> > > > want.
> > >
> > > I'm fine with GPL-2.0. Since there isn't any other RDA specific patches
> > > in my tree, you want to take this patch? Else I have to send the Pull
> > > Request to ARM SoC folks with this patch alone.
> >
> > Okay, I can take it. The preference is actually dual licensed which is
> > why I asked, but that can be done later.
>
> And is that an ack from you?
Yes, here is the formal tag:
Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Also, Andreas asked to switch to Dual license for Actions platform since he
is the maintainer of it. But for RDA he is not, so I don't think there will
be a concern here (I'm fine with GPL-2.0).
Thanks,
Mani
>
> Rob
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm: Convert RDA Micro board/soc bindings to json-schema
From: Rob Herring @ 2019-07-09 18:41 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: devicetree, Andreas Färber,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_Jsq+S9FEVq_ikLF2vWS3VkrGueFa8nPnbHhAjThemP+eajA@mail.gmail.com>
On Tue, Jul 9, 2019 at 12:29 PM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, Jul 9, 2019 at 11:15 AM Manivannan Sadhasivam
> <manivannan.sadhasivam@linaro.org> wrote:
> >
> > Hi Rob,
> >
> > On Tue, Jun 18, 2019 at 03:22:28PM -0600, Rob Herring wrote:
> > > Convert RDA Micro SoC bindings to DT schema format using json-schema.
> > >
> > > Cc: "Andreas Färber" <afaerber@suse.de>
> > > Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > > Signed-off-by: Rob Herring <robh@kernel.org>
> > > ---
> > > Andreas, Update the license on this one too to dual licensed if you
> > > want.
> >
> > I'm fine with GPL-2.0. Since there isn't any other RDA specific patches
> > in my tree, you want to take this patch? Else I have to send the Pull
> > Request to ARM SoC folks with this patch alone.
>
> Okay, I can take it. The preference is actually dual licensed which is
> why I asked, but that can be done later.
And is that an ack from you?
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/6] dt-bindings: arm: Document RTD1296
From: Rob Herring @ 2019-07-09 18:40 UTC (permalink / raw)
To: Andreas Färber
Cc: Aleix Roca Nonell, Mark Rutland, Thomas Gleixner, Jason Cooper,
Marc Zyngier, Matthias Brugger,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
devicetree, linux-kernel@vger.kernel.org
In-Reply-To: <27a3468f-e7b4-e334-5956-8db87d04ff8c@suse.de>
On Sun, Jul 7, 2019 at 7:31 AM Andreas Färber <afaerber@suse.de> wrote:
>
> Am 07.07.19 um 15:23 schrieb Aleix Roca Nonell:
> > Add bindings for Relatek RTD1296 SoC. And the Bannana Pi BPI-W2 board.
>
> "Realtek", "Banana"
>
> >
> > Signed-off-by: Aleix Roca Nonell <kernelrocks@gmail.com>
> > ---
> > Documentation/devicetree/bindings/arm/realtek.txt | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/realtek.txt b/Documentation/devicetree/bindings/arm/realtek.txt
> > index 95839e19ae92..78da1004d38c 100644
> > --- a/Documentation/devicetree/bindings/arm/realtek.txt
> > +++ b/Documentation/devicetree/bindings/arm/realtek.txt
> > @@ -20,3 +20,16 @@ Root node property compatible must contain, depending on board:
> > Example:
> >
> > compatible = "zidoo,x9s", "realtek,rtd1295";
> > +
> > +
> > +RTD1296 SoC
> > +===========
> > +
> > +Required root node properties:
> > +
> > + - compatible : must contain "realtek,rtd1296"
>
> I'm pretty sure that I had such a patch on the list already, so this is
> lacking my authorship.
>
> Also, Rob has been working to convert these to YAML, so we should
> probably complete that first and then add RTD1296 properly.
I'm just waiting for you to either ack it or apply it.
Rob
^ permalink raw reply
* [PATCH] ARM: dts: am335x-wega.dtsi: fix wrong card detect pin level
From: Andreas Klinger @ 2019-07-09 18:32 UTC (permalink / raw)
To: linux-omap
Cc: bcousson, tony, robh+dt, mark.rutland, devicetree, linux-kernel
mmc cards on mmc1 are not detected because of wrong card detect (cd) level.
Change cd from GPIO_ACTIVE_HIGH to GPIO_ACTIVE_LOW.
This is necessary because of commit e63201f19438 ("mmc: omap_hsmmc:
Delete platform data GPIO CD and WP")
Signed-off-by: Andreas Klinger <ak@it-klinger.de>
---
arch/arm/boot/dts/am335x-wega.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-wega.dtsi b/arch/arm/boot/dts/am335x-wega.dtsi
index b7d28a20341f..84581fed3d06 100644
--- a/arch/arm/boot/dts/am335x-wega.dtsi
+++ b/arch/arm/boot/dts/am335x-wega.dtsi
@@ -157,7 +157,7 @@
bus-width = <4>;
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins>;
- cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
+ cd-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
status = "okay";
};
--
2.11.0
--
^ permalink raw reply related
* Re: [PATCH] dt-bindings: arm: Convert RDA Micro board/soc bindings to json-schema
From: Rob Herring @ 2019-07-09 18:29 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: devicetree, Andreas Färber,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190709171508.GA10127@Mani-XPS-13-9360>
On Tue, Jul 9, 2019 at 11:15 AM Manivannan Sadhasivam
<manivannan.sadhasivam@linaro.org> wrote:
>
> Hi Rob,
>
> On Tue, Jun 18, 2019 at 03:22:28PM -0600, Rob Herring wrote:
> > Convert RDA Micro SoC bindings to DT schema format using json-schema.
> >
> > Cc: "Andreas Färber" <afaerber@suse.de>
> > Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
> > Andreas, Update the license on this one too to dual licensed if you
> > want.
>
> I'm fine with GPL-2.0. Since there isn't any other RDA specific patches
> in my tree, you want to take this patch? Else I have to send the Pull
> Request to ARM SoC folks with this patch alone.
Okay, I can take it. The preference is actually dual licensed which is
why I asked, but that can be done later.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [v4 1/6] dt-bindings: media: Document bindings for DW MIPI CSI-2 Host
From: Sakari Ailus @ 2019-07-09 18:25 UTC (permalink / raw)
To: Luis de Oliveira
Cc: mchehab@kernel.org, davem@davemloft.net,
gregkh@linuxfoundation.org, Jonathan.Cameron@huawei.com,
robh@kernel.org, nicolas.ferre@microchip.com,
paulmck@linux.ibm.com, mark.rutland@arm.com, kishon@ti.com,
devicetree@vger.kernel.org, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org, Joao.Pinto@synopsys.com
In-Reply-To: <MN2PR12MB37109D7AADCE4823CB458CB9CBF60@MN2PR12MB3710.namprd12.prod.outlook.com>
Hi Luis,
On Mon, Jul 08, 2019 at 03:21:50PM +0000, Luis de Oliveira wrote:
> Hi Sakari,
>
> Thank you for your feedback.
> I have my comments inline.
>
> From: Sakari Ailus <sakari.ailus@iki.fi>
> Date: Fri, Jun 28, 2019 at 15:13:26
>
> > Hi Luis,
> >
> > Thank you for the patchset.
> >
> > On Tue, Jun 11, 2019 at 09:20:50PM +0200, Luis Oliveira wrote:
> > > From: Luis Oliveira <lolivei@synopsys.com>
> > >
> > > Add bindings for Synopsys DesignWare MIPI CSI-2 host.
> > >
> > > Signed-off-by: Luis Oliveira <lolivei@synopsys.com>
> > > ---
> > > Changelog
> > > v3-v4
> > > - remove "plat" from the block name @rob @laurent
> > > - remove "phy-names" when single-entry @rob
> > > - remove "snps,output-type" -> went to the driver config @laurent
> > >
> > > .../devicetree/bindings/media/snps,dw-csi.txt | 41 ++++++++++++++++++++++
> > > 1 file changed, 41 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/media/snps,dw-csi.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/media/snps,dw-csi.txt b/Documentation/devicetree/bindings/media/snps,dw-csi.txt
> > > new file mode 100644
> > > index 0000000..613b7f9
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/snps,dw-csi.txt
> > > @@ -0,0 +1,41 @@
> > > +Synopsys DesignWare CSI-2 Host controller
> > > +
> > > +Description
> > > +-----------
> > > +
> > > +This HW block is used to receive image coming from an MIPI CSI-2 compatible
> > > +camera.
> > > +
> > > +Required properties:
> > > +- compatible : shall be "snps,dw-csi"
> > > +- reg : physical base address and size of the device memory
> > > + mapped registers;
> > > +- interrupts : DW CSI-2 Host interrupts
> > > +- phys : List of one PHY specifier (as defined in
> > > + Documentation/devicetree/bindings/phy/phy-bindings.txt).
> > > + This PHY is a MIPI DPHY working in RX mode.
> > > +- resets : Reference to a reset controller (optional)
> > > +
> > > +The per-board settings:
> > > + - port sub-node describing a single endpoint connected to the camera as
> > > + described in video-interfaces.txt[1].
> >
> > Which endpoint properties in video-interfaces.txt are relevant for the
> > hardware? Which values may they have?
> >
>
> Currently I'm using only two properties "data-lanes" and "bus-width", but
> I have plans to add blanking info also.
> I will add more info.
Isn't blanking defined by what the transmitter seneds? Or do you have
hardware limitations on the receiver side?
I've only heard of one such case before, and it was a very old parallel
receiver.
If you have a CSI-2 receiver, bus-width isn't relevant --- it's for paralle
interfaces only. Please add data-lanes to required endpoint properties.
--
Regards,
Sakari Ailus
^ permalink raw reply
* [PATCH 5/5] staging: mt7621-dts: fix register range of memc node in mt7621.dtsi
From: Chuanhong Guo @ 2019-07-09 18:20 UTC (permalink / raw)
To: open list:COMMON CLK FRAMEWORK,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, open list:MIPS, open list:STAGING SUBSYSTEM
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
Ralf Baechle, Paul Burton, James Hogan, John Crispin,
Greg Kroah-Hartman, Weijie Gao, NeilBrown, Chuanhong Guo
In-Reply-To: <20190709182018.23193-1-gch981213@gmail.com>
The memc node from mt7621.dtsi has incorrect register resource.
Fix it according to the programming guide.
Signed-off-by: Weijie Gao <hackpascal@gmail.com>
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
---
drivers/staging/mt7621-dts/mt7621.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi b/drivers/staging/mt7621-dts/mt7621.dtsi
index 12717f570ceb..ac9189276590 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -138,7 +138,7 @@
memc: memc@5000 {
compatible = "mtk,mt7621-memc";
- reg = <0x300 0x100>;
+ reg = <0x5000 0x1000>;
};
cpc: cpc@1fbf0000 {
--
2.21.0
^ permalink raw reply related
* [PATCH 4/5] staging: mt7621-dts: add dt nodes for mt7621-pll
From: Chuanhong Guo @ 2019-07-09 18:20 UTC (permalink / raw)
To: open list:COMMON CLK FRAMEWORK,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, open list:MIPS, open list:STAGING SUBSYSTEM
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
Ralf Baechle, Paul Burton, James Hogan, John Crispin,
Greg Kroah-Hartman, Weijie Gao, NeilBrown, Chuanhong Guo
In-Reply-To: <20190709182018.23193-1-gch981213@gmail.com>
This commit adds device-tree node for mt7621-pll and use its clock
accordingly.
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
---
drivers/staging/mt7621-dts/mt7621.dtsi | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi b/drivers/staging/mt7621-dts/mt7621.dtsi
index a4c08110094b..12717f570ceb 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -1,4 +1,5 @@
#include <dt-bindings/interrupt-controller/mips-gic.h>
+#include <dt-bindings/clock/mt7621-clk.h>
#include <dt-bindings/gpio/gpio.h>
/ {
@@ -27,12 +28,11 @@
serial0 = &uartlite;
};
- cpuclock: cpuclock@0 {
- #clock-cells = <0>;
- compatible = "fixed-clock";
+ pll: pll {
+ compatible = "mediatek,mt7621-pll", "syscon";
- /* FIXME: there should be way to detect this */
- clock-frequency = <880000000>;
+ #clock-cells = <1>;
+ clock-output-names = "cpu", "bus";
};
sysclock: sysclock@0 {
@@ -155,7 +155,6 @@
compatible = "ns16550a";
reg = <0xc00 0x100>;
- clocks = <&sysclock>;
clock-frequency = <50000000>;
interrupt-parent = <&gic>;
@@ -172,7 +171,7 @@
compatible = "ralink,mt7621-spi";
reg = <0xb00 0x100>;
- clocks = <&sysclock>;
+ clocks = <&pll MT7621_CLK_BUS>;
resets = <&rstctrl 18>;
reset-names = "spi";
@@ -372,7 +371,7 @@
timer {
compatible = "mti,gic-timer";
interrupts = <GIC_LOCAL 1 IRQ_TYPE_NONE>;
- clocks = <&cpuclock>;
+ clocks = <&pll MT7621_CLK_CPU>;
};
};
--
2.21.0
^ permalink raw reply related
* [PATCH 3/5] dt: bindings: add mt7621-pll dt binding documentation
From: Chuanhong Guo @ 2019-07-09 18:20 UTC (permalink / raw)
To: open list:COMMON CLK FRAMEWORK,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, open list:MIPS, open list:STAGING SUBSYSTEM
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
Ralf Baechle, Paul Burton, James Hogan, John Crispin,
Greg Kroah-Hartman, Weijie Gao, NeilBrown, Chuanhong Guo
In-Reply-To: <20190709182018.23193-1-gch981213@gmail.com>
This commit adds device tree binding documentation for MT7621
PLL controller.
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
---
.../bindings/clock/mediatek,mt7621-pll.txt | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt b/Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt
new file mode 100644
index 000000000000..05c15062cd20
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt
@@ -0,0 +1,19 @@
+Binding for Mediatek MT7621 PLL controller
+
+The PLL controller provides the 2 main clocks of the SoC: CPU and BUS.
+
+Required Properties:
+- compatible: has to be "mediatek,mt7621-pll"
+- #clock-cells: has to be one
+
+Optional properties:
+- clock-output-names: should be "cpu", "bus"
+
+Example:
+ pll {
+ compatible = "mediatek,mt7621-pll", "syscon";
+
+ #clock-cells = <1>;
+ clock-output-names = "cpu", "bus";
+ };
+
--
2.21.0
^ permalink raw reply related
* [PATCH 2/5] MIPS: ralink: fix cpu clock of mt7621 and add dt clk devices
From: Chuanhong Guo @ 2019-07-09 18:20 UTC (permalink / raw)
To: open list:COMMON CLK FRAMEWORK,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, open list:MIPS, open list:STAGING SUBSYSTEM
Cc: Mark Rutland, Weijie Gao, Greg Kroah-Hartman, Stephen Boyd,
James Hogan, Michael Turquette, Ralf Baechle, Paul Burton,
Rob Herring, John Crispin, NeilBrown
In-Reply-To: <20190709182018.23193-1-gch981213@gmail.com>
For a long time the mt7621 uses a fixed cpu clock which causes a problem
if the cpu frequency is not 880MHz.
This patch fixes the cpu clock calculation and adds the cpu/bus clkdev
which will be used in dts.
Ported from OpenWrt:
c7ca224299 ramips: fix cpu clock of mt7621 and add dt clk devices
Signed-off-by: Weijie Gao <hackpascal@gmail.com>
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
---
arch/mips/include/asm/mach-ralink/mt7621.h | 20 ++++
arch/mips/ralink/mt7621.c | 102 ++++++++++++++-------
arch/mips/ralink/timer-gic.c | 4 +-
3 files changed, 93 insertions(+), 33 deletions(-)
diff --git a/arch/mips/include/asm/mach-ralink/mt7621.h b/arch/mips/include/asm/mach-ralink/mt7621.h
index 65483a4681ab..51a6e51aef3f 100644
--- a/arch/mips/include/asm/mach-ralink/mt7621.h
+++ b/arch/mips/include/asm/mach-ralink/mt7621.h
@@ -17,6 +17,10 @@
#define SYSC_REG_CHIP_REV 0x0c
#define SYSC_REG_SYSTEM_CONFIG0 0x10
#define SYSC_REG_SYSTEM_CONFIG1 0x14
+#define SYSC_REG_CLKCFG0 0x2c
+#define SYSC_REG_CUR_CLK_STS 0x44
+
+#define MEMC_REG_CPU_PLL 0x648
#define CHIP_REV_PKG_MASK 0x1
#define CHIP_REV_PKG_SHIFT 16
@@ -24,6 +28,22 @@
#define CHIP_REV_VER_SHIFT 8
#define CHIP_REV_ECO_MASK 0xf
+#define XTAL_MODE_SEL_MASK 0x7
+#define XTAL_MODE_SEL_SHIFT 6
+
+#define CPU_CLK_SEL_MASK 0x3
+#define CPU_CLK_SEL_SHIFT 30
+
+#define CUR_CPU_FDIV_MASK 0x1f
+#define CUR_CPU_FDIV_SHIFT 8
+#define CUR_CPU_FFRAC_MASK 0x1f
+#define CUR_CPU_FFRAC_SHIFT 0
+
+#define CPU_PLL_PREDIV_MASK 0x3
+#define CPU_PLL_PREDIV_SHIFT 12
+#define CPU_PLL_FBDIV_MASK 0x7f
+#define CPU_PLL_FBDIV_SHIFT 4
+
#define MT7621_DRAM_BASE 0x0
#define MT7621_DDR2_SIZE_MIN 32
#define MT7621_DDR2_SIZE_MAX 256
diff --git a/arch/mips/ralink/mt7621.c b/arch/mips/ralink/mt7621.c
index 9415be0d57b8..31158b88bcb6 100644
--- a/arch/mips/ralink/mt7621.c
+++ b/arch/mips/ralink/mt7621.c
@@ -7,22 +7,22 @@
#include <linux/kernel.h>
#include <linux/init.h>
+#include <linux/clk.h>
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <dt-bindings/clock/mt7621-clk.h>
#include <asm/mipsregs.h>
#include <asm/smp-ops.h>
#include <asm/mips-cps.h>
#include <asm/mach-ralink/ralink_regs.h>
#include <asm/mach-ralink/mt7621.h>
+#include <asm/time.h>
#include <pinmux.h>
#include "common.h"
-#define SYSC_REG_SYSCFG 0x10
-#define SYSC_REG_CPLL_CLKCFG0 0x2c
-#define SYSC_REG_CUR_CLK_STS 0x44
-#define CPU_CLK_SEL (BIT(30) | BIT(31))
-
#define MT7621_GPIO_MODE_UART1 1
#define MT7621_GPIO_MODE_I2C 2
#define MT7621_GPIO_MODE_UART3_MASK 0x3
@@ -108,49 +108,89 @@ static struct rt2880_pmx_group mt7621_pinmux_data[] = {
{ 0 }
};
+static struct clk *clks[MT7621_CLK_MAX];
+static struct clk_onecell_data clk_data = {
+ .clks = clks,
+ .clk_num = ARRAY_SIZE(clks),
+};
+
phys_addr_t mips_cpc_default_phys_base(void)
{
panic("Cannot detect cpc address");
}
+static struct clk *__init mt7621_add_sys_clkdev(
+ const char *id, unsigned long rate)
+{
+ struct clk *clk;
+ int err;
+
+ clk = clk_register_fixed_rate(NULL, id, NULL, 0, rate);
+ if (IS_ERR(clk))
+ panic("failed to allocate %s clock structure", id);
+
+ err = clk_register_clkdev(clk, id, NULL);
+ if (err)
+ panic("unable to register %s clock device", id);
+
+ return clk;
+}
+
void __init ralink_clk_init(void)
{
- int cpu_fdiv = 0;
- int cpu_ffrac = 0;
- int fbdiv = 0;
- u32 clk_sts, syscfg;
- u8 clk_sel = 0, xtal_mode;
- u32 cpu_clk;
+ const static u32 prediv_tbl[] = {0, 1, 2, 2};
+ u32 syscfg, xtal_sel, clkcfg, clk_sel, curclk, ffiv, ffrac;
+ u32 pll, prediv, fbdiv;
+ u32 xtal_clk, cpu_clk, bus_clk;
+
+ syscfg = rt_sysc_r32(SYSC_REG_SYSTEM_CONFIG0);
+ xtal_sel = (syscfg >> XTAL_MODE_SEL_SHIFT) & XTAL_MODE_SEL_MASK;
- if ((rt_sysc_r32(SYSC_REG_CPLL_CLKCFG0) & CPU_CLK_SEL) != 0)
- clk_sel = 1;
+ clkcfg = rt_sysc_r32(SYSC_REG_CLKCFG0);
+ clk_sel = (clkcfg >> CPU_CLK_SEL_SHIFT) & CPU_CLK_SEL_MASK;
+
+ curclk = rt_sysc_r32(SYSC_REG_CUR_CLK_STS);
+ ffiv = (curclk >> CUR_CPU_FDIV_SHIFT) & CUR_CPU_FDIV_MASK;
+ ffrac = (curclk >> CUR_CPU_FFRAC_SHIFT) & CUR_CPU_FFRAC_MASK;
+
+ if (xtal_sel <= 2)
+ xtal_clk = 20 * 1000 * 1000;
+ else if (xtal_sel <= 5)
+ xtal_clk = 40 * 1000 * 1000;
+ else
+ xtal_clk = 25 * 1000 * 1000;
switch (clk_sel) {
case 0:
- clk_sts = rt_sysc_r32(SYSC_REG_CUR_CLK_STS);
- cpu_fdiv = ((clk_sts >> 8) & 0x1F);
- cpu_ffrac = (clk_sts & 0x1F);
- cpu_clk = (500 * cpu_ffrac / cpu_fdiv) * 1000 * 1000;
+ cpu_clk = 500 * 1000 * 1000;
break;
-
case 1:
- fbdiv = ((rt_sysc_r32(0x648) >> 4) & 0x7F) + 1;
- syscfg = rt_sysc_r32(SYSC_REG_SYSCFG);
- xtal_mode = (syscfg >> 6) & 0x7;
- if (xtal_mode >= 6) {
- /* 25Mhz Xtal */
- cpu_clk = 25 * fbdiv * 1000 * 1000;
- } else if (xtal_mode >= 3) {
- /* 40Mhz Xtal */
- cpu_clk = 40 * fbdiv * 1000 * 1000;
- } else {
- /* 20Mhz Xtal */
- cpu_clk = 20 * fbdiv * 1000 * 1000;
- }
+ pll = rt_memc_r32(MEMC_REG_CPU_PLL);
+ fbdiv = (pll >> CPU_PLL_FBDIV_SHIFT) & CPU_PLL_FBDIV_MASK;
+ prediv = (pll >> CPU_PLL_PREDIV_SHIFT) & CPU_PLL_PREDIV_MASK;
+ cpu_clk = ((fbdiv + 1) * xtal_clk) >> prediv_tbl[prediv];
break;
+ default:
+ cpu_clk = xtal_clk;
}
+
+ cpu_clk = cpu_clk / ffiv * ffrac;
+ bus_clk = cpu_clk / 4;
+
+ clks[MT7621_CLK_CPU] = mt7621_add_sys_clkdev("cpu", cpu_clk);
+ clks[MT7621_CLK_BUS] = mt7621_add_sys_clkdev("bus", bus_clk);
+
+ pr_info("CPU Clock: %dMHz\n", cpu_clk / 1000000);
+ mips_hpt_frequency = cpu_clk / 2;
}
+static void __init mt7621_clocks_init_dt(struct device_node *np)
+{
+ of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
+}
+
+CLK_OF_DECLARE(mt7621_clk, "mediatek,mt7621-pll", mt7621_clocks_init_dt);
+
void __init ralink_of_remap(void)
{
rt_sysc_membase = plat_of_remap_node("mtk,mt7621-sysc");
diff --git a/arch/mips/ralink/timer-gic.c b/arch/mips/ralink/timer-gic.c
index 944fbe0fc741..9bbaa37a0da1 100644
--- a/arch/mips/ralink/timer-gic.c
+++ b/arch/mips/ralink/timer-gic.c
@@ -9,14 +9,14 @@
#include <linux/of.h>
#include <linux/clk-provider.h>
-#include <linux/clocksource.h>
+#include <asm/time.h>
#include "common.h"
void __init plat_time_init(void)
{
ralink_of_remap();
-
+ ralink_clk_init();
of_clk_init(NULL);
timer_probe();
}
--
2.21.0
^ permalink raw reply related
* [PATCH 1/5] MIPS: ralink: add dt binding header for mt7621-pll
From: Chuanhong Guo @ 2019-07-09 18:20 UTC (permalink / raw)
To: open list:COMMON CLK FRAMEWORK,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, open list:MIPS, open list:STAGING SUBSYSTEM
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
Ralf Baechle, Paul Burton, James Hogan, John Crispin,
Greg Kroah-Hartman, Weijie Gao, NeilBrown, Chuanhong Guo,
Rob Herring
In-Reply-To: <20190709182018.23193-1-gch981213@gmail.com>
This patch adds dt binding header for mediatek,mt7621-pll
Signed-off-by: Weijie Gao <hackpascal@gmail.com>
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
include/dt-bindings/clock/mt7621-clk.h | 14 ++++++++++++++
1 file changed, 14 insertions(+)
create mode 100644 include/dt-bindings/clock/mt7621-clk.h
diff --git a/include/dt-bindings/clock/mt7621-clk.h b/include/dt-bindings/clock/mt7621-clk.h
new file mode 100644
index 000000000000..a29e14ee2efe
--- /dev/null
+++ b/include/dt-bindings/clock/mt7621-clk.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2018 Weijie Gao <hackpascal@gmail.com>
+ */
+
+#ifndef __DT_BINDINGS_MT7621_CLK_H
+#define __DT_BINDINGS_MT7621_CLK_H
+
+#define MT7621_CLK_CPU 0
+#define MT7621_CLK_BUS 1
+
+#define MT7621_CLK_MAX 2
+
+#endif /* __DT_BINDINGS_MT7621_CLK_H */
--
2.21.0
^ permalink raw reply related
* [PATCH 0/5] MIPS: ralink: add CPU clock detection for MT7621
From: Chuanhong Guo @ 2019-07-09 18:20 UTC (permalink / raw)
To: open list:COMMON CLK FRAMEWORK,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, open list:MIPS, open list:STAGING SUBSYSTEM
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Mark Rutland,
Ralf Baechle, Paul Burton, James Hogan, John Crispin,
Greg Kroah-Hartman, Weijie Gao, NeilBrown, Chuanhong Guo
This patchset ports CPU clock detection for MT7621 from OpenWrt.
Last time I sent this, I forgot to add an binding include which
caused a compile error and the patch doesn't stay in linux-next.
This patchset resent the first two commits and also added binding
documentation for mt7621-pll and used it in mt7621-dts at
drivers/staging.
BTW: What should I do with such a patchset that touches multiple
parts in kernel?
Is it correct to send the entire patchset to lists of all involved
subsystems?
Chuanhong Guo (5):
MIPS: ralink: add dt binding header for mt7621-pll
MIPS: ralink: fix cpu clock of mt7621 and add dt clk devices
dt: bindings: add mt7621-pll dt binding documentation
staging: mt7621-dts: add dt nodes for mt7621-pll
staging: mt7621-dts: fix register range of memc node in mt7621.dtsi
.../bindings/clock/mediatek,mt7621-pll.txt | 19 ++++
arch/mips/include/asm/mach-ralink/mt7621.h | 20 ++++
arch/mips/ralink/mt7621.c | 102 ++++++++++++------
arch/mips/ralink/timer-gic.c | 4 +-
drivers/staging/mt7621-dts/mt7621.dtsi | 17 ++-
include/dt-bindings/clock/mt7621-clk.h | 14 +++
6 files changed, 134 insertions(+), 42 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt7621-pll.txt
create mode 100644 include/dt-bindings/clock/mt7621-clk.h
--
2.21.0
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: backlight: fix vendor prefix for ArcticSand arcxcnn driver bindings
From: Dan Murphy @ 2019-07-09 18:01 UTC (permalink / raw)
To: Brian Dodge
Cc: devicetree, Daniel Thompson, jingoohan1, dri-devel, robh+dt,
jacek.anaszewski, Pavel Machek, Peter Bacon, Lee Jones,
linux-leds
In-Reply-To: <CAFaGBPk4q5Cfy4q4KqGDb7KwU_Mi22Mzu88KVO+3G7OJztyABQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4165 bytes --]
Brian
On 7/9/19 12:48 PM, Brian Dodge wrote:
> FYI: please note that pSemi's legal department has informed me that
> they do *not* want to keep the "ArcticSand" copyright notices and the
> single pSemi line is appropriate.
>
Thanks for the follow up. Lawyers can be fickle about this stuff.
> On Mon, Jul 8, 2019 at 2:02 PM Dan Murphy <dmurphy@ti.com
> <mailto:dmurphy@ti.com>> wrote:
>
> Brian
>
> On 6/30/19 7:28 PM, Brian Dodge wrote:
> > The vendor-prefixes.txt file properly refers to ArcticSand
> > as arctic but the driver bindings improperly abbreviated the
> > prefix to arc. This was a mistake in the original patch. This
> > patch adds "arctic" and retains "arc" (deprecated) bindings
> >
> > Signed-off-by: Brian Dodge <bdodge09@gmail.com
> <mailto:bdodge09@gmail.com>>
> > ---
> > .../bindings/leds/backlight/arcxcnn_bl.txt | 31
> +++++++++++++++-------
> > 1 file changed, 21 insertions(+), 10 deletions(-)
> >
> > diff --git
> a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> > index 230abde..4d98394 100644
> > ---
> a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> > +++
> b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> > @@ -1,8 +1,13 @@
> > -Binding for ArcticSand arc2c0608 LED driver
> > +Binding for ArcticSand arc family LED drivers
> >
> > Required properties:
> > -- compatible: should be "arc,arc2c0608"
> > -- reg: slave address
> > +- compatible: one of
> > + "arctic,arc1c0608"
> > + "arctic,arc2c0608"
> > + "arctic,arc3c0845"
> > + "arc,arc2c0608" (deprecated)
> > +
> > +- reg: slave address
> >
> > Optional properties:
> > - default-brightness: brightness value on boot, value
> from: 0-4095
> > @@ -11,19 +16,25 @@ Optional properties:
> > - led-sources: List of enabled channels from 0 to 5.
> > See
> Documentation/devicetree/bindings/leds/common.txt
> >
> > -- arc,led-config-0: setting for register ILED_CONFIG_0
> > -- arc,led-config-1: setting for register ILED_CONFIG_1
> > -- arc,dim-freq: PWM mode frequence setting (bits
> [3:0] used)
> > -- arc,comp-config: setting for register CONFIG_COMP
> > -- arc,filter-config: setting for register FILTER_CONFIG
> > -- arc,trim-config: setting for register IMAXTUNE
> > +- arctic,led-config-0: setting for register ILED_CONFIG_0
> > +- arctic,led-config-1: setting for register ILED_CONFIG_1
> > +- arctic,dim-freq: PWM mode frequence setting (bits [3:0] used)
> > +- arctic,comp-config: setting for register CONFIG_COMP
> > +- arctic,filter-config: setting for register FILTER_CONFIG
> > +- arctic,trim-config: setting for register IMAXTUNE
> > +- arc,led-config-0: setting for register ILED_CONFIG_0
> (deprecated)
> > +- arc,led-config-1: setting for register ILED_CONFIG_1
> (deprecated)
> > +- arc,dim-freq: PWM mode frequence setting (bits
> [3:0] used) (deprecated)
> > +- arc,comp-config: setting for register CONFIG_COMP (deprecated)
> > +- arc,filter-config: setting for register FILTER_CONFIG
> (deprecated)
> > +- arc,trim-config: setting for register IMAXTUNE (deprecated)
> >
> > Note: Optional properties not specified will default to values
> in IC EPROM
> >
> > Example:
> >
> > arc2c0608@30 {
> > - compatible = "arc,arc2c0608";
> > + compatible = "arctic,arc2c0608";
> > reg = <0x30>;
> > default-brightness = <500>;
> > label = "lcd-backlight";
>
>
> Reviewed-by: Dan Murphy <dmurphy@ti.com <mailto:dmurphy@ti.com>>
>
[-- Attachment #1.2: Type: text/html, Size: 6272 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v7 16/18] MAINTAINERS: add entry for KUnit the unit testing framework
From: Brendan Higgins @ 2019-07-09 18:01 UTC (permalink / raw)
To: shuah
Cc: Frank Rowand, Greg KH, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Luis Chamberlain, Peter Zijlstra, Rob Herring, Stephen Boyd,
Theodore Ts'o, Masahiro Yamada, devicetree, dri-devel,
kunit-dev, open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, KERNEL
In-Reply-To: <7cc417dd-036f-7dc1-6814-b1fdac810f03@kernel.org>
On Tue, Jul 9, 2019 at 7:53 AM shuah <shuah@kernel.org> wrote:
>
> On 7/9/19 12:30 AM, Brendan Higgins wrote:
> > Add myself as maintainer of KUnit, the Linux kernel's unit testing
> > framework.
> >
> > Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
> > ---
> > MAINTAINERS | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 677ef41cb012c..48d04d180a988 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -8599,6 +8599,17 @@ S: Maintained
> > F: tools/testing/selftests/
> > F: Documentation/dev-tools/kselftest*
> >
> > +KERNEL UNIT TESTING FRAMEWORK (KUnit)
> > +M: Brendan Higgins <brendanhiggins@google.com>
> > +L: linux-kselftest@vger.kernel.org
> > +L: kunit-dev@googlegroups.com
> > +W: https://google.github.io/kunit-docs/third_party/kernel/docs/
> > +S: Maintained
> > +F: Documentation/dev-tools/kunit/
> > +F: include/kunit/
> > +F: kunit/
> > +F: tools/testing/kunit/
> > +
> > KERNEL USERMODE HELPER
> > M: Luis Chamberlain <mcgrof@kernel.org>
> > L: linux-kernel@vger.kernel.org
> >
>
> Thanks Brendan.
>
> I am good with this. I can take KUnit patches through kselftest
> with your Ack.
My acknowledgement? Sure! I thought we already agreed to that.
Also, do we need an ack from Masahiro or Michal for the Kbuild patch
[PATCH v7 06/18]? And an ack from Josh or Peter for the objtool patch
[PATCH v7 08/18]?
Greg and Logan gave me a Reviewed-by for the Kbuild patch, so maybe
that's fine, but I don't have any reviews or acks for the objtool
patch.
Thanks!
^ permalink raw reply
* Re: [PATCH v2 2/4] edac: Add support for Amazon's Annapurna Labs L1 EDAC
From: Joe Perches @ 2019-07-09 17:59 UTC (permalink / raw)
To: Jonathan Cameron, Hanna Hawa
Cc: robh+dt, mark.rutland, bp, mchehab, james.morse, davem, gregkh,
linus.walleij, nicolas.ferre, paulmck, dwmw, benh, ronenk, talel,
jonnyc, hanochu, devicetree, linux-kernel, linux-edac
In-Reply-To: <20190709173229.0000135f@huawei.com>
On Tue, 2019-07-09 at 17:32 +0800, Jonathan Cameron wrote:
> On Sun, 7 Jul 2019 14:57:36 +0300
[]
> > +#define ARM_CA57_CPUMERRSR_REPEAT GENMASK(39, 32)
> > +#define ARM_CA57_CPUMERRSR_OTHER GENMASK(47, 40)
> > +#define ARM_CA57_CPUMERRSR_FATAL GENMASK(63, 63)
GENMASK_ULL
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: backlight: fix vendor prefix for ArcticSand arcxcnn driver bindings
From: Brian Dodge @ 2019-07-09 17:48 UTC (permalink / raw)
To: Dan Murphy
Cc: devicetree, Daniel Thompson, jingoohan1, dri-devel, robh+dt,
jacek.anaszewski, Pavel Machek, Peter Bacon, Lee Jones,
linux-leds
In-Reply-To: <f2cf7c51-4857-30bd-a096-b1ce5ff01bd5@ti.com>
[-- Attachment #1.1: Type: text/plain, Size: 3473 bytes --]
FYI: please note that pSemi's legal department has informed me that they do
*not* want to keep the "ArcticSand" copyright notices and the single pSemi
line is appropriate.
On Mon, Jul 8, 2019 at 2:02 PM Dan Murphy <dmurphy@ti.com> wrote:
> Brian
>
> On 6/30/19 7:28 PM, Brian Dodge wrote:
> > The vendor-prefixes.txt file properly refers to ArcticSand
> > as arctic but the driver bindings improperly abbreviated the
> > prefix to arc. This was a mistake in the original patch. This
> > patch adds "arctic" and retains "arc" (deprecated) bindings
> >
> > Signed-off-by: Brian Dodge <bdodge09@gmail.com>
> > ---
> > .../bindings/leds/backlight/arcxcnn_bl.txt | 31
> +++++++++++++++-------
> > 1 file changed, 21 insertions(+), 10 deletions(-)
> >
> > diff --git
> a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> > index 230abde..4d98394 100644
> > --- a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> > +++ b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> > @@ -1,8 +1,13 @@
> > -Binding for ArcticSand arc2c0608 LED driver
> > +Binding for ArcticSand arc family LED drivers
> >
> > Required properties:
> > -- compatible: should be "arc,arc2c0608"
> > -- reg: slave address
> > +- compatible: one of
> > + "arctic,arc1c0608"
> > + "arctic,arc2c0608"
> > + "arctic,arc3c0845"
> > + "arc,arc2c0608" (deprecated)
> > +
> > +- reg: slave address
> >
> > Optional properties:
> > - default-brightness: brightness value on boot, value from:
> 0-4095
> > @@ -11,19 +16,25 @@ Optional properties:
> > - led-sources: List of enabled channels from 0 to 5.
> > See
> Documentation/devicetree/bindings/leds/common.txt
> >
> > -- arc,led-config-0: setting for register ILED_CONFIG_0
> > -- arc,led-config-1: setting for register ILED_CONFIG_1
> > -- arc,dim-freq: PWM mode frequence setting (bits [3:0]
> used)
> > -- arc,comp-config: setting for register CONFIG_COMP
> > -- arc,filter-config: setting for register FILTER_CONFIG
> > -- arc,trim-config: setting for register IMAXTUNE
> > +- arctic,led-config-0: setting for register ILED_CONFIG_0
> > +- arctic,led-config-1: setting for register ILED_CONFIG_1
> > +- arctic,dim-freq: PWM mode frequence setting (bits [3:0] used)
> > +- arctic,comp-config: setting for register CONFIG_COMP
> > +- arctic,filter-config: setting for register FILTER_CONFIG
> > +- arctic,trim-config: setting for register IMAXTUNE
> > +- arc,led-config-0: setting for register ILED_CONFIG_0 (deprecated)
> > +- arc,led-config-1: setting for register ILED_CONFIG_1 (deprecated)
> > +- arc,dim-freq: PWM mode frequence setting (bits [3:0]
> used) (deprecated)
> > +- arc,comp-config: setting for register CONFIG_COMP (deprecated)
> > +- arc,filter-config: setting for register FILTER_CONFIG (deprecated)
> > +- arc,trim-config: setting for register IMAXTUNE (deprecated)
> >
> > Note: Optional properties not specified will default to values in IC
> EPROM
> >
> > Example:
> >
> > arc2c0608@30 {
> > - compatible = "arc,arc2c0608";
> > + compatible = "arctic,arc2c0608";
> > reg = <0x30>;
> > default-brightness = <500>;
> > label = "lcd-backlight";
>
>
> Reviewed-by: Dan Murphy <dmurphy@ti.com>
>
>
[-- Attachment #1.2: Type: text/html, Size: 4583 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm: Convert RDA Micro board/soc bindings to json-schema
From: Manivannan Sadhasivam @ 2019-07-09 17:15 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, Andreas Färber, linux-arm-kernel
In-Reply-To: <20190618212229.32302-4-robh@kernel.org>
Hi Rob,
On Tue, Jun 18, 2019 at 03:22:28PM -0600, Rob Herring wrote:
> Convert RDA Micro SoC bindings to DT schema format using json-schema.
>
> Cc: "Andreas Färber" <afaerber@suse.de>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> Andreas, Update the license on this one too to dual licensed if you
> want.
I'm fine with GPL-2.0. Since there isn't any other RDA specific patches
in my tree, you want to take this patch? Else I have to send the Pull
Request to ARM SoC folks with this patch alone.
Thanks,
Mani
>
> Documentation/devicetree/bindings/arm/rda.txt | 17 ----------------
> .../devicetree/bindings/arm/rda.yaml | 20 +++++++++++++++++++
> MAINTAINERS | 2 +-
> 3 files changed, 21 insertions(+), 18 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/rda.txt
> create mode 100644 Documentation/devicetree/bindings/arm/rda.yaml
>
> diff --git a/Documentation/devicetree/bindings/arm/rda.txt b/Documentation/devicetree/bindings/arm/rda.txt
> deleted file mode 100644
> index 43c80762c428..000000000000
> --- a/Documentation/devicetree/bindings/arm/rda.txt
> +++ /dev/null
> @@ -1,17 +0,0 @@
> -RDA Micro platforms device tree bindings
> -----------------------------------------
> -
> -RDA8810PL SoC
> -=============
> -
> -Required root node properties:
> -
> - - compatible : must contain "rda,8810pl"
> -
> -
> -Boards:
> -
> -Root node property compatible must contain, depending on board:
> -
> - - Orange Pi 2G-IoT: "xunlong,orangepi-2g-iot"
> - - Orange Pi i96: "xunlong,orangepi-i96"
> diff --git a/Documentation/devicetree/bindings/arm/rda.yaml b/Documentation/devicetree/bindings/arm/rda.yaml
> new file mode 100644
> index 000000000000..51cec2b63b04
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/rda.yaml
> @@ -0,0 +1,20 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/rda.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: RDA Micro platforms device tree bindings
> +
> +maintainers:
> + - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> +
> +properties:
> + compatible:
> + items:
> + - enum:
> + - xunlong,orangepi-2g-iot # Orange Pi 2G-IoT
> + - xunlong,orangepi-i96 # Orange Pi i96
> + - const: rda,8810pl
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2c6f4d15805e..56ee276088eb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2111,7 +2111,7 @@ F: arch/arm/boot/dts/rda8810pl-*
> F: drivers/clocksource/timer-rda.c
> F: drivers/irqchip/irq-rda-intc.c
> F: drivers/tty/serial/rda-uart.c
> -F: Documentation/devicetree/bindings/arm/rda.txt
> +F: Documentation/devicetree/bindings/arm/rda.yaml
> F: Documentation/devicetree/bindings/interrupt-controller/rda,8810pl-intc.txt
> F: Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt
> F: Documentation/devicetree/bindings/timer/rda,8810pl-timer.txt
> --
> 2.20.1
>
^ permalink raw reply
* RE: [v4 1/6] dt-bindings: media: Document bindings for DW MIPI CSI-2 Host
From: Luis de Oliveira @ 2019-07-09 17:08 UTC (permalink / raw)
To: Eugen.Hristev@microchip.com, Luis.Oliveira@synopsys.com,
mchehab@kernel.org, davem@davemloft.net,
gregkh@linuxfoundation.org, Jonathan.Cameron@huawei.com,
robh@kernel.org, Nicolas.Ferre@microchip.com,
paulmck@linux.ibm.com, mark.rutland@arm.com, kishon@ti.com,
devicetree@vger.kernel.org, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: Joao.Pinto@synopsys.com
In-Reply-To: <ae0ffeca-9305-b5a2-3480-da623d15ce67@microchip.com>
Hi Eugen,
From: Eugen.Hristev@microchip.com <Eugen.Hristev@microchip.com>
Date: Tue, Jul 09, 2019 at 15:33:50
>
>
> On 11.06.2019 22:20, Luis Oliveira wrote:
> > From: Luis Oliveira <lolivei@synopsys.com>
> >
> > Add bindings for Synopsys DesignWare MIPI CSI-2 host.
> >
> > Signed-off-by: Luis Oliveira <lolivei@synopsys.com>
> > ---
> > Changelog
> > v3-v4
> > - remove "plat" from the block name @rob @laurent
> > - remove "phy-names" when single-entry @rob
> > - remove "snps,output-type" -> went to the driver config @laurent
> >
> > .../devicetree/bindings/media/snps,dw-csi.txt | 41 ++++++++++++++++++++++
> > 1 file changed, 41 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/snps,dw-csi.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/snps,dw-csi.txt b/Documentation/devicetree/bindings/media/snps,dw-csi.txt
> > new file mode 100644
> > index 0000000..613b7f9
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/snps,dw-csi.txt
> > @@ -0,0 +1,41 @@
> > +Synopsys DesignWare CSI-2 Host controller
> > +
> > +Description
> > +-----------
> > +
> > +This HW block is used to receive image coming from an MIPI CSI-2 compatible
> > +camera.
> > +
> > +Required properties:
> > +- compatible : shall be "snps,dw-csi"
> > +- reg : physical base address and size of the device memory
> > + mapped registers;
> > +- interrupts : DW CSI-2 Host interrupts
> > +- phys : List of one PHY specifier (as defined in
> > + Documentation/devicetree/bindings/phy/phy-bindings.txt).
> > + This PHY is a MIPI DPHY working in RX mode.
> > +- resets : Reference to a reset controller (optional)
> > +
> > +The per-board settings:
> > + - port sub-node describing a single endpoint connected to the camera as
> > + described in video-interfaces.txt[1].
> > +
> > +Example:
> > +
> > + csi2: csi2@3000 {
> > + compatible = "snps,dw-csi";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = < 0x03000 0x7FF>;
> > + phys = <&mipi_dphy_rx>;
> > + resets = <&dw_rst 1>;
> > + interrupts = <2>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + csi_ep1: endpoint {
> > + remote-endpoint = <&camera_1>;
> > + data-lanes = <1 2>;
> > + };
>
> Hello Luis,
>
> Which is the output port (endpoint) : how to connect the output of
> csi2host to another node ?
> I mean, the second port of this block, or, how is the data taken from
> csi2host ?
>
I understand your question, I think you guessed this is not the complete
pipeline (I have a top driver that interacts with this one).
I was not planning to submit it, do you think I should?
The behavior is very similar with this one
./drivers/media/platform/exynos4-is/media-dev.c
> Thanks,
>
> Eugen
>
> > + };
> > + };
> >
Thanks,
Luis
^ permalink raw reply
* Re: [PATCH V5 1/5] dt-bindings: imx: Add clock binding doc for i.MX8MN
From: Rob Herring @ 2019-07-09 17:05 UTC (permalink / raw)
To: Anson.Huang
Cc: mturquette, sboyd, robh+dt, mark.rutland, shawnguo, s.hauer,
kernel, festevam, catalin.marinas, will.deacon, maxime.ripard,
olof, horms+renesas, jagan, leonard.crestez, bjorn.andersson,
dinguyen, enric.balletbo, aisheng.dong, ping.bai, abel.vesa,
l.stach, peng.fan, linux-clk, devicetree, linux-arm-kernel,
linux-kernel, Linux-imx
In-Reply-To: <20190619055247.35771-1-Anson.Huang@nxp.com>
On Wed, 19 Jun 2019 13:52:43 +0800, Anson.Huang@nxp.com wrote:
> From: Anson Huang <Anson.Huang@nxp.com>
>
> Add the clock binding doc for i.MX8MN.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> No changes.
> ---
> .../devicetree/bindings/clock/imx8mn-clock.yaml | 112 +++++++++++
> include/dt-bindings/clock/imx8mn-clock.h | 215 +++++++++++++++++++++
> 2 files changed, 327 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/imx8mn-clock.yaml
> create mode 100644 include/dt-bindings/clock/imx8mn-clock.h
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm: Convert RDA Micro board/soc bindings to json-schema
From: Rob Herring @ 2019-07-09 17:03 UTC (permalink / raw)
To: devicetree; +Cc: Andreas Färber, linux-arm-kernel, Manivannan Sadhasivam
In-Reply-To: <20190618212229.32302-4-robh@kernel.org>
On Tue, Jun 18, 2019 at 03:22:28PM -0600, Rob Herring wrote:
> Convert RDA Micro SoC bindings to DT schema format using json-schema.
>
> Cc: "Andreas Färber" <afaerber@suse.de>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> Andreas, Update the license on this one too to dual licensed if you
> want.
Ping.
>
> Documentation/devicetree/bindings/arm/rda.txt | 17 ----------------
> .../devicetree/bindings/arm/rda.yaml | 20 +++++++++++++++++++
> MAINTAINERS | 2 +-
> 3 files changed, 21 insertions(+), 18 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/rda.txt
> create mode 100644 Documentation/devicetree/bindings/arm/rda.yaml
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox