Re: [linux-sunxi] [PATCH 01/13] dt-bindings: update the binding for Allwinner H3 DE2 support
Hi, Dne četrtek, 10. avgust 2017 ob 02:21:21 CEST je Rob Herring napisal(a): > On Wed, Aug 02, 2017 at 09:06:26PM +0200, Jernej Škrabec wrote: > > Hi, > > > > Dne sreda, 02. avgust 2017 ob 07:02:39 CEST je icen...@aosc.io napisal(a): > > > 在 2017-08-02 12:53，Jernej Škrabec 写道： > > > > > > > Hi Icenowy, > > > > > > > > Dne torek, 01. avgust 2017 ob 15:12:52 CEST je Icenowy Zheng > > > > > > > > napisal(a): > > > >> Allwinner H3 features a "Display Engine 2.0". > > > >> > > > >> Add device tree bindings for the following parts: > > > >> - H3 TCONs > > > >> - H3 Mixers > > > >> - H3 Display engine > > > >> > > > >> Signed-off-by: Icenowy Zheng > > > >> --- > > > >> > > > >> .../bindings/display/sunxi/sun4i-drm.txt | 25 > > > >> > > > >> ++ 1 file changed, 21 insertions(+), 4 > > > >> deletions(-) > > > >> > > > >> diff --git > > > >> a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > > >> b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index > > > >> 2ee6ff0ef98e..92512953943e 100644 > > > >> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > > >> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > > >> > > > >> @@ -87,18 +87,17 @@ Required properties: > > > >> * allwinner,sun6i-a31-tcon > > > >> * allwinner,sun6i-a31s-tcon > > > >> * allwinner,sun8i-a33-tcon > > > >> > > > >> + * allwinner,sun8i-h3-tcon > > > >> > > > >> * allwinner,sun8i-v3s-tcon > > > >> > > > >> - reg: base address and size of memory-mapped region > > > >> - interrupts: interrupt associated to this IP > > > >> > > > >> - clocks: phandles to the clocks feeding the TCON. Three are needed: > > > >> - 'ahb': the interface clocks > > > >> > > > >> - - 'tcon-ch0': The clock driving the TCON channel 0 > > > >> > > > >> - resets: phandles to the reset controllers driving the encoder > > > >> > > > >> - "lcd": the reset line for the TCON channel 0 > > > >> > > > >> - clock-names: the clock names mentioned above > > > >> - reset-names: the reset names mentioned above > > > >> > > > >> - - clock-output-names: Name of the pixel clock created > > > >> > > > >> - ports: A ports node with endpoint definitions as defined in > > > >> > > > >>Documentation/devicetree/bindings/media/video-interfaces.txt. The > > > >> > > > >> @@ -112,7 +111,23 @@ Required properties: > > > >>channel the endpoint is associated to. If that property is not > > > >>present, the endpoint number will be used as the channel number. > > > >> > > > >> -On SoCs other than the A33 and V3s, there is one more clock > > > >> required: > > > >> +For the following compatibles: > > > >> + * allwinner,sun5i-a13-tcon > > > >> + * allwinner,sun6i-a31-tcon > > > >> + * allwinner,sun6i-a31s-tcon > > > >> + * allwinner,sun8i-a33-tcon > > > >> + * allwinner,sun8i-v3s-tcon > > > >> +there is one more clock and one more property required: > > > >> + - clocks: > > > >> + - 'tcon-ch0': The clock driving the TCON channel 0 > > > >> + - clock-output-names: Name of the pixel clock created > > > >> + > > > >> +For the following compatibles: > > > >> + * allwinner,sun5i-a13-tcon > > > >> + * allwinner,sun6i-a31-tcon > > > >> + * allwinner,sun6i-a31s-tcon > > > >> + * allwinner,sun8i-h3-tcon > > > >> > > > >> +there is one more clock required: > > > >> - 'tcon-ch1': The clock driving the TCON channel 1 > > > >> > > > >> DRC > > > >> > > > >> @@ -207,6 +222,8 @@ supported. > > > >> > > > >> Required properties: > > > >>- compatible: value must be one of: > > > >> * allwinner,sun8i-v3s-de2-mixer > > > >> > > > >> +* allwinner,sun8i-h3-de2-mixer0 > > > >> +* allwinner,sun8i-h3-de2-mixer1 > > > > > > > > About that, I concur with Maxime here, plane number properties would > > > > be > > > > better. If we don't do this now, we will never have it. > > > > > > But I still prefer different compatibles, as the capabilities are > > > already > > > proven to be different between mixer0 and mixer1, and furtherly we > > > cannot > > > promise Allwinner won't add more functions only available at mixer0. > > > > > > Then we will be trapped into a situation that we describe more and more > > > functions via properties, but they should be encoded into the > > > compatible. > > > > It is either multiple compatibles or multiple properties. I prefer the > > later, but it is up to maintainers to decide. > > It's not the same. A compatible can imply an infinite number of > properties. I'm fine with properties too, but with only 2 instances I > don't think it makes much sense. Actually, there are more combinations since different SoCs have also different capabilities regarding mixer0 or mixer1. For example, mixer0 on H3 has different capabilities than mixer0 on A83T (max. plane size and number and type of planes, etc.). Best regards, Jernej
Re: [linux-sunxi] [PATCH v3.1 01/10] clk: sunxi-ng: a64: Add minimal rate for video PLLs
Dne četrtek, 26. julij 2018 ob 19:12:48 CEST je Icenowy Zheng napisal(a): > From: Jagan Teki > > According to documentation and experience with other similar SoCs, video > PLLs don't work stable if their output frequency is set below 192 MHz. > > Because of that, set minimal rate to both A64 video PLLs to 192 MHz. > > Signed-off-by: Jagan Teki > Signed-off-by: Icenowy Zheng Reviewed-by: Jernej Skrabec
Re: [PATCH v2 04/12] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions
Hi all,
Dne sreda, 10. januar 2018 ob 20:25:04 CET je Jernej Skrabec napisal(a):
> Parts of PHY code could be useful also for custom PHYs. For example,
> Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
> with few additional memory mapped registers, so most of the Synopsys PHY
> related code could be reused.
>
> Functions exported here are actually not specific to Synopsys PHYs but
> to DWC HDMI controller PHY interface. This means that even if the PHY is
> completely custom, i.e. not designed by Synopsys, exported functions can
> be useful.
>
> Signed-off-by: Jernej Skrabec
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 44
> +-- include/drm/bridge/dw_hdmi.h |
> 11
> 2 files changed, 41 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> 7ca14d7325b5..7d80f4b56683 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct dw_hdmi
> *hdmi, u8 enable) HDMI_PHY_CONF0_SVSRET_MASK);
> }
>
> -static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> +void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> {
> hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
>HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
>HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
> }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
>
> -static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
> +void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
> {
> hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
>HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
>HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
> }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
>
> static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)
> {
> @@ -1065,6 +1067,22 @@ static void dw_hdmi_phy_sel_interface_control(struct
> dw_hdmi *hdmi, u8 enable) HDMI_PHY_CONF0_SELDIPIF_MASK);
> }
>
> +void dw_hdmi_phy_reset(struct dw_hdmi *hdmi)
> +{
> + /* PHY reset. The reset signal is active high on Gen2 PHYs. */
> + hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
> + hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
> +}
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_reset);
I just noticed that meson dw hdmi driver uses function with the same name,
which break compilation. Is it ok if I rename meson specific reset to
meson_dw_hdmi_phy_reset()?
Best regards,
Jernej
> +
> +void dw_hdmi_phy_i2c_set_addr(struct dw_hdmi *hdmi, u8 address)
> +{
> + hdmi_phy_test_clear(hdmi, 1);
> + hdmi_writeb(hdmi, address, HDMI_PHY_I2CM_SLAVE_ADDR);
> + hdmi_phy_test_clear(hdmi, 0);
> +}
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_set_addr);
> +
> static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> {
> const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
> @@ -1203,16 +1221,11 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
> if (phy->has_svsret)
> dw_hdmi_phy_enable_svsret(hdmi, 1);
>
> - /* PHY reset. The reset signal is active high on Gen2 PHYs. */
> - hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
> - hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
> + dw_hdmi_phy_reset(hdmi);
>
> hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
>
> - hdmi_phy_test_clear(hdmi, 1);
> - hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> - HDMI_PHY_I2CM_SLAVE_ADDR);
> - hdmi_phy_test_clear(hdmi, 0);
> + dw_hdmi_phy_i2c_set_addr(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2);
>
> /* Write to the PHY as configured by the platform */
> if (pdata->configure_phy)
> @@ -1251,15 +1264,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> *hdmi, void *data) dw_hdmi_phy_power_off(hdmi);
> }
>
> -static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> - void *data)
> +enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> +void *data)
> {
> return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
> connector_status_connected : connector_status_disconnected;
> }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
>
> -static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> -bool force, bool disabled, bool rxsense)
> +void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> + bool force, bool disabled, bool rxsense)
> {
> u8 old_mask = hdmi->phy_mask;
>
> @@ -1271,8 +1285,9 @@ static void dw_hdmi_phy_update_hpd(struct dw_hdmi
> *hdmi, void *data, if (old_mask != hdmi->phy_mask)
> hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
> }
> +EXPORT_SYMB
Re: [PATCH v3 02/12] clk: sunxi-ng: Change formula for NKMP PLLs
Hi, Dne četrtek, 18. januar 2018 ob 11:58:41 CET je Maxime Ripard napisal(a): > Hi, > > On Wed, Jan 17, 2018 at 09:14:11PM +0100, Jernej Skrabec wrote: > > This commit changes formula from this: > > > > Freq = (parent_freq * N * K) / (M * P) > > > > to this: > > > > Freq = (parent_freq / M) * N * K / P > > > > This improves situation when N is in the range 1-255. PLL parent clock > > is almost always 24 MHz, which means that for N >= 180 original formula > > overflows and result becomes useless. Situation can be improved if M is > > used as predivider as it can be seen in the second formula. That way at > > least M > 1 is considered, but it still leaves small gap for wrong result > > when M = 1 and N >= 180. > > > > Using M as predivider shouldn't cause any issue, because it is in range > > 1-4 at most, so there is no or only minimal rounding error. > > > > Signed-off-by: Jernej Skrabec > > I'd really prefer to stick to the formula documented and that we've > used so far. NKMP clocks are most notably used for the CPU PLLs and > I've debugged way too many cpufreq bugs already :) > > What about using long long types for the parent * n * k result? Yes, using long long is the best possible solution and covers all cases whereas this patch does not. I thought that do_div() would cause a lot of overhead, but I noticed that it's not big if both numbers fit in 32 bit, which in our case is true most of the time. I will make a helper function for calculating rate, since using long long needs more than one line of code. Best regards, Jernej
Re: [PATCH 01/11] clk: sunxi-ng: Don't set k if width is 0 for nkmp plls
Hi,
Dne četrtek, 04. januar 2018 ob 15:45:18 CET je Chen-Yu Tsai napisal(a):
> On Sun, Dec 31, 2017 at 5:01 AM, Jernej Skrabec
wrote:
> > For example, A83T have nmp plls which are modelled as nkmp plls. Since k
> > is not specified, it has offset 0, shift 0 and lowest value 1. This
> > means that LSB bit is always set to 1, which may change clock rate.
> >
> > Fix that by applying k factor only if k width is greater than 0.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/clk/sunxi-ng/ccu_nkmp.c | 21 +
> > 1 file changed, 13 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c
> > b/drivers/clk/sunxi-ng/ccu_nkmp.c index e58c95787f94..709f528af2b3 100644
> > --- a/drivers/clk/sunxi-ng/ccu_nkmp.c
> > +++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
> > @@ -81,7 +81,7 @@ static unsigned long ccu_nkmp_recalc_rate(struct clk_hw
> > *hw,>
> > unsigned long parent_rate)
> >
> > {
> >
> > struct ccu_nkmp *nkmp = hw_to_ccu_nkmp(hw);
> >
> > - unsigned long n, m, k, p;
> > + unsigned long n, m, k = 1, p;
> >
> > u32 reg;
> >
> > reg = readl(nkmp->common.base + nkmp->common.reg);
> >
> > @@ -92,11 +92,13 @@ static unsigned long ccu_nkmp_recalc_rate(struct
> > clk_hw *hw,>
> > if (!n)
> >
> > n++;
> >
> > - k = reg >> nkmp->k.shift;
> > - k &= (1 << nkmp->k.width) - 1;
> > - k += nkmp->k.offset;
> > - if (!k)
> > - k++;
> > + if (nkmp->k.width) {
> > + k = reg >> nkmp->k.shift;
> > + k &= (1 << nkmp->k.width) - 1;
> > + k += nkmp->k.offset;
> > + if (!k)
> > + k++;
> > + }
>
> The conditional shouldn't be necessary. With nkmp->k.width = 0,
> you'd simply get k & 0, which is 0, which then gets bumped up to 1,
> unless k.offset > 1, which would be a bug.
>
> > m = reg >> nkmp->m.shift;
> > m &= (1 << nkmp->m.width) - 1;
> >
> > @@ -153,12 +155,15 @@ static int ccu_nkmp_set_rate(struct clk_hw *hw,
> > unsigned long rate,>
> > reg = readl(nkmp->common.base + nkmp->common.reg);
> > reg &= ~GENMASK(nkmp->n.width + nkmp->n.shift - 1, nkmp->n.shift);
> >
> > - reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift);
> > + if (nkmp->k.width)
> > + reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1,
> > + nkmp->k.shift);
> >
> > reg &= ~GENMASK(nkmp->m.width + nkmp->m.shift - 1, nkmp->m.shift);
> > reg &= ~GENMASK(nkmp->p.width + nkmp->p.shift - 1, nkmp->p.shift);
> >
> > reg |= (_nkmp.n - nkmp->n.offset) << nkmp->n.shift;
> >
> > - reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
> > + if (nkmp->k.width)
> > + reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
>
> I think a better way would be
>
> reg |= ((_nkmp.k - nkmp->k.offset) << nkmp->k.shift) &
>GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift);
>
> And do this for all the factors, not just k. This pattern is what
> regmap_update_bits does, which seems much safer. I wonder what
> GENMASK() with a negative value would do though...
You're right, GENMASK(-1, 0) equals 0 (calculated by hand, not tested). This
seems much more elegant solution.
Semi-related question: All nmp PLLs have much wider N range than real nkmp
PLLs. This causes integer overflow when using nkmp formula from datasheet.
Usually, N is 1-256 for nmp PLLs, which means that for very high N factors, it
overflows. This also causes issue that M factor is never higher than 1.
I was wondering, if patch would be acceptable which would change this formula:
RATE = (24MHz * N * K) / (M * P)
to this:
RATE ((24MHz / M) * N * K) / P
I checked all M factors and are all in 1-4 or 1-2 range, which means it
wouldn't have any impact for real nkmp PLLs when parent is 24 MHz clock which
is probably always.
What do you think?
I discovered that when I tried to set A83T PLL_VIDEO to 346.5 MHz which is
possible only when above formula is changed.
Best regards,
Jernej
>
> ChenYu
>
> > reg |= (_nkmp.m - nkmp->m.offset) << nkmp->m.shift;
> > reg |= ilog2(_nkmp.p) << nkmp->p.shift;
> >
> > --
> > 2.15.1
Re: [linux-sunxi] Re: [PATCH 06/11] dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline
Hi, Dne petek, 05. januar 2018 ob 03:49:09 CET je Icenowy Zheng napisal(a): > 于 2018年1月5日 GMT+08:00 上午2:52:10, Maxime Ripard 写到: > >On Wed, Jan 03, 2018 at 10:32:26PM +0100, Jernej Škrabec wrote: > >> Hi Rob, > >> > >> Dne sreda, 03. januar 2018 ob 21:21:54 CET je Rob Herring napisal(a): > >> > On Sat, Dec 30, 2017 at 10:01:58PM +0100, Jernej Skrabec wrote: > >> > > This commit adds all necessary compatibles and descriptions > > > >needed to > > > >> > > implement A83T HDMI pipeline. > >> > > > >> > > Mixer is already properly described, so only compatible is added. > >> > > > >> > > However, A83T TCON1, which is connected to HDMI, doesn't have > > > >channel 0, > > > >> > > contrary to all TCONs currently described. Because of that, TCON > >> > > documentation is extended. > >> > > > >> > > A83T features Synopsys DW HDMI controller with a custom PHY which > > > >looks > > > >> > > like Synopsys Gen2 PHY with few additions. Since there is no > >> > > documentation, needed properties were found out through > > > >experimentation > > > >> > > and reading BSP code. > >> > > > >> > > At the end, example is added for newer SoCs, which features DE2 > > > >and DW > > > >> > > HDMI. > >> > > > >> > > Signed-off-by: Jernej Skrabec > >> > > --- > >> > > > >> > > .../bindings/display/sunxi/sun4i-drm.txt | 188 > >> > > - 1 file changed, 181 insertions(+), 7 > > > >deletions(-) > > > >> > > diff --git > > > >a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > > >> > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > > >index > > > >> > > 9f073af4c711..3eca258096a5 100644 > >> > > --- > > > >a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > > >> > > +++ > > > >b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > > >> > > @@ -64,6 +64,40 @@ Required properties: > >> > > first port should be the input endpoint. The second should > > > >be the > > > >> > > output, usually to an HDMI connector. > >> > > > >> > > +DWC HDMI TX Encoder > >> > > +- > >> > > + > >> > > +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX > > > >controller IP > > > >> > > +with Allwinner's own PHY IP. It supports audio and video outputs > > > >and CEC. > > > >> > > + > >> > > +These DT bindings follow the Synopsys DWC HDMI TX bindings > > > >defined in > > > >> > > +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt > > > >with the > > > >> > > +following device-specific properties. > >> > > + > >> > > +Required properties: > >> > > + > >> > > + - compatible: value must be one of: > >> > > +* "allwinner,sun8i-a83t-dw-hdmi" > >> > > + - reg: two pairs of base address and size of memory-mapped > > > >region, > > > >> > > first > >> > > +for controller and second for PHY > >> > > +registers. > >> > > >> > Seems like the phy should be a separate node and use the phy > > > >binding. > > > >> > You can use the phy binding even if you don't use the kernel phy > >> > framework... > >> > >> Unfortunately, it's not so straighforward. Phy is actually accessed > > > >through > > > >> I2C implemented in HDMI controller. Second memory region in this case > > > >has > > > >> small influence on phy. However, it has big influence on controller. > > > >For > > > >> example, magic number has to be written in one register in second > > > >memory > > > >> region in order to unlock read access to any register from first > > > >memory region > > > >> (controller). However, they shouldn't be merged to one region, > > > >because first > > > >> memory region
Re: [PATCH v3 06/12] dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline
Hi, Dne ponedeljek, 29. januar 2018 ob 19:05:26 CET je Rob Herring napisal(a): > On Wed, Jan 17, 2018 at 09:14:15PM +0100, Jernej Skrabec wrote: > > This commit adds all necessary compatibles and descriptions needed to > > implement A83T HDMI pipeline. > > > > Mixer is already properly described, so only compatible is added. > > > > However, A83T TV TCON, which is connected to HDMI, doesn't have channel 0, > > contrary to all TCONs currently described. Because of that, TCON > > documentation is extended. > > > > A83T features Synopsys DW HDMI controller with a custom PHY which looks > > like Synopsys Gen2 PHY with few additions. Since there is no > > documentation, needed properties were found out through experimentation > > and reading BSP code. > > > > At the end, example is added for newer SoCs, which feature DE2 and DW > > HDMI. > > > > Signed-off-by: Jernej Skrabec > > --- > > > > .../bindings/display/sunxi/sun4i-drm.txt | 197 > > - 1 file changed, 190 insertions(+), 7 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index > > cd626ee1147a..4fb380f3e53d 100644 > > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > > > @@ -64,6 +64,52 @@ Required properties: > > first port should be the input endpoint. The second should be the > > output, usually to an HDMI connector. > > > > +DWC HDMI TX Encoder > > +--- > > + > > +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP > > +with Allwinner's own PHY IP. It supports audio and video outputs and CEC. > > + > > +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in > > +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the > > +following device-specific properties. > > + > > +Required properties: > > + > > + - compatible: value must be one of: > > +* "allwinner,sun8i-a83t-dw-hdmi" > > + - reg: base address and size of memory-mapped region > > + - reg-io-width: See dw_hdmi.txt. Shall be 1. > > + - interrupts: HDMI interrupt number > > + - clocks: phandles to the clocks feeding the HDMI encoder > > +* iahb: the HDMI bus clock > > +* isfr: the HDMI register clock > > + - clock-names: the clock names mentioned above > > + - resets: phandle to the reset controller > > + - reset-names: must be "ctrl" > > + - phys: phandle to the DWC HDMI PHY > > + - phy-names: must be "phy" > > + > > + - ports: A ports node with endpoint definitions as defined in > > +Documentation/devicetree/bindings/media/video-interfaces.txt. The > > +first port should be the input endpoint. The second should be the > > +output, usually to an HDMI connector. > > + > > +DWC HDMI PHY > > + > > + > > +Required properties: > > + - compatible: value must be one of: > > +* allwinner,sun8i-a83t-hdmi-phy > > + - reg: base address and size of memory-mapped region > > + - clocks: phandles to the clocks feeding the HDMI PHY > > +* bus: the HDMI PHY interface clock > > +* mod: the HDMI PHY module clock > > +* tmds: TMDS clock > > + - clock-names: the clock names mentioned above > > + - resets: phandle to the reset controller driving the PHY > > + - reset-names: must be "phy" > > + > > > > TV Encoder > > -- > > > > @@ -94,24 +140,23 @@ Required properties: > > * allwinner,sun7i-a20-tcon > > * allwinner,sun8i-a33-tcon > > * allwinner,sun8i-a83t-tcon-lcd > > > > + * allwinner,sun8i-a83t-tcon-tv > > > > * allwinner,sun8i-v3s-tcon > > > > - reg: base address and size of memory-mapped region > > - interrupts: interrupt associated to this IP > > > > - - clocks: phandles to the clocks feeding the TCON. Three are needed: > > > > + - clocks: phandles to the clocks feeding the TCON. One is needed: > > - 'ahb': the interface clocks > > > > - - 'tcon-ch0': The clock driving the TCON channel 0 > > Well, it didn't look right before saying 3 are needed, but listing 2. > However, you can't just change this as it affects all the other SoCs. > This should probably be a separate patch. I had a feeling that all items which are not common to all compatibles should be listed below and explained when they are needed. At least currently it's done this way. > > > - resets: phandles to the reset controllers driving the encoder > > > > - "lcd": the reset line for the TCON channel 0 > > > > - clock-names: the clock names mentioned above > > - reset-names: the reset names mentioned above > > > > - - clock-output-names: Name of the pixel clock created > > Why is this removed? > > > - ports: A ports node with endpoint definitions as defined in > > > >Documentation/devicetree/bindings/media/video-interfaces.txt. The > >first port should be the input endpoint, the sec
Re: [linux-sunxi] Re: [PATCH 01/11] clk: sunxi-ng: Don't set k if width is 0 for nkmp plls
Hi Chen-Yu,
Dne ponedeljek, 08. januar 2018 ob 10:19:47 CET je Chen-Yu Tsai napisal(a):
> On Fri, Jan 5, 2018 at 3:28 AM, Jernej Škrabec
wrote:
> > Hi,
> >
> > Dne četrtek, 04. januar 2018 ob 15:45:18 CET je Chen-Yu Tsai napisal(a):
> >> On Sun, Dec 31, 2017 at 5:01 AM, Jernej Skrabec
> >
> > wrote:
> >> > For example, A83T have nmp plls which are modelled as nkmp plls. Since
> >> > k
> >> > is not specified, it has offset 0, shift 0 and lowest value 1. This
> >> > means that LSB bit is always set to 1, which may change clock rate.
> >> >
> >> > Fix that by applying k factor only if k width is greater than 0.
> >> >
> >> > Signed-off-by: Jernej Skrabec
> >> > ---
> >> >
> >> > drivers/clk/sunxi-ng/ccu_nkmp.c | 21 +
> >> > 1 file changed, 13 insertions(+), 8 deletions(-)
> >> >
> >> > diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c
> >> > b/drivers/clk/sunxi-ng/ccu_nkmp.c index e58c95787f94..709f528af2b3
> >> > 100644
> >> > --- a/drivers/clk/sunxi-ng/ccu_nkmp.c
> >> > +++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
> >> > @@ -81,7 +81,7 @@ static unsigned long ccu_nkmp_recalc_rate(struct
> >> > clk_hw
> >> > *hw,>
> >> >
> >> > unsigned long parent_rate)
> >> >
> >> > {
> >> >
> >> > struct ccu_nkmp *nkmp = hw_to_ccu_nkmp(hw);
> >> >
> >> > - unsigned long n, m, k, p;
> >> > + unsigned long n, m, k = 1, p;
> >> >
> >> > u32 reg;
> >> >
> >> > reg = readl(nkmp->common.base + nkmp->common.reg);
> >> >
> >> > @@ -92,11 +92,13 @@ static unsigned long ccu_nkmp_recalc_rate(struct
> >> > clk_hw *hw,>
> >> >
> >> > if (!n)
> >> >
> >> > n++;
> >> >
> >> > - k = reg >> nkmp->k.shift;
> >> > - k &= (1 << nkmp->k.width) - 1;
> >> > - k += nkmp->k.offset;
> >> > - if (!k)
> >> > - k++;
> >> > + if (nkmp->k.width) {
> >> > + k = reg >> nkmp->k.shift;
> >> > + k &= (1 << nkmp->k.width) - 1;
> >> > + k += nkmp->k.offset;
> >> > + if (!k)
> >> > + k++;
> >> > + }
> >>
> >> The conditional shouldn't be necessary. With nkmp->k.width = 0,
> >> you'd simply get k & 0, which is 0, which then gets bumped up to 1,
> >> unless k.offset > 1, which would be a bug.
> >>
> >> > m = reg >> nkmp->m.shift;
> >> > m &= (1 << nkmp->m.width) - 1;
> >> >
> >> > @@ -153,12 +155,15 @@ static int ccu_nkmp_set_rate(struct clk_hw *hw,
> >> > unsigned long rate,>
> >> >
> >> > reg = readl(nkmp->common.base + nkmp->common.reg);
> >> > reg &= ~GENMASK(nkmp->n.width + nkmp->n.shift - 1,
> >> > nkmp->n.shift);
> >> >
> >> > - reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1,
> >> > nkmp->k.shift);
> >> > + if (nkmp->k.width)
> >> > + reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1,
> >> > + nkmp->k.shift);
> >> >
> >> > reg &= ~GENMASK(nkmp->m.width + nkmp->m.shift - 1,
> >> > nkmp->m.shift);
> >> > reg &= ~GENMASK(nkmp->p.width + nkmp->p.shift - 1,
> >> > nkmp->p.shift);
> >> >
> >> > reg |= (_nkmp.n - nkmp->n.offset) << nkmp->n.shift;
> >> >
> >> > - reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
> >> > + if (nkmp->k.width)
> >> > + reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
> >>
> >> I think a better way would be
> >>
> >> reg |= ((_nkmp.k - nkmp->k.offset) << nkmp->k.shift) &
> >>
> >>GENMASK(nkmp->k.width + nkmp->k.shift
Re: [PATCH 04/11] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions
Hi Archit,
Dne torek, 09. januar 2018 ob 11:43:08 CET je Archit Taneja napisal(a):
> On 12/31/2017 02:31 AM, Jernej Skrabec wrote:
> > Parts of PHY code could be useful also for custom PHYs. For example,
> > Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
> > with few additional memory mapped registers, so most of the Synopsys PHY
> > related code could be reused.
> >
> > It turns out that even completely custom HDMI PHYs, such as the one
> > found in Allwinner H3, can reuse some of those functions. This would
> > suggest that (some?) functions exported in this commit are actually part
> > of generic PHY interface and not really specific to Synopsys PHYs.
> >
> > Export useful PHY functions.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45
> > ++-
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 2 ++
> > include/drm/bridge/dw_hdmi.h | 10 +++
> > 3 files changed, 44 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > 7ca14d7325b5..67467d0b683a 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct
> > dw_hdmi *hdmi, u8 enable)>
> > HDMI_PHY_CONF0_SVSRET_MASK);
> >
> > }
> >
> > -static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> > +void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> >
> > {
> >
> > hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
> >
> > HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
> > HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
> >
> > -static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
> > +void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
> >
> > {
> >
> > hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
> >
> > HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
> > HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
> >
> > static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)
> > {
> >
> > @@ -1065,6 +1067,23 @@ static void
> > dw_hdmi_phy_sel_interface_control(struct dw_hdmi *hdmi, u8 enable)>
> > HDMI_PHY_CONF0_SELDIPIF_MASK);
> >
> > }
> >
> > +void dw_hdmi_phy_gen2_reset(struct dw_hdmi *hdmi, u8 enable)
> > +{
> > + hdmi_mask_writeb(hdmi, enable, HDMI_MC_PHYRSTZ,
> > +HDMI_MC_PHYRSTZ_PHYRSTZ_OFFSET,
> > +HDMI_MC_PHYRSTZ_PHYRSTZ_MASK);
> > +}
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_reset);
> > +
> > +void dw_hdmi_phy_set_slave_addr(struct dw_hdmi *hdmi)
> > +{
> > + hdmi_phy_test_clear(hdmi, 1);
> > + hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> > + HDMI_PHY_I2CM_SLAVE_ADDR);
> > + hdmi_phy_test_clear(hdmi, 0);
> > +}
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_set_slave_addr);
>
> Should this be called dw_hdmi_phy_gen2_set_slave_addr?
Probably. I will rename it in v2 to be consistent with other phy functions.
Best regards,
Jernej
>
> Looks good otherwise. Same for patches 3 and 4 in this series.
>
> Thanks,
> Archit
>
> > +
> >
> > static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> > {
> >
> > const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
> >
> > @@ -1204,15 +1223,12 @@ static int hdmi_phy_configure(struct dw_hdmi
> > *hdmi)
> >
> > dw_hdmi_phy_enable_svsret(hdmi, 1);
> >
> > /* PHY reset. The reset signal is active high on Gen2 PHYs. */
> >
> > - hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
> > - hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
> > + dw_hdmi_phy_gen2_reset(hdmi, 1);
> > + dw_hdmi_phy_gen2_reset(hdmi, 0);
> >
> > hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
> >
> > - hdmi_phy_test_clear(hdmi, 1);
> > - hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> > - HDMI_PHY_I2CM_SLAVE_ADDR);
> > - hdmi_phy_test_clear(hdmi, 0);
> > + dw_hdmi_phy_set_slave_addr(hdmi);
> >
> > /* Write to the PHY as configured by the platform */
> > if (pdata->configure_phy)
> >
> > @@ -1251,15 +1267,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> > *hdmi, void *data)>
> > dw_hdmi_phy_power_off(hdmi);
> >
> > }
> >
> > -static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi
> > *hdmi, - void *data)
> > +enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> > + void *data)
> >
> > {
> >
> > return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
> >
> > c
Re: [PATCH 04/11] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions
Hi Laurent,
Dne torek, 09. januar 2018 ob 14:30:22 CET je Laurent Pinchart napisal(a):
> Hi Jernej,
>
> Thank you for the patch.
>
> On Saturday, 30 December 2017 23:01:56 EET Jernej Skrabec wrote:
> > Parts of PHY code could be useful also for custom PHYs. For example,
> > Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
> > with few additional memory mapped registers, so most of the Synopsys PHY
> > related code could be reused.
> >
> > It turns out that even completely custom HDMI PHYs, such as the one
> > found in Allwinner H3, can reuse some of those functions. This would
> > suggest that (some?) functions exported in this commit are actually part
> > of generic PHY interface and not really specific to Synopsys PHYs.
>
> That's correct, those functions control the interface between the HDMI
> controller and the PHY. They're not specific to Synopsys PHYs, but they're
> specific to the PHY interface as designed by Synopsys.
Ok, I'll update commit message.
>
> > Export useful PHY functions.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45
> > ---
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 2 ++
> > include/drm/bridge/dw_hdmi.h | 10 +++
> > 3 files changed, 44 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > 7ca14d7325b5..67467d0b683a 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct
> > dw_hdmi *hdmi, u8 enable) HDMI_PHY_CONF0_SVSRET_MASK);
> >
> > }
> >
> > -static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> > +void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> >
> > {
> >
> > hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
> >
> > HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
> > HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
> >
> > -static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
> > +void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
> >
> > {
> >
> > hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
> >
> > HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
> > HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
> >
> > }
> >
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
> >
> > static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)
> > {
> >
> > @@ -1065,6 +1067,23 @@ static void
> > dw_hdmi_phy_sel_interface_control(struct
> > dw_hdmi *hdmi, u8 enable) HDMI_PHY_CONF0_SELDIPIF_MASK);
> >
> > }
> >
> > +void dw_hdmi_phy_gen2_reset(struct dw_hdmi *hdmi, u8 enable)
> > +{
> > + hdmi_mask_writeb(hdmi, enable, HDMI_MC_PHYRSTZ,
> > +HDMI_MC_PHYRSTZ_PHYRSTZ_OFFSET,
> > +HDMI_MC_PHYRSTZ_PHYRSTZ_MASK);
> > +}
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_reset);
> > +
> > +void dw_hdmi_phy_set_slave_addr(struct dw_hdmi *hdmi)
> > +{
> > + hdmi_phy_test_clear(hdmi, 1);
> > + hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> > + HDMI_PHY_I2CM_SLAVE_ADDR);
> > + hdmi_phy_test_clear(hdmi, 0);
> > +}
> > +EXPORT_SYMBOL_GPL(dw_hdmi_phy_set_slave_addr);
>
> Should the I2C address be passed as an argument ?
Yes, I already planned to do that for v2.
Best regards,
Jernej
>
> > static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> > {
> >
> > const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
> >
> > @@ -1204,15 +1223,12 @@ static int hdmi_phy_configure(struct dw_hdmi
> > *hdmi)
> >
> > dw_hdmi_phy_enable_svsret(hdmi, 1);
> >
> > /* PHY reset. The reset signal is active high on Gen2 PHYs. */
> >
> > - hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
> > - hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
> > + dw_hdmi_phy_gen2_reset(hdmi, 1);
> > + dw_hdmi_phy_gen2_reset(hdmi, 0);
> >
> > hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
> >
> > - hdmi_phy_test_clear(hdmi, 1);
> > - hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> > - HDMI_PHY_I2CM_SLAVE_ADDR);
> > - hdmi_phy_test_clear(hdmi, 0);
> > + dw_hdmi_phy_set_slave_addr(hdmi);
> >
> > /* Write to the PHY as configured by the platform */
> > if (pdata->configure_phy)
> >
> > @@ -1251,15 +1267,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> > *hdmi, void *data) dw_hdmi_phy_power_off(hdmi);
> >
> > }
> >
> > -static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi
> > *hdmi, - void *data)
> > +enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> > + void *data)
> >
> > {
> >
> > retur
Re: [PATCH 04/11] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions
Hi,
Dne torek, 09. januar 2018 ob 17:08:55 CET je Laurent Pinchart napisal(a):
> Hello,
>
> On Tuesday, 9 January 2018 17:58:46 EET Jernej Škrabec wrote:
> > Dne torek, 09. januar 2018 ob 11:43:08 CET je Archit Taneja napisal(a):
> > > On 12/31/2017 02:31 AM, Jernej Skrabec wrote:
> > >> Parts of PHY code could be useful also for custom PHYs. For example,
> > >> Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
> > >> with few additional memory mapped registers, so most of the Synopsys
> > >> PHY
> > >> related code could be reused.
> > >>
> > >> It turns out that even completely custom HDMI PHYs, such as the one
> > >> found in Allwinner H3, can reuse some of those functions. This would
> > >> suggest that (some?) functions exported in this commit are actually
> > >> part
> > >> of generic PHY interface and not really specific to Synopsys PHYs.
> > >>
> > >> Export useful PHY functions.
> > >>
> > >> Signed-off-by: Jernej Skrabec
> > >> ---
> > >>
> > >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45 +---
> > >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 2 ++
> > >> include/drm/bridge/dw_hdmi.h | 10 +++
> > >> 3 files changed, 44 insertions(+), 13 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > >> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > >> 7ca14d7325b5..67467d0b683a 100644
> > >> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>
> [snip]
>
> > >> @@ -1065,6 +1067,23 @@ static void
> > >> dw_hdmi_phy_sel_interface_control(struct dw_hdmi *hdmi, u8 enable)
> > >>
> > >> HDMI_PHY_CONF0_SELDIPIF_MASK);
> > >>
> > >> }
> > >>
> > >> +void dw_hdmi_phy_gen2_reset(struct dw_hdmi *hdmi, u8 enable)
> > >> +{
> > >> +hdmi_mask_writeb(hdmi, enable, HDMI_MC_PHYRSTZ,
> > >> + HDMI_MC_PHYRSTZ_PHYRSTZ_OFFSET,
> > >> + HDMI_MC_PHYRSTZ_PHYRSTZ_MASK);
> > >> +}
> > >> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_reset);
>
> I don't remember the details, is the reset signal Gen2-specific ?
I don't know, since there is not much documentation. Should I remove "gen2"
from the name?
>
> How about asserting and deasserting the reset signal in the same call
> instead of having to call this function twice ?
A83T BSP driver clears txpwron and sets pddq between asserting and deasserting
reset. I'll test if it works with your proposal.
>
> > >> +void dw_hdmi_phy_set_slave_addr(struct dw_hdmi *hdmi)
> > >> +{
> > >> +hdmi_phy_test_clear(hdmi, 1);
> > >> +hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> > >> +HDMI_PHY_I2CM_SLAVE_ADDR);
> > >> +hdmi_phy_test_clear(hdmi, 0);
> > >> +}
> > >> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_set_slave_addr);
> > >
> > > Should this be called dw_hdmi_phy_gen2_set_slave_addr?
> >
> > Probably. I will rename it in v2 to be consistent with other phy
> > functions.
>
> The I2C write function is called dw_hdmi_phy_i2c_write(). If we want to be
> conosistent we should either rename this one to dw_hdmi_phy_i2c_set_addr()
> or rename them both to dw_hdmi_phy_gen2_i2c_write() and
> dw_hdmi_phy_gen2_i2c_set_addr(). I think I'd prefer the former, and we could
> even drop gen2 from dw_hdmi_phy_gen2_pddq() and dw_hdmi_phy_gen2_txpwron()
> if desired.
Ok, then I'll name it dw_hdmi_phy_i2c_set_addr(). I'll leave other names as
they are.
Best regards,
Jernej
>
> > > Looks good otherwise. Same for patches 3 and 4 in this series.
> > >
> > >> +
> > >>
> > >> static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> > >> {
> > >>
> > >> const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
>
> [snip]
>
> --
> Regards,
>
> Laurent Pinchart
Re: [PATCH 04/11] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions
Hi Laurent,
Dne torek, 09. januar 2018 ob 17:08:55 CET je Laurent Pinchart napisal(a):
> Hello,
>
> On Tuesday, 9 January 2018 17:58:46 EET Jernej Škrabec wrote:
> > Dne torek, 09. januar 2018 ob 11:43:08 CET je Archit Taneja napisal(a):
> > > On 12/31/2017 02:31 AM, Jernej Skrabec wrote:
> > >> Parts of PHY code could be useful also for custom PHYs. For example,
> > >> Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
> > >> with few additional memory mapped registers, so most of the Synopsys
> > >> PHY
> > >> related code could be reused.
> > >>
> > >> It turns out that even completely custom HDMI PHYs, such as the one
> > >> found in Allwinner H3, can reuse some of those functions. This would
> > >> suggest that (some?) functions exported in this commit are actually
> > >> part
> > >> of generic PHY interface and not really specific to Synopsys PHYs.
> > >>
> > >> Export useful PHY functions.
> > >>
> > >> Signed-off-by: Jernej Skrabec
> > >> ---
> > >>
> > >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45 +---
> > >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 2 ++
> > >> include/drm/bridge/dw_hdmi.h | 10 +++
> > >> 3 files changed, 44 insertions(+), 13 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > >> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > >> 7ca14d7325b5..67467d0b683a 100644
> > >> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>
> [snip]
>
> > >> @@ -1065,6 +1067,23 @@ static void
> > >> dw_hdmi_phy_sel_interface_control(struct dw_hdmi *hdmi, u8 enable)
> > >>
> > >> HDMI_PHY_CONF0_SELDIPIF_MASK);
> > >>
> > >> }
> > >>
> > >> +void dw_hdmi_phy_gen2_reset(struct dw_hdmi *hdmi, u8 enable)
> > >> +{
> > >> +hdmi_mask_writeb(hdmi, enable, HDMI_MC_PHYRSTZ,
> > >> + HDMI_MC_PHYRSTZ_PHYRSTZ_OFFSET,
> > >> + HDMI_MC_PHYRSTZ_PHYRSTZ_MASK);
> > >> +}
> > >> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_reset);
>
> I don't remember the details, is the reset signal Gen2-specific ?
According to this comment:
/* PHY reset. The reset signal is active high on Gen2 PHYs. */
I would guess that it is not specific to Gen2, otherwise the comment wouldn't
be needed. I will remove "gen2" from the name.
>
> How about asserting and deasserting the reset signal in the same call
> instead of having to call this function twice ?
It works on A83T if reset signal is asserted and deasserted immediately. I
will change function according to your proposal.
Best regards,
Jernej
>
> > >> +void dw_hdmi_phy_set_slave_addr(struct dw_hdmi *hdmi)
> > >> +{
> > >> +hdmi_phy_test_clear(hdmi, 1);
> > >> +hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> > >> +HDMI_PHY_I2CM_SLAVE_ADDR);
> > >> +hdmi_phy_test_clear(hdmi, 0);
> > >> +}
> > >> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_set_slave_addr);
> > >
> > > Should this be called dw_hdmi_phy_gen2_set_slave_addr?
> >
> > Probably. I will rename it in v2 to be consistent with other phy
> > functions.
>
> The I2C write function is called dw_hdmi_phy_i2c_write(). If we want to be
> conosistent we should either rename this one to dw_hdmi_phy_i2c_set_addr()
> or rename them both to dw_hdmi_phy_gen2_i2c_write() and
> dw_hdmi_phy_gen2_i2c_set_addr(). I think I'd prefer the former, and we could
> even drop gen2 from dw_hdmi_phy_gen2_pddq() and dw_hdmi_phy_gen2_txpwron()
> if desired.
>
> > > Looks good otherwise. Same for patches 3 and 4 in this series.
> > >
> > >> +
> > >>
> > >> static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> > >> {
> > >>
> > >> const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
>
> [snip]
>
> --
> Regards,
>
> Laurent Pinchart
Re: [linux-sunxi] [PATCH v3 15/16] ARM: dts: sun8i: h3: Enable HDMI output on H3 boards
Hi!
Dne ponedeljek, 05. marec 2018 ob 16:27:00 CET je Joonas Kylmälä napisal(a):
> Jernej Skrabec:
> > +&hdmi_out {
> > + hdmi_out_con: endpoint {
> > + remote-endpoint = <&hdmi_con_in>;
> > + };
> > +};
>
> This node is added to all the DTS files you enabled HDMI on. Is it
> something that could be instead put to the DTSI file?
I guess that would mean also including connector node (hdmi_con_in) in DTSI,
since it is referenced inside. However, not all boards have HDMI connector, so
I didn't include it in DTSI.
Best regards,
Jernej
Re: [BUG] Kernel crash on Allwinner H3 due to sound core changes
Hi,
Dne petek, 02. marec 2018 ob 13:40:50 CET je Mark Brown napisal(a):
> On Thu, Mar 01, 2018 at 11:23:57PM +0100, Jernej Škrabec wrote:
> > I removed parts of the code from the sun4i codec driver and interestingly
> > it doesn't crash if I remove following lines:
> >
> > ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL, 0);
> > if (ret) {
> >
> > dev_err(&pdev->dev, "Failed to register against DMAEngine\n");
> > goto err_assert_reset;
> >
> > }
> >
> > Is it possible that NULL pointer causes troubles somewhere down the line?
>
> Shouldn't be, that's just the configuration which is optional and not
> what we're crashing trying to register, we can mostly configure things
> by querying the capabilities of the DMA controller via the dmaengine API
> these days. You're removing all the DMA support there so cutting out a
> huge segment of the initialization of both this driver and the machine
> driver. Other sunxi devices seem to be starting happily in -next so
> there's something system dependent here...
I enabled memory debugging and it seems that there is an issue caused by
loading sun4i-codec driver and it is somehow connected to
snd_dmaengine_pcm_unregister().
Here is relevant dmesg: https://pastebin.com/raw/80K9GPnB
Does this tell anything?
Best regards,
Jernej
Re: [BUG] Kernel crash on Allwinner H3 due to sound core changes
Hi,
Dne ponedeljek, 05. marec 2018 ob 22:30:23 CET je Jernej Škrabec napisal(a):
> Hi,
>
> Dne petek, 02. marec 2018 ob 13:40:50 CET je Mark Brown napisal(a):
> > On Thu, Mar 01, 2018 at 11:23:57PM +0100, Jernej Škrabec wrote:
> > > I removed parts of the code from the sun4i codec driver and
> > > interestingly
> > > it doesn't crash if I remove following lines:
> > >
> > > ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL, 0);
> > > if (ret) {
> > >
> > > dev_err(&pdev->dev, "Failed to register against DMAEngine\n");
> > > goto err_assert_reset;
> > >
> > > }
> > >
> > > Is it possible that NULL pointer causes troubles somewhere down the
> > > line?
> >
> > Shouldn't be, that's just the configuration which is optional and not
> > what we're crashing trying to register, we can mostly configure things
> > by querying the capabilities of the DMA controller via the dmaengine API
> > these days. You're removing all the DMA support there so cutting out a
> > huge segment of the initialization of both this driver and the machine
> > driver. Other sunxi devices seem to be starting happily in -next so
> > there's something system dependent here...
>
> I enabled memory debugging and it seems that there is an issue caused by
> loading sun4i-codec driver and it is somehow connected to
> snd_dmaengine_pcm_unregister().
>
> Here is relevant dmesg: https://pastebin.com/raw/80K9GPnB
>
I found the issue. Commit be7ee5f32a9a ("ASoC: soc-generic-dmaengine-pcm:
replace platform to component") changes struct dmaengine_pcm:
struct dmaengine_pcm {
struct dma_chan *chan[SNDRV_PCM_STREAM_LAST + 1];
const struct snd_dmaengine_pcm_config *config;
- struct snd_soc_platform platform;
+ struct snd_soc_component component;
unsigned int flags;
};
In snd_dmaengine_pcm_register():
ret = snd_soc_add_component(dev, &pcm->component,
&dmaengine_pcm_component, NULL, 0);
And now, sun4i-codec first time returns -EPROBE_DEFER since driver for analog
part is not yet loaded. Because of that, all components get destroyed.
snd_dmaengine_pcm_unregister() calls snd_soc_unregister_component() and that
one calls __snd_soc_unregister_component() multiple times (until it fails).
Issue is that __snd_soc_unregister_component() uses kfree() on component
pointer and that naturally can't succed since component was never kmalloc'ed
since it is a part of a bigger structure - struct dmaengine_pcm.
What would be the best fix? Changing struct dmaengine_pcm to have pointer to a
component, so it can be freed?
Best regards,
Jernej
Re: [linux-sunxi] Re: [PATCH 2/7] dt-bindings: add binding for the Allwinner A64 DE2 bus
Hi all, Dne sreda, 21. marec 2018 ob 03:18:13 CET je Icenowy Zheng napisal(a): > 于 2018年3月21日 GMT+08:00 上午2:46:46, Maxime Ripard 写到: > >On Sat, Mar 17, 2018 at 01:53:49AM +0800, Icenowy Zheng wrote: > >> All the sub-blocks of Allwinner A64 DE2 needs the SRAM C on A64 SoC > > > >to > > > >> be claimed, otherwise the whole DE2 space is inaccessible. > >> > >> Add a device tree binding of the DE2 part as a sub-bus. > > > >Where did you get the info that it was a bus? > > There's no direct evidence, just some guess. > > The DE2 is a whole part that is just allocated a memory > space at the user manual, and the SRAM controls the > access to all modules in the DE2. > > So it might be a bus. > > Implement it as a bus is a clear representation on A64. Since there is already syscon for same mmio region, we migh as well use it when loading ccu-sun8i-de2 driver on A64. Other options, like SRAM driver or bus driver, might better represent HW, but then we would have two DT nodes covering same mmio region, which I think is not really acceptable. Any suggestions? BTW, H6 has same design in this regard. Best regards, Jernej
Re: [alsa-devel] [BUG] Kernel crash on Allwinner H3 due to sound core changes
Hi,
Thank you for looking into it so quickly.
Dne četrtek, 08. marec 2018 ob 02:21:02 CET je Kuninori Morimoto napisal(a):
> Hi Jernej
>
> Thank you for your hard work
>
> > I found the issue. Commit be7ee5f32a9a ("ASoC: soc-generic-dmaengine-pcm:
> >
> > replace platform to component") changes struct dmaengine_pcm:
> > struct dmaengine_pcm {
> >
> > struct dma_chan *chan[SNDRV_PCM_STREAM_LAST + 1];
> > const struct snd_dmaengine_pcm_config *config;
> >
> > - struct snd_soc_platform platform;
> > + struct snd_soc_component component;
> >
> > unsigned int flags;
> >
> > };
> >
> > In snd_dmaengine_pcm_register():
> > ret = snd_soc_add_component(dev, &pcm->component,
> >
> > &dmaengine_pcm_component, NULL, 0);
> >
> > And now, sun4i-codec first time returns -EPROBE_DEFER since driver for
> > analog part is not yet loaded. Because of that, all components get
> > destroyed.
> >
> > snd_dmaengine_pcm_unregister() calls snd_soc_unregister_component() and
> > that one calls __snd_soc_unregister_component() multiple times (until it
> > fails).
> >
> > Issue is that __snd_soc_unregister_component() uses kfree() on component
> > pointer and that naturally can't succed since component was never
> > kmalloc'ed since it is a part of a bigger structure - struct
> > dmaengine_pcm.
> >
> > What would be the best fix? Changing struct dmaengine_pcm to have pointer
> > to a component, so it can be freed?
>
> Ahh.. indeed. Good catch !
> How about to add such flag ?
> This is just idea. No tested, No compiled, but can help you ?
>
> One note here is that reusing "registered_as_component" flag is
> not good idea, because it will be removed
> when platform/codec were removed
>
>
> diff --git a/include/sound/soc.h b/include/sound/soc.h
> index 1a73232..b9b1b4c 100644
> --- a/include/sound/soc.h
> +++ b/include/sound/soc.h
> @@ -853,6 +853,7 @@ struct snd_soc_component {
> unsigned int ignore_pmdown_time:1; /* pmdown_time is ignored at stop */
> unsigned int registered_as_component:1;
> unsigned int suspended:1; /* is in suspend PM state */
> + unsigned int alloced_component:1;
>
> struct list_head list;
> struct list_head card_aux_list; /* for auxiliary bound components */
> diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
> index c0edac8..0e33bcf 100644
> --- a/sound/soc/soc-core.c
> +++ b/sound/soc/soc-core.c
> @@ -3492,6 +3492,7 @@ int snd_soc_register_component(struct device *dev,
> if (!component)
> return -ENOMEM;
>
> + component->alloced_component = 1;
> return snd_soc_add_component(dev, component, component_driver,
>dai_drv, num_dai);
> }
> @@ -3523,7 +3524,9 @@ static int __snd_soc_unregister_component(struct
> device *dev)
>
> if (found) {
> snd_soc_component_cleanup(component);
> - kfree(component);
> +
> + if (component->alloced_component)
> + kfree(component);
> }
>
> return found;
>
I tested this patch and there is no crash anymore. If you will send it as a
fix, you can add:
Reported-by: Jernej Skrabec
Tested-by: Jernej Skrabec
Best regards,
Jernej
Re: [linux-sunxi] [PATCH v3 06/16] drm/sun4i: Release exclusive clock lock when disabling TCON
Hi,
Dne četrtek, 08. marec 2018 ob 23:47:17 CET je Ondřej Jirman napisal(a):
> Hi,
>
> On Thu, Mar 01, 2018 at 10:34:32PM +0100, Jernej Skrabec wrote:
> > Currently exclusive TCON clock lock is never released, which, for
> > example, prevents changing resolution on HDMI.
> >
> > In order to fix that, release clock when disabling TCON. TCON is always
> > disabled first before new mode is set.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 1d714c06ec9d..7f6c4125c89f
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > @@ -102,10 +102,12 @@ static void sun4i_tcon_channel_set_status(struct
> > sun4i_tcon *tcon, int channel,>
> > return;
> >
> > }
> >
> > - if (enabled)
> > + if (enabled) {
> >
> > clk_prepare_enable(clk);
> >
> > - else
> > + } else {
> > + clk_rate_exclusive_put(clk);
> >
> > clk_disable_unprepare(clk);
> >
> > + }
> >
> > }
>
> At least in the linux-next/master I can't see clk_rate_exclusive_get call:
>
It is in drm-misc/drm-misc-fixes:
https://cgit.freedesktop.org/drm/drm-misc/commit/?h=drm-misc-fixes&id=79d103a565d16b1893d990b2ee5e0fe71767759f
My patch is also applied in same branch, so there should be no issues while
merging all those branches.
linux-next doesn't have either patches currently: https://git.kernel.org/pub/
scm/linux/kernel/git/next/linux-next.git/log/drivers/gpu/drm/sun4i
This is issue only if you manually apply one patch without the other.
Best regards,
Jernej
> $ git grep 'exclusive' linux-next/master -- drivers/gpu/drm/sun4i
>
> linux-next/master:sun4i_hdmi.h:* On sun5i the threshold is exclusive,
> i.e. does not include, linux-next/master:sun4i_tcon.c:
> clk_rate_exclusive_put(clk); linux-next/master:sun4i_tcon.c:
> clk_set_rate_exclusive(tcon->dclk, mode->crtc_clock * 1000);
> linux-next/master:sun4i_tcon.c: clk_set_rate_exclusive(tcon->sclk1,
> mode->crtc_clock * 1000);
>
> and the kernel complains too:
>
> [ 841.915161] [ cut here ]
> [ 841.915187] WARNING: CPU: 0 PID: 273 at
> /workspace/megous.com/orangepi-pc/linux-4.16/drivers/clk/clk.c:608
> clk_rate_exclusive_put+0x48/0x4c [ 841.915194] CPU: 0 PID: 273 Comm: Xorg
> Not tainted 4.16.0-rc4-00268-gbac2ecf73ed0 #13 [ 841.915196] Hardware
> name: Allwinner sun8i Family
> [ 841.915217] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14) [ 841.915228] [] (show_stack) from
> [] (dump_stack+0x88/0x9c) [ 841.915237] []
> (dump_stack) from [] (__warn+0xd4/0xf0) [ 841.915244]
> [] (__warn) from [] (warn_slowpath_null+0x40/0x48) [
> 841.915250] [] (warn_slowpath_null) from []
> (clk_rate_exclusive_put+0x48/0x4c) [ 841.915261] []
> (clk_rate_exclusive_put) from []
> (sun4i_tcon_set_status+0x178/0x2f0) [ 841.915269] []
> (sun4i_tcon_set_status) from []
> (sun4i_crtc_atomic_disable+0x7c/0xe4) [ 841.915279] []
> (sun4i_crtc_atomic_disable) from []
> (drm_atomic_helper_commit_modeset_disables+0x390/0x46c) [ 841.915288]
> [] (drm_atomic_helper_commit_modeset_disables) from []
> (drm_atomic_helper_commit_tail_rpm+0x18/0x64) [ 841.915295] []
> (drm_atomic_helper_commit_tail_rpm) from []
> (commit_tail+0x40/0x6c) [ 841.915302] [] (commit_tail) from
> [] (drm_atomic_helper_commit+0xbc/0x128) [ 841.915311]
> [] (drm_atomic_helper_commit) from []
> (restore_fbdev_mode_atomic+0x100/0x1fc) [ 841.915319] []
> (restore_fbdev_mode_atomic) from []
> (drm_fb_helper_dpms+0x50/0x130) [ 841.915328] []
> (drm_fb_helper_dpms) from [] (drm_fb_helper_blank+0x54/0x90) [
> 841.915337] [] (drm_fb_helper_blank) from []
> (fb_blank+0x54/0xa8) [ 841.915343] [] (fb_blank) from
> [] (do_fb_ioctl+0x360/0x62c) [ 841.915351] []
> (do_fb_ioctl) from [] (do_vfs_ioctl+0x9c/0x774) [ 841.915358]
> [] (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x58) [
> 841.915364] [] (SyS_ioctl) from []
> (ret_fast_syscall+0x0/0x4c) [ 841.915368] Exception stack(0xe5fc5fa8 to
> 0xe5fc5ff0)
> [ 841.915373] 5fa0: 00674f10 00675460 000b 4611
> 0001 [ 841.915379] 5fc0: 00674f10 00675460 0001 0036
> 00650474 006504a4 00675df8 [ 841.915382] 5fe0: b61a502c be8acb2c
> b6192c38 b6b152ec
> [ 841.915386] ---[ end trace fa81b956197707f8 ]---
>
> It looks like clk_rate_exclusive_put inside sun4i_tcon_channel_set_status is
> called without first calling some function that would call
> clk_set_rate_exclusive, leading to unbalanced get/put calls.
>
> regards,
> o.
>
> > static void sun4i_tcon_lvds_set_status(struct sun4i_tcon *tcon,
> >
> > --
> > 2.16.2
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "linux-sunxi" group. To unsubscribe from this group and stop receiving
> > e
Re: [linux-sunxi] [PATCH v3 06/16] drm/sun4i: Release exclusive clock lock when disabling TCON
Hi,
Dne petek, 09. marec 2018 ob 01:44:55 CET je Ondřej Jirman napisal(a):
> Hi,
>
> I've debugged this further and it seems that the code has incorrect
> assumptions. See docs for mode_set_nofb.
>
> https://elixir.bootlin.com/linux/v4.16-rc4/source/include/drm/drm_modeset_he
> lper_vtables.h#L209
>
Does this happen with https://github.com/jernejsk/linux-1/tree/h3_hdmi_v3 ?
I also tested running X, but I don't remember having the issue.
> I've added traces to a few functions that call clk_.*exclusive.*()
> functions, and I see this after a few restarts of Xorg server:
>
> [0.783842] *** sun4i_tcon1_mode_set()
> [0.783886] *** sun4i_tcon_channel_set_status(..., 1, true)
> [6.881690] *** sun4i_tcon_channel_set_status(..., 1, false)
> [6.881758] *** sun4i_tcon_channel_set_status(..., 1, true)
> [ 52.335085] *** sun4i_tcon_channel_set_status(..., 1, false)
> [ 52.335343] *** sun4i_tcon_channel_set_status(..., 1, true)
> [ 68.921079] *** sun4i_tcon_channel_set_status(..., 1, false)
> [ 68.921337] *** sun4i_tcon_channel_set_status(..., 1, true)
>
> mode_set_nofb is called just once, yet sun4i_tcon_channel_set_status(..., 1,
> false) is called multiple times, which leads to unbalanced calls to
> clk_set_rate_exclusive and clk_rate_exclusive_put.
>
> I don't know how to fix this.
Since there is no function to check if clock is protected, flag can be
introduced within TCON which is set when clock rate is protected and unset
when it is unprotected. That way we could track if clk_rate_exclusive_put()
needs to be called or not.
Best regards,
Jernej
>
> regards,
> o.
>
> On Fri, Mar 09, 2018 at 01:13:14AM +0100, 'Ondřej Jirman' via linux-sunxi
wrote:
> > Hi Jernej,
> >
> > On Thu, Mar 08, 2018 at 11:57:40PM +0100, Jernej Škrabec wrote:
> > > Hi,
> > >
> > > Dne četrtek, 08. marec 2018 ob 23:47:17 CET je Ondřej Jirman napisal(a):
> > > > Hi,
> > > >
> > > > On Thu, Mar 01, 2018 at 10:34:32PM +0100, Jernej Skrabec wrote:
> > > > > Currently exclusive TCON clock lock is never released, which, for
> > > > > example, prevents changing resolution on HDMI.
> > > > >
> > > > > In order to fix that, release clock when disabling TCON. TCON is
> > > > > always
> > > > > disabled first before new mode is set.
> > > > >
> > > > > Signed-off-by: Jernej Skrabec
> > > > > ---
> > > > >
> > > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 --
> > > > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> > > > > 1d714c06ec9d..7f6c4125c89f
> > > > > 100644
> > > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > @@ -102,10 +102,12 @@ static void
> > > > > sun4i_tcon_channel_set_status(struct
> > > > > sun4i_tcon *tcon, int channel,>
> > > > >
> > > > > return;
> > > > >
> > > > > }
> > > > >
> > > > > - if (enabled)
> > > > > + if (enabled) {
> > > > >
> > > > > clk_prepare_enable(clk);
> > > > >
> > > > > - else
> > > > > + } else {
> > > > > + clk_rate_exclusive_put(clk);
> > > > >
> > > > > clk_disable_unprepare(clk);
> > > > >
> > > > > + }
> > > > >
> > > > > }
> > > >
> > > > At least in the linux-next/master I can't see clk_rate_exclusive_get
call:
> > > It is in drm-misc/drm-misc-fixes:
> > > https://cgit.freedesktop.org/drm/drm-misc/commit/?h=drm-misc-fixes&id=79
> > > d103a565d16b1893d990b2ee5e0fe71767759f
> > >
> > > My patch is also applied in same branch, so there should be no issues
> > > while
> > > merging all those branches.
> > >
> > > linux-next doesn't have either patches currently:
> > > https://git.kernel.org/pub/
> > > scm/linux/kernel/git/next/linux-next.git/log/drivers/gpu/drm/sun4i
> > >
> > > This is issue only if you manually apply one patch without the other.
> >
> > I have (and had) both patches applied. There's
Re: [alsa-devel] [BUG] Kernel crash on Allwinner H3 due to sound core changes
Hi,
Dne petek, 09. marec 2018 ob 00:49:18 CET je Kuninori Morimoto napisal(a):
> Hi Mark,Jernej
>
> > > Ahh.. indeed. Good catch !
> > > How about to add such flag ?
> > > This is just idea. No tested, No compiled, but can help you ?
> >
> > I think this makes sense as a patch. We might want to disallow
> > allocating components as part of a bigger struct so everything is more
> > consistent but that's a bigger thing.
>
> (snip)
>
> > I tested this patch and there is no crash anymore. If you will send it as
> > a
> > fix, you can add:
> >
> > Reported-by: Jernej Skrabec
> > Tested-by: Jernej Skrabec
>
> previous my patch used new flag (= .alloced_component),
> but I think it is not good idea.
> And I noticed that snd_soc_add_component() is
> also calling kfree(component) (= has same bug).
>
> So how about below one ?
> I want to post it instead of previous.
>
> # I will go to ELC next week, thus posting patch will be
> # 2weeks later
>
>
> diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
> index c0edac8..4a8de23 100644
> --- a/sound/soc/soc-core.c
> +++ b/sound/soc/soc-core.c
> @@ -3476,7 +3476,6 @@ int snd_soc_add_component(struct device *dev,
> err_cleanup:
> snd_soc_component_cleanup(component);
> err_free:
> - kfree(component);
> return ret;
> }
> EXPORT_SYMBOL_GPL(snd_soc_add_component);
> @@ -3488,7 +3487,7 @@ int snd_soc_register_component(struct device *dev,
> {
> struct snd_soc_component *component;
>
> - component = kzalloc(sizeof(*component), GFP_KERNEL);
> + component = devm_kzalloc(dev, sizeof(*component), GFP_KERNEL);
> if (!component)
> return -ENOMEM;
>
> @@ -3523,7 +3522,6 @@ static int __snd_soc_unregister_component(struct
> device *dev)
>
> if (found) {
> snd_soc_component_cleanup(component);
> - kfree(component);
> }
>
> return found;
That patch also prevents the crash, so you can add my tested-by and reported-
by tags for this patch too.
Best regards,
Jernej
Re: [linux-sunxi] [PATCH v2 15/15] arm64: dts: allwinner: a64: Add Video Engine node
Hi!
Dne sreda, 05. december 2018 ob 10:24:44 CET je Paul Kocialkowski napisal(a):
> This adds the Video Engine node for the A64. Since it can map the whole
> DRAM range, there is no particular need for a reserved memory node
> (unlike platforms preceding the A33).
>
> Signed-off-by: Paul Kocialkowski
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi index
> 8557d52c7c99..8d024c10d7cb 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -397,6 +397,17 @@
> };
> };
>
> + video-codec@1c0e000 {
> + compatible = "allwinner,sun50i-h5-video-engine";
You meant A64 instead of H5, right?
Best regards,
Jernej
> + reg = <0x01c0e000 0x1000>;
> + clocks = <&ccu CLK_BUS_VE>, <&ccu CLK_VE>,
> + <&ccu CLK_DRAM_VE>;
> + clock-names = "ahb", "mod", "ram";
> + resets = <&ccu RST_BUS_VE>;
> + interrupts = ;
> + allwinner,sram = <&ve_sram 1>;
> + };
> +
> mmc0: mmc@1c0f000 {
> compatible = "allwinner,sun50i-a64-mmc";
> reg = <0x01c0f000 0x1000>;
Re: [linux-sunxi] Re: [PATCH 05/15] drm/sun4i: Add TCON TOP driver
Hi,
Dne četrtek, 24. maj 2018 ob 10:43:51 CEST je Maxime Ripard napisal(a):
> Hi,
>
> On Mon, May 21, 2018 at 05:15:15PM +0200, Jernej Škrabec wrote:
> > > > + /*
> > > > +* Default register values might have some reserved bits set,
which
> > > > +* prevents TCON TOP from working properly. Set them to 0 here.
> > > > +*/
> > > > + writel(0, tcon_top->regs + TCON_TOP_PORT_SEL_REG);
> > > > + writel(0, tcon_top->regs + TCON_TOP_GATE_SRC_REG);
> > > > +
> > > > + for (i = 0; i < CLK_NUM; i++) {
> > > > + const char *parent_name = "bus-tcon-top";
> > >
> > > I guess retrieving the parent's clock name at runtime would be more
> > > flexible.
> >
> > It is, but will it ever be anything else?
>
> Probably not, but when the complexity is exactly the same (using
> __clk_get_name), we'd better use the more appropriate solution. If we
> ever need to change that clock name, or to use the driver with an SoC
> that wouldn't have the same clock name for whatever reason, it will
> just work.
>
> > > > + struct clk_init_data init;
> > > > + struct clk_gate *gate;
> > > > +
> > > > + gate = devm_kzalloc(dev, sizeof(*gate), GFP_KERNEL);
> > > > + if (!gate) {
> > > > + ret = -ENOMEM;
> > > > + goto err_disable_clock;
> > > > + }
> > > > +
> > > > + init.name = gates[i].name;
> > > > + init.ops = &clk_gate_ops;
> > > > + init.flags = CLK_IS_BASIC;
> > > > + init.parent_names = &parent_name;
> > > > + init.num_parents = 1;
> > > > +
> > > > + gate->reg = tcon_top->regs + TCON_TOP_GATE_SRC_REG;
> > > > + gate->bit_idx = gates[i].bit;
> > > > + gate->lock = &tcon_top->reg_lock;
> > > > + gate->hw.init = &init;
> > > > +
> > > > + ret = devm_clk_hw_register(dev, &gate->hw);
> > > > + if (ret)
> > > > + goto err_disable_clock;
> > >
> > > Isn't it what clk_hw_register_gate is doing?
> >
> > Almost, but not exactly. My goal was to use devm_* functions, so there is
> > no need to do any special cleanup.
>
> Is it the only difference? If so, you can just create a
> devm_clk_hw_register gate.
I checked around and it seems that in clk core there are only non devm_*
helpers like clk_hw_register_gate() for some reason. I guess I'll just use
that and manually unregister all the clocks in cleanup function.
Best regards,
Jernej
Re: [linux-sunxi] Re: [PATCH v2 24/27] drm: of: Export drm_crtc_port_mask()
Dne sreda, 13. junij 2018 ob 09:36:05 CEST je Maxime Ripard napisal(a): > On Tue, Jun 12, 2018 at 10:00:33PM +0200, Jernej Skrabec wrote: > > Function is useful when drm_of_find_possible_crtcs() can't be used and > > custom parsing is needed. This can happen for example when there is a > > node with multiple muxes between crtc and encoder. > > > > Signed-off-by: Jernej Skrabec > > --- > > > > drivers/gpu/drm/drm_of.c | 4 ++-- > > include/drm/drm_of.h | 8 > > 2 files changed, 10 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c > > index 1fe122461298..2e9cea3287b2 100644 > > --- a/drivers/gpu/drm/drm_of.c > > +++ b/drivers/gpu/drm/drm_of.c > > @@ -22,8 +22,8 @@ static void drm_release_of(struct device *dev, void > > *data)> > > * Given a port OF node, return the possible mask of the corresponding > > * CRTC within a device's list of CRTCs. Returns zero if not found. > > */ > > > > -static uint32_t drm_crtc_port_mask(struct drm_device *dev, > > - struct device_node *port) > > +uint32_t drm_crtc_port_mask(struct drm_device *dev, > > + struct device_node *port) > > It should probably be exported too? Yes, of course. It will be in next version. Best regards, Jernej
Re: [linux-sunxi] [PATCH v2 20/27] drm/sun4i: Don't change clock bits in DW HDMI PHY driver
Dne torek, 12. junij 2018 ob 22:00:29 CEST je Jernej Skrabec napisal(a): > DW HDMI PHY driver and PHY clock driver share same registers. Make sure > that DW HDMI PHY setup code doesn't change any clock related bits and > set them to 0 during initialization. > > Signed-off-by: Jernej Skrabec > --- > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 +- > drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 12 +++- > 2 files changed, 12 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h > b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h index 79154f0f674a..3ba71aff92fc > 100644 > --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h > +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h > @@ -98,7 +98,7 @@ > #define SUN8I_HDMI_PHY_PLL_CFG1_LDO2_EN BIT(29) > #define SUN8I_HDMI_PHY_PLL_CFG1_LDO1_EN BIT(28) > #define SUN8I_HDMI_PHY_PLL_CFG1_HV_IS_33 BIT(27) > -#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL BIT(26) > +#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK BIT(26) > #define SUN8I_HDMI_PHY_PLL_CFG1_PLLENBIT(25) > #define SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(x) ((x) << 22) > #define SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(x) ((x) << 20) > diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c > b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c index 966688f04741..cd07ceb71601 > 100644 > --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c > +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c > @@ -183,7 +183,13 @@ static int sun8i_hdmi_phy_config_h3(struct dw_hdmi > *hdmi, regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_ANA_CFG1_REG, > SUN8I_HDMI_PHY_ANA_CFG1_TXEN_MASK, 0); > > - regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, pll_cfg1_init); > + /* > + * NOTE: We have to be careful not to overwrite PHY parent > + * clock selection bit and clock divider. > + */ > + regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, > +(u32)~SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK, > +pll_cfg1_init); > regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG, > (u32)~SUN8I_HDMI_PHY_PLL_CFG2_PREDIV_MSK, > pll_cfg2_init); > @@ -352,6 +358,10 @@ static void sun8i_hdmi_phy_init_h3(struct > sun8i_hdmi_phy *phy) SUN8I_HDMI_PHY_ANA_CFG3_SCLEN | > SUN8I_HDMI_PHY_ANA_CFG3_SDAEN); > > + /* reset PLL clock configuration */ > + regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, 0); > + regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG, 0); > + For some reason, this change breaks HDMI on H3. Clearing only PLL parent selection bit works ok, though. I'll fix it in next revision. Best regards, Jernej > /* set HW control of CEC pins */ > regmap_write(phy->regs, SUN8I_HDMI_PHY_CEC_REG, 0);
Re: [PATCH v2 12/26] drm/sun4i: Add support for multiple DW HDMI PHY clock parents
Hi,
Dne petek, 18. maj 2018 ob 12:01:16 CEST je Maxime Ripard napisal(a):
> On Fri, May 18, 2018 at 03:15:22PM +0530, Jagan Teki wrote:
> > From: Jernej Skrabec
> >
> > Some SoCs with DW HDMI have multiple possible clock parents, like A64
> > and R40.
> >
> > Expand HDMI PHY clock driver to support second clock parent.
> >
> > Signed-off-by: Jernej Skrabec
> > Signed-off-by: Jagan Teki
> > ---
> > Changes for v2:
> > - new patch
> >
> > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 9 ++-
> > drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 33 ---
> > drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c | 89
> > ++ 3 files changed, 96 insertions(+), 35
> > deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> > b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h index 79154f0f674a..303189d6602c
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> > +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> > @@ -98,7 +98,8 @@
> >
> > #define SUN8I_HDMI_PHY_PLL_CFG1_LDO2_ENBIT(29)
> > #define SUN8I_HDMI_PHY_PLL_CFG1_LDO1_ENBIT(28)
> > #define SUN8I_HDMI_PHY_PLL_CFG1_HV_IS_33 BIT(27)
> >
> > -#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL BIT(26)
> > +#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK BIT(26)
> > +#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT 26
> >
> > #define SUN8I_HDMI_PHY_PLL_CFG1_PLLEN BIT(25)
> > #define SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(x)((x) << 22)
> > #define SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(x) ((x) << 20)
> >
> > @@ -146,7 +147,7 @@
> >
> > struct sun8i_hdmi_phy;
> >
> > struct sun8i_hdmi_phy_variant {
> >
> > - bool has_phy_clk;
> > + int phy_clk_num;
> >
> > void (*phy_init)(struct sun8i_hdmi_phy *phy);
> > void (*phy_disable)(struct dw_hdmi *hdmi,
> >
> > struct sun8i_hdmi_phy *phy);
> >
> > @@ -160,6 +161,7 @@ struct sun8i_hdmi_phy {
> >
> > struct clk *clk_mod;
> > struct clk *clk_phy;
> > struct clk *clk_pll0;
> >
> > + struct clk *clk_pll1;
> >
> > unsigned intrcal;
> > struct regmap *regs;
> > struct reset_control*rst_phy;
> >
> > @@ -188,6 +190,7 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi
> > *hdmi);
> >
> > void sun8i_hdmi_phy_init(struct sun8i_hdmi_phy *phy);
> > const struct dw_hdmi_phy_ops *sun8i_hdmi_phy_get_ops(void);
> >
> > -int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev);
> > +int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev,
> > +int clk_num);
> >
> > #endif /* _SUN8I_DW_HDMI_H_ */
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> > b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c index 5a52fc489a9d..0eadf087fc46
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> > @@ -183,7 +183,13 @@ static int sun8i_hdmi_phy_config_h3(struct dw_hdmi
> > *hdmi,>
> > regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_ANA_CFG1_REG,
> >
> >SUN8I_HDMI_PHY_ANA_CFG1_TXEN_MASK, 0);
> >
> > - regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, pll_cfg1_init);
> > + /*
> > +* NOTE: We have to be careful not to overwrite PHY parent
> > +* clock selection bit and clock divider.
> > +*/
> > + regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG,
> > + (u32)~SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK,
> > + pll_cfg1_init);
> >
> > regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG,
> >
> >(u32)~SUN8I_HDMI_PHY_PLL_CFG2_PREDIV_MSK,
> >pll_cfg2_init);
> >
> > @@ -232,7 +238,7 @@ static int sun8i_hdmi_phy_config(struct dw_hdmi *hdmi,
> > void *data,>
> > regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_DBG_CTRL_REG,
> >
> >SUN8I_HDMI_PHY_DBG_CTRL_POL_MASK, val);
> >
> > - if (phy->variant->has_phy_clk)
> > + if (phy->variant->phy_clk_num)
> >
> > clk_set_rate(phy->clk_phy, mode->crtc_clock * 1000);
> >
> > return phy->variant->phy_config(hdmi, phy, mode->crtc_clock * 1000);
> >
> > @@ -393,7 +399,7 @@ static const struct sun8i_hdmi_phy_variant
> > sun8i_a83t_hdmi_phy = {>
> > };
> >
> > static const struct sun8i_hdmi_phy_variant sun8i_h3_hdmi_phy = {
> >
> > - .has_phy_clk = true,
> > + .phy_clk_num = 1,
> >
> > .phy_init = &sun8i_hdmi_phy_init_h3,
> > .phy_disable = &sun8i_hdmi_phy_disable_h3,
> > .phy_config = &sun8i_hdmi_phy_config_h3,
> >
> > @@ -464,7 +470,7 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi,
> > struct device_node *node)>
> > goto err_put_clk_bus;
> >
> > }
> >
> > - if (phy->variant->has_phy_clk) {
> > + if (phy->variant->phy_clk_num) {
> >
> > phy
Re: [PATCH v2 12/26] drm/sun4i: Add support for multiple DW HDMI PHY clock parents
Hi,
Dne petek, 18. maj 2018 ob 17:09:40 CEST je Sergey Suloev napisal(a):
> Hi, guys,
>
> On 05/18/2018 05:46 PM, Jernej Škrabec wrote:
> > Hi,
> >
> > Dne petek, 18. maj 2018 ob 12:01:16 CEST je Maxime Ripard napisal(a):
> >> On Fri, May 18, 2018 at 03:15:22PM +0530, Jagan Teki wrote:
> >>> From: Jernej Skrabec
> >>>
> >>> Some SoCs with DW HDMI have multiple possible clock parents, like A64
> >>> and R40.
> >>>
> >>> Expand HDMI PHY clock driver to support second clock parent.
> >>>
> >>> Signed-off-by: Jernej Skrabec
> >>> Signed-off-by: Jagan Teki
> >>> ---
> >>> Changes for v2:
> >>> - new patch
> >>>
> >>> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 9 ++-
> >>> drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 33 ---
> >>> drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c | 89
> >>> ++ 3 files changed, 96 insertions(+), 35
> >>> deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> >>> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h index 79154f0f674a..303189d6602c
> >>> 100644
> >>> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> >>> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> >>> @@ -98,7 +98,8 @@
> >>>
> >>> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO2_EN BIT(29)
> >>> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO1_EN BIT(28)
> >>> #define SUN8I_HDMI_PHY_PLL_CFG1_HV_IS_33BIT(27)
> >>>
> >>> -#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL BIT(26)
> >>> +#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK BIT(26)
> >>> +#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT 26
> >>>
> >>> #define SUN8I_HDMI_PHY_PLL_CFG1_PLLEN BIT(25)
> >>> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(x) ((x) << 22)
> >>> #define SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(x) ((x) << 20)
> >>>
> >>> @@ -146,7 +147,7 @@
> >>>
> >>> struct sun8i_hdmi_phy;
> >>>
> >>> struct sun8i_hdmi_phy_variant {
> >>>
> >>> - bool has_phy_clk;
> >>> + int phy_clk_num;
> >>>
> >>> void (*phy_init)(struct sun8i_hdmi_phy *phy);
> >>> void (*phy_disable)(struct dw_hdmi *hdmi,
> >>>
> >>> struct sun8i_hdmi_phy *phy);
> >>>
> >>> @@ -160,6 +161,7 @@ struct sun8i_hdmi_phy {
> >>>
> >>> struct clk *clk_mod;
> >>> struct clk *clk_phy;
> >>> struct clk *clk_pll0;
> >>>
> >>> + struct clk *clk_pll1;
> >>>
> >>> unsigned intrcal;
> >>> struct regmap *regs;
> >>> struct reset_control*rst_phy;
> >>>
> >>> @@ -188,6 +190,7 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi
> >>> *hdmi);
> >>>
> >>> void sun8i_hdmi_phy_init(struct sun8i_hdmi_phy *phy);
> >>> const struct dw_hdmi_phy_ops *sun8i_hdmi_phy_get_ops(void);
> >>>
> >>> -int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device
> >>> *dev);
> >>> +int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device
> >>> *dev,
> >>> + int clk_num);
> >>>
> >>> #endif /* _SUN8I_DW_HDMI_H_ */
> >>>
> >>> diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> >>> b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c index
> >>> 5a52fc489a9d..0eadf087fc46
> >>> 100644
> >>> --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> >>> +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> >>> @@ -183,7 +183,13 @@ static int sun8i_hdmi_phy_config_h3(struct dw_hdmi
> >>> *hdmi,>
> >>>
> >>> regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_ANA_CFG1_REG,
> >>>
> >>> SUN8I_HDMI_PHY_ANA_CFG1_TXEN_MASK, 0);
> >>>
> >>> - regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, pll_cfg1_init);
> >>> + /*
> >>> + * NOTE: W
Re: [PATCH v2 12/26] drm/sun4i: Add support for multiple DW HDMI PHY clock parents
Hi, Dne petek, 18. maj 2018 ob 17:26:51 CEST je Maxime Ripard napisal(a): > On Fri, May 18, 2018 at 04:46:41PM +0200, Jernej Škrabec wrote: > > > And this is a bit sloppy, since if phy_clk_num == 3, you won't try to > > > lookup pll-2 either. > > > > It is highly unlikely this will be higher than 2, at least for this HDMI > > PHY, since it has only 1 bit reserved for parent selection. But since I > > have to fix it, I'll add ">= 2" > > If we're only going to have two parents at most, ever, why don't we > had just a single other boolean. This would be less intrusive, and we > wouldn't have to check for those corner cases. That works for me too. And since it's only the code, it can always be reworked if there is the need. Best regards, Jernej > > > BTW, I'll resend fixed version of this patch for my R40 HDMI series, since > > there is nothing to hold it back, unlike for this. > > Awesome, thanks! > Maxime > > -- > Maxime Ripard, Bootlin (formerly Free Electrons) > Embedded Linux and Kernel engineering > https://bootlin.com
Re: [PATCH 1/4] dt-bindings: iio: light: stk33xx: add regulator for vdd supply
Dne nedelja, 14. april 2024 ob 19:57:13 GMT +2 je Aren Moynihan napisal(a): > Signed-off-by: Aren Moynihan Commit message cannot be empty. Best regards, Jernej > --- > Documentation/devicetree/bindings/iio/light/stk33xx.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/iio/light/stk33xx.yaml > b/Documentation/devicetree/bindings/iio/light/stk33xx.yaml > index f6e22dc9814a..db35e239d4a8 100644 > --- a/Documentation/devicetree/bindings/iio/light/stk33xx.yaml > +++ b/Documentation/devicetree/bindings/iio/light/stk33xx.yaml > @@ -29,6 +29,7 @@ properties: >interrupts: > maxItems: 1 > > + vdd-supply: true >proximity-near-level: true > > required: >
[BUG] Kernel crash on Allwinner H3 due to sound core changes
Hi all,
with todays linux-next (next-20180228), kernel on Allwinner H3 SoC crashes
with dmesg like that: https://pastebin.com/raw/0D5JeaJ8
I bisected the kernel and first offending commit is:
be7ee5f32a9a ("ASoC: soc-generic-dmaengine-pcm: replace platform to
component")
I know that crash message is completely unrelated to sound subsystem, but it
turns out that if I disable CONFIG_SND_SUN4I_CODEC kernel works ok, but this
way I lose analog audio output.
Any suggestions what can be the issue?
Best regards,
Jernej
Re: [PATCH v2 00/16] Implement H3/H5 HDMI driver
Hi Maxime, Dne torek, 27. februar 2018 ob 23:26:45 CET je Jernej Skrabec napisal(a): > This series implements H3/H5 HDMI driver. It was tested on OrangePi 2 (H3), > OrangePi Plus2e (H3) and OrangePi PC2 (H5) with many resolutions and it > works well. Bug, which prevented correct operation for some resolutions, > is also fixed. > > Code is based on linux-next, next-20180226 tag. Today I tried on this series on next-20180228, but resolution switching doesn't really work. The reason for this is use of clk_set_rate_exclusive() in sun4i_tcon1_mode_set(). If I revert it to ordinary clk_set_rate() it works ok. I investigated a bit and it seems that clocks stays at first set even if tcon (the owner of exclusive lock) request the new one. Example: [ 69.325732] TCON clk wanted: 14850 [ 69.325740] TCON real clk: 69272728 [ 69.325770] HDMI clk wanted: 14850 [ 69.325773] HDMI real clk: 138545455 [ 69.325815] HDMI PHY clk wanted: 14850 [ 69.325819] HDMI PHY real clk: 138545454 Is there anything I can do to help debug this? Best regards, Jernej
Re: [PATCH v2 06/16] drm/sun4i: Don't process LVDS if TCON doesn't support it
Hi Maxime, Dne sreda, 28. februar 2018 ob 08:36:08 CET je Maxime Ripard napisal(a): > On Tue, Feb 27, 2018 at 11:26:51PM +0100, Jernej Skrabec wrote: > > TCON checks for LVDS properties even if it doesn't support it. Add a > > check to skip that part of the code if TCON doesn't support channel 0. > > > > Signed-off-by: Jernej Skrabec > > I have already sent a similar patch here: > https://lists.freedesktop.org/archives/dri-devel/2018-February/15.html Right. However, check last chunk in my patch. There is no need to call sun4i_rgb_init() if TCON doesn't support channel 0. It doesn't do anything, except producing warning. Will you add that this change to your patch and then I can remove this patch from next revision? BTW, your patch won't apply cleanly, since you didn't base it on latest code (every TCON variant has at least one entry now). Best regards, Jernej
Re: [PATCH v2 01/16] clk: sunxi-ng: Add check for minimal rate to NM PLLs
Hi,
Dne sreda, 28. februar 2018 ob 08:34:40 CET je Maxime Ripard napisal(a):
> Hi,
>
> On Tue, Feb 27, 2018 at 11:26:46PM +0100, Jernej Skrabec wrote:
> > Some NM PLLs doesn't work well when their output clock rate is set below
> > certain rate.
> >
> > Add support for that constrain.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/clk/sunxi-ng/ccu_nm.c | 11 +++
> > drivers/clk/sunxi-ng/ccu_nm.h | 27 +++
> > 2 files changed, 34 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/clk/sunxi-ng/ccu_nm.c b/drivers/clk/sunxi-ng/ccu_nm.c
> > index a16de092bf94..7fc743c78c1b 100644
> > --- a/drivers/clk/sunxi-ng/ccu_nm.c
> > +++ b/drivers/clk/sunxi-ng/ccu_nm.c
> > @@ -20,7 +20,7 @@ struct _ccu_nm {
> >
> > };
> >
> > static void ccu_nm_find_best(unsigned long parent, unsigned long rate,
> >
> > -struct _ccu_nm *nm)
> > +unsigned long min_rate, struct _ccu_nm *nm)
> >
> > {
> >
> > unsigned long best_rate = 0;
> > unsigned long best_n = 0, best_m = 0;
> >
> > @@ -30,7 +30,7 @@ static void ccu_nm_find_best(unsigned long parent,
> > unsigned long rate,>
> > for (_m = nm->min_m; _m <= nm->max_m; _m++) {
> >
> > unsigned long tmp_rate = parent * _n / _m;
> >
> > - if (tmp_rate > rate)
> > + if (tmp_rate > rate || tmp_rate < min_rate)
> >
> > continue;
> >
> > if ((rate - tmp_rate) < (rate - best_rate)) {
> >
> > @@ -117,6 +117,9 @@ static long ccu_nm_round_rate(struct clk_hw *hw,
> > unsigned long rate,>
> > if (nm->common.features & CCU_FEATURE_FIXED_POSTDIV)
> >
> > rate *= nm->fixed_post_div;
> >
> > + if (rate < nm->min_rate)
> > + rate = nm->min_rate;
> > +
>
> I guess you can just return there. There's no point in trying to find
> the factors at this point, since the minimum should be a value that
> can be reached.
>
Right, I already tested it and it works.
Best regards,
Jernej
> > if (ccu_frac_helper_has_rate(&nm->common, &nm->frac, rate)) {
> >
> > if (nm->common.features & CCU_FEATURE_FIXED_POSTDIV)
> >
> > rate /= nm->fixed_post_div;
> >
> > @@ -134,7 +137,7 @@ static long ccu_nm_round_rate(struct clk_hw *hw,
> > unsigned long rate,>
> > _nm.min_m = 1;
> > _nm.max_m = nm->m.max ?: 1 << nm->m.width;
> >
> > - ccu_nm_find_best(*parent_rate, rate, &_nm);
> > + ccu_nm_find_best(*parent_rate, rate, nm->min_rate, &_nm);
>
> Therefore, you don't need to change the prototype there either.
>
> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com
Re: [BUG] Kernel crash on Allwinner H3 due to sound core changes
Hi Kuninori,
I'm responding to my own mail, since I didn't received yours for some reason
but I still saw your response in mailing list archive.
Dne sreda, 28. februar 2018 ob 22:02:09 CET je Jernej Škrabec napisal(a):
> Hi all,
>
> with todays linux-next (next-20180228), kernel on Allwinner H3 SoC crashes
> with dmesg like that: https://pastebin.com/raw/0D5JeaJ8
>
> I bisected the kernel and first offending commit is:
> be7ee5f32a9a ("ASoC: soc-generic-dmaengine-pcm: replace platform to
> component")
>
> I know that crash message is completely unrelated to sound subsystem, but it
> turns out that if I disable CONFIG_SND_SUN4I_CODEC kernel works ok, but
> this way I lose analog audio output.
>
> Any suggestions what can be the issue?
I did a bit of research and I can tell you that different kernel options (some
drivers added or removed) change how or where kernel crashes. That would
suggest some kind of memory corruption.
I removed parts of the code from the sun4i codec driver and interestingly it
doesn't crash if I remove following lines:
ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL, 0);
if (ret) {
dev_err(&pdev->dev, "Failed to register against DMAEngine\n");
goto err_assert_reset;
}
Is it possible that NULL pointer causes troubles somewhere down the line?
I tested this on linux-next, next-20180228 tag.
Best regards,
Jernej
Re: [RFC 00/13] arm64: allwinner: Add A64 DE2 pipeline support
Hi, Dne četrtek, 26. april 2018 ob 15:26:49 CEST je Jagan Teki napisal(a): > On Wed, Apr 25, 2018 at 11:29 PM, Jernej Škrabec > > wrote: > > Hi, > > > > Dne sreda, 25. april 2018 ob 12:34:09 CEST je Jagan Teki napisal(a): > >> On Tue, Apr 24, 2018 at 9:02 PM, Jernej Škrabec > > > > wrote: > >> > Hi, > >> > > >> > Dne torek, 24. april 2018 ob 15:34:12 CEST je Jagan Teki napisal(a): > >> >> Allwinner A64 has display engine pipeline like other Allwinner SOC's > >> >> A83T/H3/H5. > >> >> > >> >> A64 DE2 behaviour similar to Allwinner A83T where mixer0, connected to > >> >> tcon0 with RGB, LVDS MIPI-DSI and mixer1, connected to tcon1 with > >> >> HDMI. > >> >> This series merely concentrated on HDMI pipeline and rest will add > >> >> eventually. > >> >> > >> >> patch 1: dt-bindings for a64 DE2 CCU > >> >> > >> >> patch 2: a64 DE2 CCU node addition > >> >> > >> >> patch 3: dt-bindings for a64 DE2 pipeline > >> >> > >> >> patch 4 - 5: dt-bindings for a64 mixer0 and tcon-lcd > >> >> > >> >> patch 6: a64 DE2 pipeline node addition > >> >> > >> >> patch 7 - 8: dt-bindings for a64 HDMI and HDMI PHY > >> >> > >> >> patch 9: a64 HDMI nodes addition > >> >> > >> >> patch 10 - 11: dt-bindings for a64 mixer1 and tcon-tv > >> >> > >> >> patch 12: a64 HDMI pipeline > >> >> > >> >> patch 13: enable HDMI out on bananpi-m64 > >> >> > >> >> Tested HDMI on bananapi-m64 (along with DE2 SRAM C changes from [1] > >> >> thread), able to detect the HDMI but, no penguins on screen. > >> >> > >> >> Request for any suggestions. > >> > > >> > You are mising sunxi-ng clock patches. PLL_VIDEO0 and PLL_VIDEO1 need > >> > fixes by setting minimum stable frequency. Please note that datasheet > >> > may > >> > have wrong information. That was obvious in H3 case and I had to check > >> > minimum stable PLL_VIDEO frequency in BSP driver. > >> > >> Can you point me the clock patches? > > > > Here is my A64 HDMI wip repo, which includes my clock changes: > > https://github.com/jernejsk/linux-1/tree/a64_hdmi_wip > > > > At some point HDMI output worked ok, I'm not sure in what state I left the > > code. > > Jernej, thanks for the regulator change in another mail, yes > bananapi-m64 has HVCC regulator for HDMI glue, with this I'm able to > see penguins on screen. Ok, great. > > >> I've phadled only CLK_PLL_VIDEO0 > >> on hdmi_phy So we need CLK_PLL_VIDEO1 as fourth clock? > > > > I'm not sure what is the best way. I guess some research is needed. There > > is even the possibility that one bit (SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL) > > in hdmi phy needs to be toggled depending on which clock is selected as > > HDMI source. I never finished my research since I'm waiting to SRAM C > > claiming patches. > > > > At the end, HDMI driver should be tested by both, PLL_VIDEO0 and > > PLL_VIDEO1 as a HDMI clock source, otherwise there is no guarantee that > > we got binding right. A83T, H3 and H5 has only one possible HDMI parent > > clock, so it was much easier in this regard. > > From Figure 3-3.Module Clock Diagram of > Allwinner_A64_User_Manual_V1.1.pdf clearly shows PLL_VIDEO1 is > connected TCON1 which intern used by HDMI. I've verified both > PLL_VIDEO0 and 1 both seems working. I'm thinking we can go for > PLL_VIDEO1 as per datasheet, any suggestions? > > Jagan. Actually, same diagram also shows that PLL_VIDEO0 can be connected to TCON1/ HDMI. Since DT descibes HW, probably both phandles should be specified and driver should decide some way which one to select. Additionally, HDMI controller and HDMI PHY should use same PLL at the same time. If nothing is done, PLL_VIDEO0 will always be used, which might interfere in dual monitor setup. Best regards, Jernej
Re: [RFC 00/13] arm64: allwinner: Add A64 DE2 pipeline support
Hi, Dne sreda, 25. april 2018 ob 12:34:09 CEST je Jagan Teki napisal(a): > On Tue, Apr 24, 2018 at 9:02 PM, Jernej Škrabec wrote: > > Hi, > > > > Dne torek, 24. april 2018 ob 15:34:12 CEST je Jagan Teki napisal(a): > >> Allwinner A64 has display engine pipeline like other Allwinner SOC's > >> A83T/H3/H5. > >> > >> A64 DE2 behaviour similar to Allwinner A83T where mixer0, connected to > >> tcon0 with RGB, LVDS MIPI-DSI and mixer1, connected to tcon1 with HDMI. > >> This series merely concentrated on HDMI pipeline and rest will add > >> eventually. > >> > >> patch 1: dt-bindings for a64 DE2 CCU > >> > >> patch 2: a64 DE2 CCU node addition > >> > >> patch 3: dt-bindings for a64 DE2 pipeline > >> > >> patch 4 - 5: dt-bindings for a64 mixer0 and tcon-lcd > >> > >> patch 6: a64 DE2 pipeline node addition > >> > >> patch 7 - 8: dt-bindings for a64 HDMI and HDMI PHY > >> > >> patch 9: a64 HDMI nodes addition > >> > >> patch 10 - 11: dt-bindings for a64 mixer1 and tcon-tv > >> > >> patch 12: a64 HDMI pipeline > >> > >> patch 13: enable HDMI out on bananpi-m64 > >> > >> Tested HDMI on bananapi-m64 (along with DE2 SRAM C changes from [1] > >> thread), able to detect the HDMI but, no penguins on screen. > >> > >> Request for any suggestions. > > > > You are mising sunxi-ng clock patches. PLL_VIDEO0 and PLL_VIDEO1 need > > fixes by setting minimum stable frequency. Please note that datasheet may > > have wrong information. That was obvious in H3 case and I had to check > > minimum stable PLL_VIDEO frequency in BSP driver. > > Can you point me the clock patches? Here is my A64 HDMI wip repo, which includes my clock changes: https://github.com/jernejsk/linux-1/tree/a64_hdmi_wip At some point HDMI output worked ok, I'm not sure in what state I left the code. > I've phadled only CLK_PLL_VIDEO0 > on hdmi_phy So we need CLK_PLL_VIDEO1 as fourth clock? I'm not sure what is the best way. I guess some research is needed. There is even the possibility that one bit (SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL) in hdmi phy needs to be toggled depending on which clock is selected as HDMI source. I never finished my research since I'm waiting to SRAM C claiming patches. At the end, HDMI driver should be tested by both, PLL_VIDEO0 and PLL_VIDEO1 as a HDMI clock source, otherwise there is no guarantee that we got binding right. A83T, H3 and H5 has only one possible HDMI parent clock, so it was much easier in this regard. Unfortunately, BSP driver is not much of a help, since it was always distributed as a blob. Disassembly looks much like H3 driver, with few bits added. However, BSP clocks are pretty much hardcoded so they don't tell all the story. Best regards, Jernej
Re: [RFC 00/13] arm64: allwinner: Add A64 DE2 pipeline support
Hi, Dne sreda, 25. april 2018 ob 15:55:48 CEST je Maxime Ripard napisal(a): > On Wed, Apr 25, 2018 at 06:29:05PM +0530, Jagan Teki wrote: > > On Tue, Apr 24, 2018 at 7:38 PM, Maxime Ripard > > > > wrote: > > > On Tue, Apr 24, 2018 at 07:04:12PM +0530, Jagan Teki wrote: > > >> Allwinner A64 has display engine pipeline like other Allwinner SOC's > > >> A83T/H3/H5. > > >> > > >> A64 DE2 behaviour similar to Allwinner A83T where mixer0, connected to > > >> tcon0 with RGB, LVDS MIPI-DSI and mixer1, connected to tcon1 with > > >> HDMI. > > >> This series merely concentrated on HDMI pipeline and rest will add > > >> eventually. > > >> > > >> patch 1: dt-bindings for a64 DE2 CCU > > >> > > >> patch 2: a64 DE2 CCU node addition > > >> > > >> patch 3: dt-bindings for a64 DE2 pipeline > > >> > > >> patch 4 - 5: dt-bindings for a64 mixer0 and tcon-lcd > > >> > > >> patch 6: a64 DE2 pipeline node addition > > >> > > >> patch 7 - 8: dt-bindings for a64 HDMI and HDMI PHY > > >> > > >> patch 9: a64 HDMI nodes addition > > >> > > >> patch 10 - 11: dt-bindings for a64 mixer1 and tcon-tv > > >> > > >> patch 12: a64 HDMI pipeline > > >> > > >> patch 13: enable HDMI out on bananpi-m64 > > >> > > >> Tested HDMI on bananapi-m64 (along with DE2 SRAM C changes from [1] > > >> thread), able to detect the HDMI but, no penguins on screen. > > >> > > >> Request for any suggestions. > > >> > > >> Test log on Bananpi-m64: > > >> [0.247631] sun4i-drm display-engine: bound 110.mixer (ops > > >> sun8i_mixer_ops) [0.256717] sun4i-drm display-engine: bound > > >> 120.mixer (ops sun8i_mixer_ops) [0.256783] sun4i-tcon > > >> 1c0c000.lcd-controller: Missing LVDS properties, Please upgrade your > > >> DT [0.256792] sun4i-tcon 1c0c000.lcd-controller: LVDS output > > >> disabled> > > > > That doesn't seem to work so well for LVDS. > > > > > >> [0.257081] sun4i-drm display-engine: No panel or bridge found... > > >> RGB output disabled [0.257099] sun4i-drm display-engine: bound > > >> 1c0c000.lcd-controller (ops sun4i_tcon_ops) [0.257273] sun4i-drm > > >> display-engine: No panel or bridge found... RGB output disabled [ > > >> 0.257288] sun4i-drm display-engine: bound 1c0d000.lcd-controller (ops > > >> sun4i_tcon_ops) [0.258176] sun8i-dw-hdmi 1ee.hdmi: Detected > > >> HDMI TX controller v1.32a with HDCP (sun8i_dw_hdmi_p) [0.258596] > > >> sun8i-dw-hdmi 1ee.hdmi: registered DesignWare HDMI I2C bus driver > > >> [0.259188] sun4i-drm display-engine: bound 1ee.hdmi (ops > > >> sun8i_dw_hdmi_ops) [0.259199] [drm] Supports vblank timestamp > > >> caching Rev 2 (21.10.2013). [0.259205] [drm] No driver support for > > >> vblank timestamp query. [0.259308] [drm] Cannot find any crtc or > > >> sizes > > > > > > A good guess would be that you can't get the EDIDs for some > > > reason. Have you tried forcing a mode to see if the display part > > > already works? > > > > Yes I've forced and used custom EDID with 1024x786 bin and observed > > that the bin is able to load. > > > > [0.262973] [drm] No driver support for vblank timestamp query. > > [0.263842] [drm] Got built-in EDID base block and 0 extensions > > from "edid/1024x768.bin" for connector > > It's not really clear, is it displaying something? > This smells like HDMI voltage regulator not being enabled. You have to include patch like this: https://github.com/Icenowy/linux/commit/ 27d12cd2fe89f64c5f4d5224984d4cbfcb7ee137 I guess it won't apply as-is, since it's based on my old, out-of-tree hdmi driver. Best regards, Jernej
Re: [PATCH 3/3] clk: sunxi-ng: h6: Allow video & vpu clocks to change parent rate
Dne sreda, 03. april 2019 ob 15:22:52 CEST je Chen-Yu Tsai napisal(a): > On Wed, Apr 3, 2019 at 3:54 PM Maxime Ripard wrote: > > On Tue, Apr 02, 2019 at 11:06:23PM +0200, Jernej Skrabec wrote: > > > Video related clocks need to set rate as close as possible to the > > > requested one, so they should be able to change parent clock rate. > > > > > > VPU clock sometimes has to be set to higher than default parent clock > > > rate. This is requ > > The commit log looks unfinished. Can you and Jernej fix this up? Ah, sorry. I will send v2 with this commit message fixed and additional patch as requested by Maxime. Best regards, Jernej > > > > Add CLK_SET_RATE_PARENT flag to tcon-lcd0, tcon-tv0 and ve. > > > > > > Signed-off-by: Jernej Skrabec > > > > Applied, thanks! > > Maxime > > > > -- > > Maxime Ripard, Bootlin > > Embedded Linux and Kernel engineering > > https://bootlin.com
Re: [PATCH] ARM: dts: sun8i: h3: orangepi-plus: Fix Ethernet PHY mode
Hi! Let me first explain that it was oversight on my side not noticing initials in your SoB tag. But since the issue was raised by Maxime, I didn't follow up. Dne sobota, 13. februar 2021 ob 07:51:32 CET je B.R. Oake napisal(a): > On Wed Feb 10 at 16:01:18 CET 2021, Maxime Ripard wrote: > > Unfortunately we can't take this patch as is, this needs to be your real > > name, see: > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#de > > veloper-s-certificate-of-origin-1-1 > Dear Maxime, > > Thank you very much for considering my contribution and for all your > work on supporting sunxi-based hardware; I appreciate it. > > Thank you for referring me to the Developer's Certificate of Origin, but > I had already read it before submitting (I had to do so in order to know > what I was saying by "Signed-off-by:") and I do certify what it says. > > Looking through recent entries in the commit log of the mainline kernel, > I see several patches from authors such as: > > H.J. Lu > B K Karthik > JC Kuo > EJ Hsu > LH Lin > KP Singh > Karthik B S > Shreyas NC > Vandana BN > > so I believe names of this form are in fact acceptable, even if the > style might seem a little old-fashioned to some. Speaking generally, not only for this case, prior art arguments rarely hold, because: - it might be oversight, - it might be a bad practice, which should not be followed in new contributions, - different maintainers have different point of view on same thing, - maintainer wants to adapt new practice or steer subsystem in new direction > > I would like to add that I have met many people with names such as C.J., > A A, TC, MG, etc. That is what everybody calls them and it would be > natural for them to sign themselves that way. Some of them might want to > contribute to Linux some day, and I think it would be a great shame and > a loss to all of us if they were discouraged from doing so by reading > our conversation in the archives and concluding that any contribution > from them, however small, would be summarily refused simply because of > their name. Please could you ensure that does not happen? The link you posted says following: "using your real name (sorry, no pseudonyms or anonymous contributions.)" I believe that real name means no initials, no matter what people are accustomed to. From my point of view, CJ is pseudonym derived from real name. This is not the first time that fix of SoB tag was requested, you can find such requests in ML archives. Best regards, Jernej > > Thank you again for your consideration. > > Yours sincerely, > B.R. Oake.
Re: [PATCH v3 1/5] clk: sunxi-ng: mp: fix parent rate change flag check
Dne četrtek, 11. februar 2021 ob 03:28:00 CET je Stephen Boyd napisal(a):
> Quoting Maxime Ripard (2021-02-10 02:29:04)
>
> > Hi Mike, Stephen,
> >
> > On Tue, Feb 09, 2021 at 06:58:56PM +0100, Jernej Skrabec wrote:
> > > CLK_SET_RATE_PARENT flag is checked on parent clock instead of current
> > > one. Fix that.
> > >
> > > Fixes: 3f790433c3cb ("clk: sunxi-ng: Adjust MP clock parent rate when
> > > allowed") Reviewed-by: Chen-Yu Tsai
> > > Tested-by: Andre Heider
> > > Signed-off-by: Jernej Skrabec
> >
> > This is a last minute fix for us, can you merge it into clk-fixes
> > directly?
> >
> > Acked-by: Maxime Ripard
>
> It's also fixing a problem that's been around since v5.0. Is something
> broken that needs fixing this late? The motivation could be added to the
> commit text because right now it looks like a typo fix spotted visually.
Yes, it's needed. Without this patch, 4k@60 doesn't work and probably some
other resolutions too. That's why it's send with other display related fixes.
This is part of solution for longstanding display issues.
Best regards,
Jernej
Re: [PATCH v2 4/9] media: uapi: Add a control for HANTRO driver
Hi!
Dne četrtek, 18. februar 2021 ob 20:18:39 CET je Benjamin Gaignard napisal(a):
> The HEVC HANTRO driver needs to know the number of bits to skip at
> the beginning of the slice header.
> That is a hardware specific requirement so create a dedicated control
> that this purpose.
>
> Signed-off-by: Benjamin Gaignard
> ---
> include/uapi/linux/hantro-v4l2-controls.h | 20
> include/uapi/linux/v4l2-controls.h| 5 +
> 2 files changed, 25 insertions(+)
> create mode 100644 include/uapi/linux/hantro-v4l2-controls.h
>
> diff --git a/include/uapi/linux/hantro-v4l2-controls.h b/include/uapi/linux/
hantro-v4l2-controls.h
> new file mode 100644
> index ..30b1999b7af3
> --- /dev/null
> +++ b/include/uapi/linux/hantro-v4l2-controls.h
> @@ -0,0 +1,20 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +
> +#ifndef __UAPI_HANTRO_V4L2_CONYTROLS_H__
> +#define __UAPI_HANTRO_V4L2_CONYTROLS_H__
> +
> +#include
> +#include
> +
> +#define V4L2_CID_HANTRO_HEVC_EXTRA_DECODE_PARAMS
(V4L2_CID_USER_HANTRO_BASE + 0)
> +
> +/**
> + * struct hantro_hevc_extra_decode_params - extra decode parameters for
hantro driver
> + * @hevc_hdr_skip_lenght:header first bits offset
> + */
> +struct hantro_hevc_extra_decode_params {
> + __u32 hevc_hdr_skip_lenght;
typo: lenght -> length
Same mistake in description above.
Best regards,
Jernej
> + __u8padding[4];
> +};
> +
> +#endif
> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-
controls.h
> index 039c0d7add1b..ced7486c7f46 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -209,6 +209,11 @@ enum v4l2_colorfx {
> * We reserve 128 controls for this driver.
> */
> #define V4L2_CID_USER_CCS_BASE (V4L2_CID_USER_BASE +
0x10f0)
> +/*
> + * The base for HANTRO driver controls.
> + * We reserve 32 controls for this driver.
> + */
> +#define V4L2_CID_USER_HANTRO_BASE(V4L2_CID_USER_BASE +
0x1170)
>
> /* MPEG-class control IDs */
> /* The MPEG controls are applicable to all codec controls
> --
> 2.25.1
>
>
Re: [PATCH v2 1/9] media: hevc: Modify structures to follow H265 ITU spec
Hi!
Dne četrtek, 18. februar 2021 ob 20:18:36 CET je Benjamin Gaignard napisal(a):
> The H.265 ITU specification (section 7.4) define the general
> slice segment header semantics.
> Modified/added fields are:
> - video_parameter_set_id: (7.4.3.1) identifies the VPS for
> reference by other syntax elements.
> - seq_parameter_set_id: (7.4.3.2.1) specifies the value of
> the vps_video_parameter_set_id of the active VPS.
> - chroma_format_idc: (7.4.3.2.1) specifies the chroma sampling
> relative to the luma sampling
> - pic_parameter_set_id: (7.4.3.3.1) identifies the PPS for
> reference by other syntax elements
> - num_ref_idx_l0_default_active_minus1: (7.4.3.3.1) specifies
> the inferred value of num_ref_idx_l0_active_minus1
> - num_ref_idx_l1_default_active_minus1: (7.4.3.3.1) specifies
> the inferred value of num_ref_idx_l1_active_minus1
> - slice_segment_addr: (7.4.7.1) specifies the address of
> the first coding tree block in the slice segment
> - num_entry_point_offsets: (7.4.7.1) specifies the number of
> entry_point_offset_minus1[ i ] syntax elements in the slice header
>
> Add HEVC decode params contains the information used in section
> "8.3 Slice decoding process" of the specification to let the hardware
> perform decoding of a slices.
>
> Adapt Cedrus driver according to these changes.
>
> Signed-off-by: Benjamin Gaignard
> ---
> version 2:
> - remove all change related to scaling
> - squash commits to a coherent split
> - be more verbose about the added fields
>
> drivers/media/v4l2-core/v4l2-ctrls.c | 26 ---
> drivers/staging/media/sunxi/cedrus/cedrus.c | 6 +++
> drivers/staging/media/sunxi/cedrus/cedrus.h | 1 +
> .../staging/media/sunxi/cedrus/cedrus_dec.c | 2 +
> .../staging/media/sunxi/cedrus/cedrus_h265.c | 6 ++-
> include/media/hevc-ctrls.h| 45 +++
> 6 files changed, 69 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/
v4l2-ctrls.c
> index 016cf6204cbb..4060b5bcc3c0 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -1028,6 +1028,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_MPEG_VIDEO_HEVC_SPS:
return "HEVC Sequence Parameter Set";
> case V4L2_CID_MPEG_VIDEO_HEVC_PPS:
return "HEVC Picture Parameter Set";
> case V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS: return
"HEVC Slice Parameters";
> + case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS:
return "HEVC Decode Parameters";
> case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_MODE: return "HEVC
Decode Mode";
> case V4L2_CID_MPEG_VIDEO_HEVC_START_CODE: return
"HEVC Start Code";
>
> @@ -1482,6 +1483,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
> case V4L2_CID_MPEG_VIDEO_HEVC_SLICE_PARAMS:
> *type = V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS;
> break;
> + case V4L2_CID_MPEG_VIDEO_HEVC_DECODE_PARAMS:
> + *type = V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS;
> + break;
> case V4L2_CID_UNIT_CELL_SIZE:
> *type = V4L2_CTRL_TYPE_AREA;
> *flags |= V4L2_CTRL_FLAG_READ_ONLY;
> @@ -1833,6 +1837,7 @@ static int std_validate_compound(const struct
v4l2_ctrl *ctrl, u32 idx,
> struct v4l2_ctrl_hevc_sps *p_hevc_sps;
> struct v4l2_ctrl_hevc_pps *p_hevc_pps;
> struct v4l2_ctrl_hevc_slice_params *p_hevc_slice_params;
> + struct v4l2_ctrl_hevc_decode_params *p_hevc_decode_params;
> struct v4l2_area *area;
> void *p = ptr.p + idx * ctrl->elem_size;
> unsigned int i;
> @@ -2108,23 +2113,27 @@ static int std_validate_compound(const struct
v4l2_ctrl *ctrl, u32 idx,
> zero_padding(*p_hevc_pps);
> break;
>
> - case V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS:
> - p_hevc_slice_params = p;
> + case V4L2_CTRL_TYPE_HEVC_DECODE_PARAMS:
> + p_hevc_decode_params = p;
>
> - if (p_hevc_slice_params->num_active_dpb_entries >
> + if (p_hevc_decode_params->num_active_dpb_entries >
> V4L2_HEVC_DPB_ENTRIES_NUM_MAX)
> return -EINVAL;
>
> - zero_padding(p_hevc_slice_params->pred_weight_table);
> -
> - for (i = 0; i < p_hevc_slice_params-
>num_active_dpb_entries;
> + for (i = 0; i < p_hevc_decode_params-
>num_active_dpb_entries;
>i++) {
> struct v4l2_hevc_dpb_entry *dpb_entry =
> - &p_hevc_slice_params->dpb[i];
> + &p_hevc_decode_params->dpb[i];
>
> zero_padding(*dpb_entry);
> }
>
> + break;
> +
> + case V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS:
> + p_hevc_slice_params = p;
> +
> + zero_padding(p_hevc_slice_pa
Re: [PATCH v5 12/20] dt-bindings: rtc: sun6i: Add H616 compatible string
Hi! Dne sreda, 27. januar 2021 ob 18:24:52 CET je Andre Przywara napisal(a): > Add the obvious compatible name to the existing RTC binding, and pair > it with the existing H6 fallback compatible string, as the devices are > compatible. After close lookup I would disagree with this observation. Major difference is that H616 doesn't support usage of external 32768 Hz oscillator. It uses 24 MHz oscillator with divider for that case. Due to that change, whole logic for external oscillator should go out. Additionally, this logic overwrites default value in LOSC_CTRL register, which is not nice (there is no documentation for those bits). Best regards, Jernej > > Signed-off-by: Andre Przywara > Acked-by: Rob Herring > --- > .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31- rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > index b1b0ee769b71..4193e5813344 100644 > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > @@ -26,6 +26,9 @@ properties: >- const: allwinner,sun50i-a64-rtc >- const: allwinner,sun8i-h3-rtc >- const: allwinner,sun50i-h6-rtc > + - items: > + - const: allwinner,sun50i-h616-rtc > + - const: allwinner,sun50i-h6-rtc > >reg: > maxItems: 1 > -- > 2.17.5 > >
Re: Re: Re: [PATCH 2/5] drm/sun4i: tcon: set sync polarity for tcon1 channel
Dne petek, 05. februar 2021 ob 17:28:23 CET je Chen-Yu Tsai napisal(a):
> On Sat, Feb 6, 2021 at 12:21 AM Jernej Škrabec
wrote:
> >
> > Dne petek, 05. februar 2021 ob 17:01:30 CET je Maxime Ripard napisal(a):
> > > On Fri, Feb 05, 2021 at 11:21:22AM +0800, Chen-Yu Tsai wrote:
> > > > On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec
> > wrote:
> > > > >
> > > > > Channel 1 has polarity bits for vsync and hsync signals but driver
never
> > > > > sets them. It turns out that with pre-HDMI2 controllers seemingly
there
> > > > > is no issue if polarity is not set. However, with HDMI2 controllers
> > > > > (H6) there often comes to de-synchronization due to phase shift.
This
> > > > > causes flickering screen. It's safe to assume that similar issues
might
> > > > > happen also with pre-HDMI2 controllers.
> > > > >
> > > > > Solve issue with setting vsync and hsync polarity. Note that display
> > > > > stacks with tcon top have polarity bits actually in tcon0 polarity
> > > > > register.
> > > > >
> > > > > Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine
support")
> > > > > Tested-by: Andre Heider
> > > > > Signed-off-by: Jernej Skrabec
> > > > > ---
> > > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 24
> > > > > drivers/gpu/drm/sun4i/sun4i_tcon.h | 5 +
> > > > > 2 files changed, 29 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/
sun4i/
> > sun4i_tcon.c
> > > > > index 6b9af4c08cd6..0d132dae58c0 100644
> > > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > > @@ -672,6 +672,29 @@ static void sun4i_tcon1_mode_set(struct
sun4i_tcon
> > *tcon,
> > > > > SUN4I_TCON1_BASIC5_V_SYNC(vsync) |
> > > > > SUN4I_TCON1_BASIC5_H_SYNC(hsync));
> > > > >
> > > > > + /* Setup the polarity of sync signals */
> > > > > + if (tcon->quirks->polarity_in_ch0) {
> > > > > + val = 0;
> > > > > +
> > > > > + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> > > > > + val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
> > > > > +
> > > > > + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> > > > > + val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
> > > > > +
> > > > > + regmap_write(tcon->regs, SUN4I_TCON0_IO_POL_REG,
val);
> > > > > + } else {
> > > > > + val = SUN4I_TCON1_IO_POL_UNKNOWN;
> > > >
> > > > I think a comment for the origin of this is warranted.
> > >
> > > If it's anything like TCON0, it's the pixel clock polarity
> >
> > Hard to say, DW HDMI controller has "data enable" polarity along hsync and
> > vsync. It could be either or none of those.
> >
> > What should I write in comment? BSP drivers and documentation use only
generic
> > names like io2_inv.
>
> Just say that we don't know exactly what it is, but it is required for
things
> to work properly? Would be interesting to know what happens if you don't set
> this bit, but do set VSYNC/HSYNC polarity properly.
Nothing seems to happen - tested on H3 with HDMI (4k@30) and CVBS. At least I
didn't notice anything.
Best regards,
Jernej
Re: Re: [PATCH v3 1/9] media: hevc: Modify structures to follow H265 ITU spec
Hi Ezequiel, Dne četrtek, 25. februar 2021 ob 14:09:52 CET je Ezequiel Garcia napisal(a): > Hi Benjamin, > > Thanks for the good work. > > On Mon, 2021-02-22 at 13:23 +0100, Benjamin Gaignard wrote: > > The H.265 ITU specification (section 7.4) define the general > > slice segment header semantics. > > Modified/added fields are: > > - video_parameter_set_id: (7.4.3.1) identifies the VPS for > > reference by other syntax elements. > > - seq_parameter_set_id: (7.4.3.2.1) specifies the value of > > the vps_video_parameter_set_id of the active VPS. > > - chroma_format_idc: (7.4.3.2.1) specifies the chroma sampling > > relative to the luma sampling > > - pic_parameter_set_id: (7.4.3.3.1) identifies the PPS for > > reference by other syntax elements > > - num_ref_idx_l0_default_active_minus1: (7.4.3.3.1) specifies > > the inferred value of num_ref_idx_l0_active_minus1 > > - num_ref_idx_l1_default_active_minus1: (7.4.3.3.1) specifies > > the inferred value of num_ref_idx_l1_active_minus1 > > - slice_segment_addr: (7.4.7.1) specifies the address of > > the first coding tree block in the slice segment > > - num_entry_point_offsets: (7.4.7.1) specifies the number of > > entry_point_offset_minus1[ i ] syntax elements in the slice header > > > > Add HEVC decode params contains the information used in section > > "8.3 Slice decoding process" of the specification to let the hardware > > perform decoding of a slices. > > > > Adapt Cedrus driver according to these changes. > > > > Signed-off-by: Benjamin Gaignard > > --- > > version 3: > > - Add documentation about the new structuers and fields. > > > > version 2: > > - remove all change related to scaling > > - squash commits to a coherent split > > - be more verbose about the added fields > > > > .../media/v4l/ext-ctrls-codec.rst | 126 +++--- > > .../media/v4l/vidioc-queryctrl.rst| 6 + > > drivers/media/v4l2-core/v4l2-ctrls.c | 26 +++- > > drivers/staging/media/sunxi/cedrus/cedrus.c | 6 + > > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 + > > .../staging/media/sunxi/cedrus/cedrus_dec.c | 2 + > > .../staging/media/sunxi/cedrus/cedrus_h265.c | 6 +- > > include/media/hevc-ctrls.h| 45 +-- > > 8 files changed, 186 insertions(+), 32 deletions(-) > > > > diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/ Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > index 00944e97d638..5e6d77e858c0 100644 > > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > @@ -3109,6 +3109,15 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - > > :stub-columns: 0 > > :widths: 1 1 2 > > > > +* - __u8 > > + - ``video_parameter_set_id`` > > + - Identifies the VPS for reference by other syntax elements > > +* - __u8 > > + - ``seq_parameter_set_id̀`` > > + - Specifies the value of the vps_video_parameter_set_id of the active VPS > > +* - __u8 > > + - ``chroma_format_idc`` > > + - Specifies the chroma sampling relative to the luma sampling > > None of these fields seem needed for the Hantro G2 driver, > so I suggest you drop them for now. > > > * - __u16 > >- ``pic_width_in_luma_samples`` > >- > > @@ -3172,6 +3181,9 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - > > * - __u8 > >- ``chroma_format_idc`` > >- > > +* - __u8 > > + - ``num_slices`` > > + > > Not used, but also doesn't seem part of the SPS syntax. If we have to > pass the number of slices, we'll need another mechanism. > > > - > > * - __u64 > >- ``flags`` > >- See :ref:`Sequence Parameter Set Flags ` > > @@ -3231,9 +3243,18 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - > > :stub-columns: 0 > > :widths: 1 1 2 > > > > +* - __u8 > > + - ``pic_parameter_set_id`` > > + - Identifies the PPS for reference by other syntax elements > > Not used. > > > * - __u8 > >- ``num_extra_slice_header_bits`` > >- > > +* - __u8 > > + - ``num_ref_idx_l0_default_active_minus1`` > > + - Specifies the inferred value of num_ref_idx_l0_active_minus1 > > +* - __u8 > > + - ``num_ref_idx_l1_default_active_minus1`` > > + - Specifies the inferred value of num_ref_idx_l1_active_minus1 > > * - __s8 > >- ``init_qp_minus26`` > >- > > @@ -3342,6 +3363,12 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - > > * - ``V4L2_HEVC_PPS_FLAG_SLICE_SEGMENT_HEADER_EXTENSION_PRESENT`` > >- 0x0004 > >- > > +* - ``V4L2_HEVC_PPS_FLAG_DEBLOCKING_FILTER_CONTROL_PRESENT`` > > + - 0x0008 > > + - > > +* - ``V4L2_HEVC_PPS_FLAG_UNIFORM_SPACING`` > > + - 0x0010 > > + - > > > > I suggest to do all the PPS control changes in a separate patch, > feels easier to review
Re: Re: Re: [PATCH v3 1/9] media: hevc: Modify structures to follow H265 ITU spec
Dne četrtek, 25. februar 2021 ob 18:34:48 CET je Ezequiel Garcia napisal(a): > Hey Jernej, > > On Thu, 2021-02-25 at 18:01 +0100, Jernej Škrabec wrote: > > Hi Ezequiel, > > > > Dne četrtek, 25. februar 2021 ob 14:09:52 CET je Ezequiel Garcia napisal(a): > > > Hi Benjamin, > > > > > > Thanks for the good work. > > > > > > On Mon, 2021-02-22 at 13:23 +0100, Benjamin Gaignard wrote: > > > > The H.265 ITU specification (section 7.4) define the general > > > > slice segment header semantics. > > > > Modified/added fields are: > > > > - video_parameter_set_id: (7.4.3.1) identifies the VPS for > > > > reference by other syntax elements. > > > > - seq_parameter_set_id: (7.4.3.2.1) specifies the value of > > > > the vps_video_parameter_set_id of the active VPS. > > > > - chroma_format_idc: (7.4.3.2.1) specifies the chroma sampling > > > > relative to the luma sampling > > > > - pic_parameter_set_id: (7.4.3.3.1) identifies the PPS for > > > > reference by other syntax elements > > > > - num_ref_idx_l0_default_active_minus1: (7.4.3.3.1) specifies > > > > the inferred value of num_ref_idx_l0_active_minus1 > > > > - num_ref_idx_l1_default_active_minus1: (7.4.3.3.1) specifies > > > > the inferred value of num_ref_idx_l1_active_minus1 > > > > - slice_segment_addr: (7.4.7.1) specifies the address of > > > > the first coding tree block in the slice segment > > > > - num_entry_point_offsets: (7.4.7.1) specifies the number of > > > > entry_point_offset_minus1[ i ] syntax elements in the slice header > > > > > > > > Add HEVC decode params contains the information used in section > > > > "8.3 Slice decoding process" of the specification to let the hardware > > > > perform decoding of a slices. > > > > > > > > Adapt Cedrus driver according to these changes. > > > > > > > > Signed-off-by: Benjamin Gaignard > > > > --- > > > > version 3: > > > > - Add documentation about the new structuers and fields. > > > > > > > > version 2: > > > > - remove all change related to scaling > > > > - squash commits to a coherent split > > > > - be more verbose about the added fields > > > > > > > > .../media/v4l/ext-ctrls-codec.rst | 126 ++ +--- > > > > .../media/v4l/vidioc-queryctrl.rst| 6 + > > > > drivers/media/v4l2-core/v4l2-ctrls.c | 26 +++- > > > > drivers/staging/media/sunxi/cedrus/cedrus.c | 6 + > > > > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 + > > > > .../staging/media/sunxi/cedrus/cedrus_dec.c | 2 + > > > > .../staging/media/sunxi/cedrus/cedrus_h265.c | 6 +- > > > > include/media/hevc-ctrls.h| 45 +-- > > > > 8 files changed, 186 insertions(+), 32 deletions(-) > > > > > > > > diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/ > > Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > > index 00944e97d638..5e6d77e858c0 100644 > > > > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > > @@ -3109,6 +3109,15 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - > > > > :stub-columns: 0 > > > > :widths: 1 1 2 > > > > > > > > +* - __u8 > > > > + - ``video_parameter_set_id`` > > > > + - Identifies the VPS for reference by other syntax elements > > > > +* - __u8 > > > > + - ``seq_parameter_set_id̀`` > > > > + - Specifies the value of the vps_video_parameter_set_id of the > > active VPS > > > > +* - __u8 > > > > + - ``chroma_format_idc`` > > > > + - Specifies the chroma sampling relative to the luma sampling > > > > > > None of these fields seem needed for the Hantro G2 driver, > > > so I suggest you drop them for now. > > > > > > > * - __u16 > > > >- ``pic_width_in_luma_samples`` > > > >- > > > > @@ -3172,6 +3181,9 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - > > > > * - __u8 > > > >- ``chroma_format_idc`` > > > >- > > > &g
Re: [PATCH] media: cedrus: Add support for VP8 decoding
Dne sreda, 20. maj 2020 ob 23:43:40 CEST je Nicolas Dufresne napisal(a): > Le mercredi 20 mai 2020 à 23:01 +0200, Jernej Skrabec a écrit : > > VP8 in Cedrus shares same engine as H264. > > > > Note that it seems necessary to call bitstream parsing functions, > > to parse frame header, otherwise decoded image is garbage. This is > > contrary to what is driver supposed to do. However, values are not > > really used, so this might be acceptable. It's possible that bitstream > > Have you verified that all values passed through controls are not used > ? To remain a stateless driver, there is no requirement for parsed data > to be used, the only requirement is that the reference are used. > Otherwise doing parallel decoding of two stream of different stream > would be broken. Have you verified that parallel decoding is working as > expected ? I'm not sure if you understand what I meant. Although userspace app parses frame header and fills all data in VP8 control, driver parses frame header again, using HW bitstream parsing functionality in cedrus_read_header(). Without that second header parsing in HW, decoded image is garbage. Note that cedrus_read_header() discards all parsed values and relies on those provided in controls. This parsing doesn't cause any problems with parallel decoding or anything. It's done during frame decoding job, so it doesn't affect any state. It's just that we shouldn't need to parse header in driver because all data is already provided in controls. It seems that Cedrus core was never tested without that HW frame header parsing. I found out that HEVC and H264 frames can sometimes also be wrongly decoded if no bitstream parsing function is triggered in HW before final decoding. I spend a lot of time trying to avoid that header parsing, but I couldn't find any way around it. In another words, Cedrus VPU provides two functionalities - HW bitstream parsing (to speed up header parsing) and video decoding. One would thought that video decoding can be used independently, if all data from header is already known, but it can't be. Best regards, Jernej > > > parsing functions set some internal VPU state, which is later necessary > > for proper decoding. Biggest suspect is "VP8 probs update" trigger. > > > > Signed-off-by: Jernej Skrabec > > --- > > > > drivers/staging/media/sunxi/cedrus/Makefile | 3 +- > > drivers/staging/media/sunxi/cedrus/cedrus.c | 8 + > > drivers/staging/media/sunxi/cedrus/cedrus.h | 15 + > > .../staging/media/sunxi/cedrus/cedrus_dec.c | 5 + > > .../staging/media/sunxi/cedrus/cedrus_hw.c| 1 + > > .../staging/media/sunxi/cedrus/cedrus_regs.h | 80 ++ > > .../staging/media/sunxi/cedrus/cedrus_video.c | 9 + > > .../staging/media/sunxi/cedrus/cedrus_vp8.c | 699 ++ > > 8 files changed, 819 insertions(+), 1 deletion(-) > > create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_vp8.c
Re: [PATCH v2 01/14] media: uapi: h264: Update reference lists
Hi! Dne četrtek, 06. avgust 2020 ob 17:47:07 CEST je Paul Kocialkowski napisal(a): > Hi, > > On Thu 06 Aug 20, 12:12, Ezequiel Garcia wrote: > > From: Jernej Skrabec > > > > When dealing with with interlaced frames, reference lists must tell if > > each particular reference is meant for top or bottom field. This info > > is currently not provided at all in the H264 related controls. > > > > Make reference lists hold a structure which will also hold an > > enumerator type along index into DPB array. The enumerator must > > be used to specify if reference is for top or bottom field. > > > > Currently the only user of these lists is Cedrus which is just compile > > fixed here. Actual usage of will come in a following commit. > > Is there a particular reason we are adding this to the ref_pic_list[0-1] > instead of the DPB entries directly? Yes, it is. > > It feels nicer to avoid making the lists structs when the entries they are > referring to are already in a struct. I think this is the approach Kwiboo > took when adding support for fields in references some time ago. > > What do you think? It's different thing. I tried using that, but image wasn't decoded correctly. IMO this is also the same reason why VAAPI doesn't have indices to DPB and instead have full VAPictureH264 structure array for RefPicList0 and RefPicList1. VAAPI has also note here "/* See 8.2.4.2 */" but I need to check it... Best regards, Jernej > > Cheers, > > Paul > > > Signed-off-by: Jernej Skrabec > > Signed-off-by: Ezequiel Garcia > > --- > > v2: > > * As pointed out by Jonas, enum v4l2_h264_dpb_reference here. > > --- > > > > .../media/v4l/ext-ctrls-codec.rst | 44 ++- > > .../staging/media/sunxi/cedrus/cedrus_h264.c | 6 +-- > > include/media/h264-ctrls.h| 23 +++--- > > 3 files changed, 62 insertions(+), 11 deletions(-) > > > > diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index > > d0d506a444b1..f2b2a381369f 100644 > > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > @@ -1843,10 +1843,10 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type > > -> > > * - __u32 > > > >- ``slice_group_change_cycle`` > >- > > > > -* - __u8 > > +* - struct :c:type:`v4l2_h264_reference` > > > >- ``ref_pic_list0[32]`` > >- Reference picture list after applying the per-slice modifications > > > > -* - __u8 > > +* - struct :c:type:`v4l2_h264_reference` > > > >- ``ref_pic_list1[32]`` > >- Reference picture list after applying the per-slice modifications > > > > * - __u32 > > > > @@ -1926,6 +1926,46 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type > > - > > > >- ``chroma_offset[32][2]`` > >- > > > > +``Picture Reference`` > > + > > +.. c:type:: v4l2_h264_reference > > + > > +.. cssclass:: longtable > > + > > +.. flat-table:: struct v4l2_h264_reference > > +:header-rows: 0 > > +:stub-columns: 0 > > +:widths: 1 1 2 > > + > > +* - enum :c:type:`v4l2_h264_dpb_reference` > > + - ``reference`` > > + - Specifies how the DPB entry is referenced. > > +* - __u8 > > + - ``index`` > > + - Index into the :c:type:`v4l2_ctrl_h264_decode_params`.dpb array. > > + > > +.. c:type:: v4l2_h264_dpb_reference > > + > > +.. cssclass:: longtable > > + > > +.. flat-table:: > > +:header-rows: 0 > > +:stub-columns: 0 > > +:widths: 1 1 2 > > + > > +* - ``V4L2_H264_DPB_TOP_REF`` > > + - 0x1 > > + - The top field in field pair is used for > > +short-term reference. > > +* - ``V4L2_H264_DPB_BOTTOM_REF`` > > + - 0x2 > > + - The bottom field in field pair is used for > > +short-term reference. > > +* - ``V4L2_H264_DPB_FRAME_REF`` > > + - 0x3 > > + - The frame (or the top/bottom fields, if it's a field pair) > > +is used for short-term reference. > > + > > > > ``V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS (struct)`` > > > > Specifies the decode parameters (as extracted from the bitstream) > > for the associated H264 slice data. This includes the necessary > > > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c > > b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c index > > 54ee2aa423e2..cce527bbdf86 100644 > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c > > @@ -166,8 +166,8 @@ static void cedrus_write_frame_list(struct cedrus_ctx > > *ctx,> > > static void _cedrus_write_ref_list(struct cedrus_ctx *ctx, > > > >struct cedrus_run *run, > > > > - const u8 *ref_list, u8 num_ref, > > - enum cedrus_h264_sram_off sram) > >
Re: [PATCH v2 03/14] media: uapi: h264: Split prediction weight parameters
Dne nedelja, 09. avgust 2020 ob 15:55:50 CEST je Ezequiel Garcia napisal(a): > On Sat, 8 Aug 2020 at 18:01, Jonas Karlman wrote: > > On 2020-08-06 17:12, Ezequiel Garcia wrote: > > > The prediction weight parameters are only required under > > > certain conditions, which depend on slice header parameters. > > > > > > As specified in section 7.3.3 Slice header syntax, the prediction > > > weight table is present if: > > > > > > ((weighted_pred_flag && (slice_type == P || slice_type == SP)) || \ > > > (weighted_bipred_idc == 1 && slice_type == B)) > > > > Maybe a macro can be added to help check this contition? > > > > Something like this maybe: > > > > #define V4L2_H264_CTRL_PRED_WEIGHTS_REQUIRED(pps, slice) \ > > > > pps)->flags & V4L2_H264_PPS_FLAG_WEIGHTED_PRED) && \ > > > > ((slice)->slice_type == V4L2_H264_SLICE_TYPE_P || \ > > > >(slice)->slice_type == V4L2_H264_SLICE_TYPE_SP)) || \ > > > > ((pps)->weighted_bipred_idc == 1 && \ > > > > (slice)->slice_type == V4L2_H264_SLICE_TYPE_B)) > > Yeah, that could make sense. > > Note that the biggest value in having the prediction weight table > separated is to allow applications to skip setting this largish control, > reducing the amount of data that needs to be passed from userspace > -- especially when not needed :-) > > > > Given its size, it makes sense to move this table to its control, > > > so applications can avoid passing it if the slice doesn't specify it. > > > > > > Before this change struct v4l2_ctrl_h264_slice_params was 960 bytes. > > > With this change, it's 188 bytes and struct v4l2_ctrl_h264_pred_weight > > > is 772 bytes. > > > > > > Signed-off-by: Ezequiel Garcia > > > --- > > > v2: Fix missing Cedrus changes and mssing control declaration, > > > > > > as noted by Hans and Jernej. > > > > > > --- > > > > > > .../media/v4l/ext-ctrls-codec.rst | 19 --- > > > drivers/media/v4l2-core/v4l2-ctrls.c | 8 > > > drivers/staging/media/sunxi/cedrus/cedrus.c | 7 +++ > > > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 + > > > .../staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++ > > > .../staging/media/sunxi/cedrus/cedrus_h264.c | 6 ++ > > > include/media/h264-ctrls.h| 5 +++-- > > > include/media/v4l2-ctrls.h| 2 ++ > > > 8 files changed, 37 insertions(+), 13 deletions(-) > > > > > > diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index > > > d1438b1e259f..c36ce5a95fc5 100644 > > > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > @@ -1879,18 +1879,23 @@ enum > > > v4l2_mpeg_video_h264_hierarchical_coding_type -> > > > >- 0x0008 > > >- > > > > > > -``Prediction Weight Table`` > > > +``V4L2_CID_MPEG_VIDEO_H264_PRED_WEIGHTS (struct)`` > > > +Prediction weight table defined according to :ref:`h264`, > > > +section 7.4.3.2 "Prediction Weight Table Semantics". > > > +The prediction weight table must be passed by applications > > > +under the conditions explained in section 7.3.3 "Slice header > > > +syntax". > > > > > > -The bitstream parameters are defined according to :ref:`h264`, > > > -section 7.4.3.2 "Prediction Weight Table Semantics". For further > > > -documentation, refer to the above specification, unless there is > > > -an explicit comment stating otherwise. > > > +.. note:: > > > + > > > + This compound control is not yet part of the public kernel API > > > and > > > + it is expected to change. > > > > > > -.. c:type:: v4l2_h264_pred_weight_table > > > +.. c:type:: v4l2_ctrl_h264_pred_weights > > > > > > .. cssclass:: longtable > > > > > > -.. flat-table:: struct v4l2_h264_pred_weight_table > > > +.. flat-table:: struct v4l2_ctrl_h264_pred_weights > > > > > > :header-rows: 0 > > > :stub-columns: 0 > > > :widths: 1 1 2 > > > > > > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c > > > b/drivers/media/v4l2-core/v4l2-ctrls.c index 3f3fbcd60cc6..76c8dc8fb31c > > > 100644 > > > --- a/drivers/media/v4l2-core/v4l2-ctrls.c > > > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c > > > @@ -897,6 +897,7 @@ const char *v4l2_ctrl_get_name(u32 id) > > > > > > case V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS:return > > > "H264 Decode Parameters"; case > > > V4L2_CID_MPEG_VIDEO_H264_DECODE_MODE: return "H264 > > > Decode Mode"; case V4L2_CID_MPEG_VIDEO_H264_START_CODE: > > > return "H264 Start Code";> > > > > + case V4L2_CID_MPEG_VIDEO_H264_PRED_WEIGHTS: return > > > "H264 Prediction Weight Table";> > > > > case V4L2_CID_MPEG_VIDEO_MPEG2_LEVEL: return > > >
Re: [PATCH v2 03/14] media: uapi: h264: Split prediction weight parameters
Dne ponedeljek, 10. avgust 2020 ob 14:57:17 CEST je Ezequiel Garcia napisal(a): > On Sun, 2020-08-09 at 23:11 +0200, Jernej Škrabec wrote: > > Dne nedelja, 09. avgust 2020 ob 15:55:50 CEST je Ezequiel Garcia napisal(a): > > > On Sat, 8 Aug 2020 at 18:01, Jonas Karlman wrote: > > > > On 2020-08-06 17:12, Ezequiel Garcia wrote: > > > > > The prediction weight parameters are only required under > > > > > certain conditions, which depend on slice header parameters. > > > > > > > > > > As specified in section 7.3.3 Slice header syntax, the prediction > > > > > weight table is present if: > > > > > > > > > > ((weighted_pred_flag && (slice_type == P || slice_type == SP)) || \ > > > > > (weighted_bipred_idc == 1 && slice_type == B)) > > > > > > > > Maybe a macro can be added to help check this contition? > > > > > > > > Something like this maybe: > > > > > > > > #define V4L2_H264_CTRL_PRED_WEIGHTS_REQUIRED(pps, slice) \ > > > > > > > > pps)->flags & V4L2_H264_PPS_FLAG_WEIGHTED_PRED) && \ > > > > > > > > ((slice)->slice_type == V4L2_H264_SLICE_TYPE_P || \ > > > > > > > >(slice)->slice_type == V4L2_H264_SLICE_TYPE_SP)) || \ > > > > > > > > ((pps)->weighted_bipred_idc == 1 && \ > > > > > > > > (slice)->slice_type == V4L2_H264_SLICE_TYPE_B)) > > > > > > Yeah, that could make sense. > > > > > > Note that the biggest value in having the prediction weight table > > > separated is to allow applications to skip setting this largish > > > control, > > > reducing the amount of data that needs to be passed from userspace > > > -- especially when not needed :-) > > > > > > > > Given its size, it makes sense to move this table to its control, > > > > > so applications can avoid passing it if the slice doesn't specify > > > > > it. > > > > > > > > > > Before this change struct v4l2_ctrl_h264_slice_params was 960 bytes. > > > > > With this change, it's 188 bytes and struct > > > > > v4l2_ctrl_h264_pred_weight > > > > > is 772 bytes. > > > > > > > > > > Signed-off-by: Ezequiel Garcia > > > > > --- > > > > > v2: Fix missing Cedrus changes and mssing control declaration, > > > > > > > > > > as noted by Hans and Jernej. > > > > > > > > > > --- > > > > > > > > > > .../media/v4l/ext-ctrls-codec.rst | 19 > > > > > --- > > > > > drivers/media/v4l2-core/v4l2-ctrls.c | 8 > > > > > drivers/staging/media/sunxi/cedrus/cedrus.c | 7 +++ > > > > > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 + > > > > > .../staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++ > > > > > .../staging/media/sunxi/cedrus/cedrus_h264.c | 6 ++ > > > > > include/media/h264-ctrls.h| 5 +++-- > > > > > include/media/v4l2-ctrls.h| 2 ++ > > > > > 8 files changed, 37 insertions(+), 13 deletions(-) > > > > > > > > > > diff --git > > > > > a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > > > b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index > > > > > d1438b1e259f..c36ce5a95fc5 100644 > > > > > --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > > > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > > > > @@ -1879,18 +1879,23 @@ enum > > > > > v4l2_mpeg_video_h264_hierarchical_coding_type -> > > > > > > > > > > >- 0x0008 > > > > >- > > > > > > > > > > -``Prediction Weight Table`` > > > > > +``V4L2_CID_MPEG_VIDEO_H264_PRED_WEIGHTS (struct)`` > > > > > +Prediction weight table defined according to :ref:`h264`, > > > > > +section 7.4.3.2 "Prediction Weight Table Semantics". > > > > > +The prediction weight table must be passed by applications > > > > > +under the conditions explaine
Re: [PATCH v2 03/14] media: uapi: h264: Split prediction weight parameters
Dne ponedeljek, 10. avgust 2020 ob 21:30:59 CEST je Ezequiel Garcia napisal(a): > On Mon, 2020-08-10 at 19:05 +0200, Jernej Škrabec wrote: > > Dne ponedeljek, 10. avgust 2020 ob 14:57:17 CEST je Ezequiel Garcia > > > > napisal(a): > > > On Sun, 2020-08-09 at 23:11 +0200, Jernej Škrabec wrote: > > > > Dne nedelja, 09. avgust 2020 ob 15:55:50 CEST je Ezequiel Garcia > > > > napisal(a): > > > > > On Sat, 8 Aug 2020 at 18:01, Jonas Karlman wrote: > > > > > > On 2020-08-06 17:12, Ezequiel Garcia wrote: > > > > > > > The prediction weight parameters are only required under > > > > > > > certain conditions, which depend on slice header parameters. > > > > > > > > > > > > > > As specified in section 7.3.3 Slice header syntax, the > > > > > > > prediction > > > > > > > weight table is present if: > > > > > > > > > > > > > > ((weighted_pred_flag && (slice_type == P || slice_type == SP)) > > > > > > > || \ > > > > > > > (weighted_bipred_idc == 1 && slice_type == B)) > > > > > > > > > > > > Maybe a macro can be added to help check this contition? > > > > > > > > > > > > Something like this maybe: > > > > > > > > > > > > #define V4L2_H264_CTRL_PRED_WEIGHTS_REQUIRED(pps, slice) \ > > > > > > > > > > > > pps)->flags & V4L2_H264_PPS_FLAG_WEIGHTED_PRED) && \ > > > > > > > > > > > > ((slice)->slice_type == V4L2_H264_SLICE_TYPE_P || \ > > > > > > > > > > > >(slice)->slice_type == V4L2_H264_SLICE_TYPE_SP)) || \ > > > > > > > > > > > > ((pps)->weighted_bipred_idc == 1 && \ > > > > > > > > > > > > (slice)->slice_type == V4L2_H264_SLICE_TYPE_B)) > > > > > > > > > > Yeah, that could make sense. > > > > > > > > > > Note that the biggest value in having the prediction weight table > > > > > separated is to allow applications to skip setting this largish > > > > > control, > > > > > reducing the amount of data that needs to be passed from userspace > > > > > -- especially when not needed :-) > > > > > > > > > > > > Given its size, it makes sense to move this table to its > > > > > > > control, > > > > > > > so applications can avoid passing it if the slice doesn't > > > > > > > specify > > > > > > > it. > > > > > > > > > > > > > > Before this change struct v4l2_ctrl_h264_slice_params was 960 > > > > > > > bytes. > > > > > > > With this change, it's 188 bytes and struct > > > > > > > v4l2_ctrl_h264_pred_weight > > > > > > > is 772 bytes. > > > > > > > > > > > > > > Signed-off-by: Ezequiel Garcia > > > > > > > --- > > > > > > > v2: Fix missing Cedrus changes and mssing control declaration, > > > > > > > > > > > > > > as noted by Hans and Jernej. > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > .../media/v4l/ext-ctrls-codec.rst | 19 > > > > > > > --- > > > > > > > drivers/media/v4l2-core/v4l2-ctrls.c | 8 > > > > > > > drivers/staging/media/sunxi/cedrus/cedrus.c | 7 +++ > > > > > > > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 + > > > > > > > .../staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++ > > > > > > > .../staging/media/sunxi/cedrus/cedrus_h264.c | 6 ++ > > > > > > > include/media/h264-ctrls.h| 5 +++-- > > > > > > > include/media/v4l2-ctrls.h| 2 ++ > > > > > > > 8 files changed, 37 insertions(+), 13 deletions(-) > > > > > > > > > > > > > > diff --git > > > > > > > a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst > > >
Re: [PATCH] ARM: dts: sun8i-v3s: Add CSI0 MCLK pin definition
Hi!
Dne petek, 18. december 2020 ob 20:50:33 CET je Paul Kocialkowski napisal(a):
> This adds a device-tree definition for the CSI0 MCLK pin,
> which can be used for feeding MIPI CSI-2 sensors.
>
> Signed-off-by: Paul Kocialkowski
Is this used anywhere? Current policy is to add pin definitions only if any
user exists.
Best regards,
Jernej
> ---
> arch/arm/boot/dts/sun8i-v3s.dtsi | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi
> b/arch/arm/boot/dts/sun8i-v3s.dtsi index a9f5795d4e57..bff822b9fa01 100644
> --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> @@ -337,6 +337,12 @@ pio: pinctrl@1c20800 {
> interrupt-controller;
> #interrupt-cells = <3>;
>
> + /omit-if-no-ref/
> + csi0_mclk_pin: csi0-mclk-pin {
> + pins = "PE20";
> + function = "csi_mipi";
> + };
> +
> /omit-if-no-ref/
> csi1_8bit_pins: csi1-8bit-pins {
> pins = "PE0", "PE2", "PE3",
"PE8", "PE9",
Re: [PATCH v2 1/2] dt-bindings: pwm: allwinner: Add V3s compatible description
Hi! Dne petek, 18. december 2020 ob 21:54:35 CET je Paul Kocialkowski napisal(a): > Introduce bindings description for the V3s PWM, which is > register-compatible with the A20 PWM. > > Signed-off-by: Paul Kocialkowski This is meant to be used together with V3s PWM patch you recently send? Can you please resend them together, with fixed compatible in DT node? Currently it's not clear why this patch is needed and PWM patch will need fix anyway. Best regards, Jernej > --- > .../devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml > b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml index > 7dcab2bf8128..04ff708fdc86 100644 > --- a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml > +++ b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml > @@ -24,6 +24,9 @@ properties: >- items: >- const: allwinner,sun8i-a83t-pwm >- const: allwinner,sun8i-h3-pwm > + - items: > + - const: allwinner,sun8i-v3s-pwm > + - const: allwinner,sun7i-a20-pwm >- items: >- const: allwinner,sun50i-a64-pwm >- const: allwinner,sun5i-a13-pwm
Re: [PATCH RESEND] ARM: configs: sunxi: enable brcm wireless
Hi! Dne nedelja, 27. december 2020 ob 21:00:00 CET je Corentin Labbe napisal(a): > Lot of sunxi boards have BRCM wireless device, so let's enable necessary > options for it in our defconfig. Idea is good but modules (=m) instead of build in (=y) would be better. As you said, not all boards have such wifi and there is no need to make kernel binary bigger. Best regards, Jernej > > Signed-off-by: Corentin Labbe > --- > arch/arm/configs/sunxi_defconfig | 23 ++- > 1 file changed, 22 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/configs/sunxi_defconfig > b/arch/arm/configs/sunxi_defconfig index a60c134c5e04..4891aefdef7d 100644 > --- a/arch/arm/configs/sunxi_defconfig > +++ b/arch/arm/configs/sunxi_defconfig > @@ -52,7 +52,28 @@ CONFIG_STMMAC_ETH=y > # CONFIG_NET_VENDOR_WIZNET is not set > CONFIG_MICREL_PHY=y > CONFIG_REALTEK_PHY=y > -# CONFIG_WLAN is not set > +CONFIG_WLAN=y > +# CONFIG_WLAN_VENDOR_ADMTEK is not set > +# CONFIG_WLAN_VENDOR_ATH is not set > +# CONFIG_WLAN_VENDOR_ATMEL is not set > +CONFIG_WLAN_VENDOR_BROADCOM=y > +# CONFIG_WLAN_VENDOR_CISCO is not set > +# CONFIG_WLAN_VENDOR_INTEL is not set > +# CONFIG_WLAN_VENDOR_INTERSIL is not set > +# CONFIG_WLAN_VENDOR_MARVELL is not set > +# CONFIG_WLAN_VENDOR_MEDIATEK is not set > +# CONFIG_WLAN_VENDOR_MICROCHIP is not set > +# CONFIG_WLAN_VENDOR_RALINK is not set > +# CONFIG_WLAN_VENDOR_REALTEK is not set > +# CONFIG_WLAN_VENDOR_RSI is not set > +# CONFIG_WLAN_VENDOR_ST is not set > +# CONFIG_WLAN_VENDOR_TI is not set > +# CONFIG_WLAN_VENDOR_ZYDAS is not set > +# CONFIG_WLAN_VENDOR_QUANTENNA is not set > +CONFIG_CFG80211=y > +CONFIG_CFG80211_WEXT=y > +CONFIG_MAC80211=y > +CONFIG_BRCMFMAC=y > CONFIG_INPUT_EVDEV=y > CONFIG_KEYBOARD_SUN4I_LRADC=y > # CONFIG_INPUT_MOUSE is not set
Re: [PATCH 4/5] arm64: dts: allwinner: Add sun4i MMIO timer nodes
Hi!
Dne ponedeljek, 15. marec 2021 ob 05:32:49 CET je Samuel Holland napisal(a):
> For a CPU to enter an idle state, there must be some timer which can
> trigger an IRQ to wake it back up. The local ARM architectural timer is
> not sufficient, because that timer stops when the CPU is powered down.
> Some other CPU's ARM architectural timer can be used, but this prevents
> that other CPU from entering an idle state. So to allow all CPUs to
> enter an idle state at the same time, some MMIO timer must be available
> that is not tied to any CPU.
>
> The basic "sun4i" timer seems most appropriate for this purpose due to
> its moderate rate, balancing precision and power consumption.
>
> Signed-off-by: Samuel Holland
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +
> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 9 +
> arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 +
> 3 files changed, 27 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi index
> 33df866f6ea9..64e8b4a372cc 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -905,6 +905,15 @@ uart4_rts_cts_pins: uart4-rts-cts-pins {
> };
> };
>
> + timer@1c20c00 {
> + compatible = "allwinner,sun50i-a64-timer",
> + "allwinner,sun8i-a23-timer";
> + reg = <0x01c20c00 0xa0>;
> + interrupts = ,
> + ;
> + clocks = <&osc24M>;
> + };
> +
> wdt0: watchdog@1c20ca0 {
> compatible = "allwinner,sun50i-a64-wdt",
>"allwinner,sun6i-a31-wdt";
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi index
> 62334054c710..9ba3b30e11fa 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> @@ -332,6 +332,15 @@ cpu_speed_grade: cpu-speed-grade@1c {
> };
> };
>
> + timer@3009000 {
> + compatible = "allwinner,sun50i-h6-timer",
> + "allwinner,sun8i-a23-timer";
> + reg = <0x03009000 0xa0>;
> + interrupts = ,
> + ;
> + clocks = <&osc24M>;
> + };
> +
> watchdog: watchdog@30090a0 {
> compatible = "allwinner,sun50i-h6-wdt",
>"allwinner,sun6i-a31-wdt";
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi index
> c277b53f94ea..ff55712ce96e 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
This file does not exist yet upstream.
Best regards,
Jernej
> @@ -128,6 +128,15 @@ ccu: clock@3001000 {
> #reset-cells = <1>;
> };
>
> + timer@3009000 {
> + compatible = "allwinner,sun50i-h616-timer",
> + "allwinner,sun8i-a23-timer";
> + reg = <0x03009000 0xa0>;
> + interrupts = ,
> + ;
> + clocks = <&osc24M>;
> + };
> +
> watchdog: watchdog@30090a0 {
> compatible = "allwinner,sun50i-h616-wdt",
>"allwinner,sun6i-a31-wdt";
Re: [PATCH 4/8] iommu/sun50i: Fix spelling mistake "consits" -> "consists"
Hi! Dne petek, 26. marec 2021 ob 07:24:08 CEST je Zhen Lei napisal(a): > There is a spelling mistake in a comment, fix it. > > Signed-off-by: Zhen Lei > --- > drivers/iommu/sun50i-iommu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC sub-driver
CC Hans Verkuil Dne petek, 16. april 2021 ob 13:38:59 CEST je Neil Armstrong napisal(a): > On 16/04/2021 11:58, Laurent Pinchart wrote: > > Hi Neil, > > > > On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote: > >> This adds DW-HDMI driver a glue option to disable loading of the CEC > >> sub-driver. > >> > >> On some SoCs, the CEC functionality is enabled in the IP config bits, but > >> the CEC bus is non-functional like on Amlogic SoCs, where the CEC config > >> bit is set but the DW-HDMI CEC signal is not connected to a physical > >> pin, leading to some confusion when the DW-HDMI CEC controller can't > >> communicate on the bus.> > > If we can't trust the CEC config bit, would it be better to not use it > > at all, and instead let each platform glue logic tell whether to enable > > CEC or not ? > > Actually, the CEC config bit is right, the HW exists and should be > functional, but this bit doesn't tell if the CEC signal is connected to > something. I'm in favour of Neil's solution. Currently we have only one exception. > > This lies in the IP integration, like other bits under the > "amlogic,meson-*-dw-hdmi" umbrella. > > The first attempt was by Hans using DT, but adding a property in DT for a > vendor specific compatible doesn't make sense. Another idea would be to > describe the CEC signal endpoint like we do for video signal, but I think > this is out of scope and this solution is much simpler and straightforward, > and it's more an exception than a general use case to solve. Note that we still need DT property for disabling CEC. I have one Allwinner H3 board where board designer decided to use GPIO CEC implementation instead of DW HDMI one (vendor Linux doesn't implement DW HDMI CEC driver). Other H3 boards happily use DW HDMI CEC. Best regards, Jernej > > Neil > > >> Jernej Skrabec (1): > >> drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC > >> > >> driver > >> > >> Neil Armstrong (1): > >> drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver > >> > >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > >> drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 + > >> include/drm/bridge/dw_hdmi.h | 2 ++ > >> 3 files changed, 4 insertions(+), 1 deletion(-)
Re: [PATCH -next] media: sunxi: sun8i-rotate: fix PM reference leak in rotate_start_streaming()
Dne petek, 09. april 2021 ob 08:46:58 CEST je Xiang Yang napisal(a): > pm_runtime_get_sync will increment pm usage counter even it failed. > Forgetting to putting operation will result in reference leak here. > Fix it by replacing it with pm_runtime_resume_and_get to keep usage > counter balanced. > > Reported-by: Hulk Robot > Signed-off-by: Xiang Yang Acked-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH -next] media: sun8i: Fix PM reference leak in deinterlace_start_streaming()
Dne četrtek, 08. april 2021 ob 15:36:30 CEST je Lu Jialin napisal(a): > > pm_runtime_get_sync will increment pm usage counter even it failed. > Forgetting to putting operation will result in reference leak here. > Fix it by replacing it with pm_runtime_resume_and_get to keep usage > counter balanced. > > Reported-by: Hulk Robot > Signed-off-by: Lu Jialin Acked-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH v2] drm/sun4i: dw-hdmi: fix error return code in sun8i_dw_hdmi_bind()
Dne ponedeljek, 16. november 2020 ob 02:09:29 CET je Xiongfeng Wang
napisal(a):
> Fix to return a negative error code from the error handling case instead
> of 0 in function sun8i_dw_hdmi_bind().
>
> Fixes: b7c7436a5ff0 ("drm/sun4i: Implement A83T HDMI driver")
> Reported-by: Hulk Robot
> Signed-off-by: Xiongfeng Wang
> Reviewed-by: Jernej Skrabec
Applied to drm-misc-fixes, thanks!
In future, please CC all people given by get_maintainer.pl script. In this
case you missed Maxime Ripard and Chen-Yu Tsai.
Best regards,
Jernej
Re: [PATCH v2 2/9] media: cedrus: h264: Support profile and level controls
Hi Ezequiel,
sorry for late review.
First of all, this patch doesn't break anything. However, see comment below.
Dne petek, 13. november 2020 ob 22:51:14 CET je Ezequiel Garcia napisal(a):
> Cedrus supports H.264 profiles from Baseline to High,
> up to Level 5.1, except for the Extended profile
>
> Expose the V4L2_CID_MPEG_VIDEO_H264_PROFILE and
> V4L2_CID_MPEG_VIDEO_H264_LEVEL so that userspace can
> query the driver for the supported profiles and levels.
>
> Signed-off-by: Ezequiel Garcia
> ---
> drivers/staging/media/sunxi/cedrus/cedrus.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/
media/sunxi/cedrus/cedrus.c
> index 9a102b7c1bb9..8b0e97752d27 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> @@ -103,6 +103,27 @@ static const struct cedrus_control cedrus_controls[] =
{
> .codec = CEDRUS_CODEC_H264,
> .required = false,
> },
> + {
> + .cfg = {
> + .id =
V4L2_CID_MPEG_VIDEO_H264_PROFILE,
> + .min=
V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE,
> + .def=
V4L2_MPEG_VIDEO_H264_PROFILE_MAIN,
> + .max=
V4L2_MPEG_VIDEO_H264_PROFILE_HIGH,
> + .menu_skip_mask =
> +
BIT(V4L2_MPEG_VIDEO_H264_PROFILE_EXTENDED),
> + },
> + .codec = CEDRUS_CODEC_H264,
> + .required = false,
> + },
> + {
> + .cfg = {
> + .id = V4L2_CID_MPEG_VIDEO_H264_LEVEL,
> + .min = V4L2_MPEG_VIDEO_H264_LEVEL_1_0,
> + .max = V4L2_MPEG_VIDEO_H264_LEVEL_5_1,
I went through several datasheets and only newer ones (H6, H616) state max.
supported level, which is 4.2. Please change it in next revision.
After that, you can add
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> + },
> + .codec = CEDRUS_CODEC_H264,
> + .required = false,
> + },
> {
> .cfg = {
> .id = V4L2_CID_MPEG_VIDEO_HEVC_SPS,
> --
> 2.27.0
>
>
Re: Re: [PATCH v2 2/9] media: cedrus: h264: Support profile and level controls
Dne torek, 17. november 2020 ob 20:40:09 CET je Ezequiel Garcia napisal(a):
> On Tue, 2020-11-17 at 20:24 +0100, Jernej Škrabec wrote:
> > Hi Ezequiel,
> >
> > sorry for late review.
> >
> > First of all, this patch doesn't break anything. However, see comment
below.
> >
> > Dne petek, 13. november 2020 ob 22:51:14 CET je Ezequiel Garcia
napisal(a):
> > > Cedrus supports H.264 profiles from Baseline to High,
> > > up to Level 5.1, except for the Extended profile
> > >
> > > Expose the V4L2_CID_MPEG_VIDEO_H264_PROFILE and
> > > V4L2_CID_MPEG_VIDEO_H264_LEVEL so that userspace can
> > > query the driver for the supported profiles and levels.
> > >
> > > Signed-off-by: Ezequiel Garcia
> > > ---
> > > drivers/staging/media/sunxi/cedrus/cedrus.c | 21 +
> > > 1 file changed, 21 insertions(+)
> > >
> > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/
staging/
> > media/sunxi/cedrus/cedrus.c
> > > index 9a102b7c1bb9..8b0e97752d27 100644
> > > --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> > > @@ -103,6 +103,27 @@ static const struct cedrus_control
cedrus_controls[] =
> > {
> > > .codec = CEDRUS_CODEC_H264,
> > > .required = false,
> > > },
> > > + {
> > > + .cfg = {
> > > + .id =
> > V4L2_CID_MPEG_VIDEO_H264_PROFILE,
> > > + .min=
> > V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE,
> > > + .def=
> > V4L2_MPEG_VIDEO_H264_PROFILE_MAIN,
> > > + .max=
> > V4L2_MPEG_VIDEO_H264_PROFILE_HIGH,
> > > + .menu_skip_mask =
> > > +
> > BIT(V4L2_MPEG_VIDEO_H264_PROFILE_EXTENDED),
> > > + },
> > > + .codec = CEDRUS_CODEC_H264,
> > > + .required = false,
> > > + },
> > > + {
> > > + .cfg = {
> > > + .id = V4L2_CID_MPEG_VIDEO_H264_LEVEL,
> > > + .min = V4L2_MPEG_VIDEO_H264_LEVEL_1_0,
> > > + .max = V4L2_MPEG_VIDEO_H264_LEVEL_5_1,
> >
> > I went through several datasheets and only newer ones (H6, H616) state
max.
> > supported level, which is 4.2. Please change it in next revision.
> >
> > After that, you can add
> > Reviewed-by: Jernej Skrabec
> >
>
> Note that I used level 5.1 based on a commit from you:
> """
> media: cedrus: h264: Fix 4K decoding on H6
>
> Due to unknown reason, H6 needs larger intraprediction buffer for 4K
> videos than other SoCs. This was discovered by playing 4096x2304 video,
> which is maximum what H6 VPU is supposed to support.
> """
>
> I guessed this meant it supported level 5 or higher.
> (Now that I think about it, I meant at least H6, does).
>
> According to https://en.wikipedia.org/wiki/Advanced_Video_Coding#Levels,
> level 4.2 is up to 2,048×1,080@60.0.
Strange, then I guess datasheet is wrong (wouldn't be first time).
Unfortunatelly there is no documentation for Cedrus capabilities, so
everything is either educated guess or tested on HW. Documentation for older
than H6 SoCs always mention only 1080p @ 60fps limit, even though several of
them are capable of decoding 4K H264 videos (I'm not sure about max. fps
though).
>
> Frankly, I'm open to put whatever value makes you happy.
To be honest, I'm not sure what is correct value here. It may depend on Cedrus
core variant.
Best regards,
Jernej
>
> Thanks,
> Ezequiel
>
> > Best regards,
> > Jernej
> >
> > > + },
> > > + .codec = CEDRUS_CODEC_H264,
> > > + .required = false,
> > > + },
> > > {
> > > .cfg = {
> > > .id = V4L2_CID_MPEG_VIDEO_HEVC_SPS,
> > > --
> > > 2.27.0
> > >
> > >
> >
> >
>
>
>
Re: [linux-sunxi] [PATCH 5/8] clk: sunxi-ng: Add support for the Allwinner H616 CCU
Dne sreda, 09. december 2020 ob 22:35:51 CET je André Przywara napisal(a):
> On 09/12/2020 14:33, Clément Péron wrote:
>
> Hi,
>
> > I try to review this, and compare against the vendor Kernel>
> >
> > On Wed, 2 Dec 2020 at 14:54, Andre Przywara
wrote:
> >> While the clocks are fairly similar to the H6, many differ in tiny
> >> details, so a separate clock driver seems indicated.
> >>
> >> Derived from the H6 clock driver, and adjusted according to the manual.
> >>
> >> Signed-off-by: Andre Przywara
> >> ---
> >>
> >> drivers/clk/sunxi-ng/Kconfig|7 +-
> >> drivers/clk/sunxi-ng/Makefile |1 +
> >> drivers/clk/sunxi-ng/ccu-sun50i-h616.c | 1134 +++
> >> drivers/clk/sunxi-ng/ccu-sun50i-h616.h | 58 +
> >> include/dt-bindings/clock/sun50i-h616-ccu.h | 110 ++
> >> include/dt-bindings/reset/sun50i-h616-ccu.h | 67 ++
> >> 6 files changed, 1376 insertions(+), 1 deletion(-)
> >> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> >> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-h616.h
> >> create mode 100644 include/dt-bindings/clock/sun50i-h616-ccu.h
> >> create mode 100644 include/dt-bindings/reset/sun50i-h616-ccu.h
> >>
> >> diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
> >> index ce5f5847d5d3..cd46d8853876 100644
> >> --- a/drivers/clk/sunxi-ng/Kconfig
> >> +++ b/drivers/clk/sunxi-ng/Kconfig
> >> @@ -32,8 +32,13 @@ config SUN50I_H6_CCU
> >>
> >> default ARM64 && ARCH_SUNXI
> >> depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
> >>
> >> +config SUN50I_H616_CCU
> >> + bool "Support for the Allwinner H616 CCU"
> >> + default ARM64 && ARCH_SUNXI
> >> + depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
> >> +
> >>
> >> config SUN50I_H6_R_CCU
> >>
> >> - bool "Support for the Allwinner H6 PRCM CCU"
> >> + bool "Support for the Allwinner H6 and H616 PRCM CCU"
> >>
> >> default ARM64 && ARCH_SUNXI
> >> depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
> >>
> >> diff --git a/drivers/clk/sunxi-ng/Makefile
> >> b/drivers/clk/sunxi-ng/Makefile
> >> index 3eb5cff40eac..96c324306d97 100644
> >> --- a/drivers/clk/sunxi-ng/Makefile
> >> +++ b/drivers/clk/sunxi-ng/Makefile
> >> @@ -26,6 +26,7 @@ obj-$(CONFIG_SUN50I_A64_CCU) += ccu-sun50i-a64.o
> >>
> >> obj-$(CONFIG_SUN50I_A100_CCU) += ccu-sun50i-a100.o
> >> obj-$(CONFIG_SUN50I_A100_R_CCU)+= ccu-sun50i-a100-r.o
> >> obj-$(CONFIG_SUN50I_H6_CCU)+= ccu-sun50i-h6.o
> >>
> >> +obj-$(CONFIG_SUN50I_H616_CCU) += ccu-sun50i-h616.o
> >>
> >> obj-$(CONFIG_SUN50I_H6_R_CCU) += ccu-sun50i-h6-r.o
> >> obj-$(CONFIG_SUN4I_A10_CCU)+= ccu-sun4i-a10.o
> >> obj-$(CONFIG_SUN5I_CCU)+= ccu-sun5i.o
> >>
> >> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> >> b/drivers/clk/sunxi-ng/ccu-sun50i-h616.c new file mode 100644
> >> index ..3fbb258f0354
> >> --- /dev/null
> >> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> >> @@ -0,0 +1,1134 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/*
> >> + * Copyright (c) 2020 Arm Ltd.
> >> + * Based on the H6 CCU driver, which is:
> >> + * Copyright (c) 2017 Icenowy Zheng
> >> + */
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#include "ccu_common.h"
> >> +#include "ccu_reset.h"
> >> +
> >> +#include "ccu_div.h"
> >> +#include "ccu_gate.h"
> >> +#include "ccu_mp.h"
> >> +#include "ccu_mult.h"
> >> +#include "ccu_nk.h"
> >> +#include "ccu_nkm.h"
> >> +#include "ccu_nkmp.h"
> >> +#include "ccu_nm.h"
> >> +
> >> +#include "ccu-sun50i-h616.h"
> >> +
> >> +/*
> >> + * The CPU PLL is actually NP clock, with P being /1, /2 or /4. However
> >> + * P should only be used for output frequencies lower than 288 MHz.
> >> + *
> >> + * For now we can just model it as a multiplier clock, and force P to
> >> /1.
> >> + *
> >> + * The M factor is present in the register's description, but not in the
> >> + * frequency formula, and it's documented as "M is only used for
> >> backdoor
> >> + * testing", so it's not modelled and then force to 0.
> >> + */
> >> +#define SUN50I_H616_PLL_CPUX_REG 0x000
> >> +static struct ccu_mult pll_cpux_clk = {
> >> + .enable = BIT(31),
> >> + .lock = BIT(28),
> >> + .mult = _SUNXI_CCU_MULT_MIN(8, 8, 12),
> >> + .common = {
> >> + .reg= 0x000,
> >> + .hw.init= CLK_HW_INIT("pll-cpux", "osc24M",
> >> + &ccu_mult_ops,
> >> + CLK_SET_RATE_UNGATE),
> >> + },
> >> +};
> >> +
> >> +/* Some PLLs are input * N / div1 / P. Model them as NKMP with no K */
> >> +#define SUN50I_H616_PLL_DDR0_REG 0x010
> >> +static struct ccu_nkmp pll_ddr0_clk = {
> >> + .enable = BIT(31),
> >> + .lock = BIT(28),
> >> + .n = _SUNXI
Re: [linux-sunxi] [PATCH 2/8] pinctrl: sunxi: Add support for the Allwinner H616 pin controller
Dne nedelja, 06. december 2020 ob 13:32:49 CET je Clément Péron napisal(a):
> Hi Andre,
>
> On Wed, 2 Dec 2020 at 14:54, Andre Przywara wrote:
> > Port A is used for an internal connection to some analogue circuitry
> > which looks like an AC200 IP (as in the H6), though this is not
> > mentioned in the manual.
> >
> > Signed-off-by: Andre Przywara
> > ---
> >
> > drivers/pinctrl/sunxi/Kconfig | 5 +
> > drivers/pinctrl/sunxi/Makefile | 1 +
> > drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c | 549
> > 3 files changed, 555 insertions(+)
> > create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
> >
> > diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
> > index 593293584ecc..73e88ce71a48 100644
> > --- a/drivers/pinctrl/sunxi/Kconfig
> > +++ b/drivers/pinctrl/sunxi/Kconfig
> > @@ -119,4 +119,9 @@ config PINCTRL_SUN50I_H6_R
> >
> > default ARM64 && ARCH_SUNXI
> > select PINCTRL_SUNXI
> >
> > +config PINCTRL_SUN50I_H616
> > + bool "Support for the Allwinner H616 PIO"
> > + default ARM64 && ARCH_SUNXI
> > + select PINCTRL_SUNXI
> > +
> >
> > endif
> >
> > diff --git a/drivers/pinctrl/sunxi/Makefile
> > b/drivers/pinctrl/sunxi/Makefile index 8b7ff0dc3bdf..5359327a3c8f 100644
> > --- a/drivers/pinctrl/sunxi/Makefile
> > +++ b/drivers/pinctrl/sunxi/Makefile
> > @@ -23,5 +23,6 @@ obj-$(CONFIG_PINCTRL_SUN8I_V3S) +=
> > pinctrl-sun8i-v3s.o>
> > obj-$(CONFIG_PINCTRL_SUN50I_H5)+= pinctrl-sun50i-h5.o
> > obj-$(CONFIG_PINCTRL_SUN50I_H6)+= pinctrl-sun50i-h6.o
> > obj-$(CONFIG_PINCTRL_SUN50I_H6_R) += pinctrl-sun50i-h6-r.o
> >
> > +obj-$(CONFIG_PINCTRL_SUN50I_H616) += pinctrl-sun50i-h616.o
> >
> > obj-$(CONFIG_PINCTRL_SUN9I_A80)+= pinctrl-sun9i-a80.o
> > obj-$(CONFIG_PINCTRL_SUN9I_A80_R) += pinctrl-sun9i-a80-r.o
> >
> > diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
> > b/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c new file mode 100644
> > index ..734f63eb08dd
> > --- /dev/null
> > +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
> > @@ -0,0 +1,549 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Allwinner H616 SoC pinctrl driver.
> > + *
> > + * Copyright (C) 2020 Arm Ltd.
> > + * based on the H6 pinctrl driver
> > + * Copyright (C) 2017 Icenowy Zheng
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "pinctrl-sunxi.h"
> > +
> > +static const struct sunxi_desc_pin h616_pins[] = {
> > + /* Internal connection to the AC200 part */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 0),
> > + SUNXI_FUNCTION(0x2, "emac1")), /* ERXD1 */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 1),
> > + SUNXI_FUNCTION(0x2, "emac1")), /* ERXD0 */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 2),
> > + SUNXI_FUNCTION(0x2, "emac1")), /* ECRS_DV */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 3),
> > + SUNXI_FUNCTION(0x2, "emac1")), /* ERXERR */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 4),
> > + SUNXI_FUNCTION(0x2, "emac1")), /* ETXD1 */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 5),
> > + SUNXI_FUNCTION(0x2, "emac1")), /* ETXD0 */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 6),
> > + SUNXI_FUNCTION(0x2, "emac1")), /* ETXCK */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 7),
> > + SUNXI_FUNCTION(0x2, "emac1")), /* ETXEN */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 8),
> > + SUNXI_FUNCTION(0x2, "emac1")), /* EMDC */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 9),
> > + SUNXI_FUNCTION(0x2, "emac1")), /* EMDIO */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 10),
> > + SUNXI_FUNCTION(0x2, "i2c3")), /* SCK */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 11),
> > + SUNXI_FUNCTION(0x2, "i2c3")), /* SDA */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 12),
> > + SUNXI_FUNCTION(0x2, "pwm5")),
> > + /* Hole */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0),
> > + SUNXI_FUNCTION(0x0, "gpio_in"),
> > + SUNXI_FUNCTION(0x1, "gpio_out"),
> > + SUNXI_FUNCTION(0x2, "nand0"), /* WE */
> > + SUNXI_FUNCTION(0x3, "mmc2"), /* DS */
> > + SUNXI_FUNCTION(0x4, "spi0"), /* CLK */
> > + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)), /* PC_EINT0 */
> > + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 1),
> > + SUNXI_FUNCTION(0x0, "gpio_in"),
> > + SUNXI_FUNCTION(0x1, "gpio_out"),
> > + SUNXI_FUNCTION(0x2, "nand0"), /* ALE */
> > + SUNXI_FUNCTION(0x3, "mmc2"), /* RST */
> > + SUNXI_FUNCTION_IRQ_B
Re: [PATCH v4 00/13] Stateless H.264 de-staging
Hi! Dne ponedeljek, 23. november 2020 ob 15:39:47 CET je Ezequiel Garcia napisal(a): > Seems we are converging, as this iteration is really small. > > Just like v3, this iteration (plus a patch for VP8 VP8_FRAME_HEADER initialization, > which I'll send shortly) passes v4l2-compliance with no failures. > > As an additional test, Fluendo's JVT-AVC_V1 conformance test [1] passes with > score 72/135, for the Hantro driver on i.MX8MQ (Hantro G1 VPU). > Considering the Hantro driver only supports 4:2:0 and 4:0:0, this score > looks quite good. > > [1] https://github.com/fluendo/fluster/ Tested with ffmpeg/kodi stack on Allwinner R40 with different samples which use different H264 features and works without any problem. You can add Tested-by: Jernej Skrabec for whole series. Best regards, Jernej > > Thanks, > Ezequiel > > v4: > * Minor documentation fixes. > * Remove media/h264-ctrls.h, which was missing before. > * Thanks to feedback from Jernej, std_validation_compound > is now more complete, initializing non-present syntax elements. > v3: > * Dropped level control from Cedrus, as agreed. > * Add support for H264 stateless controls in std_log and std_validate_compound. > * Added a ctrl debug error message, to help debug validation issues. > * Style minor fixes as requested by Hans. > v2: > * Split destage changes in several patches so it's easier to review. > * Added missing changes to drivers/media/v4l2-core/v4l2-ctrls.c. > * Renamed V4L2_CID_CODEC_CX2341X_ and V4L2_CID_MPEG_MFC51_ > * Moved the compatibility macros for MPEG to the end of the header. > > Ezequiel Garcia (12): > media: ctrls: Add validate failure debug message > media: cedrus: h264: Support profile controls > media: Rename stateful codec control macros > media: Clean stateless control includes > media: uapi: h264: Add profile_idc macros > media: controls: Validate H264 stateless controls > media: controls: Add the stateless codec control class > media: uapi: Move parsed H264 pixel format out of staging > media: uapi: Move the H264 stateless control types out of staging > media: controls: Log H264 stateless controls in .std_log > media: uapi: move H264 stateless controls out of staging > media: docs: Move the H264 stateless codec uAPI > > Jonas Karlman (1): > media: rkvdec: h264: Support profile and level controls > > .../userspace-api/media/v4l/common.rst| 1 + > .../userspace-api/media/v4l/dev-mem2mem.rst | 2 +- > .../media/v4l/ext-ctrls-codec-stateless.rst | 674 +++ > .../media/v4l/ext-ctrls-codec.rst | 696 +-- > .../media/v4l/extended-controls.rst | 9 +- > .../media/v4l/pixfmt-compressed.rst | 21 +- > .../media/v4l/vidioc-g-ext-ctrls.rst | 6 +- > drivers/media/common/cx2341x.c| 4 +- > drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 2 +- > drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 2 +- > drivers/media/v4l2-core/v4l2-ctrls.c | 198 - > drivers/staging/media/hantro/hantro_drv.c | 26 +- > drivers/staging/media/hantro/hantro_h264.c| 8 +- > drivers/staging/media/hantro/hantro_hw.h | 4 +- > drivers/staging/media/rkvdec/rkvdec-h264.c| 8 +- > drivers/staging/media/rkvdec/rkvdec.c | 39 +- > drivers/staging/media/sunxi/cedrus/cedrus.c | 43 +- > .../staging/media/sunxi/cedrus/cedrus_dec.c | 12 +- > include/media/fwht-ctrls.h| 2 +- > include/media/h264-ctrls.h| 406 - > include/media/hevc-ctrls.h| 10 +- > include/media/mpeg2-ctrls.h | 4 +- > include/media/v4l2-ctrls.h| 1 - > include/media/v4l2-h264.h | 2 +- > include/media/vp8-ctrls.h | 2 +- > include/uapi/linux/v4l2-controls.h| 804 +- > include/uapi/linux/videodev2.h| 8 + > 27 files changed, 1582 insertions(+), 1412 deletions(-) > create mode 100644 Documentation/userspace-api/media/v4l/ext-ctrls-codec- stateless.rst > delete mode 100644 include/media/h264-ctrls.h > > -- > 2.27.0 > >
Re: [PATCH v4 03/13] media: cedrus: h264: Support profile controls
Hi! Dne ponedeljek, 23. november 2020 ob 15:39:50 CET je Ezequiel Garcia napisal(a): > Cedrus supports H.264 profiles from Baseline to High, > except for the Extended profile > > Expose the V4L2_CID_MPEG_VIDEO_H264_PROFILE so that > userspace can query the driver for the supported > profiles and levels. > > Signed-off-by: Ezequiel Garcia Reviewed-by: Jernej Skrabec Best regards, Jernej
Re: [PATCH 1/8] clk: sunxi-ng: h6: Fix clock divider range on some clocks
Dne sreda, 02. december 2020 ob 14:54:02 CET je Andre Przywara napisal(a):
> While comparing clocks between the H6 and H616, some of the M factor
> ranges were found to be wrong: the manual says they are only covering
> two bits [1:0], but our code had "5" in the number-of-bits field.
>
> By writing 0xff into that register in U-Boot and via FEL, it could be
> confirmed that bits [4:2] are indeed masked off, so the manual is right.
>
> Change to number of bits in the affected clock's description.
>
> Fixes: 524353ea480b ("clk: sunxi-ng: add support for the Allwinner H6 CCU")
> Signed-off-by: Andre Przywara
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
Re: Re: [PATCH 8/8] arm64: dts: allwinner: Add OrangePi Zero 2 .dts
Dne sreda, 02. december 2020 ob 17:07:02 CET je Maxime Ripard napisal(a):
> On Wed, Dec 02, 2020 at 01:54:09PM +, Andre Przywara wrote:
> > The OrangePi Zero 2 is a development board with the new H616 SoC.
> >
> > It features the usual connectors used on those small boards, and comes
> > with the AXP305, which seems to be compatible with the AXP805.
> >
> > For more details see: http://linux-sunxi.org/Xunlong_Orange_Pi_Zero2
> >
> > Signed-off-by: Andre Przywara
> > ---
> > arch/arm64/boot/dts/allwinner/Makefile| 1 +
> > .../allwinner/sun50i-h616-orangepi-zero2.dts | 228 ++
> > 2 files changed, 229 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-
zero2.dts
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/
allwinner/Makefile
> > index 211d1e9d4701..0cf8299b1ce7 100644
> > --- a/arch/arm64/boot/dts/allwinner/Makefile
> > +++ b/arch/arm64/boot/dts/allwinner/Makefile
> > @@ -35,3 +35,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-
plus.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
> > +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
> > new file mode 100644
> > index ..814f5b4fec7c
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
> > @@ -0,0 +1,228 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > +/*
> > + * Copyright (C) 2020 Arm Ltd.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "sun50i-h616.dtsi"
> > +
> > +#include
> > +#include
> > +
> > +/ {
> > + model = "OrangePi Zero2";
> > + compatible = "xunlong,orangepi-zero2", "allwinner,sun50i-h616";
>
> This needs to be documented too
>
> > + aliases {
> > + ethernet0 = &emac0;
> > + serial0 = &uart0;
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > +
> > + power {
> > + label = "orangepi:red:power";
> > + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /*
PC13 */
> > + default-state = "on";
> > + };
> > +
> > + status {
> > + label = "orangepi:green:status";
> > + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /*
PC12 */
> > + };
>
> Those node names don't follow the led binding convention
>
> > + };
> > +
> > + reg_vcc5v: vcc5v {
> > + /* board wide 5V supply directly from the USB-C socket
*/
> > + compatible = "regulator-fixed";
> > + regulator-name = "vcc-5v";
> > + regulator-min-microvolt = <500>;
> > + regulator-max-microvolt = <500>;
> > + regulator-always-on;
> > + };
> > +
> > + reg_usb1_vbus: usb1-vbus {
> > + compatible = "regulator-fixed";
> > + regulator-name = "usb1-vbus";
> > + regulator-min-microvolt = <500>;
> > + regulator-max-microvolt = <500>;
> > + enable-active-high;
> > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
> > + status = "okay";
> > + };
> > +};
> > +
> > +&ehci0 {
> > + status = "okay";
> > +};
> > +
> > +&ehci1 {
> > + status = "okay";
> > +};
> > +
> > +/* USB 2 & 3 are on headers only. */
> > +
> > +&emac0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&ext_rgmii_pins>;
> > + phy-mode = "rgmii";
> > + phy-handle = <&ext_rgmii_phy>;
> > + phy-supply = <®_dcdce>;
> > + allwinner,rx-delay-ps = <3100>;
> > + allwinner,tx-delay-ps = <700>;
> > + status = "okay";
> > +};
> > +
> > +&mdio {
> > + ext_rgmii_phy: ethernet-phy@1 {
> > + compatible = "ethernet-phy-ieee802.3-c22";
> > + reg = <1>;
> > + };
> > +};
> > +
> > +&mmc0 {
> > + vmmc-supply = <®_dcdce>;
> > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> > + bus-width = <4>;
> > + status = "okay";
> > +};
> > +
> > +&ohci0 {
> > + status = "okay";
> > +};
> > +
> > +&ohci1 {
> > + status = "okay";
> > +};
> > +
> > +&r_i2c {
> > + status = "okay";
> > +
> > + axp305: pmic@36 {
> > + compatible = "x-powers,axp305", "x-powers,axp805",
> > +"x-powers,axp806";
> > + reg = <0x36>;
> > +
> > + /* dummy interrupt to appease the driver for now */
> > + interrupts = ;
> > + interrupt-controller;
> > + #interrupt-cells = <1>;
> > +
> > + x-powers,self-working-mode;
> > + vina-supply = <®_vcc5v>;
> > + vinb-supply = <®_vcc5v>;
> > + vinc-supply = <®_vcc5v>;
> > + vind-supply = <®_vcc5v>;
> > + vine-s
Re: [PATCH 7/8] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
Dne sreda, 02. december 2020 ob 14:54:08 CET je Andre Przywara napisal(a):
> This (relatively) new SoC is similar to the H6, but drops the (broken)
> PCIe support and the USB 3.0 controller. It also gets the management
> controller removed, which in turn removes *some*, but not all of the
> devices formerly dedicated to the ARISC (CPUS).
> There does not seem to be an external interrupt controller anymore, so
> no external interrupts through an NMI pin. The AXP driver needs to learn
> living with that.
>
> Signed-off-by: Andre Przywara
> ---
> .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 704 ++
> 1 file changed, 704 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/
boot/dts/allwinner/sun50i-h616.dtsi
> new file mode 100644
> index ..dcffbfdcd26b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> @@ -0,0 +1,704 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +// Copyright (C) 2020 Arm Ltd.
> +// based on the H6 dtsi, which is:
> +// Copyright (C) 2017 Icenowy Zheng
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/ {
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <0>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> +
> + cpu1: cpu@1 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <1>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> +
> + cpu2: cpu@2 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <2>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> +
> + cpu3: cpu@3 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <3>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> + };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> + secmon_reserved: secmon@4000 {
> + reg = <0x0 0x4000 0x0 0x8>;
> + no-map;
> + };
> + };
> +
> + osc24M: osc24M_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <2400>;
> + clock-output-names = "osc24M";
> + };
> +
> + pmu {
> + compatible = "arm,cortex-a53-pmu";
> + interrupts = ,
> + ,
> + ,
> + ;
> + interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
> + };
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + arm,no-tick-in-suspend;
> + interrupts = + (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH)>,
> + + (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH)>,
> + + (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH)>,
> + + (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH)>;
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x0 0x0 0x4000>;
> +
> + syscon: syscon@300 {
> + compatible = "allwinner,sun50i-h616-system-
control",
> + "allwinner,sun50i-a64-system-
control";
Those H616 is not compatible to A64 one because it has second emac control
register at offset 0x34, which no other supported SoC has.
> + reg = <0x0300 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + sram_c: sram@28000 {
> + compatible = "mmio-sram";
> + reg = <0x00028000 0x3>;
> + #address-cells = <1>;
> +
Re: [PATCH 3/8] pinctrl: sunxi: Add support for the Allwinner H616-R pin controller
Dne sreda, 02. december 2020 ob 14:54:04 CET je Andre Przywara napisal(a):
> There are only two pins left now, used to connect to the PMIC via I2C.
>
> Signed-off-by: Andre Przywara
> ---
> drivers/pinctrl/sunxi/Kconfig | 5 ++
> drivers/pinctrl/sunxi/Makefile| 1 +
> drivers/pinctrl/sunxi/pinctrl-sun50i-h616-r.c | 58 +++
> 3 files changed, 64 insertions(+)
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-h616-r.c
>
> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
> index 73e88ce71a48..33751a6a0757 100644
> --- a/drivers/pinctrl/sunxi/Kconfig
> +++ b/drivers/pinctrl/sunxi/Kconfig
> @@ -124,4 +124,9 @@ config PINCTRL_SUN50I_H616
> default ARM64 && ARCH_SUNXI
> select PINCTRL_SUNXI
>
> +config PINCTRL_SUN50I_H616_R
> + bool "Support for the Allwinner H616 R-PIO"
> + default ARM64 && ARCH_SUNXI
> + select PINCTRL_SUNXI
> +
> endif
> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
> index 5359327a3c8f..d3440c42b9d6 100644
> --- a/drivers/pinctrl/sunxi/Makefile
> +++ b/drivers/pinctrl/sunxi/Makefile
> @@ -24,5 +24,6 @@ obj-$(CONFIG_PINCTRL_SUN50I_H5) +=
pinctrl-sun50i-h5.o
> obj-$(CONFIG_PINCTRL_SUN50I_H6) += pinctrl-sun50i-h6.o
> obj-$(CONFIG_PINCTRL_SUN50I_H6_R)+= pinctrl-sun50i-h6-r.o
> obj-$(CONFIG_PINCTRL_SUN50I_H616)+= pinctrl-sun50i-h616.o
> +obj-$(CONFIG_PINCTRL_SUN50I_H616_R) += pinctrl-sun50i-h616-r.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80) += pinctrl-sun9i-a80.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80_R)+= pinctrl-sun9i-a80-r.o
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h616-r.c b/drivers/pinctrl/
sunxi/pinctrl-sun50i-h616-r.c
> new file mode 100644
> index ..eb76c009bf24
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h616-r.c
> @@ -0,0 +1,58 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Allwinner H616 R_PIO pin controller driver
> + *
> + * Copyright (C) 2020 Arm Ltd.
> + * Based on former work, which is:
> + * Copyright (C) 2017 Icenowy Zheng
> + * Copyright (C) 2014 Boris Brezillon
> + * Boris Brezillon
> + * Copyright (C) 2014 Maxime Ripard
> + * Maxime Ripard
> + */
I'm not sure if it makes sense to reference so many previous work for so
simple driver...
Anyway:
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin sun50i_h616_r_pins[] = {
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "s_i2c")),/* SCK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "s_i2c")),/* SDA */
> +};
> +
> +static const struct sunxi_pinctrl_desc sun50i_h616_r_pinctrl_data = {
> + .pins = sun50i_h616_r_pins,
> + .npins = ARRAY_SIZE(sun50i_h616_r_pins),
> + .pin_base = PL_BASE,
> +};
> +
> +static int sun50i_h616_r_pinctrl_probe(struct platform_device *pdev)
> +{
> + return sunxi_pinctrl_init(pdev,
> + &sun50i_h616_r_pinctrl_data);
> +}
> +
> +static const struct of_device_id sun50i_h616_r_pinctrl_match[] = {
> + { .compatible = "allwinner,sun50i-h616-r-pinctrl", },
> + {}
> +};
> +
> +static struct platform_driver sun50i_h616_r_pinctrl_driver = {
> + .probe = sun50i_h616_r_pinctrl_probe,
> + .driver = {
> + .name = "sun50i-h616-r-pinctrl",
> + .of_match_table = sun50i_h616_r_pinctrl_match,
> + },
> +};
> +builtin_platform_driver(sun50i_h616_r_pinctrl_driver);
> --
> 2.17.5
>
>
Re: [PATCH 2/8] pinctrl: sunxi: Add support for the Allwinner H616 pin controller
Dne sreda, 02. december 2020 ob 14:54:03 CET je Andre Przywara napisal(a):
> Port A is used for an internal connection to some analogue circuitry
> which looks like an AC200 IP (as in the H6), though this is not
> mentioned in the manual.
>
> Signed-off-by: Andre Przywara
> ---
> drivers/pinctrl/sunxi/Kconfig | 5 +
> drivers/pinctrl/sunxi/Makefile | 1 +
> drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c | 549
> 3 files changed, 555 insertions(+)
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
>
> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
> index 593293584ecc..73e88ce71a48 100644
> --- a/drivers/pinctrl/sunxi/Kconfig
> +++ b/drivers/pinctrl/sunxi/Kconfig
> @@ -119,4 +119,9 @@ config PINCTRL_SUN50I_H6_R
> default ARM64 && ARCH_SUNXI
> select PINCTRL_SUNXI
>
> +config PINCTRL_SUN50I_H616
> + bool "Support for the Allwinner H616 PIO"
> + default ARM64 && ARCH_SUNXI
> + select PINCTRL_SUNXI
> +
> endif
> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
> index 8b7ff0dc3bdf..5359327a3c8f 100644
> --- a/drivers/pinctrl/sunxi/Makefile
> +++ b/drivers/pinctrl/sunxi/Makefile
> @@ -23,5 +23,6 @@ obj-$(CONFIG_PINCTRL_SUN8I_V3S) +=
pinctrl-sun8i-v3s.o
> obj-$(CONFIG_PINCTRL_SUN50I_H5) += pinctrl-sun50i-h5.o
> obj-$(CONFIG_PINCTRL_SUN50I_H6) += pinctrl-sun50i-h6.o
> obj-$(CONFIG_PINCTRL_SUN50I_H6_R)+= pinctrl-sun50i-h6-r.o
> +obj-$(CONFIG_PINCTRL_SUN50I_H616)+= pinctrl-sun50i-h616.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80) += pinctrl-sun9i-a80.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80_R)+= pinctrl-sun9i-a80-r.o
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c b/drivers/pinctrl/
sunxi/pinctrl-sun50i-h616.c
> new file mode 100644
> index ..734f63eb08dd
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
> @@ -0,0 +1,549 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Allwinner H616 SoC pinctrl driver.
> + *
> + * Copyright (C) 2020 Arm Ltd.
> + * based on the H6 pinctrl driver
> + * Copyright (C) 2017 Icenowy Zheng
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin h616_pins[] = {
> + /* Internal connection to the AC200 part */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 0),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ERXD1
*/
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 1),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ERXD0
*/
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 2),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ECRS_DV
*/
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 3),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ERXERR
*/
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 4),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXD1
*/
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 5),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXD0
*/
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 6),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXCK
*/
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 7),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXEN
*/
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 8),
> + SUNXI_FUNCTION(0x2, "emac1")), /* EMDC */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 9),
> + SUNXI_FUNCTION(0x2, "emac1")), /* EMDIO
*/
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 10),
> + SUNXI_FUNCTION(0x2, "i2c3")), /* SCK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 11),
> + SUNXI_FUNCTION(0x2, "i2c3")), /* SDA */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 12),
> + SUNXI_FUNCTION(0x2, "pwm5")),
> + /* Hole */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* WE */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* DS */
> + SUNXI_FUNCTION(0x4, "spi0"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)), /*
PC_EINT0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* ALE */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* RST */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)), /*
PC_EINT1 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* CLE */
> + SUNXI_FUNCTION(0x4, "spi0"), /* MOSI
*/
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)), /*
PC_EINT2 */
> + SUNXI_PIN(SUNXI_
Re: [PATCH 4/8] clk: sunxi-ng: Add support for the Allwinner H616 R-CCU
Dne sreda, 02. december 2020 ob 14:54:05 CET je Andre Przywara napisal(a):
> The clocks itself are identical to the H6 R-CCU, it's just that the H616
> has not all of them implemented (or connected).
>
> Signed-off-by: Andre Przywara
> ---
> drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c | 47 +-
> drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h | 3 +-
> 2 files changed, 48 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c b/drivers/clk/sunxi-ng/
ccu-sun50i-h6-r.c
> index 50f8d1bc7046..119d1797f501 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
> @@ -136,6 +136,15 @@ static struct ccu_common *sun50i_h6_r_ccu_clks[] = {
> &w1_clk.common,
> };
>
> +static struct ccu_common *sun50i_h616_r_ccu_clks[] = {
> + &r_apb1_clk.common,
> + &r_apb2_clk.common,
> + &r_apb1_twd_clk.common,
> + &r_apb2_i2c_clk.common,
> + &r_apb1_ir_clk.common,
> + &ir_clk.common,
> +};
> +
> static struct clk_hw_onecell_data sun50i_h6_r_hw_clks = {
> .hws= {
> [CLK_AR100] = &ar100_clk.common.hw,
> @@ -152,7 +161,20 @@ static struct clk_hw_onecell_data sun50i_h6_r_hw_clks =
{
> [CLK_IR]= &ir_clk.common.hw,
> [CLK_W1]= &w1_clk.common.hw,
> },
> - .num= CLK_NUMBER,
> + .num= CLK_NUMBER_H616,
Above macro should be CLK_NUMBER_H6.
> +};
> +
> +static struct clk_hw_onecell_data sun50i_h616_r_hw_clks = {
> + .hws= {
> + [CLK_R_AHB] = &r_ahb_clk.hw,
> + [CLK_R_APB1]=
&r_apb1_clk.common.hw,
> + [CLK_R_APB2]=
&r_apb2_clk.common.hw,
> + [CLK_R_APB1_TWD]= &r_apb1_twd_clk.common.hw,
Do we know if TWD exists? I tested I2C and IR. What is your source for these
clocks?
Best regards,
Jernej
> + [CLK_R_APB2_I2C]= &r_apb2_i2c_clk.common.hw,
> + [CLK_R_APB1_IR] =
&r_apb1_ir_clk.common.hw,
> + [CLK_IR]= &ir_clk.common.hw,
> + },
> + .num= CLK_NUMBER_H616,
> };
>
> static struct ccu_reset_map sun50i_h6_r_ccu_resets[] = {
> @@ -165,6 +187,12 @@ static struct ccu_reset_map sun50i_h6_r_ccu_resets[] =
{
> [RST_R_APB1_W1] = { 0x1ec, BIT(16) },
> };
>
> +static struct ccu_reset_map sun50i_h616_r_ccu_resets[] = {
> + [RST_R_APB1_TWD]= { 0x12c, BIT(16) },
> + [RST_R_APB2_I2C]= { 0x19c, BIT(16) },
> + [RST_R_APB1_IR] = { 0x1cc, BIT(16) },
> +};
> +
> static const struct sunxi_ccu_desc sun50i_h6_r_ccu_desc = {
> .ccu_clks = sun50i_h6_r_ccu_clks,
> .num_ccu_clks = ARRAY_SIZE(sun50i_h6_r_ccu_clks),
> @@ -175,6 +203,16 @@ static const struct sunxi_ccu_desc sun50i_h6_r_ccu_desc
= {
> .num_resets = ARRAY_SIZE(sun50i_h6_r_ccu_resets),
> };
>
> +static const struct sunxi_ccu_desc sun50i_h616_r_ccu_desc = {
> + .ccu_clks = sun50i_h616_r_ccu_clks,
> + .num_ccu_clks = ARRAY_SIZE(sun50i_h616_r_ccu_clks),
> +
> + .hw_clks= &sun50i_h616_r_hw_clks,
> +
> + .resets = sun50i_h616_r_ccu_resets,
> + .num_resets = ARRAY_SIZE(sun50i_h616_r_ccu_resets),
> +};
> +
> static void __init sunxi_r_ccu_init(struct device_node *node,
> const struct sunxi_ccu_desc
*desc)
> {
> @@ -195,3 +233,10 @@ static void __init sun50i_h6_r_ccu_setup(struct
device_node *node)
> }
> CLK_OF_DECLARE(sun50i_h6_r_ccu, "allwinner,sun50i-h6-r-ccu",
> sun50i_h6_r_ccu_setup);
> +
> +static void __init sun50i_h616_r_ccu_setup(struct device_node *node)
> +{
> + sunxi_r_ccu_init(node, &sun50i_h616_r_ccu_desc);
> +}
> +CLK_OF_DECLARE(sun50i_h616_r_ccu, "allwinner,sun50i-h616-r-ccu",
> +sun50i_h616_r_ccu_setup);
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h b/drivers/clk/sunxi-ng/
ccu-sun50i-h6-r.h
> index 782117dc0b28..128302696ca1 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
> @@ -14,6 +14,7 @@
>
> #define CLK_R_APB2 3
>
> -#define CLK_NUMBER (CLK_W1 + 1)
> +#define CLK_NUMBER_H6(CLK_W1 + 1)
> +#define CLK_NUMBER_H616 (CLK_IR + 1)
>
> #endif /* _CCU_SUN50I_H6_R_H */
> --
> 2.17.5
>
>
Re: [PATCH 5/8] clk: sunxi-ng: Add support for the Allwinner H616 CCU
Dne sreda, 02. december 2020 ob 14:54:06 CET je Andre Przywara napisal(a):
> While the clocks are fairly similar to the H6, many differ in tiny
> details, so a separate clock driver seems indicated.
>
> Derived from the H6 clock driver, and adjusted according to the manual.
>
> Signed-off-by: Andre Przywara
> ---
> drivers/clk/sunxi-ng/Kconfig|7 +-
> drivers/clk/sunxi-ng/Makefile |1 +
> drivers/clk/sunxi-ng/ccu-sun50i-h616.c | 1134 +++
> drivers/clk/sunxi-ng/ccu-sun50i-h616.h | 58 +
> include/dt-bindings/clock/sun50i-h616-ccu.h | 110 ++
> include/dt-bindings/reset/sun50i-h616-ccu.h | 67 ++
> 6 files changed, 1376 insertions(+), 1 deletion(-)
> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-h616.h
> create mode 100644 include/dt-bindings/clock/sun50i-h616-ccu.h
> create mode 100644 include/dt-bindings/reset/sun50i-h616-ccu.h
>
> diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
> index ce5f5847d5d3..cd46d8853876 100644
> --- a/drivers/clk/sunxi-ng/Kconfig
> +++ b/drivers/clk/sunxi-ng/Kconfig
> @@ -32,8 +32,13 @@ config SUN50I_H6_CCU
> default ARM64 && ARCH_SUNXI
> depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
>
> +config SUN50I_H616_CCU
> + bool "Support for the Allwinner H616 CCU"
> + default ARM64 && ARCH_SUNXI
> + depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
> +
> config SUN50I_H6_R_CCU
> - bool "Support for the Allwinner H6 PRCM CCU"
> + bool "Support for the Allwinner H6 and H616 PRCM CCU"
> default ARM64 && ARCH_SUNXI
> depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
>
> diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
> index 3eb5cff40eac..96c324306d97 100644
> --- a/drivers/clk/sunxi-ng/Makefile
> +++ b/drivers/clk/sunxi-ng/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_SUN50I_A64_CCU)+= ccu-sun50i-a64.o
> obj-$(CONFIG_SUN50I_A100_CCU)+= ccu-sun50i-a100.o
> obj-$(CONFIG_SUN50I_A100_R_CCU) += ccu-sun50i-a100-r.o
> obj-$(CONFIG_SUN50I_H6_CCU) += ccu-sun50i-h6.o
> +obj-$(CONFIG_SUN50I_H616_CCU)+= ccu-sun50i-h616.o
> obj-$(CONFIG_SUN50I_H6_R_CCU)+= ccu-sun50i-h6-r.o
> obj-$(CONFIG_SUN4I_A10_CCU) += ccu-sun4i-a10.o
> obj-$(CONFIG_SUN5I_CCU) += ccu-sun5i.o
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h616.c b/drivers/clk/sunxi-ng/
ccu-sun50i-h616.c
> new file mode 100644
> index ..3fbb258f0354
> --- /dev/null
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> @@ -0,0 +1,1134 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 Arm Ltd.
> + * Based on the H6 CCU driver, which is:
> + * Copyright (c) 2017 Icenowy Zheng
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "ccu_common.h"
> +#include "ccu_reset.h"
> +
> +#include "ccu_div.h"
> +#include "ccu_gate.h"
> +#include "ccu_mp.h"
> +#include "ccu_mult.h"
> +#include "ccu_nk.h"
> +#include "ccu_nkm.h"
> +#include "ccu_nkmp.h"
> +#include "ccu_nm.h"
> +
> +#include "ccu-sun50i-h616.h"
> +
> +/*
> + * The CPU PLL is actually NP clock, with P being /1, /2 or /4. However
> + * P should only be used for output frequencies lower than 288 MHz.
> + *
> + * For now we can just model it as a multiplier clock, and force P to /1.
> + *
> + * The M factor is present in the register's description, but not in the
> + * frequency formula, and it's documented as "M is only used for backdoor
> + * testing", so it's not modelled and then force to 0.
> + */
> +#define SUN50I_H616_PLL_CPUX_REG 0x000
> +static struct ccu_mult pll_cpux_clk = {
> + .enable = BIT(31),
> + .lock = BIT(28),
> + .mult = _SUNXI_CCU_MULT_MIN(8, 8, 12),
> + .common = {
> + .reg= 0x000,
> + .hw.init= CLK_HW_INIT("pll-cpux", "osc24M",
> + &ccu_mult_ops,
> +
CLK_SET_RATE_UNGATE),
> + },
> +};
> +
> +/* Some PLLs are input * N / div1 / P. Model them as NKMP with no K */
> +#define SUN50I_H616_PLL_DDR0_REG 0x010
> +static struct ccu_nkmp pll_ddr0_clk = {
> + .enable = BIT(31),
> + .lock = BIT(28),
> + .n = _SUNXI_CCU_MULT_MIN(8, 8, 12),
> + .m = _SUNXI_CCU_DIV(1, 1), /* input divider */
> + .p = _SUNXI_CCU_DIV(0, 1), /* output divider */
> + .common = {
> + .reg= 0x010,
> + .hw.init= CLK_HW_INIT("pll-ddr0", "osc24M",
> + &ccu_nkmp_ops,
> +
CLK_SET_RATE_UNGATE),
> + },
> +};
> +
> +#define SUN50I_H616_PLL_DDR1_REG 0x018
> +static struct ccu_nkmp pll_ddr1_clk = {
> + .enable = BIT(31),
> + .lock = BIT(28),
>
Re: [PATCH] arm64: dts: allwinner: h6: Switch to macros for RSB clock/reset indices
Hi Chen-Yu,
Dne ponedeljek, 01. marec 2021 ob 17:23:09 CET je Chen-Yu Tsai napisal(a):
> From: Chen-Yu Tsai
>
> The macros for the clock and reset indices for the RSB hardware block
> were replaced with raw numbers when the RSB controller node was added.
> This was done to avoid cross-tree dependencies.
>
> Now that both the clk and DT changes have been merged, we can switch
> back to using the macros.
>
> Fixes: aaad900757a6 ("arm64: dts: allwinner: h6: Add RSB controller node")
> Signed-off-by: Chen-Yu Tsai
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
Re: Re: [PATCH] ARM: dts: sun8i: h3: beelink-x2: Add power button
Hi!
Dne ponedeljek, 08. marec 2021 ob 14:05:06 CET je Maxime Ripard napisal(a):
> Hi
>
> On Sat, Mar 06, 2021 at 09:36:11PM +0100, Jernej Skrabec wrote:
> > Beelink X2 has power button. Add node for it.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> > arch/arm/boot/dts/sun8i-h3-beelink-x2.dts | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts b/arch/arm/boot/dts/
sun8i-h3-beelink-x2.dts
> > index 62b5280ec093..4a2cb072ecf6 100644
> > --- a/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
> > +++ b/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
> > @@ -111,6 +111,17 @@ spdif_out: spdif-out {
> > #sound-dai-cells = <0>;
> > compatible = "linux,spdif-dit";
> > };
> > +
> > + r_gpio_keys {
>
> Underscores are not valid for node names (and will trigger a dtc warning
> when running with W=1).
Unless I'm doing something wrong, I didn't get any warning with "make dtbs
W=1". In fact many H3 boards have a node with this name and not a single
warning is produced with this command for underscores (there are other
warnings though).
Actually, several H3 DT files have nodes like "sound_spdif" or "wifi_pwrseq".
It
seems like warnings are triggered only for children of soc node.
>
> > + compatible = "gpio-keys";
> > +
> > + power {
> > + label = "power";
>
> IIRC the node name is used as a fallback when the label isn't there?
Binding doesn't say anything about what happens if label is missing. Driver
sets generic description "gpio_keys" in such case, which is not something that
we want.
Best regards,
Jernej
>
> Maxime
>
Re: [PATCH v2] ARM: dts: sun7i: a20: bananapro: Fix ethernet node
Dne četrtek, 21. januar 2021 ob 18:08:36 CET je Hermann Lauer napisal(a): > BPi Pro needs TX and RX delay for Gbit to work reliable and avoid high > packet loss rates. The realtek phy driver overrides the settings of the > pull ups for the delays, so fix this for Banana Pro. > > Signed-off-by: Hermann Lauer Much better. Now the only thing missing is "Fixes" tag, which references commit which introduced the issue. Probably this will be the commit which added ethernet node. This tag is important for deciding which commits should be backported to stable releases. Take a look in v1 for M2U fixes tag. Btw, each version should have changelog under "---" line, so maintainers and reviewers know what changed. Best regards, Jernej
Re: Re: [PATCH 2/5] drm/sun4i: tcon: set sync polarity for tcon1 channel
Dne petek, 05. februar 2021 ob 17:01:30 CET je Maxime Ripard napisal(a):
> On Fri, Feb 05, 2021 at 11:21:22AM +0800, Chen-Yu Tsai wrote:
> > On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec
wrote:
> > >
> > > Channel 1 has polarity bits for vsync and hsync signals but driver never
> > > sets them. It turns out that with pre-HDMI2 controllers seemingly there
> > > is no issue if polarity is not set. However, with HDMI2 controllers
> > > (H6) there often comes to de-synchronization due to phase shift. This
> > > causes flickering screen. It's safe to assume that similar issues might
> > > happen also with pre-HDMI2 controllers.
> > >
> > > Solve issue with setting vsync and hsync polarity. Note that display
> > > stacks with tcon top have polarity bits actually in tcon0 polarity
> > > register.
> > >
> > > Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
> > > Tested-by: Andre Heider
> > > Signed-off-by: Jernej Skrabec
> > > ---
> > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 24
> > > drivers/gpu/drm/sun4i/sun4i_tcon.h | 5 +
> > > 2 files changed, 29 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/
sun4i_tcon.c
> > > index 6b9af4c08cd6..0d132dae58c0 100644
> > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > @@ -672,6 +672,29 @@ static void sun4i_tcon1_mode_set(struct sun4i_tcon
*tcon,
> > > SUN4I_TCON1_BASIC5_V_SYNC(vsync) |
> > > SUN4I_TCON1_BASIC5_H_SYNC(hsync));
> > >
> > > + /* Setup the polarity of sync signals */
> > > + if (tcon->quirks->polarity_in_ch0) {
> > > + val = 0;
> > > +
> > > + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> > > + val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
> > > +
> > > + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> > > + val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
> > > +
> > > + regmap_write(tcon->regs, SUN4I_TCON0_IO_POL_REG, val);
> > > + } else {
> > > + val = SUN4I_TCON1_IO_POL_UNKNOWN;
> >
> > I think a comment for the origin of this is warranted.
>
> If it's anything like TCON0, it's the pixel clock polarity
Hard to say, DW HDMI controller has "data enable" polarity along hsync and
vsync. It could be either or none of those.
What should I write in comment? BSP drivers and documentation use only generic
names like io2_inv.
Best regards,
Jernej
Re: Re: [linux-sunxi] [PATCH 4/5] drm/sun4i: Fix H6 HDMI PHY configuration
Dne petek, 05. februar 2021 ob 04:22:56 CET je Chen-Yu Tsai napisal(a):
> On Fri, Feb 5, 2021 at 2:48 AM Jernej Skrabec
wrote:
> >
> > cpce value for 594 MHz is set differently in BSP driver. Fix that.
> >
> > Fixes: c71c9b2fee17 ("drm/sun4i: Add support for Synopsys HDMI PHY")
> > Tested-by: Andre Heider
> > Signed-off-by: Jernej Skrabec
>
> Reviewed-by: Chen-Yu Tsai
Thanks, but I figured that this change is not the proper one. It still gives me
issues with my TV. Proper change is to fix current and voltage settings below.
I'll replace this patch in v2.
Best regards,
Jernej
>
> --
> You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to linux-sunxi+unsubscr...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/
linux-sunxi/
CAGb2v64BpizczmSJdompGosFwWWayNscWvW-7oARLgwNNo%3DteQ%40mail.gmail.com.
>
Re: [PATCH] ARM: dts: sun8i: h3: orangepi-plus: Fix Ethernet PHY mode
Dne ponedeljek, 08. februar 2021 ob 12:24:57 CET je B.R. Oake napisal(a):
> Since commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx
> delay config"), Ethernet no longer works on the Orange Pi Plus,
> because that commit sets the RX/TX delay according to the phy-mode
> property in the device tree, which is "rgmii", the wrong setting
> for this board.
>
> Following the example of others who fixed the same problem for
> many other boards, this patch changes the phy-mode to "rgmii-id"
> which gets Ethernet working again on this board.
>
> Fixes: 4904337fe34f ("ARM: dts: sunxi: Restore EMAC changes (boards)")
> Fixes: 1dcd0095019a ("ARM: sun8i: orangepi-plus: Enable dwmac-sun8i")
> Signed-off-by: B.R. Oake
> ---
> arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Jernej Skrabec
Thanks!
Best regards,
Jernej
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts b/arch/arm/boot/
dts/sun8i-h3-orangepi-plus.dts
> index 97f497854e..d05fa679dc 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
> @@ -85,7 +85,7 @@
> pinctrl-0 = <&emac_rgmii_pins>;
> phy-supply = <®_gmac_3v3>;
> phy-handle = <&ext_rgmii_phy>;
> - phy-mode = "rgmii";
> + phy-mode = "rgmii-id";
>
> status = "okay";
> };
> --
> 2.20.1
>
>
Re: [PATCH v3] drm/sun4i: de2: Reimplement plane z position setting logic
Dne sreda, 06. januar 2021 ob 21:46:30 CET je Jernej Skrabec napisal(a):
> From: Roman Stratiienko
>
> To set blending channel order register software needs to know state and
> position of each channel, which impossible at plane commit stage.
>
> Move this procedure to atomic_flush stage, where all necessary information
> is available.
>
> Fixes: f88c5ee77496 ("drm/sun4i: Implement zpos for DE2")
> Fixes: d8b3f454dab4 ("drm/sun4i: sun8i: Avoid clearing blending order at
each atomic commit")
> Signed-off-by: Roman Stratiienko
> [rebased, addressed comments]
> Signed-off-by: Jernej Skrabec
> ---
Forgot to include changelog:
This is update of:
https://patchwork.kernel.org/project/dri-devel/patch/20191229162828.3326-1-roman.stratiie...@globallogic.com/
with addressed comments.
Changes from v2:
- renamed SUN8I_MIXER_MAX_LAYERS to SUN8I_MIXER_MAX_CHANNELS
- removed unused variable in sun8i_vi_layer_enable()
- renamed and reordered variables in sun8i_mixer_commit()
- removed route allocation for disabled channels
- write SUN8I_MIXER_BLEND_PIPE_CTL reg only in commit hook
- added fixed tags
Best regards,
Jernej
> drivers/gpu/drm/sun4i/sun8i_mixer.c| 57 +-
> drivers/gpu/drm/sun4i/sun8i_mixer.h| 5 +++
> drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 42 +++
> drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 42 +++
> 4 files changed, 64 insertions(+), 82 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/
sun8i_mixer.c
> index 5b42cf25cc86..d2153b10b08d 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> @@ -250,6 +250,50 @@ int sun8i_mixer_drm_format_to_hw(u32 format, u32
*hw_format)
>
> static void sun8i_mixer_commit(struct sunxi_engine *engine)
> {
> + struct sun8i_mixer *mixer = engine_to_sun8i_mixer(engine);
> + int channel_by_zpos[SUN8I_MIXER_MAX_CHANNELS];
> + u32 base = sun8i_blender_base(mixer);
> + u32 route = 0, pipe_ctl = 0;
> + unsigned int channel_count;
> + int i, j;
> +
> + channel_count = mixer->cfg->vi_num + mixer->cfg->ui_num;
> +
> + DRM_DEBUG_DRIVER("Update blender routing\n");
> +
> + for (i = 0; i < SUN8I_MIXER_MAX_CHANNELS; i++)
> + channel_by_zpos[i] = -1;
> +
> + for (i = 0; i < channel_count; i++) {
> + int zpos = mixer->channel_zpos[i];
> +
> + if (zpos >= 0 && zpos < channel_count)
> + channel_by_zpos[zpos] = i;
> + }
> +
> + j = 0;
> + for (i = 0; i < channel_count; i++) {
> + int ch = channel_by_zpos[i];
> +
> + if (ch >= 0) {
> + pipe_ctl |= SUN8I_MIXER_BLEND_PIPE_CTL_EN(j);
> + route |= ch <<
SUN8I_MIXER_BLEND_ROUTE_PIPE_SHIFT(j);
> + j++;
> + }
> + }
> +
> + /*
> + * Set fill color of bottom plane to black. Generally not needed
> + * except when VI plane is at bottom (zpos = 0) and enabled.
> + */
> + pipe_ctl |= SUN8I_MIXER_BLEND_PIPE_CTL_FC_EN(0);
> +
> + regmap_write(mixer->engine.regs,
> + SUN8I_MIXER_BLEND_PIPE_CTL(base), pipe_ctl);
> +
> + regmap_write(mixer->engine.regs,
> + SUN8I_MIXER_BLEND_ROUTE(base), route);
> +
> DRM_DEBUG_DRIVER("Committing changes\n");
>
> regmap_write(engine->regs, SUN8I_MIXER_GLOBAL_DBUFF,
> @@ -479,23 +523,16 @@ static int sun8i_mixer_bind(struct device *dev, struct
device *master,
> regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_BKCOLOR(base),
>SUN8I_MIXER_BLEND_COLOR_BLACK);
>
> - /*
> - * Set fill color of bottom plane to black. Generally not needed
> - * except when VI plane is at bottom (zpos = 0) and enabled.
> - */
> - regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_PIPE_CTL(base),
> - SUN8I_MIXER_BLEND_PIPE_CTL_FC_EN(0));
> regmap_write(mixer->engine.regs,
SUN8I_MIXER_BLEND_ATTR_FCOLOR(base, 0),
>SUN8I_MIXER_BLEND_COLOR_BLACK);
>
> plane_cnt = mixer->cfg->vi_num + mixer->cfg->ui_num;
> - for (i = 0; i < plane_cnt; i++)
> + for (i = 0; i < plane_cnt; i++) {
> + mixer->channel_zpos[i] = -1;
> regmap_write(mixer->engine.regs,
>SUN8I_MIXER_BLEND_MODE(base, i),
>SUN8I_MIXER_BLEND_MODE_DEF);
> -
> - regmap_update_bits(mixer->engine.regs,
SUN8I_MIXER_BLEND_PIPE_CTL(base),
> -SUN8I_MIXER_BLEND_PIPE_CTL_EN_MSK, 0);
> + }
>
> return 0;
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h b/drivers/gpu/drm/sun4i/
sun8i_mixer.h
> index 7576b523fdbb..7b378d6e4dd9 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> @@ -12,6 +12,8 @@
>
> #include "sunxi_engine.h"
>
> +#define SUN8I_MIXER_MAX_CHANNELS 5
> +
> #defi
Re: [PATCH 1/2] drm/sun4i: tcon: fix inverted DCLK polarity
Dne sreda, 06. januar 2021 ob 20:27:59 CET je Giulio Benetti napisal(a): > During commit "88bc4178568b8e0331143cc0616640ab72f0cba1" DRM_BUS_FLAG_* Please use same commit referencing approach as for "Fixes" tag. > macros have been changed to avoid ambiguity but just because of this > ambiguity previous DRM_BUS_FLAG_PIXDATA_(POS/NEG)EDGE were used meaning > _SAMPLE_ not _DRIVE_. This lead to DLCK inversion, so let's swap DCLK > phase to fix it. > Add Fixes tag here. Best regards, Jernej > Signed-off-by: Giulio Benetti > --- > drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/ sun4i_tcon.c > index eaaf5d70e352..52598bb0fb0b 100644 > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c > @@ -585,10 +585,10 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon, >* and DOTCLOCK drivers. >*/ > if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE) > - clk_set_phase(tcon->dclk, 240); > + clk_set_phase(tcon->dclk, 0); > > if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE) > - clk_set_phase(tcon->dclk, 0); > + clk_set_phase(tcon->dclk, 240); > > regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG, > SUN4I_TCON0_IO_POL_HSYNC_POSITIVE | > -- > 2.25.1 > >
Re: Re: [PATCH v3] media: cedrus: Add support for VP8 decoding
Hi! Dne petek, 27. november 2020 ob 00:21:11 CET je Ezequiel Garcia napisal(a): > Hi Jernej, Emmanuel, > > Thanks for the patch. > > On Tue, 2020-11-10 at 23:35 +0100, Jernej Skrabec wrote: > > VP8 in Cedrus shares same engine as H264. > > > > Note that it seems necessary to call bitstream parsing functions, > > to parse frame header, otherwise decoded image is garbage. This is > > contrary to what is driver supposed to do. However, values are not > > really used, so this might be acceptable. It's possible that bitstream > > parsing functions set some internal VPU state, which is later necessary > > for proper decoding. Biggest suspect is "VP8 probs update" trigger. > > > > Signed-off-by: Jernej Skrabec > > [addressed issues from reviewer] > > Signed-off-by: Emmanuel Gil Peyrot > > --- > > Changes in v3: > > - addressed comments from Ezequiel Garcia - new comments, > > using new macros from VP8 UAPI, new function for waiting > > on bit to be set > > Changes in v2: > > - rebased on top of current linux-media master branch > > > > NOTE: This now depends on following patch: > > https://patchwork.linuxtv.org/project/linux-media/patch/ 20201108202021.4187-1-linkma...@linkmauve.fr/ > > > > The patch looks fairly good, so let's wait and see > what Hans, Paul and Maxime think about it. > > FWIW, my humble Reviewed-by: Ezequiel Garcia Thanks! > > It would be good to make sure this doesn't regress > v4l2-compliance, or cause some regression in decoding. I didn't include v4l2-compliance here, but it was in previous revisions. This revision has just cosmetics. Not sure how it could cause any regression since it's pretty standalone. > > Not really a blocker to merge this, but I'm thinking > that now that we have Fluster for conformance testing, > we could add the VP8 vectors and use them against > Cedrus and Hantro: > > https://chromium.googlesource.com/webm/vp8-test-vectors/+/refs/heads/master I tested VP8 test vectors with initial version of this decoder by hand and all videos were properly decoded as far as I can tell. But automated testing is always welcome. Best regards, Jernej > > Thanks, > Ezequiel > > > drivers/staging/media/sunxi/cedrus/Makefile | 3 +- > > drivers/staging/media/sunxi/cedrus/cedrus.c | 8 + > > drivers/staging/media/sunxi/cedrus/cedrus.h | 24 + > > .../staging/media/sunxi/cedrus/cedrus_dec.c | 5 + > > .../staging/media/sunxi/cedrus/cedrus_hw.c| 2 + > > .../staging/media/sunxi/cedrus/cedrus_regs.h | 80 ++ > > .../staging/media/sunxi/cedrus/cedrus_video.c | 9 + > > .../staging/media/sunxi/cedrus/cedrus_vp8.c | 907 ++ > > 8 files changed, 1037 insertions(+), 1 deletion(-) > > create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_vp8.c > > > >
Re: [linux-sunxi] [PATCH v3 2/2] media: cedrus: Add H264 decoding support
Hi Maxime,
I spotted few minor issues, but otherwise it looks very well.
I'll do detailed review at a later time.
Dne ponedeljek, 11. februar 2019 ob 15:39:03 CET je Maxime Ripard napisal(a):
> Introduce some basic H264 decoding support in cedrus. So far, only the
> baseline profile videos have been tested, and some more advanced features
> used in higher profiles are not even implemented.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/staging/media/sunxi/cedrus/Makefile | 3 +-
> drivers/staging/media/sunxi/cedrus/cedrus.c | 31 +-
> drivers/staging/media/sunxi/cedrus/cedrus.h | 38 +-
> drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 15 +-
> drivers/staging/media/sunxi/cedrus/cedrus_h264.c | 589 +++-
> drivers/staging/media/sunxi/cedrus/cedrus_hw.c| 4 +-
> drivers/staging/media/sunxi/cedrus/cedrus_regs.h | 91 ++-
> drivers/staging/media/sunxi/cedrus/cedrus_video.c | 9 +-
> 8 files changed, 778 insertions(+), 2 deletions(-)
> create mode 100644 drivers/staging/media/sunxi/cedrus/cedrus_h264.c
>
> diff --git a/drivers/staging/media/sunxi/cedrus/Makefile
> b/drivers/staging/media/sunxi/cedrus/Makefile index
> e9dc68b7bcb6..aaf141fc58b6 100644
> --- a/drivers/staging/media/sunxi/cedrus/Makefile
> +++ b/drivers/staging/media/sunxi/cedrus/Makefile
> @@ -1,3 +1,4 @@
> obj-$(CONFIG_VIDEO_SUNXI_CEDRUS) += sunxi-cedrus.o
>
> -sunxi-cedrus-y = cedrus.o cedrus_video.o cedrus_hw.o cedrus_dec.o
> cedrus_mpeg2.o +sunxi-cedrus-y = cedrus.o cedrus_video.o cedrus_hw.o
> cedrus_dec.o \ + cedrus_mpeg2.o cedrus_h264.o
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
> b/drivers/staging/media/sunxi/cedrus/cedrus.c index
> ff11cbeba205..b275607b8111 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> @@ -40,6 +40,36 @@ static const struct cedrus_control cedrus_controls[] = {
> .codec = CEDRUS_CODEC_MPEG2,
> .required = false,
> },
> + {
> + .id =
V4L2_CID_MPEG_VIDEO_H264_DECODE_PARAMS,
> + .elem_size = sizeof(struct
v4l2_ctrl_h264_decode_param),
> + .codec = CEDRUS_CODEC_H264,
> + .required = true,
> + },
> + {
> + .id =
V4L2_CID_MPEG_VIDEO_H264_SLICE_PARAMS,
> + .elem_size = sizeof(struct v4l2_ctrl_h264_slice_param),
> + .codec = CEDRUS_CODEC_H264,
> + .required = true,
> + },
> + {
> + .id = V4L2_CID_MPEG_VIDEO_H264_SPS,
> + .elem_size = sizeof(struct v4l2_ctrl_h264_sps),
> + .codec = CEDRUS_CODEC_H264,
> + .required = true,
> + },
> + {
> + .id = V4L2_CID_MPEG_VIDEO_H264_PPS,
> + .elem_size = sizeof(struct v4l2_ctrl_h264_pps),
> + .codec = CEDRUS_CODEC_H264,
> + .required = true,
> + },
> + {
> + .id =
V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX,
> + .elem_size = sizeof(struct
v4l2_ctrl_h264_scaling_matrix),
> + .codec = CEDRUS_CODEC_H264,
> + .required = true,
> + },
> };
>
> #define CEDRUS_CONTROLS_COUNTARRAY_SIZE(cedrus_controls)
> @@ -278,6 +308,7 @@ static int cedrus_probe(struct platform_device *pdev)
> }
>
> dev->dec_ops[CEDRUS_CODEC_MPEG2] = &cedrus_dec_ops_mpeg2;
> + dev->dec_ops[CEDRUS_CODEC_H264] = &cedrus_dec_ops_h264;
>
> mutex_init(&dev->dev_mutex);
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
> b/drivers/staging/media/sunxi/cedrus/cedrus.h index
> 4aedd24a9848..8c64f9a27e9d 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> @@ -30,7 +30,7 @@
>
> enum cedrus_codec {
> CEDRUS_CODEC_MPEG2,
> -
> + CEDRUS_CODEC_H264,
> CEDRUS_CODEC_LAST,
> };
>
> @@ -40,6 +40,12 @@ enum cedrus_irq_status {
> CEDRUS_IRQ_OK,
> };
>
> +enum cedrus_h264_pic_type {
> + CEDRUS_H264_PIC_TYPE_FRAME = 0,
> + CEDRUS_H264_PIC_TYPE_FIELD,
> + CEDRUS_H264_PIC_TYPE_MBAFF,
> +};
> +
> struct cedrus_control {
> u32 id;
> u32 elem_size;
> @@ -47,6 +53,14 @@ struct cedrus_control {
> unsigned char required:1;
> };
>
> +struct cedrus_h264_run {
> + const struct v4l2_ctrl_h264_decode_param*decode_param;
> + const struct v4l2_ctrl_h264_pps *pps;
> + const struct v4l2_ctrl_h264_scaling_matrix *scaling_matrix;
> + const struct v4l2_ctrl_h264_slice_param *slice_param;
> + const struct v4l2_ctrl_h264_sps *sps;
> +};
> +
> struct cedrus_mpeg2_run {
> const struct v4l2_ctrl_mpeg2_slice_params *slice_params;
>
Re: [PATCH v2] drm: bridge/dw_hdmi: add audio sample channel status setting
Dne četrtek, 05. september 2019 ob 11:43:25 CEST je Cheng-Yi Chiang
napisal(a):
> From: Yakir Yang
>
> When transmitting IEC60985 linear PCM audio, we configure the
> Aduio Sample Channel Status information of all the channel
> status bits in the IEC60958 frame.
> Refer to 60958-3 page 10 for frequency, original frequency, and
> wordlength setting.
>
> This fix the issue that audio does not come out on some monitors
> (e.g. LG 22CV241)
>
> Note that these registers are only for interfaces:
> I2S audio interface, General Purpose Audio (GPA), or AHB audio DMA
> (AHBAUDDMA).
> For S/PDIF interface this information comes from the stream.
>
> Currently this function dw_hdmi_set_channel_status is only called
> from dw-hdmi-i2s-audio in I2S setup.
>
> Signed-off-by: Yakir Yang
> Signed-off-by: Cheng-Yi Chiang
> ---
> Original patch by Yakir Yang is at
>
> https://lore.kernel.org/patchwork/patch/539653/
>
> Change from v1 to v2:
> 1. Remove the version check because this will only be called by
> dw-hdmi-i2s-audio, and the registers are available in I2S setup.
> 2. Set these registers in dw_hdmi_i2s_hw_params.
> 3. Fix the sample width setting so it can use 16 or 24 bits.
>
> .../drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 1 +
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 70 +++
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20 ++
> include/drm/bridge/dw_hdmi.h | 2 +
> 4 files changed, 93 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c index
> 34d8e837555f..b801a28b0f17 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> @@ -102,6 +102,7 @@ static int dw_hdmi_i2s_hw_params(struct device *dev,
> void *data, }
>
> dw_hdmi_set_sample_rate(hdmi, hparms->sample_rate);
> + dw_hdmi_set_channel_status(hdmi, hparms->sample_width);
> dw_hdmi_set_channel_count(hdmi, hparms->channels);
> dw_hdmi_set_channel_allocation(hdmi, hparms-
>cea.channel_allocation);
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> bd65d0479683..d1daa369c8ae 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -582,6 +582,76 @@ static unsigned int hdmi_compute_n(unsigned int freq,
> unsigned long pixel_clk) return n;
> }
>
> +/*
> + * When transmitting IEC60958 linear PCM audio, these registers allow to
> + * configure the channel status information of all the channel status
> + * bits in the IEC60958 frame. For the moment this configuration is only
> + * used when the I2S audio interface, General Purpose Audio (GPA),
> + * or AHB audio DMA (AHBAUDDMA) interface is active
> + * (for S/PDIF interface this information comes from the stream).
> + */
> +void dw_hdmi_set_channel_status(struct dw_hdmi *hdmi,
> + unsigned int sample_width)
> +{
> + u8 aud_schnl_samplerate;
> + u8 aud_schnl_8;
> + u8 word_length_bits;
> +
> + switch (hdmi->sample_rate) {
> + case 32000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_32K;
> + break;
> + case 44100:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_44K1;
> + break;
> + case 48000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_48K;
> + break;
> + case 88200:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_88K2;
> + break;
> + case 96000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_96K;
> + break;
> + case 176400:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_176K4;
> + break;
> + case 192000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_192K;
> + break;
> + case 768000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_768K;
> + break;
> + default:
> + dev_warn(hdmi->dev, "Unsupported audio sample rate (%u)
\n",
> + hdmi->sample_rate);
> + return;
> + }
> +
> + /* set channel status register */
> + hdmi_modb(hdmi, aud_schnl_samplerate,
HDMI_FC_AUDSCHNLS7_SMPRATE_MASK,
> + HDMI_FC_AUDSCHNLS7);
> +
> + /*
> + * Set original frequency to be the same as frequency.
> + * Use one-complement value as stated in IEC60958-3 page 13.
> + */
> + aud_schnl_8 = (~aud_schnl_samplerate) <<
> + HDMI_FC_AUDSCHNLS8_ORIGSAMPFREQ_OFFSET;
> +
> + /*
> + * Refer to IEC60958-3 page 12. We can accept 16 bits or 24 bits.
> + * Otherwise, set the register to 0t o indicate using default
value.
Nit: "0t 0" -> "0 to"
With that fixed, this patch is:
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> +
Re: [PATCH 5/8] media: cedrus: Detect first slice of a frame
Dne ponedeljek, 26. avgust 2019 ob 20:28:31 CEST je Boris Brezillon
napisal(a):
> Hi Jernej,
>
> On Thu, 22 Aug 2019 21:44:57 +0200
>
> Jernej Skrabec wrote:
> > When codec supports multiple slices in one frame, VPU has to know when
> > first slice of each frame is being processed, presumably to correctly
> > clear/set data in auxiliary buffers.
> >
> > Add first_slice field to cedrus_run structure and set it according to
> > timestamps of capture and output buffers. If timestamps are different,
> > it's first slice and viceversa.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 +
> > drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++
> > 2 files changed, 3 insertions(+)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > b/drivers/staging/media/sunxi/cedrus/cedrus.h index
> > 2f017a651848..32cb38e541c6 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> > @@ -70,6 +70,7 @@ struct cedrus_mpeg2_run {
> >
> > struct cedrus_run {
> >
> > struct vb2_v4l2_buffer *src;
> > struct vb2_v4l2_buffer *dst;
> >
> > + bool first_slice;
> >
> > union {
> >
> > struct cedrus_h264_run h264;
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c index
> > 56ca4c9ad01c..d7b54accfe83 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > @@ -31,6 +31,8 @@ void cedrus_device_run(void *priv)
> >
> > run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> > run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> >
> > + run.first_slice =
> > + run.src->vb2_buf.timestamp != run.dst-
>vb2_buf.timestamp;
>
> Can't we use slice->first_mb_in_slice to determine if a slice is the
> first? I'd expect ->first_mb_in_slice to be 0 (unless we decide to
> support ASO).
I looked in all VPU documentation available to me (which isn't much) and there
is no indication if ASO is supported or not. Do you have any sample video with
out-of-order slices? It's my understanding that this is uncommon. If it's
supported, I would leave code as-is.
Best regards,
Jernej
>
> > /* Apply request(s) controls if needed. */
> > src_req = run.src->vb2_buf.req_obj.req;
Re: [linux-sunxi] [PATCH] ARM64: dts: allwinner: Add devicetree for pine H64 modelA evaluation board
Dne sreda, 14. avgust 2019 ob 15:28:53 CEST je Clément Péron napisal(a):
> Hi,
>
> On Wed, 14 Aug 2019 at 15:20, Corentin Labbe
wrote:
> > On Mon, Aug 12, 2019 at 12:56:56PM +0200, Jernej Škrabec wrote:
> > > Dne četrtek, 08. avgust 2019 ob 10:42:53 CEST je Corentin Labbe
napisal(a):
> > > > This patch adds the evaluation variant of the model A of the PineH64.
> > > > The model A has the same size of the pine64 and has a PCIE slot.
> > > >
> > > > The only devicetree difference with current pineH64, is the PHY
> > > > regulator.
> > >
> > > I have Model A board which also needs ddc-en-gpios property for HDMI
> > > connector in order for HDMI to work correctly. Otherwise it will just
> > > use 1024x768 resolution. Can you confirm that?
>
> Schematics Rev A:
> http://files.pine64.org/doc/Pine%20H64/Pine%20H64%20Ver1.1-20180104.pdf
>
> Rev B:
> http://files.pine64.org/doc/Pine%20H64/PINE-H6-model-B-20181212-schematic.pd
> f
>
> There is a DDC_EN on REV A not on REV B
>
> Regards,
> Clément
>
> > > Best regards,
> > > Jernej
> >
> > Sorry I didnt use at all video stuff (like HDMI), so I cannot answer now.
> >
> > Could you send me a patch against my future v2 and I could test
> > with/without.
I don't have access to my Model A board currently, but this should suffice:
&connector {
ddc-en-gpios = <&pio 7 2 GPIO_ACTIVE_HIGH>; /* PH2 */
};
Best regards,
Jernej
> >
> > Regards
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "linux-sunxi" group. To unsubscribe from this group and stop receiving
> > emails from it, send an email to
> > linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the
> > web, visit
> > https://groups.google.com/d/msgid/linux-sunxi/20190814132001.GC24324%40Re
> > d.
Re: [PATCH 2/2] arm64: dts: allwinner: h6: Introduce Tanix TX6 board
Dne nedelja, 18. avgust 2019 ob 20:42:49 CEST je kbuild test robot napisal(a): > Hi Jernej, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on linus/master] > [cannot apply to v5.3-rc4 next-20190816] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Jernej-Skrabec/dt-bindings-arm-sun > xi-Add-compatible-for-Tanix-TX6-board/20190819-002034 config: > arm64-defconfig (attached as .config) > compiler: aarch64-linux-gcc (GCC) 7.4.0 > reproduce: > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > GCC_VERSION=7.4.0 make.cross ARCH=arm64 > > If you fix the issue, kindly add following tag > Reported-by: kbuild test robot > > All errors (new ones prefixed by >>): > >> Error: arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts:83.1-6 Label > >> or path r_ir not found FATAL ERROR: Syntax error parsing input tree Strange, Allwinner tree has commit, which introduces r_ir node: https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/? h=sunxi/dt-for-5.4&id=9267811aad3524c857cf2e16bbadd8c569e15ab9 Maybe kbuild test robot tree doesn't have it? Best regards, Jernej > > --- > 0-DAY kernel test infrastructureOpen Source Technology > Center https://lists.01.org/pipermail/kbuild-all Intel > Corporation
Re: [linux-sunxi] [PATCH v2 0/3] Add basic support for RTC on Allwinner H6 SoC
Hi! Dne torek, 20. avgust 2019 ob 17:19:31 CEST je meg...@megous.com napisal(a): > From: Ondrej Jirman > > I went through the datasheets for H6 and H5, and compared the differences. > RTCs are largely similar, but not entirely compatible. Incompatibilities > are in details not yet implemented by the rtc driver though. > > I also corrected the clock tree in H6 DTSI. > > This patchset is necessary for implementing the WiFi/Bluetooth support > on boards using H6 SoC. > > There was some discussion previously of describing HOSC, DCXO and XO > oscillators and clocks as part of RTC in DT, but I decided against it > because it's not necessary, becuse information that would be provided > as a part of DT can already be determined at runtime from RTC registers, > so this woudn't add any value and would only introduce complications > to the driver. See: https://patchwork.kernel.org/cover/10898083/ > > Please take a look. > > > Thank you and regards, > Ondrej Jirman Sorry for a bit late test, but with your patches on Tanix TX6 box I get this in dmesg: [ 17.431742] sun6i-rtc 700.rtc: Failed to set rtc time. [ 20.439742] sun6i-rtc 700.rtc: rtc is still busy. [ 21.435744] sun6i-rtc 700.rtc: rtc is still busy. [ 24.055741] sun6i-rtc 700.rtc: rtc is still busy. [ 24.439752] sun6i-rtc 700.rtc: rtc is still busy. Last line is repeated non-stop. Any idea what could be wrong? Best regards, Jernej
Re: [linux-sunxi] [PATCH v2 0/3] Add basic support for RTC on Allwinner H6 SoC
Dne sobota, 24. avgust 2019 ob 10:04:24 CEST je Jernej Škrabec napisal(a): > Hi! > > Dne torek, 20. avgust 2019 ob 17:19:31 CEST je meg...@megous.com napisal(a): > > From: Ondrej Jirman > > > > I went through the datasheets for H6 and H5, and compared the differences. > > RTCs are largely similar, but not entirely compatible. Incompatibilities > > are in details not yet implemented by the rtc driver though. > > > > I also corrected the clock tree in H6 DTSI. > > > > This patchset is necessary for implementing the WiFi/Bluetooth support > > on boards using H6 SoC. > > > > There was some discussion previously of describing HOSC, DCXO and XO > > oscillators and clocks as part of RTC in DT, but I decided against it > > because it's not necessary, becuse information that would be provided > > as a part of DT can already be determined at runtime from RTC registers, > > so this woudn't add any value and would only introduce complications > > to the driver. See: https://patchwork.kernel.org/cover/10898083/ > > > > Please take a look. > > > > > > Thank you and regards, > > > > Ondrej Jirman > > Sorry for a bit late test, but with your patches on Tanix TX6 box I get this > in dmesg: > > [ 17.431742] sun6i-rtc 700.rtc: Failed to set rtc time. > [ 20.439742] sun6i-rtc 700.rtc: rtc is still busy. > [ 21.435744] sun6i-rtc 700.rtc: rtc is still busy. > [ 24.055741] sun6i-rtc 700.rtc: rtc is still busy. > [ 24.439752] sun6i-rtc 700.rtc: rtc is still busy. > > Last line is repeated non-stop. > > Any idea what could be wrong? Additional info - this is on kernel 5.2.6 with your patches applied. Best regards, Jernej
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
Hi!
Dne torek, 20. avgust 2019 ob 17:19:33 CEST je meg...@megous.com napisal(a):
> From: Ondrej Jirman
>
> RTC on H6 is mostly the same as on H5 and H3. It has slight differences
> mostly in features that are not yet supported by this driver.
>
> Some differences are already stated in the comments in existing code.
> One other difference is that H6 has extra bit in LOSC_CTRL_REG, called
> EXT_LOSC_EN to enable/disable external low speed crystal oscillator.
>
> It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check whether
> external low speed oscillator is working correctly.
>
> This patch adds support for enabling LOSC when necessary:
>
> - during reparenting
> - when probing the clock
>
> H6 also has capacbility to automatically reparent RTC clock from
> external crystal oscillator, to internal RC oscillator, if external
> oscillator fails. This is enabled by default. Disable it during
> probe.
>
> Signed-off-by: Ondrej Jirman
> Reviewed-by: Chen-Yu Tsai
> ---
> drivers/rtc/rtc-sun6i.c | 40 ++--
> 1 file changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> index d50ee023b559..b0c3752bed3f 100644
> --- a/drivers/rtc/rtc-sun6i.c
> +++ b/drivers/rtc/rtc-sun6i.c
> @@ -32,9 +32,11 @@
> /* Control register */
> #define SUN6I_LOSC_CTRL 0x
> #define SUN6I_LOSC_CTRL_KEY (0x16aa << 16)
> +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS BIT(15)
User manual says that above field is bit 14.
Best regards,
Jernej
> #define SUN6I_LOSC_CTRL_ALM_DHMS_ACC BIT(9)
> #define SUN6I_LOSC_CTRL_RTC_HMS_ACC BIT(8)
> #define SUN6I_LOSC_CTRL_RTC_YMD_ACC BIT(7)
> +#define SUN6I_LOSC_CTRL_EXT_LOSC_EN BIT(4)
> #define SUN6I_LOSC_CTRL_EXT_OSC BIT(0)
> #define SUN6I_LOSC_CTRL_ACC_MASK GENMASK(9, 7)
>
> @@ -128,6 +130,8 @@ struct sun6i_rtc_clk_data {
> unsigned int has_prescaler : 1;
> unsigned int has_out_clk : 1;
> unsigned int export_iosc : 1;
> + unsigned int has_losc_en : 1;
> + unsigned int has_auto_swt : 1;
> };
>
> struct sun6i_rtc_dev {
> @@ -190,6 +194,10 @@ static int sun6i_rtc_osc_set_parent(struct clk_hw *hw,
> u8 index) val &= ~SUN6I_LOSC_CTRL_EXT_OSC;
> val |= SUN6I_LOSC_CTRL_KEY;
> val |= index ? SUN6I_LOSC_CTRL_EXT_OSC : 0;
> + if (rtc->data->has_losc_en) {
> + val &= ~SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> + val |= index ? SUN6I_LOSC_CTRL_EXT_LOSC_EN : 0;
> + }
> writel(val, rtc->base + SUN6I_LOSC_CTRL);
> spin_unlock_irqrestore(&rtc->lock, flags);
>
> @@ -215,6 +223,7 @@ static void __init sun6i_rtc_clk_init(struct device_node
> *node, const char *iosc_name = "rtc-int-osc";
> const char *clkout_name = "osc32k-out";
> const char *parents[2];
> + u32 reg;
>
> rtc = kzalloc(sizeof(*rtc), GFP_KERNEL);
> if (!rtc)
> @@ -235,9 +244,18 @@ static void __init sun6i_rtc_clk_init(struct
> device_node *node, goto err;
> }
>
> + reg = SUN6I_LOSC_CTRL_KEY;
> + if (rtc->data->has_auto_swt) {
> + /* Bypass auto-switch to int osc, on ext losc failure */
> + reg |= SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS;
> + writel(reg, rtc->base + SUN6I_LOSC_CTRL);
> + }
> +
> /* Switch to the external, more precise, oscillator */
> - writel(SUN6I_LOSC_CTRL_KEY | SUN6I_LOSC_CTRL_EXT_OSC,
> -rtc->base + SUN6I_LOSC_CTRL);
> + reg |= SUN6I_LOSC_CTRL_EXT_OSC;
> + if (rtc->data->has_losc_en)
> + reg |= SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> + writel(reg, rtc->base + SUN6I_LOSC_CTRL);
>
> /* Yes, I know, this is ugly. */
> sun6i_rtc = rtc;
> @@ -345,6 +363,23 @@ CLK_OF_DECLARE_DRIVER(sun8i_h3_rtc_clk,
> "allwinner,sun8i-h3-rtc", CLK_OF_DECLARE_DRIVER(sun50i_h5_rtc_clk,
> "allwinner,sun50i-h5-rtc", sun8i_h3_rtc_clk_init);
>
> +static const struct sun6i_rtc_clk_data sun50i_h6_rtc_data = {
> + .rc_osc_rate = 1600,
> + .fixed_prescaler = 32,
> + .has_prescaler = 1,
> + .has_out_clk = 1,
> + .export_iosc = 1,
> + .has_losc_en = 1,
> + .has_auto_swt = 1,
> +};
> +
> +static void __init sun50i_h6_rtc_clk_init(struct device_node *node)
> +{
> + sun6i_rtc_clk_init(node, &sun50i_h6_rtc_data);
> +}
> +CLK_OF_DECLARE_DRIVER(sun50i_h6_rtc_clk, "allwinner,sun50i-h6-rtc",
> + sun50i_h6_rtc_clk_init);
> +
> static const struct sun6i_rtc_clk_data sun8i_v3_rtc_data = {
> .rc_osc_rate = 32000,
> .has_out_clk = 1,
> @@ -675,6 +710,7 @@ static const struct of_device_id sun6i_rtc_dt_ids[] = {
> { .compatible = "allwinner,sun8i-r40-rtc" },
> { .compatible = "allwinner,sun8i-v3-rtc" },
> { .compatible = "allwinner,sun50i-h5-rtc" },
> + { .compatible = "allwinner,sun50i-h6-rtc" },
> { /* sentinel */ },
> };
> MODULE_DEVICE_TABLE(of, sun6i
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
Dne sobota, 24. avgust 2019 ob 14:46:54 CEST je Ondřej Jirman napisal(a):
> Hi,
>
> On Sat, Aug 24, 2019 at 02:32:32PM +0200, Jernej Škrabec wrote:
> > Hi!
> >
> > Dne torek, 20. avgust 2019 ob 17:19:33 CEST je meg...@megous.com
napisal(a):
> > > From: Ondrej Jirman
> > >
> > > RTC on H6 is mostly the same as on H5 and H3. It has slight differences
> > > mostly in features that are not yet supported by this driver.
> > >
> > > Some differences are already stated in the comments in existing code.
> > > One other difference is that H6 has extra bit in LOSC_CTRL_REG, called
> > > EXT_LOSC_EN to enable/disable external low speed crystal oscillator.
> > >
> > > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check whether
> > > external low speed oscillator is working correctly.
> > >
> > > This patch adds support for enabling LOSC when necessary:
> > >
> > > - during reparenting
> > > - when probing the clock
> > >
> > > H6 also has capacbility to automatically reparent RTC clock from
> > > external crystal oscillator, to internal RC oscillator, if external
> > > oscillator fails. This is enabled by default. Disable it during
> > > probe.
> > >
> > > Signed-off-by: Ondrej Jirman
> > > Reviewed-by: Chen-Yu Tsai
> > > ---
> > >
> > > drivers/rtc/rtc-sun6i.c | 40 ++--
> > > 1 file changed, 38 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> > > index d50ee023b559..b0c3752bed3f 100644
> > > --- a/drivers/rtc/rtc-sun6i.c
> > > +++ b/drivers/rtc/rtc-sun6i.c
> > > @@ -32,9 +32,11 @@
> > >
> > > /* Control register */
> > > #define SUN6I_LOSC_CTRL 0x
> > > #define SUN6I_LOSC_CTRL_KEY (0x16aa << 16)
> > >
> > > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS BIT(15)
> >
> > User manual says that above field is bit 14.
>
> See the previous discussion, this is from BSP.
I have two versions of BSP (don't ask me which) which have this set as bit 14
and changing this to 14 actually solves all my problems with LOSC (no more
issues with setting RTC and HDMI-CEC works now - it uses LOSC as parent) on
Tanix TX6 box.
Best regards,
Jernej
>
> regards,
> o.
>
> > Best regards,
> > Jernej
> >
> > > #define SUN6I_LOSC_CTRL_ALM_DHMS_ACC BIT(9)
> > > #define SUN6I_LOSC_CTRL_RTC_HMS_ACC BIT(8)
> > > #define SUN6I_LOSC_CTRL_RTC_YMD_ACC BIT(7)
> > >
> > > +#define SUN6I_LOSC_CTRL_EXT_LOSC_EN BIT(4)
> > >
> > > #define SUN6I_LOSC_CTRL_EXT_OSC BIT(0)
> > > #define SUN6I_LOSC_CTRL_ACC_MASK GENMASK(9, 7)
> > >
> > > @@ -128,6 +130,8 @@ struct sun6i_rtc_clk_data {
> > >
> > > unsigned int has_prescaler : 1;
> > > unsigned int has_out_clk : 1;
> > > unsigned int export_iosc : 1;
> > >
> > > + unsigned int has_losc_en : 1;
> > > + unsigned int has_auto_swt : 1;
> > >
> > > };
> > >
> > > struct sun6i_rtc_dev {
> > >
> > > @@ -190,6 +194,10 @@ static int sun6i_rtc_osc_set_parent(struct clk_hw
> > > *hw,
> > > u8 index) val &= ~SUN6I_LOSC_CTRL_EXT_OSC;
> > >
> > > val |= SUN6I_LOSC_CTRL_KEY;
> > > val |= index ? SUN6I_LOSC_CTRL_EXT_OSC : 0;
> > >
> > > + if (rtc->data->has_losc_en) {
> > > + val &= ~SUN6I_LOSC_CTRL_EXT_LOSC_EN;
> > > + val |= index ? SUN6I_LOSC_CTRL_EXT_LOSC_EN : 0;
> > > + }
> > >
> > > writel(val, rtc->base + SUN6I_LOSC_CTRL);
> > > spin_unlock_irqrestore(&rtc->lock, flags);
> > >
> > > @@ -215,6 +223,7 @@ static void __init sun6i_rtc_clk_init(struct
> > > device_node *node, const char *iosc_name = "rtc-int-osc";
> > >
> > > const char *clkout_name = "osc32k-out";
> > > const char *parents[2];
> > >
> > > + u32 reg;
> > >
> > > rtc = kzalloc(sizeof(*rtc), GFP_KERNEL);
> > > if (!rtc)
> > >
> > > @@ -235,9 +244,18 @@ static void __init sun6i_rtc_clk_init(struct
> > > device_node *node, goto err;
> > >
> > > }
> > >
> > > + reg =
Re: [linux-sunxi] [PATCH v2 0/3] Add basic support for RTC on Allwinner H6 SoC
Dne sobota, 24. avgust 2019 ob 14:56:12 CEST je Ondřej Jirman napisal(a): > Hi, > > On Sat, Aug 24, 2019 at 10:06:14AM +0200, Jernej Škrabec wrote: > > Dne sobota, 24. avgust 2019 ob 10:04:24 CEST je Jernej Škrabec napisal(a): > > > Hi! > > > > > > Dne torek, 20. avgust 2019 ob 17:19:31 CEST je meg...@megous.com napisal(a): > > > > From: Ondrej Jirman > > > > > > > > I went through the datasheets for H6 and H5, and compared the > > > > differences. > > > > RTCs are largely similar, but not entirely compatible. > > > > Incompatibilities > > > > are in details not yet implemented by the rtc driver though. > > > > > > > > I also corrected the clock tree in H6 DTSI. > > > > > > > > This patchset is necessary for implementing the WiFi/Bluetooth support > > > > on boards using H6 SoC. > > > > > > > > There was some discussion previously of describing HOSC, DCXO and XO > > > > oscillators and clocks as part of RTC in DT, but I decided against it > > > > because it's not necessary, becuse information that would be provided > > > > as a part of DT can already be determined at runtime from RTC > > > > registers, > > > > so this woudn't add any value and would only introduce complications > > > > to the driver. See: https://patchwork.kernel.org/cover/10898083/ > > > > > > > > Please take a look. > > > > > > > > > > > > Thank you and regards, > > > > > > > > Ondrej Jirman > > > > > > Sorry for a bit late test, but with your patches on Tanix TX6 box I get > > > this in dmesg: > > > > > > [ 17.431742] sun6i-rtc 700.rtc: Failed to set rtc time. > > > [ 20.439742] sun6i-rtc 700.rtc: rtc is still busy. > > > [ 21.435744] sun6i-rtc 700.rtc: rtc is still busy. > > > [ 24.055741] sun6i-rtc 700.rtc: rtc is still busy. > > > [ 24.439752] sun6i-rtc 700.rtc: rtc is still busy. > > > > > > Last line is repeated non-stop. > > > > > > Any idea what could be wrong? > > > > Additional info - this is on kernel 5.2.6 with your patches applied. > > Do you have schematics, or a FEX file for the board or any other info on how > the RTC is set up on that board? > > Can you dump the RTC register range? I have only Android DT, but as I already said in latest reply to patch 2, changing switch bypass to bit 14 instead of 15 solved all issues. Best regards, Jernej > > regards, > o. > > > Best regards, > > Jernej > > > > > > > > > > > > ___ > > linux-arm-kernel mailing list > > linux-arm-ker...@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
Dne sobota, 24. avgust 2019 ob 15:05:44 CEST je Ondřej Jirman napisal(a): > On Sat, Aug 24, 2019 at 02:51:54PM +0200, Jernej Škrabec wrote: > > Dne sobota, 24. avgust 2019 ob 14:46:54 CEST je Ondřej Jirman napisal(a): > > > Hi, > > > > > > On Sat, Aug 24, 2019 at 02:32:32PM +0200, Jernej Škrabec wrote: > > > > Hi! > > > > > > > > Dne torek, 20. avgust 2019 ob 17:19:33 CEST je meg...@megous.com > > > > napisal(a): > > > > > From: Ondrej Jirman > > > > > > > > > > RTC on H6 is mostly the same as on H5 and H3. It has slight > > > > > differences > > > > > mostly in features that are not yet supported by this driver. > > > > > > > > > > Some differences are already stated in the comments in existing > > > > > code. > > > > > One other difference is that H6 has extra bit in LOSC_CTRL_REG, > > > > > called > > > > > EXT_LOSC_EN to enable/disable external low speed crystal oscillator. > > > > > > > > > > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check > > > > > whether > > > > > external low speed oscillator is working correctly. > > > > > > > > > > This patch adds support for enabling LOSC when necessary: > > > > > > > > > > - during reparenting > > > > > - when probing the clock > > > > > > > > > > H6 also has capacbility to automatically reparent RTC clock from > > > > > external crystal oscillator, to internal RC oscillator, if external > > > > > oscillator fails. This is enabled by default. Disable it during > > > > > probe. > > > > > > > > > > Signed-off-by: Ondrej Jirman > > > > > Reviewed-by: Chen-Yu Tsai > > > > > --- > > > > > > > > > > drivers/rtc/rtc-sun6i.c | 40 > > > > > ++-- > > > > > 1 file changed, 38 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c > > > > > index d50ee023b559..b0c3752bed3f 100644 > > > > > --- a/drivers/rtc/rtc-sun6i.c > > > > > +++ b/drivers/rtc/rtc-sun6i.c > > > > > @@ -32,9 +32,11 @@ > > > > > > > > > > /* Control register */ > > > > > #define SUN6I_LOSC_CTRL 0x > > > > > #define SUN6I_LOSC_CTRL_KEY (0x16aa << 16) > > > > > > > > > > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS BIT(15) > > > > > > > > User manual says that above field is bit 14. > > > > > > See the previous discussion, this is from BSP. > > > > I have two versions of BSP (don't ask me which) which have this set as bit > > 14 and changing this to 14 actually solves all my problems with LOSC (no > > more issues with setting RTC and HDMI-CEC works now - it uses LOSC as > > parent) on Tanix TX6 box. > > Interesting. Is LOSC fed externally generated clock, or is it setup as a > crystal oscillator on your board? I really don't know, but here is DT: http://ix.io/1ThI > > Anyway, see here: > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.h?h=h6-4.9-bsp#n649 > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n652 Interesting, 4.9 BSP has additional bit definition, which is not documented in manual and 3.10 BSP to which I refer. I was referring to 3.10 BSP, which uses only bit 14. I thought that you named it differently. > > It would be nice to know what's really happening. > > My output is: > > [0.832252] sun6i-rtc 700.rtc: registered as rtc0 > [0.832257] sun6i-rtc 700.rtc: RTC enabled > [1.728968] sun6i-rtc 700.rtc: setting system clock to > 1970-01-01T00:00:07 UTC (7) With change, I get same output. > > I think, you may have just enabled the auto switch feature, and running the > clock from low precision RC oscillator with your patch. True, now I think there is no external crystal, but I'm still not sure how to confirm that. > > The real issue probably is that the mainline driver is missing this: > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n650 > Not sure what you mean by that. ext vs. int source selection? Best regards, Jernej > regards, > o. > > > Best regards, >
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
Dne sobota, 24. avgust 2019 ob 15:30:57 CEST je Ondřej Jirman napisal(a): > On Sat, Aug 24, 2019 at 03:16:41PM +0200, Jernej Škrabec wrote: > > Dne sobota, 24. avgust 2019 ob 15:05:44 CEST je Ondřej Jirman napisal(a): > > > On Sat, Aug 24, 2019 at 02:51:54PM +0200, Jernej Škrabec wrote: > > > > Dne sobota, 24. avgust 2019 ob 14:46:54 CEST je Ondřej Jirman napisal(a): > > > > > Hi, > > > > > > > > > > On Sat, Aug 24, 2019 at 02:32:32PM +0200, Jernej Škrabec wrote: > > > > > > Hi! > > > > > > > > > > > > Dne torek, 20. avgust 2019 ob 17:19:33 CEST je meg...@megous.com > > > > > > > > napisal(a): > > > > > > > From: Ondrej Jirman > > > > > > > > > > > > > > RTC on H6 is mostly the same as on H5 and H3. It has slight > > > > > > > differences > > > > > > > mostly in features that are not yet supported by this driver. > > > > > > > > > > > > > > Some differences are already stated in the comments in existing > > > > > > > code. > > > > > > > One other difference is that H6 has extra bit in LOSC_CTRL_REG, > > > > > > > called > > > > > > > EXT_LOSC_EN to enable/disable external low speed crystal > > > > > > > oscillator. > > > > > > > > > > > > > > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check > > > > > > > whether > > > > > > > external low speed oscillator is working correctly. > > > > > > > > > > > > > > This patch adds support for enabling LOSC when necessary: > > > > > > > > > > > > > > - during reparenting > > > > > > > - when probing the clock > > > > > > > > > > > > > > H6 also has capacbility to automatically reparent RTC clock from > > > > > > > external crystal oscillator, to internal RC oscillator, if > > > > > > > external > > > > > > > oscillator fails. This is enabled by default. Disable it during > > > > > > > probe. > > > > > > > > > > > > > > Signed-off-by: Ondrej Jirman > > > > > > > Reviewed-by: Chen-Yu Tsai > > > > > > > --- > > > > > > > > > > > > > > drivers/rtc/rtc-sun6i.c | 40 > > > > > > > ++-- > > > > > > > 1 file changed, 38 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c > > > > > > > index d50ee023b559..b0c3752bed3f 100644 > > > > > > > --- a/drivers/rtc/rtc-sun6i.c > > > > > > > +++ b/drivers/rtc/rtc-sun6i.c > > > > > > > @@ -32,9 +32,11 @@ > > > > > > > > > > > > > > /* Control register */ > > > > > > > #define SUN6I_LOSC_CTRL 0x > > > > > > > #define SUN6I_LOSC_CTRL_KEY (0x16aa > > > > << 16) > > > > > > > > > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS BIT(15) > > > > > > > > > > > > User manual says that above field is bit 14. > > > > > > > > > > See the previous discussion, this is from BSP. > > > > > > > > I have two versions of BSP (don't ask me which) which have this set as > > > > bit > > > > 14 and changing this to 14 actually solves all my problems with LOSC > > > > (no > > > > more issues with setting RTC and HDMI-CEC works now - it uses LOSC as > > > > parent) on Tanix TX6 box. > > > > > > Interesting. Is LOSC fed externally generated clock, or is it setup as a > > > crystal oscillator on your board? > > > > I really don't know, but here is DT: http://ix.io/1ThI > > > > > Anyway, see here: > > > > > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.h?h=h6-4.9-bsp#n > > > 649 > > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n > > > 652 > > > > Interesting, 4.9 BSP has additional bit definition, which is not > > documented in ma
Re: [linux-sunxi] [PATCH v2 2/3] rtc: sun6i: Add support for H6 RTC
Dne sobota, 24. avgust 2019 ob 23:27:46 CEST je Ondřej Jirman napisal(a): > Hello Jernej, > > On Sat, Aug 24, 2019 at 11:09:49PM +0200, Jernej Škrabec wrote: > > > Visually? > > > > > > That would explain why it doesn't work for you. The mainline RTC driver > > > disables auto-switch feature, and if your board doesn't have a crystal > > > for > > > LOSC, RTC will not generate a clock for the RTC. > > > > > > H6's dtsi describes by default a situatiuon with external 32k crystal > > > oscillator. See ext_osc32k node. That's incorrect for your board if it > > > doesn't have the crystal. You need to fix this in the DTS for your board > > > instead of patching the driver. > > > > I see that reparenting is supported, but I'm not sure how to fix that in > > DT. Any suggestion? > > You may try removing the clocks property from rtc node. I don't think this would work: https://elixir.bootlin.com/linux/latest/source/drivers/rtc/rtc-sun6i.c#L246 > > > > The driver has parent clock selection logic in case the LOSC crystal is > > > not > > > used. > > > > > > Your patch enables automatic detection of LOSC failure and RTC changes > > > clock to LOSC automatically, despite what's described in the DTS. That > > > may fix the issue, but is not the correct solution. > > > > > > Registers on my board look like this (external 32k osc is used) for > > > reference: > > > > > > LOSC_CTRL_REG[700]: 8011 > > > > > > KEY_FIELD ??? (0) > > > LOSC_AUTO_SWT_BYPASS EN (1) > > > LOSC_AUTO_SWT_EN DIS (0) > > > EXT_LOSC_ENEN (1) > > > EXT_LOSC_GSM LOW (0) > > > BATTERY_DIRDISCHARGE(0) > > > LOSC_SRC_SEL EXT32k (1) > > > > > > LOSC_AUTO_SWT_STA_REG[704]: 1 > > > > > > EXT_LOSC_STA OK (0) > > > LOSC_AUTO_SWT_PEND NOEFF(0) > > > LOSC_SRC_SEL_STA EXT32K (1) > > > > In my case LOSC_CTRL_REG has value 0x4010 and LOSC_AUTO_SWT_STA_REG > > has value 0x4, so there is issue with external crystal (it's missing) and > > RTC switched to internal one. > > > > BTW, what's wrong with automatic switching? Why is it disabled? > > It always was disabled on mainline (bit 14 was set to 0 even before my > patch). H6 just probably has another extra undocummented bit, that's needed > to disables it properly. > > You probably don't want a glitch to switch your RTC from high-precision > clock to a low precision one possibly without any indication in the > userspace or a kernel log. > > Regardless of all this, DTS needs to have a correct description of the HW, > which means if RTC module is not connected to the 32.757kHz crystal/clock, > clocks property should be empty. If we are talking about correct HW description, then clock property should actually have possibility that two clocks are defined - one for internal RC (always present) and one external crystal (optional). In such case I could really just omit external clock and be done with it. But I'm not sure if such solution is acceptable at this point. Best regards, Jernej > > regards, > o. > > > Best regards, > > Jernej > > > > > regards, > > > > > > o. > > > > > > > > The real issue probably is that the mainline driver is missing this: > > > > > > > > > > https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-b > > > > > sp#n > > > > > 650 > > > > > > > > Not sure what you mean by that. ext vs. int source selection? > > > > > > > > > > > > > > > > Best regards, > > > > Jernej > > > > > > > > > regards, > > > > > > > > > > o.
Re: [PATCH 5/8] media: cedrus: Detect first slice of a frame
Dne ponedeljek, 26. avgust 2019 ob 20:28:31 CEST je Boris Brezillon
napisal(a):
> Hi Jernej,
>
> On Thu, 22 Aug 2019 21:44:57 +0200
>
> Jernej Skrabec wrote:
> > When codec supports multiple slices in one frame, VPU has to know when
> > first slice of each frame is being processed, presumably to correctly
> > clear/set data in auxiliary buffers.
> >
> > Add first_slice field to cedrus_run structure and set it according to
> > timestamps of capture and output buffers. If timestamps are different,
> > it's first slice and viceversa.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 +
> > drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++
> > 2 files changed, 3 insertions(+)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > b/drivers/staging/media/sunxi/cedrus/cedrus.h index
> > 2f017a651848..32cb38e541c6 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> > @@ -70,6 +70,7 @@ struct cedrus_mpeg2_run {
> >
> > struct cedrus_run {
> >
> > struct vb2_v4l2_buffer *src;
> > struct vb2_v4l2_buffer *dst;
> >
> > + bool first_slice;
> >
> > union {
> >
> > struct cedrus_h264_run h264;
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c index
> > 56ca4c9ad01c..d7b54accfe83 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > @@ -31,6 +31,8 @@ void cedrus_device_run(void *priv)
> >
> > run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> > run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> >
> > + run.first_slice =
> > + run.src->vb2_buf.timestamp != run.dst-
>vb2_buf.timestamp;
>
> Can't we use slice->first_mb_in_slice to determine if a slice is the
> first? I'd expect ->first_mb_in_slice to be 0 (unless we decide to
> support ASO).
I'm not sure if that is always the case, I would have to check the standard.
Anyway, this method of comparing timestamps was suggested to me a while ago
when we were discussing details on a way forward for multi-slice decoding. I
highly doubt someone would decode slices in mixed order (from different frames)
in same instance.
I can change that in next version if ->first_mb_in_slice == 0 is always true
for the first slice.
Best regards,
Jernej
>
> > /* Apply request(s) controls if needed. */
> > src_req = run.src->vb2_buf.req_obj.req;
Re: [PATCH 7/8] media: cedrus: Add support for holding capture buffer
Dne četrtek, 29. avgust 2019 ob 13:23:29 CEST je Hans Verkuil napisal(a):
> On 8/22/19 9:44 PM, Jernej Skrabec wrote:
> > When frame contains multiple slices and driver works in slice mode, it's
> > more efficient to hold capture buffer in queue until all slices of a
> > same frame are decoded.
> >
> > Add support for that to Cedrus driver by exposing and implementing
> > V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF capability.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 9 +
> > drivers/staging/media/sunxi/cedrus/cedrus_hw.c| 8 +---
> > drivers/staging/media/sunxi/cedrus/cedrus_video.c | 1 +
> > 3 files changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c index
> > d7b54accfe83..68462b99750e 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > @@ -31,6 +31,14 @@ void cedrus_device_run(void *priv)
> >
> > run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> > run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> >
> > +
> > + if (v4l2_m2m_release_capture_buf(run.src, run.dst)) {
> > + v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> > + v4l2_m2m_buf_done(run.dst, VB2_BUF_STATE_DONE);
> > + run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> > + }
> > + run.dst->is_held = run.src->flags &
V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF;
> > +
> >
> > run.first_slice =
> >
> > run.src->vb2_buf.timestamp != run.dst-
>vb2_buf.timestamp;
> >
> > @@ -46,6 +54,7 @@ void cedrus_device_run(void *priv)
> >
> > V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);
> >
> > run.mpeg2.quantization = cedrus_find_control_data(ctx,
> >
> > V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
> >
> > + run.dst->is_held = false;
> >
> > break;
> >
> > case V4L2_PIX_FMT_H264_SLICE:
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c index
> > a942cd9bed57..99fedec80224 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
> > @@ -122,7 +122,7 @@ static irqreturn_t cedrus_irq(int irq, void *data)
> >
> > dev->dec_ops[ctx->current_codec]->irq_clear(ctx);
> >
> > src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> >
> > - dst_buf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> > + dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> >
> > if (!src_buf || !dst_buf) {
> >
> > v4l2_err(&dev->v4l2_dev,
> >
> > @@ -136,8 +136,10 @@ static irqreturn_t cedrus_irq(int irq, void *data)
> >
> > state = VB2_BUF_STATE_DONE;
> >
> > v4l2_m2m_buf_done(src_buf, state);
> >
> > - v4l2_m2m_buf_done(dst_buf, state);
> > -
> > + if (!dst_buf->is_held) {
> > + v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> > + v4l2_m2m_buf_done(dst_buf, state);
> > + }
> >
> > v4l2_m2m_job_finish(ctx->dev->m2m_dev, ctx->fh.m2m_ctx);
> >
> > return IRQ_HANDLED;
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_video.c index
> > 3efd247b..5153b2bba21e 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > @@ -515,6 +515,7 @@ int cedrus_queue_init(void *priv, struct vb2_queue
> > *src_vq,>
> > src_vq->type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
> > src_vq->io_modes = VB2_MMAP | VB2_DMABUF;
> > src_vq->drv_priv = ctx;
> >
> > + src_vq->subsystem_flags =
VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF;
>
> This isn't quite right: this flag should only be set for formats that
> support slicing. So cedrus_s_fmt_vid_out() should set this for H264, but
> clear it for MPEG2.
>
> Looking at the cedrus code it seems that it does not set an initial default
> output format after opening the video device. This seems wrong to me. If it
> did set a default output format, then src_vq->subsystem_flags should set
> this flag corresponding to the default output format.
Ok, I'll base v2 series on your "cedrus: v4l2-compliance fixes", because it has
some useful changes for this case.
Best regards,
Jernej
>
> > src_vq->buf_struct_size = sizeof(struct cedrus_buffer);
> > src_vq->min_buffers_needed = 1;
> > src_vq->ops = &cedrus_qops;
>
> Regards,
>
> Hans
Re: [PATCH 3/6] ARM: dts: sunxi: h3/h5: Add MBUS controller node
Dne četrtek, 12. september 2019 ob 22:20:57 CEST je Maxime Ripard napisal(a):
> Hi,
>
> On Thu, Sep 12, 2019 at 07:51:29PM +0200, Jernej Skrabec wrote:
> > Both, H3 and H5, contain MBUS, which is the bus used by DMA devices to
> > access system memory.
> >
> > MBUS controller is responsible for arbitration between channels based
> > on set priority and can do some other things as well, like report
> > bandwidth used. It also maps RAM region to different address than CPU.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > arch/arm/boot/dts/sunxi-h3-h5.dtsi | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > b/arch/arm/boot/dts/sunxi-h3-h5.dtsi index eba190b3f9de..ef1d03812636
> > 100644
> > --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > @@ -109,6 +109,7 @@
> >
> > compatible = "simple-bus";
> > #address-cells = <1>;
> > #size-cells = <1>;
> >
> > + dma-ranges;
> >
> > ranges;
> >
> > display_clocks: clock@100 {
> >
> > @@ -538,6 +539,14 @@
> >
> > };
> >
> > };
> >
> > + mbus: dram-controller@1c62000 {
> > + compatible = "allwinner,sun8i-h3-mbus";
> > + reg = <0x01c62000 0x1000>;
> > + clocks = <&ccu 113>;
> > + dma-ranges = <0x 0x4000
0xc000>;
> > + #interconnect-cells = <1>;
> > + };
> > +
>
> If that's easy enough to access, can you also add the references in
> the devices that are already there? (CSI and DE comes to my mind, but
> there might be others).
Strangely, DE2 doesn't use this offset. That was tested on OrangePi Plus2E,
which has 2 GiB of RAM and subtracting this offset causes corrupted image.
But I can add this properties to CSI too. However, wouldn't that need CSI DT
binding expansion with those properties? othetwise DT check will fail.
Best regards,
Jernej
>
> Thanks!
> Maxime
Re: [PATCH 5/6] media: sun4i: Add H3 deinterlace driver
Dne četrtek, 12. september 2019 ob 22:26:47 CEST je Maxime Ripard napisal(a):
> Hi,
>
> On Thu, Sep 12, 2019 at 07:51:31PM +0200, Jernej Skrabec wrote:
> > + dev->regmap = devm_regmap_init_mmio(dev->dev, dev->base,
> > +
&deinterlace_regmap_config);
> > + if (IS_ERR(dev->regmap)) {
> > + dev_err(dev->dev, "Couldn't create deinterlace
regmap\n");
> > +
> > + return PTR_ERR(dev->regmap);
> > + }
> > +
> > + ret = clk_prepare_enable(dev->bus_clk);
> > + if (ret) {
> > + dev_err(dev->dev, "Failed to enable bus clock\n");
> > +
> > + return ret;
> > + }
>
> Do you need to keep the bus clock enabled all the time? Usually, for
> the SoCs that have a reset line, you only need it to read / write to
> the registers, not to have the controller actually running.
>
> If you don't, then regmap_init_mmio_clk will take care of that for
> you.
I'll test that.
>
> > + clk_set_rate(dev->mod_clk, 3);
> > +
> > + ret = clk_prepare_enable(dev->mod_clk);
> > + if (ret) {
> > + dev_err(dev->dev, "Failed to enable mod clock\n");
> > +
> > + goto err_bus_clk;
> > + }
> > +
> > + ret = clk_prepare_enable(dev->ram_clk);
> > + if (ret) {
> > + dev_err(dev->dev, "Failed to enable ram clock\n");
> > +
> > + goto err_mod_clk;
> > + }
> > +
> > + ret = reset_control_reset(dev->rstc);
> > + if (ret) {
> > + dev_err(dev->dev, "Failed to apply reset\n");
> > +
> > + goto err_ram_clk;
> > + }
>
> This could be moved to a runtime_pm hook, with get_sync called in the
> open. That way you won't leave the device powered on if it's unused.
Ok.
>
> > +struct deinterlace_dev {
> > + struct v4l2_device v4l2_dev;
> > + struct video_device vfd;
> > + struct device *dev;
> > + struct v4l2_m2m_dev *m2m_dev;
> > +
> > + /* Device file mutex */
> > + struct mutexdev_mutex;
> > +
> > + void __iomem*base;
> > + struct regmap *regmap;
>
> Do you need to store the base address in that structure if you're
> using the regmap?
Probably not. I'll remove it in v2.
Best regards,
Jernej
>
> Maxime
Re: [PATCH 3/6] ARM: dts: sunxi: h3/h5: Add MBUS controller node
Dne četrtek, 12. september 2019 ob 22:34:27 CEST je Maxime Ripard napisal(a):
> On Thu, Sep 12, 2019 at 10:28:37PM +0200, Jernej Škrabec wrote:
> > Dne četrtek, 12. september 2019 ob 22:20:57 CEST je Maxime Ripard
napisal(a):
> > > Hi,
> > >
> > > On Thu, Sep 12, 2019 at 07:51:29PM +0200, Jernej Skrabec wrote:
> > > > Both, H3 and H5, contain MBUS, which is the bus used by DMA devices to
> > > > access system memory.
> > > >
> > > > MBUS controller is responsible for arbitration between channels based
> > > > on set priority and can do some other things as well, like report
> > > > bandwidth used. It also maps RAM region to different address than CPU.
> > > >
> > > > Signed-off-by: Jernej Skrabec
> > > > ---
> > > >
> > > > arch/arm/boot/dts/sunxi-h3-h5.dtsi | 9 +
> > > > 1 file changed, 9 insertions(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > > > b/arch/arm/boot/dts/sunxi-h3-h5.dtsi index eba190b3f9de..ef1d03812636
> > > > 100644
> > > > --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > > > +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > > > @@ -109,6 +109,7 @@
> > > >
> > > > compatible = "simple-bus";
> > > > #address-cells = <1>;
> > > > #size-cells = <1>;
> > > >
> > > > + dma-ranges;
> > > >
> > > > ranges;
> > > >
> > > > display_clocks: clock@100 {
> > > >
> > > > @@ -538,6 +539,14 @@
> > > >
> > > > };
> > > >
> > > > };
> > > >
> > > > + mbus: dram-controller@1c62000 {
> > > > + compatible = "allwinner,sun8i-h3-mbus";
> > > > + reg = <0x01c62000 0x1000>;
> > > > + clocks = <&ccu 113>;
> > > > + dma-ranges = <0x 0x4000
> >
> > 0xc000>;
> >
> > > > + #interconnect-cells = <1>;
> > > > + };
> > > > +
> > >
> > > If that's easy enough to access, can you also add the references in
> > > the devices that are already there? (CSI and DE comes to my mind, but
> > > there might be others).
> >
> > Strangely, DE2 doesn't use this offset. That was tested on OrangePi
> > Plus2E,
> > which has 2 GiB of RAM and subtracting this offset causes corrupted image.
>
> Ok, weird. But if it was tested then fine by me :)
>
> > But I can add this properties to CSI too. However, wouldn't that need CSI
> > DT binding expansion with those properties? othetwise DT check will fail.
> Oh right, we definitely need to update the binding indeed. The code
> should be able to cope with both cases already.
I guess it's better to handle that with another patch series then? Changing
CSI bindings doesn't fit here.
Best regards,
Jernej
Re: [PATCH 5/6] media: sun4i: Add H3 deinterlace driver
Hi! Dne petek, 13. september 2019 ob 11:11:47 CEST je Maxime Ripard napisal(a): > Hi, > > On Thu, Sep 12, 2019 at 10:43:28PM +0200, Jernej Škrabec wrote: > > Dne četrtek, 12. september 2019 ob 22:26:47 CEST je Maxime Ripard napisal(a): > > > > + clk_set_rate(dev->mod_clk, 3); > > I just realized I missed this too. If you really need the rate to be > fixed, and if the controller cannot operate properly at any other > frequency, you probably want to use clk_set_rate_exclusive there. I don't think that's needed. Parents of deinterlace clock are pll-periph0 and pll-periph1 which both have fixed clock and thus deinterlace clock will never be changed. I just set it to same frequency as it is set in BSP driver. I think it works with 600 MHz too, but that's overkill. Best regards, Jernej
