* [PATCH v5 2/5] drm/bridge: Add RGB to VGA bridge support
From: Laurent Pinchart @ 2016-10-07 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f39e907c-424f-7572-f88e-5dd0b6009631@codeaurora.org>
Hi Archit,
On Friday 07 Oct 2016 10:27:31 Archit Taneja wrote:
> On 10/07/2016 02:34 AM, Laurent Pinchart wrote:
> > On Thursday 06 Oct 2016 15:53:28 Sean Paul wrote:
> >> On Thu, Oct 6, 2016 at 1:27 PM, Laurent Pinchart wrote:
> >>> On Thursday 06 Oct 2016 17:09:57 Archit Taneja wrote:
> >>>> On 10/06/2016 12:51 PM, Maxime Ripard wrote:
> >>>>> On Mon, Oct 03, 2016 at 04:40:57PM +0530, Archit Taneja wrote:
> >>>>>> On 09/30/2016 08:07 PM, Maxime Ripard wrote:
> >>>>>>> Some boards have an entirely passive RGB to VGA bridge, based on
> >>>>>>> either DACs or resistor ladders.
> >>>>>>>
> >>>>>>> Those might or might not have an i2c bus routed to the VGA connector
> >>>>>>> in order to access the screen EDIDs.
> >>>>>>>
> >>>>>>> Add a bridge that doesn't do anything but expose the modes available
> >>>>>>> on the screen, either based on the EDIDs if available, or based on
> >>>>>>> the XGA standards.
> >>>>>>>
> >>>>>>> Acked-by: Rob Herring <robh@kernel.org>
> >>>>>>> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >>>>>>> ---
> >>>>>>> .../bindings/display/bridge/rgb-to-vga-bridge.txt | 48 +++++
> >>>>>>> drivers/gpu/drm/bridge/Kconfig | 7 +
> >>>>>>> drivers/gpu/drm/bridge/Makefile | 1 +
> >>>>>>> drivers/gpu/drm/bridge/rgb-to-vga.c | 229 +++++++++++
> >>>>>>> 4 files changed, 285 insertions(+)
> >>>>>>> create mode 100644
> >>>>>>> Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.t
> >>>>>>> xt
> >>>>>>> create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c
> >>>>>>>
> >>>>>>> diff --git
> >>>>>>> a/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge
> >>>>>>> .
> >>>>>>> txt
> >>>>>>> b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge
> >>>>>>> .
> >>>>>>> txt
> >>>>>>> new file mode 100644
> >>>>>>> index 000000000000..a8375bc1f9cb
> >>>>>>> --- /dev/null
> >>>>>>> +++
> >>>>>>> b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge
> >>>>>>> .
> >>>>>>> tx
> >>>>>>> t @@ -0,0 +1,48 @@
> >>>>>>> +Dumb RGB to VGA bridge
> >>>>>>> +----------------------
> >>>>>>> +
> >>>>>>> +This binding is aimed for dumb RGB to VGA bridges that do not
> >>>>>>> require
> >>>>>>> +any configuration.
> >>>>>>> +
> >>>>>>> +Required properties:
> >>>>>>> +
> >>>>>>> +- compatible: Must be "rgb-to-vga-bridge"
> >>>>>>
> >>>>>> I'd talked to Laurent on IRC if he's okay with this. And I guess you
> >>>>>> to had discussed it during XDC too. He's suggested that it'd be
> >>>>>> better
> >>>>>> to have the compatible string as "simple-vga-dac".
> >>>>>
> >>>>> I just wished this bikeshedding had taken place publicly and be
> >>>>> actually part of that discussion, but yeah, ok.
> >>>>
> >>>> Sorry about that. I'd pinged him for an Ack, the discussion went
> >>>> more than that :)
> >>>>
> >>>>>> Some of the reasons behind having this:
> >>>>>>
> >>>>>> - We don't need to specify "rgb" in the compatible string since most
> >>>>>> simple VGA DACs can only work with an RGB input.
> >>>>>
> >>>>> Ok.
> >>>>>
> >>>>>> - Also, with "dac" specified in the string, we don't need to
> >>>>>> specifically mention "bridge" in the string. Also, bridge is a drm
> >>>>>> specific term.
> >>>>>>
> >>>>>> - "simple" is considered because it's an unconfigurable bridge, and
> >>>>>> it might be misleading for other VGA DACs to not use "vga-dac".
> >>>>>
> >>>>> All those "simple" bindings are just the biggest lie we ever
> >>>>> told. It's simple when you introduce it, and then grows into something
> >>>>> much more complicated than a non-simple implementation.
> >>>>
> >>>> "simple" here is supposed to mean that it's an unconfigurable RGB to
> >>>> VGA DAC. This isn't supposed to follow the simple-panel model, where
> >>>> you add the "simple-panel" string in the compatible node, along with
> >>>> you chip specific compatible string.
> >>>
> >>> I agree with Maxime, I don't like the word "simple". My preference would
> >>> be "vga-dac" for a lack of a better qualifier than "simple" to describe
> >>> the fact that the device requires no configuration. My only concern with
> >>> "vga-dac" is that we would restrict usage of that compatible string for
> >>> a subset of VGA DACs, with more complex devices not being compatible
> >>> with "vga-dac" even though they are VGA DACs. That's a problem I can
> >>> live with though.
> >>
> >> While we're bikeshedding (feel free to ignore my input on this), I
> >> think Maxime's initial "dumb" qualifier was better than "simple".
> >
> > I think I agree.
> >
> >> I think "passive" also gets the point across better than "simple", which
> >> we've already established as something else in drm.
> >
> > To my electrical engineer's ear, passive refers to a component or
> > combination of components that is not capable of power gain. The
> > resistors ladder VGA DAC that Maxime is trying to support is a passive
> > system, but the ADV7123 VGA DAC that equally requires no configuration is
> > an active component.
>
> If no one has any more objections within the next day, I'll pull in
> Maxime's v5 RGB to VGA bridge driver,
I'm testing the patch with rcar-du-drm and will provide results today.
> and change the compatible to "dumb-vga-dac".
Feel free to ignore the bikeshedding, but "transparent" could be a candidate
to replace "dumb" (either as "vga-dac-transparent" or "transparent-vga-dac").
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v5 2/5] drm/bridge: Add RGB to VGA bridge support
From: Maxime Ripard @ 2016-10-07 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f39e907c-424f-7572-f88e-5dd0b6009631@codeaurora.org>
On Fri, Oct 07, 2016 at 10:27:31AM +0530, Archit Taneja wrote:
>
>
> On 10/07/2016 02:34 AM, Laurent Pinchart wrote:
> >Hi Sean,
> >
> >On Thursday 06 Oct 2016 15:53:28 Sean Paul wrote:
> >>On Thu, Oct 6, 2016 at 1:27 PM, Laurent Pinchart wrote:
> >>>On Thursday 06 Oct 2016 17:09:57 Archit Taneja wrote:
> >>>>On 10/06/2016 12:51 PM, Maxime Ripard wrote:
> >>>>>On Mon, Oct 03, 2016 at 04:40:57PM +0530, Archit Taneja wrote:
> >>>>>>On 09/30/2016 08:07 PM, Maxime Ripard wrote:
> >>>>>>>Some boards have an entirely passive RGB to VGA bridge, based on
> >>>>>>>either DACs or resistor ladders.
> >>>>>>>
> >>>>>>>Those might or might not have an i2c bus routed to the VGA connector
> >>>>>>>in order to access the screen EDIDs.
> >>>>>>>
> >>>>>>>Add a bridge that doesn't do anything but expose the modes available
> >>>>>>>on the screen, either based on the EDIDs if available, or based on
> >>>>>>>the XGA standards.
> >>>>>>>
> >>>>>>>Acked-by: Rob Herring <robh@kernel.org>
> >>>>>>>Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >>>>>>>---
> >>>>>>>.../bindings/display/bridge/rgb-to-vga-bridge.txt | 48 +++++
> >>>>>>>drivers/gpu/drm/bridge/Kconfig | 7 +
> >>>>>>>drivers/gpu/drm/bridge/Makefile | 1 +
> >>>>>>>drivers/gpu/drm/bridge/rgb-to-vga.c | 229 +++++++++++++
> >>>>>>>4 files changed, 285 insertions(+)
> >>>>>>>create mode 100644
> >>>>>>>Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.tx
> >>>>>>>t
> >>>>>>>create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c
> >>>>>>>
> >>>>>>>diff --git
> >>>>>>>a/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.
> >>>>>>>txt
> >>>>>>>b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.
> >>>>>>>txt
> >>>>>>>new file mode 100644
> >>>>>>>index 000000000000..a8375bc1f9cb
> >>>>>>>--- /dev/null
> >>>>>>>+++
> >>>>>>>b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.
> >>>>>>>tx
> >>>>>>>t @@ -0,0 +1,48 @@
> >>>>>>>+Dumb RGB to VGA bridge
> >>>>>>>+----------------------
> >>>>>>>+
> >>>>>>>+This binding is aimed for dumb RGB to VGA bridges that do not
> >>>>>>>require
> >>>>>>>+any configuration.
> >>>>>>>+
> >>>>>>>+Required properties:
> >>>>>>>+
> >>>>>>>+- compatible: Must be "rgb-to-vga-bridge"
> >>>>>>
> >>>>>>I'd talked to Laurent on IRC if he's okay with this. And I guess you
> >>>>>>to had discussed it during XDC too. He's suggested that it'd be better
> >>>>>>to have the compatible string as "simple-vga-dac".
> >>>>>
> >>>>>I just wished this bikeshedding had taken place publicly and be
> >>>>>actually part of that discussion, but yeah, ok.
> >>>>
> >>>>Sorry about that. I'd pinged him for an Ack, the discussion went
> >>>>more than that :)
> >>>>
> >>>>>>Some of the reasons behind having this:
> >>>>>>
> >>>>>>- We don't need to specify "rgb" in the compatible string since most
> >>>>>>simple VGA DACs can only work with an RGB input.
> >>>>>
> >>>>>Ok.
> >>>>>
> >>>>>>- Also, with "dac" specified in the string, we don't need to
> >>>>>>specifically mention "bridge" in the string. Also, bridge is a drm
> >>>>>>specific term.
> >>>>>>
> >>>>>>- "simple" is considered because it's an unconfigurable bridge, and it
> >>>>>>might be misleading for other VGA DACs to not use "vga-dac".
> >>>>>
> >>>>>All those "simple" bindings are just the biggest lie we ever
> >>>>>told. It's simple when you introduce it, and then grows into something
> >>>>>much more complicated than a non-simple implementation.
> >>>>
> >>>>"simple" here is supposed to mean that it's an unconfigurable RGB to
> >>>>VGA DAC. This isn't supposed to follow the simple-panel model, where
> >>>>you add the "simple-panel" string in the compatible node, along with
> >>>>you chip specific compatible string.
> >>>
> >>>I agree with Maxime, I don't like the word "simple". My preference would
> >>>be "vga-dac" for a lack of a better qualifier than "simple" to describe
> >>>the fact that the device requires no configuration. My only concern with
> >>>"vga-dac" is that we would restrict usage of that compatible string for a
> >>>subset of VGA DACs, with more complex devices not being compatible with
> >>>"vga-dac" even though they are VGA DACs. That's a problem I can live with
> >>>though.
> >>
> >>While we're bikeshedding (feel free to ignore my input on this), I
> >>think Maxime's initial "dumb" qualifier was better than "simple".
> >
> >I think I agree.
> >
> >>I think "passive" also gets the point across better than "simple", which
> >>we've already established as something else in drm.
> >
> >To my electrical engineer's ear, passive refers to a component or combination
> >of components that is not capable of power gain. The resistors ladder VGA DAC
> >that Maxime is trying to support is a passive system, but the ADV7123 VGA DAC
> >that equally requires no configuration is an active component.
>
> If no one has any more objections within the next day, I'll pull in
> Maxime's v5 RGB to VGA bridge driver, and change the compatible to
> "dumb-vga-dac".
That works for me. You'll probably want to update the Kconfig and file
name to match though.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161007/cac9efa7/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 0/5] Add runtime PM support for clocks (on Exynos SoC example)
From: Marek Szyprowski @ 2016-10-07 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57F6926F.1070707@math.uni-bielefeld.de>
Hi Tobias,
On 2016-10-06 20:05, Tobias Jakobi wrote:
> Hello Marek,
>
> I'm using the patches from the v4.8-clocks-pm-v2 branch plus the ones
> from the v4.8-clocks-pm-v2 branch on top of 4.8.0.
>
> I see some warnings on boot coming from driver core. It appears that the
> warnings are actually meaningful, since IOMMUs stop working completly.
> E.g. if I modprobe s5p-mfc later, firmware loading fails because
> apparantly the IOMMU domain isn't online.
>
>> WARNING: CPU: 0 PID: 1 at drivers/base/core.c:356 device_links_driver_bound+0x124/0x12c
> I added some debug printk() to device_links_driver_bound(), to show the
> link status. Apparantly it is always DEVICE_LINK_AVAILABLE.
Please note that some additional patches are needed to get IOMMU working
properly with both runtime-pm patches and deferred probe, which feature
in turn is needed to get it working after adding clocks-pm changes. I
will send such patch soon (as a new version of IOMMU deferred probe
support patches were posted a few days ago).
> (...)
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH 7/9] ARM: sunxi: Remove useless allwinner,drive property
From: Maxime Ripard @ 2016-10-07 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65SmZqR-MJgNxa0RGUYyWgeLHQcQfa0b8U0XiEtp+RfBg@mail.gmail.com>
On Tue, Oct 04, 2016 at 10:34:39AM +0800, Chen-Yu Tsai wrote:
> On Mon, Oct 3, 2016 at 6:21 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > The allwinner,drive property set to 10mA was really considered as our
> > default. Remove all those properties entirely to make that obvious.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> Did you use sed or some other scripting tool to do this patch?
> Including the command should make it easier to verify the result,
> instead of having to go through the 93 files here.
Yeah, I used some dumb sed commands.
Unfortunately, it disappeared from my history, but given my sed-fu, it
was pretty trivial, just a succession of
sed -i 'd/SUN4I_PINCTRL_10_MA' *.dtsi
Something along those lines, and pretty much the same thing for the
next patches.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161007/4122b19e/attachment-0001.sig>
^ permalink raw reply
* [PATCH 6/9] dt-bindings: pinctrl: Deprecate sunxi pinctrl bindings
From: Maxime Ripard @ 2016-10-07 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67wk_DANTyzaxTM6Stgh-u2kZXn_kjb0vbWDYUd-DUxGA@mail.gmail.com>
On Tue, Oct 04, 2016 at 10:32:12AM +0800, Chen-Yu Tsai wrote:
> On Mon, Oct 3, 2016 at 6:21 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > The generic pin configuration and multiplexing should be preferred now,
> > even though we still support the old one.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 5 +++++
> > 1 file changed, 5 insertions(+), 0 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> > index 69617220c5d6..e8b7cf64fdf1 100644
> > --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> > +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> > @@ -36,6 +36,11 @@ pins it needs, and how they should be configured, with regard to muxer
> > configuration, drive strength and pullups. If one of these options is
> > not set, its actual value will be unspecified.
> >
> > +This driver supports the generic pin multiplexing and configuration
> > +bindings.
>
> Should we list which options are supported? We don't support them all.
Yep, I'll add that.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161007/f1ab6c83/attachment.sig>
^ permalink raw reply
* [PATCH 4/9] pinctrl: sunxi: Deal with configless pins
From: Maxime Ripard @ 2016-10-07 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v654vv3B-OhHPgdLjsEOf0zPP=Ky1_+o=8mf9dZHMFjR-w@mail.gmail.com>
Hi,
On Tue, Oct 04, 2016 at 10:28:18AM +0800, Chen-Yu Tsai wrote:
> > if (sunxi_pctrl_has_drive_prop(node)) {
> > int drive = sunxi_pctrl_parse_drive_prop(node);
> > - if (drive < 0)
> > + if (drive < 0) {
> > + ret = -EINVAL;
>
> Why not just pass the error code returned from the parse function?
Yep, I'll change that.
> > - (*map)[i].type = PIN_MAP_TYPE_CONFIGS_GROUP;
> > - (*map)[i].data.configs.group_or_pin = group;
> > - (*map)[i].data.configs.configs = pinconfig;
> > - (*map)[i].data.configs.num_configs = configlen;
> > -
> > - i++;
> > + if (pinconfig) {
> > + (*map)[i].type = PIN_MAP_TYPE_CONFIGS_GROUP;
> > + (*map)[i].data.configs.group_or_pin = group;
> > + (*map)[i].data.configs.configs = pinconfig;
> > + (*map)[i].data.configs.num_configs = configlen;
> > + i++;
> > + }
> > }
> >
> > - *num_maps = nmaps;
> > + *num_maps = i;
>
> Thought: should we do a krealloc to shrink the array?
Yep, I'll make an additional patch to fix that.
>
> >
> > return 0;
> >
> > @@ -342,8 +357,13 @@ static void sunxi_pctrl_dt_free_map(struct pinctrl_dev *pctldev,
> > struct pinctrl_map *map,
> > unsigned num_maps)
> > {
> > + unsigned long *pinconfig;
> > +
> > /* All the maps have the same pin config, free only the first one */
> > - kfree(map[0].data.configs.configs);
> > + pinconfig = map[0].data.configs.configs;
> > + if (pinconfig)
> > + kfree(pinconfig);
>
> Passing NULL to kfree is allowed. (It becomes a no-op.)
> So you could leave this function alone.
And I'll change that as well.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161007/081df1b2/attachment.sig>
^ permalink raw reply
* [PATCH 6/9] ARM: dts: sun6i: Sort pinmux setting nodes
From: Maxime Ripard @ 2016-10-07 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006160629.11198-7-wens@csie.org>
On Fri, Oct 07, 2016 at 12:06:26AM +0800, Chen-Yu Tsai wrote:
> The pinmux setting nodes for the A31 were added out of alphabetical
> order. Sort them.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161007/6ea12fe3/attachment.sig>
^ permalink raw reply
* [PATCH 4/9] drm/sun4i: Add compatible string for A31/A31s TCON (timing controller)
From: Maxime Ripard @ 2016-10-07 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006160629.11198-5-wens@csie.org>
Hi,
On Fri, Oct 07, 2016 at 12:06:24AM +0800, Chen-Yu Tsai wrote:
> The A31 TCON has mux controls for how TCON outputs are routed to the
> HDMI and MIPI DSI blocks.
>
> Since the A31s does not have MIPI DSI, it only has a mux for the HDMI
> controller input.
>
> This patch only adds support for the compatible strings. Actual support
> for the mux controls should be added with HDMI and MIPI DSI support.
Then let's add those fields then, having dead code and useless
variables is never a good option :)
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161007/265db26f/attachment-0001.sig>
^ permalink raw reply
* [PATCH 3/9] drm/sun4i: Put dotclock range into tcon quirks and check against them
From: Maxime Ripard @ 2016-10-07 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006160629.11198-4-wens@csie.org>
On Fri, Oct 07, 2016 at 12:06:23AM +0800, Chen-Yu Tsai wrote:
> In commit bb43d40d7c83 ("drm/sun4i: rgb: Validate the clock rate") the
> driver was rounding the requested clock rate and then checking the
> result against the original requested rate.
>
> This does not work well for a number of reasons:
>
> - The pixel clock does not have enough resolution to be able to
> provide all sub-MHz clock rates. This makes it filter out most modes
> found in simple-panel.
>
> - When first introduced, the main limiting factors were the video PLL
> clock range (27 ~ 381 MHz) and the lowest divider (6). On sun6i and
> later, the valid PLL clock range is extended to 30 ~ 600 MHz. The
> PLL's multiplier and divider can make it go much higher out of range,
> but the clock driver currently has no checks for it.
>
> Since the limits are well known, we can hard code the range into the
> tcon driver, and check against them. And we really only care about the
> upper limit, which affects the highest resolutions we can support.
We already discussed this, but this is really the wrong way to fix
that issue.
clk_round_rate already gives you the maximum clock rate that can be
handled in a generic and abstracted way, disregarding the current
state of the clock driver.
However, the issue that you're trying to solve is that panels might
have a pixel clock requirement that is not aligned on the resolution
on the pixel clock we can generate.
And this can actually happen at any rate, you could very well have a
display that requires a pixel clock of 63501kHz that you would reject,
while using the 63,5 MHz clock rate would be just fine.
On the other hand, (totally made up example) some panel that requires
a pixel clock of 43MHz, with a +- 1MHz tolerance, that we wouldn't be
able to generate since we would only generate 41 or 45 MHz.
And on yet another hand, the panel might be requesting a pixel clock
well below what we can generate, which is also something that we want
to reject.
I can see two way of fixing this so far, the second being a solution
if the first one fails:
- Look to a decent amount of panels and bridges datasheet to see
what their usual tolerance on the pixel clock rate is, then use
that to make a decision.
- If there's not really a common tolerance that we can find out,
extend the panel and bridges API to be able for the panel to
provide its tolerance on the timings, and make a function that we
can call to see if a given rate is within boundaries.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161007/a94a036f/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/2] ARM: dts: rockchip: Add rk3066 MK808 board
From: Shawn Lin @ 2016-10-07 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <18c0552c-10fa-a749-9777-9a99da9f275f@gmail.com>
? 2016/10/7 16:40, Pawe? Jarosz ??:
> Hi Shawn,
>
>
>>> +&mmc0 {
>>> + bus-width = <4>;
>>> + cap-mmc-highspeed;
>>> + cap-sd-highspeed;
>>> + mmc-pwrseq = <&mmc_pwrseq>;
>>
>> Removed this could make SD works?
>
> Yes but disabling bus-width causes sd performance decrease(defaults to
> 1?) so i'll leave this one.
I just pointed to the mmc-pwrseq, not for others properties :)
>
> Other sugestions will be included in v3.
>
> Thanks
>
> Pawe?.
>
>
>
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
--
Best Regards
Shawn Lin
^ permalink raw reply
* [PATCH] ARM: dts: fix the SD card on the Snowball
From: Linus Walleij @ 2016-10-07 8:52 UTC (permalink / raw)
To: linux-arm-kernel
This fixes a very annoying regression on the Snowball SD card
that has been around for a while. It turns out that the device
tree does not configure the direction pins properly, nor sets
up the pins for the voltage converter properly at boot. Unless
all things are correctly set up, the feedback clock will not
work, and makes the driver spew messages in the console (but
it works, very slowly):
root at Ux500:/ mount /dev/mmcblk0p2 /mnt/
[ 9.953460] mmci-pl18x 80126000.sdi0_per1: error during DMA transfer!
[ 9.960296] mmcblk0: error -110 sending status command, retrying
[ 9.966461] mmcblk0: error -110 sending status command, retrying
[ 9.972534] mmcblk0: error -110 sending status command, aborting
Fix this by rectifying the device tree to correspond to that of
the Ux500 HREF boards plus the DAT31DIR setting that is unique for
the Snowball, and things start working smoothly. Add in the SDR12
and SDR25 modes which this host can do without any problems.
I don't know if this has ever been correct, sadly. It works after
this patch.
Cc: stable at vger.kernel.org
Reported-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ARM SoC folks: please apply this directly for fixes.
---
arch/arm/boot/dts/ste-snowball.dts | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/ste-snowball.dts b/arch/arm/boot/dts/ste-snowball.dts
index b3df1c60d465..386eee6de232 100644
--- a/arch/arm/boot/dts/ste-snowball.dts
+++ b/arch/arm/boot/dts/ste-snowball.dts
@@ -239,14 +239,25 @@
arm,primecell-periphid = <0x10480180>;
max-frequency = <100000000>;
bus-width = <4>;
+ cap-sd-highspeed;
cap-mmc-highspeed;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ /* All direction control is used */
+ st,sig-dir-cmd;
+ st,sig-dir-dat0;
+ st,sig-dir-dat2;
+ st,sig-dir-dat31;
+ st,sig-pin-fbclk;
+ full-pwr-cycle;
vmmc-supply = <&ab8500_ldo_aux3_reg>;
vqmmc-supply = <&vmmci>;
pinctrl-names = "default", "sleep";
pinctrl-0 = <&sdi0_default_mode>;
pinctrl-1 = <&sdi0_sleep_mode>;
- cd-gpios = <&gpio6 26 GPIO_ACTIVE_LOW>; // 218
+ /* GPIO218 MMC_CD */
+ cd-gpios = <&gpio6 26 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -549,7 +560,7 @@
/* VMMCI level-shifter enable */
snowball_cfg3 {
pins = "GPIO217_AH12";
- ste,config = <&gpio_out_lo>;
+ ste,config = <&gpio_out_hi>;
};
/* VMMCI level-shifter voltage select */
snowball_cfg4 {
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/2] ARM: dts: rockchip: Add rk3066 MK808 board
From: Paweł Jarosz @ 2016-10-07 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a166a444-8819-ffe7-8ee1-1f632f6a66ab@rock-chips.com>
Hi Shawn,
>> +&mmc0 {
>> + bus-width = <4>;
>> + cap-mmc-highspeed;
>> + cap-sd-highspeed;
>> + mmc-pwrseq = <&mmc_pwrseq>;
>
> Removed this could make SD works?
Yes but disabling bus-width causes sd performance decrease(defaults to
1?) so i'll leave this one.
Other sugestions will be included in v3.
Thanks
Pawe?.
^ permalink raw reply
* [PATCH 1/8] PM / Domains: Make genpd state allocation dynamic
From: Ulf Hansson @ 2016-10-07 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006205724.GA41480@linaro.org>
On 6 October 2016 at 22:57, Lina Iyer <lina.iyer@linaro.org> wrote:
> On Thu, Oct 06 2016 at 13:45 -0600, Ulf Hansson wrote:
>>
>> On 6 October 2016 at 17:40, Lina Iyer <lina.iyer@linaro.org> wrote:
>>>
>>> On Thu, Oct 06 2016 at 02:37 -0600, Ulf Hansson wrote:
>>>>
>>>>
>>>> On 5 October 2016 at 22:31, Lina Iyer <lina.iyer@linaro.org> wrote:
>>>>>
>>>>>
>>>>> Allow PM Domain states to be defined dynamically by the drivers. This
>>>>> removes the limitation on the maximum number of states possible for a
>>>>> domain.
>>>>>
>>>>> Cc: Axel Haslam <ahaslam+renesas@baylibre.com>
>>>>> Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
>>>>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>>>
>>>
>>> <...>
>>>>>
>>>>>
>>>>> -#define GENPD_MAX_NUM_STATES 8 /* Number of possible low power
>>>>> states
>>>>> */
>>>>> -
>>>>> enum gpd_status {
>>>>> GPD_STATE_ACTIVE = 0, /* PM domain is active */
>>>>> GPD_STATE_POWER_OFF, /* PM domain is off */
>>>>> @@ -70,7 +68,7 @@ struct generic_pm_domain {
>>>>> void (*detach_dev)(struct generic_pm_domain *domain,
>>>>> struct device *dev);
>>>>> unsigned int flags; /* Bit field of configs for
>>>>> genpd
>>>>> */
>>>>> - struct genpd_power_state states[GENPD_MAX_NUM_STATES];
>>>>> + struct genpd_power_state *states;
>>>>> unsigned int state_count; /* number of states */
>>>>> unsigned int state_idx; /* state that genpd will go to when off
>>>>> */
>>>>>
>>>>> --
>>>>> 2.7.4
>>>>>
>>>>
>>>> In general I like the improvement, but..
>>>>
>>>> This change implies that ->states may very well be NULL. This isn't
>>>> validated by genpd's internal logic when power off/on the domain
>>>> (genpd_power_on|off(), __default_power_down_ok()). You need to fix
>>>> this, somehow.
>>>>
>>> Good point.
>>>
>>>> Perhaps the easiest solutions is, when pm_genpd_init() finds that
>>>> ->state is NULL, that we allocate a struct genpd_power_state with
>>>> array size of 1 and assign it to ->states. Although, doing this also
>>>> means you need to track that genpd was responsible for the the
>>>> allocation, so it must also free the data from within genpd_remove().
>>>>
>>>> Unless you have other ideas!?
>>>>
>>> I can think of some hacks, but they are uglier than the problem we are
>>> trying to solve. We could drop this patch. Real world situations would
>>> not have more than 8 states and if there is one, we can think about it
>>> then.
>>
>>
>> The problem with the current approach is that we waste some memory as
>> we always have an array of 8 states per genpd. In the worst case,
>> which currently is the most common case, only 1 out of 8 states is
>> being used.
>>
>> So, let's not be lazy here and instead take the opportunity to fix
>> this, and especially I think this makes sense, before we go on and add
>> the DT parsing of the domain-idle-states.
>>
> Hmm.. We are not wasting much memory in comparison, but if you insist,
> sure.
>
>> The more sophisticated method would probably be to use kobject/kref,
>> but let's not go there for now. Instead let's try an easy method of
>> just tracking whether the allocations had been made internally by
>> genpd, via adding a "bool state_allocated to the struct
>> generic_pm_domain. Would that work?
>>
> It would work.
>
> i.
> How about an additional static state by default in the domain structure,
> if the platform does not provide a state then the default structure is
> used. That way we dont have to track it. But it does waste memory
> eqivalent to a state, when there are states provided by the platform.
I thought about this, but I think it could be a bit messy as well.
Better to do an allocation when needed.
>
> ii.
> I could add a void *free to the domain structure and save the memory
> allocated by default in the *free. At domain remove, we just do a kfree
> on free.
>
> iii.
> Use a boolean flag.
Both ii) and iii) works for me!
Kind regards
Uffe
>
> Thanks,
> Lina
>
^ permalink raw reply
* [PATCH 2/9] drm/sun4i: tcon: Move SoC specific quirks to a DT matched data structure
From: Maxime Ripard @ 2016-10-07 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006160629.11198-3-wens@csie.org>
Hi,
On Fri, Oct 07, 2016 at 12:06:22AM +0800, Chen-Yu Tsai wrote:
> +struct sun4i_tcon_quirks {
> + bool is_sun5i; /* sun5i has undocumented mux */
> + bool has_channel_1; /* a33 does not have channel 1 */
> + bool has_bypass_src; /* has separate input bypassing CEU */
> + bool has_dma_src; /* has DMA input */
> +};
> +
I'd really prefer to keep the has_mux quirk name. is_sun5i doesn't
really relate to what we're doing there, is redundant with the
compatible, and render the other quirks name useless, since we could
just have is_sun.i quirks and deal with that (which is essentially
what we were doing before).
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161007/ea01852f/attachment.sig>
^ permalink raw reply
* [PATCH 00/14] ASoc: sunxi: Add Allwinner A33 codec driver
From: Icenowy Zheng @ 2016-10-07 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1475569400.git.mylene.josserand@free-electrons.com>
On Tue, 4 Oct 2016 11:46:13 +0200
Myl?ne Josserand <mylene.josserand@free-electrons.com> wrote:
> Hi everyone,
>
>
> This patchset add the audio codec for Allwinner A33 (sun8i) SoC.
>
> It adds different drivers:
> - sun8i-codec-analog (patch 4): This driver implements the analog
> part of the audio codec. The analog part is handled in PRCM registers
> so this driver must be added as prcm's subnode (patch 5).
> - sun8i-codec (patch 6): This driver implements the digital part
> of the A33 codec.
> - sun8i (patch 7): This driver implements a sound card for A33.
> It links the DAI and the audio codec. The analog codec driver is
> handled as an "aux_device".
>
> The DAI for this codec is the same than for A20: "sun4i-i2s".
> The digital codec code is coming from Allwinner's BSP (after some
> cleanup and DAPM conversion) [1]
> The analog codec driver is coming from Chen-Yu Tsai's driver [2]
> with some modifications (such as read/write regmap functions).
>
> Currently, all the drivers handle only the playback feature.
> The other ones (such as capture) and all other interfaces except
> headphone are not supported.
>
> These drivers are functional except for one issue. When playing a
> sound for the first time, a short delay can be noticed. On a second
> play (right after), the sound is played correctly. If we wait a short
> time (~5 sec), the delay is back.
> There is the same behavior for left/right channel. On the first
> time, a left sound is played on the left channel but in the second
> time, the sound will be played on wrong channel.
>
> These issues will be fixed in a second time. Is someone have
> suggestions about it?
>
> Examples of amixer commands:
> amixer set 'Headphone' 75%
> amixer set 'Headphone' on
> amixer set 'DAC' on
> amixer set 'Right DAC Mixer RSlot 0' on
> amixer set 'Left DAC Mixer LSlot 0' on
> amixer set 'DAC Reversed Right' on
> amixer set 'DAC Reversed Left' on
>
> It was tested on Parrot and Sinlinx board where device tree's
> modifications are added (patch 11 to 14).
I tested it on my iNet D978 Rev2 board (dts available in linux-next now)
Directly output audio from mpg123 to the audio codec failed, with
noises appear in the earphone. (And the mpg123 process terminated very
fast, seems that the bitrate become wrong)
However, paplay works well with the decoded wav file, and ```mpg123 -o
pulse``` works properly.
>
> Thank you in advance,
> Best regards,
>
> [1]:
> https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/sound/soc/sunxi/audiocodec/sun8iw5_sndcodec.c
> [2]: https://github.com/wens/linux/tree/a31-audio
>
> Myl?ne Josserand (14):
> dma: sun6i-dma: Add burst case of 4
> clk: ccu-sun8i-a33: Add CLK_SET_RATE_PARENT to ac-dig
> ASoC: sun4i-i2s: Add apb reset
> ASoC: Add sun8i analog codec driver
> mfd: sun6i-prcm: Add sun8i analog codec as subnode
> ASoC: Add sun8i digital audio codec
> ASoC: Add sun8i audio card
> dt-bindings: sound: Add sun8i analog codec documentation
> dt-bindings: sound: Add sun8i codec documentation
> dt-bindings: sound: Add sun8i audio card documentation
> ARM: dts: sun8i: Add analog codec on prcm node
> ARM: dts: sun8i: Add audio codec, dai and card for A33
> ARM: dts: sun8i: parrot: Enable audio nodes
> ARM: dts: sun8i: sinlinx: Enable audio nodes
>
> .../devicetree/bindings/sound/sun8i-audio.txt | 17 +
> .../bindings/sound/sun8i-codec-analog.txt | 20 +
> .../devicetree/bindings/sound/sun8i-codec.txt | 24 +
> arch/arm/boot/dts/sun8i-a23-a33.dtsi | 7 +
> arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 8 +
> arch/arm/boot/dts/sun8i-a33.dtsi | 33 ++
> arch/arm/boot/dts/sun8i-r16-parrot.dts | 8 +
> drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 2 +-
> drivers/dma/sun6i-dma.c | 2 +
> drivers/mfd/sun6i-prcm.c | 16 +
> sound/soc/sunxi/Kconfig | 30 ++
> sound/soc/sunxi/Makefile | 3 +
> sound/soc/sunxi/sun4i-i2s.c | 16 +-
> sound/soc/sunxi/sun8i-codec-analog.c | 305
> +++++++++++++ sound/soc/sunxi/sun8i-codec.c |
> 492 +++++++++++++++++++++
> sound/soc/sunxi/sun8i.c | 101 +++++ 16
> files changed, 1082 insertions(+), 2 deletions(-) create mode 100644
> Documentation/devicetree/bindings/sound/sun8i-audio.txt create mode
> 100644 Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
> create mode 100644
> Documentation/devicetree/bindings/sound/sun8i-codec.txt create mode
> 100644 sound/soc/sunxi/sun8i-codec-analog.c create mode 100644
> sound/soc/sunxi/sun8i-codec.c create mode 100644
> sound/soc/sunxi/sun8i.c
>
^ permalink raw reply
* [PATCH v3 03/11] ARM: shmobile: r8a7743: basic SoC support
From: Laurent Pinchart @ 2016-10-07 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161007031537.GK13721@verge.net.au>
Hi Simon,
On Friday 07 Oct 2016 12:15:37 Simon Horman wrote:
> On Thu, Oct 06, 2016 at 12:37:08AM +0300, Sergei Shtylyov wrote:
> > Add minimal support for the RZ/G1M (R8A7743) SoC.
> >
> > Based on the original (and large) patch by Dmitry Shifrin
> > <dmitry.shifrin@cogentembedded.com>.
> >
> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Thanks, I have queued this up.
I'd like to see this patch rebased on top of "[PATCH] ARM: shmobile:
Consolidate R8A779[234] machine definitions".
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] ARM: shmobile: Consolidate R8A779[234] machine definitions
From: Laurent Pinchart @ 2016-10-07 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVVE2N20zmCddy6Y2mMBf4zk0u=WfQ3Sa1e_ASOf5zO_Q@mail.gmail.com>
Hi Geert,
On Friday 07 Oct 2016 09:43:53 Geert Uytterhoeven wrote:
> On Wed, Oct 5, 2016 at 12:31 PM, Laurent Pinchart wrote:
> > The three SoCs use the exact same machine definition, consolidate them
> > into a single one.
>
> Thanks for your patch!
>
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks.
> I'm wondering if we can improve upon...
I think we can. Your points below are valid, patches are welcome ;-)
> > --- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
> > +++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
> > @@ -203,3 +204,22 @@ void __init rcar_gen2_reserve(void)
> > }
> > #endif
> > }
> > +
> > +static const char * const rcar_gen2_boards_compat_dt[] __initconst = {
> > + /*
> > + * R8A7790 and R8A7791 can't be handled here as long as they need
> > SMP
> > + * initialization fallback.
> > + */
> > + "renesas,r8a7792",
> > + "renesas,r8a7793",
> > + "renesas,r8a7794",
> > + NULL,
> > +};
> > +
> > +DT_MACHINE_START(RCAR_GEN2_DT, "Generic Gen2 (Flattened Device Tree)")
> > + .init_early = shmobile_init_delay,
>
> shmobile_init_delay() is not really Renesas-specific, but ARM-specific.
> This is just to avoid calibrating the delay loop?
>
> > + .init_late = shmobile_init_late,
>
> This calls only into shmobile_suspend_init(), which is also not
> Renesas-specific.
>
> > + .init_time = rcar_gen2_timer_init,
>
> This is about fixing up the ARM Arch timer, and initializing clocks as we
> need to pass the mode pin state (ugh, will hopefully go away soon).
>
> > + .reserve = rcar_gen2_reserve,
>
> Reserving a block for CMA DMA is also not really Renesas-specific.
>
> > + .dt_compat = rcar_gen2_boards_compat_dt,
> > +MACHINE_END
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v4 10/10] ARM: sunxi: Enable sun8i-emac driver on multi_v7_defconfig
From: Corentin Labbe @ 2016-10-07 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475828757-926-1-git-send-email-clabbe.montjoie@gmail.com>
Enable the sun8i-emac driver in the multi_v7 default configuration
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 5845910..f44d633 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -229,6 +229,7 @@ CONFIG_NETDEVICES=y
CONFIG_VIRTIO_NET=y
CONFIG_HIX5HD2_GMAC=y
CONFIG_SUN4I_EMAC=y
+CONFIG_SUN8I_EMAC=y
CONFIG_MACB=y
CONFIG_BCMGENET=m
CONFIG_SYSTEMPORT=m
--
2.7.3
^ permalink raw reply related
* [PATCH v4 09/10] ARM: sunxi: Enable sun8i-emac driver on sunxi_defconfig
From: Corentin Labbe @ 2016-10-07 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475828757-926-1-git-send-email-clabbe.montjoie@gmail.com>
Enable the sun8i-emac driver in the sunxi default configuration
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/configs/sunxi_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 714da33..153707a 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -40,6 +40,7 @@ CONFIG_ATA=y
CONFIG_AHCI_SUNXI=y
CONFIG_NETDEVICES=y
CONFIG_SUN4I_EMAC=y
+CONFIG_SUN8I_EMAC=y
# CONFIG_NET_VENDOR_ARC is not set
# CONFIG_NET_CADENCE is not set
# CONFIG_NET_VENDOR_BROADCOM is not set
--
2.7.3
^ permalink raw reply related
* [PATCH v4 08/10] ARM: dts: sun8i: Enable sun8i-emac on the Orange Pi 2
From: Corentin Labbe @ 2016-10-07 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475828757-926-1-git-send-email-clabbe.montjoie@gmail.com>
The sun8i-emac hardware is present on the Orange PI 2.
It uses the internal PHY.
This patch create the needed emac node.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
index f93f5d1..5608eb4 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
@@ -54,6 +54,7 @@
aliases {
serial0 = &uart0;
+ ethernet0 = &emac;
};
chosen {
@@ -184,3 +185,10 @@
usb1_vbus-supply = <®_usb1_vbus>;
status = "okay";
};
+
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
--
2.7.3
^ permalink raw reply related
* [PATCH v4 07/10] ARM: dts: sun8i: Enable sun8i-emac on the Orange PI One
From: Corentin Labbe @ 2016-10-07 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475828757-926-1-git-send-email-clabbe.montjoie@gmail.com>
From: Hans de Goede <hdegoede@redhat.com>
The sun8i-emac hardware is present on the Orange PI One.
It uses the internal PHY.
This patch create the needed emac node.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
index 0adf932..25f2455 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
@@ -54,6 +54,7 @@
aliases {
serial0 = &uart0;
+ ethernet0 = &emac;
};
chosen {
@@ -94,6 +95,13 @@
status = "okay";
};
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
--
2.7.3
^ permalink raw reply related
* [PATCH v4 06/10] ARM: dts: sun8i: Enable sun8i-emac on the Orange PI PC
From: Corentin Labbe @ 2016-10-07 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475828757-926-1-git-send-email-clabbe.montjoie@gmail.com>
The sun8i-emac hardware is present on the Orange PI PC.
It uses the internal PHY.
This patch create the needed emac node.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
index daf50b9a6..71717cc 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
@@ -54,6 +54,7 @@
aliases {
serial0 = &uart0;
+ ethernet0 = &emac;
};
chosen {
@@ -165,3 +166,10 @@
/* USB VBUS is always on */
status = "okay";
};
+
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ status = "okay";
+};
--
2.7.3
^ permalink raw reply related
* [PATCH v4 05/10] ARM: dts: sun8i-h3: add sun8i-emac ethernet driver
From: Corentin Labbe @ 2016-10-07 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475828757-926-1-git-send-email-clabbe.montjoie@gmail.com>
The sun8i-emac is an ethernet MAC hardware that support 10/100/1000
speed.
This patch enable the sun8i-emac on the Allwinner H3 SoC Device-tree.
The SoC H3 have an internal PHY, so optionals syscon and ephy are set.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sun8i-h3.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 1101d2f..d218154 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -446,6 +446,30 @@
status = "disabled";
};
+ emac: ethernet at 1c30000 {
+ compatible = "allwinner,sun8i-h3-emac";
+ syscon = <&syscon>;
+ reg = <0x01c30000 0x104>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "ahb";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "ahb";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ int_mii_phy: ethernet-phy at 1 {
+ reg = <1>;
+ clocks = <&ccu CLK_BUS_EPHY>;
+ resets = <&ccu RST_BUS_EPHY>;
+ };
+ };
+ };
+
gic: interrupt-controller at 01c81000 {
compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
reg = <0x01c81000 0x1000>,
--
2.7.3
^ permalink raw reply related
* [PATCH v4 04/10] ARM: dts: sun8i-h3: Add dt node for the syscon control module
From: Corentin Labbe @ 2016-10-07 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475828757-926-1-git-send-email-clabbe.montjoie@gmail.com>
This patch add the dt node for the syscon register present on the
Allwinner H3.
Only two register are present in this syscon and the only one useful is
the one dedicated to EMAC clock.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
arch/arm/boot/dts/sun8i-h3.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 8a95e36..1101d2f 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -140,6 +140,11 @@
#size-cells = <1>;
ranges;
+ syscon: syscon at 01c00000 {
+ compatible = "syscon";
+ reg = <0x01c00000 0x1000>;
+ };
+
dma: dma-controller at 01c02000 {
compatible = "allwinner,sun8i-h3-dma";
reg = <0x01c02000 0x1000>;
--
2.7.3
^ permalink raw reply related
* [PATCH v4 03/10] ARM: sun8i: dt: Add DT bindings documentation for Allwinner sun8i-emac
From: Corentin Labbe @ 2016-10-07 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475828757-926-1-git-send-email-clabbe.montjoie@gmail.com>
This patch adds documentation for Device-Tree bindings for the
Allwinner sun8i-emac driver.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
.../bindings/net/allwinner,sun8i-emac.txt | 70 ++++++++++++++++++++++
1 file changed, 70 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/allwinner,sun8i-emac.txt
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-emac.txt b/Documentation/devicetree/bindings/net/allwinner,sun8i-emac.txt
new file mode 100644
index 0000000..92e4ef3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-emac.txt
@@ -0,0 +1,70 @@
+* Allwinner sun8i EMAC ethernet controller
+
+Required properties:
+- compatible: should be one of the following string:
+ "allwinner,sun8i-a83t-emac"
+ "allwinner,sun8i-h3-emac"
+ "allwinner,sun50i-a64-emac"
+- reg: address and length of the register for the device.
+- syscon: A phandle to the syscon of the SoC
+- interrupts: interrupt for the device
+- clocks: A phandle to the reference clock for this device
+- clock-names: should be "ahb"
+- resets: A phandle to the reset control for this device
+- reset-names: should be "ahb"
+- phy-mode: See ethernet.txt
+- phy-handle: See ethernet.txt
+- #address-cells: shall be 1
+- #size-cells: shall be 0
+
+Optional properties:
+- allwinner,tx-delay: TX clock delay chain value. Range value is 0-0x07. Default is 0)
+- allwinner,rx-delay: RX clock delay chain value. Range value is 0-0x1F. Default is 0)
+Both delay properties does not have units, there are arbitrary value.
+The TX/RX clock delay chain settings are board specific and could be found
+in vendor FEX files.
+
+Optional properties for "allwinner,sun8i-h3-emac":
+- allwinner,leds-active-low: EPHY LEDs are active low
+
+Required child node of emac:
+- mdio bus node: should be named mdio
+
+Required properties of the mdio node:
+- #address-cells: shall be 1
+- #size-cells: shall be 0
+
+The device node referenced by "phy" or "phy-handle" should be a child node
+of the mdio node. See phy.txt for the generic PHY bindings.
+
+Required properties of the phy node with "allwinner,sun8i-h3-emac":
+- clocks: an extra phandle to the reference clock for the EPHY
+- resets: an extra phandle to the reset control for the EPHY
+
+Example:
+
+emac: ethernet at 01c0b000 {
+ compatible = "allwinner,sun8i-h3-emac";
+ syscon = <&syscon>;
+ reg = <0x01c0b000 0x104>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "ahb";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "ahb";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy = <&int_mii_phy>;
+ phy-mode = "mii";
+ allwinner,leds-active-low;
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ int_mii_phy: ethernet-phy at 1 {
+ reg = <1>;
+ clocks = <&ccu CLK_BUS_EPHY>;
+ resets = <&ccu RST_BUS_EPHY>;
+ };
+ };
+};
--
2.7.3
^ 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