[linux-sunxi] Re: [PATCH v2 15/20] drm/sun4i: Ignore the generic connectors for components

[Chen-Yu Tsai]

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
 wrote:
> The generic connectors such as hdmi-connector doesn't have any driver in,
> so if they are added to the component list, we will be waiting forever for
> a non-existing driver to probe.
>
> Add a list of the connectors we want to ignore when building our component
> list.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/sun4i_drv.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 8ddd72cd5873..8c9d2e36be55 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -164,6 +164,11 @@ static const struct component_master_ops 
> sun4i_drv_master_ops = {
> .unbind = sun4i_drv_unbind,
>  };
>
> +static bool sun4i_drv_node_is_connector(struct device_node *node)
> +{
> +   return of_device_is_compatible(node, "hdmi-connector");
> +}
> +
>  static bool sun4i_drv_node_is_frontend(struct device_node *node)
>  {
> return of_device_is_compatible(node, 
> "allwinner,sun5i-a13-display-frontend") ||
> @@ -204,7 +209,8 @@ static int sun4i_drv_add_endpoints(struct device *dev,
> !of_device_is_available(node))
> return 0;
>
> -   if (!sun4i_drv_node_is_frontend(node)) {
> +   if (!sun4i_drv_node_is_connector(node) &&

I think it's better to just bail out (return 0) if the current node
is a connector. The connector is the end of the pipeline anyway.
Nothing after it should be considered for the component graph.
The way you currently have it, traversal will continue beyond
the connector node.

ChenYu

> +   !sun4i_drv_node_is_frontend(node)) {
> /* Add current component */
> DRM_DEBUG_DRIVER("Adding component %s\n",
>  of_node_full_name(node));
> --
> git-series 0.8.11

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 14/20] drm/sun4i: tcon: multiply the vtotal when not in interlace

[Chen-Yu Tsai]

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
 wrote:
> It appears that the total vertical resolution needs to be doubled when
> we're not in interlaced. Make sure that is the case.

I think the total vertical resolution needs to be doubled in all cases.
It just happens that you should've been using mode->crtc_vtotal, which
is halved when the mode is interlaced. Instead you used mode->vtotal,
which is double the actual scan resolution in interlaced mode.

ChenYu

> Signed-off-by: Maxime Ripard 
> ---
>  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 0f91ec8a4b26..efa079c1a3f5 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -272,9 +272,9 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
> /* Set vertical display timings */
> bp = mode->crtc_vtotal - mode->crtc_vsync_start;
> DRM_DEBUG_DRIVER("Setting vertical total %d, backporch %d\n",
> -mode->vtotal, bp);
> +mode->crtc_vtotal, bp);
> regmap_write(tcon->regs, SUN4I_TCON1_BASIC4_REG,
> -SUN4I_TCON1_BASIC4_V_TOTAL(mode->vtotal) |
> +SUN4I_TCON1_BASIC4_V_TOTAL(mode->crtc_vtotal * 2) |
>  SUN4I_TCON1_BASIC4_V_BACKPORCH(bp));
>
> /* Set Hsync and Vsync length */
> --
> git-series 0.8.11

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 13/20] drm/sun4i: tcon: Change vertical total size computation inconsistency

[Chen-Yu Tsai]

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
 wrote:
> Both TCON channels need to have the resolution doubled, since the size the
> hardware is going to use is whatever we put in the register divided by two.
>
> However, we handle it differently for the two channels: in the channel 0,
> our register access macro does the multiplication of the value passed as
> paremeter, while in the channel 1, the macro doesn't do this, and we need
> to do it before calling it.
>
> Make this consistent by aligning the channel 0 with the channel 1
> behaviour.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 11/20] drm/sun4i: tcon: Switch mux on only for composite

[Chen-Yu Tsai]

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
 wrote:
> Even though that mux is undocumented, it seems like it needs to be set to 1
> when using composite, and 0 when using HDMI.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 10/20] drm/sun4i: tcon: Move the muxing out of the mode set function

[Chen-Yu Tsai]

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
 wrote:
> The muxing can actually happen on both channels on some SoCs, so it makes
> more sense to just move it out of the sun4i_tcon1_mode_set function and
> create a separate function that needs to be called by the encoders.
>
> Let's do that and convert the existing drivers.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/sun4i/sun4i_rgb.c  |  1 +
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 22 --
>  drivers/gpu/drm/sun4i/sun4i_tcon.h |  2 ++
>  drivers/gpu/drm/sun4i/sun4i_tv.c   |  1 +
>  4 files changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
> b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> index 67f0b91a99de..3003d290c635 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> @@ -175,6 +175,7 @@ static void sun4i_rgb_encoder_mode_set(struct drm_encoder 
> *encoder,
> struct sun4i_tcon *tcon = rgb->tcon;
>
> sun4i_tcon0_mode_set(tcon, mode);
> +   sun4i_tcon_set_mux(tcon, 0, encoder);
>
> clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 66a5bb9b85e9..0204d9fadb66 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -108,6 +108,22 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, 
> bool enable)
>  }
>  EXPORT_SYMBOL(sun4i_tcon_enable_vblank);
>
> +void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel,
> +   struct drm_encoder *encoder)

The channel doesn't really matter. What is needed is which TCON and encoder
are supposed to be muxed together. This is going to be per SoC type anyway.

I have something in the works, though it's not finished yet.
I think this works for now.

Acked-by: Chen-Yu Tsai 

> +{
> +   if (!tcon->quirks->has_unknown_mux)
> +   return;
> +
> +   if (channel != 1)
> +   return;
> +
> +   /*
> +* FIXME: Undocumented bits
> +*/
> +   regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, 1);
> +}
> +EXPORT_SYMBOL(sun4i_tcon_set_mux);
> +
>  static int sun4i_tcon_get_clk_delay(struct drm_display_mode *mode,
> int channel)
>  {
> @@ -266,12 +282,6 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
> regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG,
>SUN4I_TCON_GCTL_IOMAP_MASK,
>SUN4I_TCON_GCTL_IOMAP_TCON1);
> -
> -   /*
> -* FIXME: Undocumented bits
> -*/
> -   if (tcon->quirks->has_unknown_mux)
> -   regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, 1);
>  }
>  EXPORT_SYMBOL(sun4i_tcon1_mode_set);
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> index f636343a935d..0350936b413c 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> @@ -190,6 +190,8 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, 
> bool enable);
>  /* Mode Related Controls */
>  void sun4i_tcon_switch_interlace(struct sun4i_tcon *tcon,
>  bool enable);
> +void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel,
> +   struct drm_encoder *encoder);
>  void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
>   struct drm_display_mode *mode);
>  void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c 
> b/drivers/gpu/drm/sun4i/sun4i_tv.c
> index 49c49431a053..03c494b8159c 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
> @@ -393,6 +393,7 @@ static void sun4i_tv_mode_set(struct drm_encoder *encoder,
> const struct tv_mode *tv_mode = sun4i_tv_find_tv_by_mode(mode);
>
> sun4i_tcon1_mode_set(tcon, mode);
> +   sun4i_tcon_set_mux(tcon, 1, encoder);
>
> /* Enable and map the DAC to the output */
> regmap_update_bits(tv->regs, SUN4I_TVE_EN_REG,
> --
> git-series 0.8.11

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 8/20] clk: sunxi-ng: sun5i: Export video PLLs

[Chen-Yu Tsai]

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
 wrote:
> The video PLLs are used directly by the HDMI controller. Export them so
> that we can use them in our DT node.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 7/20] clk: sunxi-ng: mux: Re-adjust parent rate

[Chen-Yu Tsai]

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
 wrote:
> Currently, the parent rate given back to the clock framework in our
> request is the original parent rate we calculated before trying to round
> the rate of our clock.
>
> This works fine unless our clock also changes its parent rate, in which
> case we will simply ignore that change and still use the previous parent
> rate.
>
> Create a new function to re-adjust the parent rate to take the pre-dividers
> into account, and give that back to the clock framework.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/clk/sunxi-ng/ccu_mux.c | 33 -
>  1 file changed, 28 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
> index c33210972581..1ce62cc23f8a 100644
> --- a/drivers/clk/sunxi-ng/ccu_mux.c
> +++ b/drivers/clk/sunxi-ng/ccu_mux.c
> @@ -64,6 +64,14 @@ unsigned long ccu_mux_helper_apply_prediv(struct 
> ccu_common *common,
> return parent_rate / ccu_mux_get_prediv(common, cm, parent_index);
>  }
>
> +unsigned long ccu_mux_helper_unapply_prediv(struct ccu_common *common,
> +   struct ccu_mux_internal *cm,
> +   int parent_index,
> +   unsigned long parent_rate)
> +{
> +   return parent_rate * ccu_mux_get_prediv(common, cm, parent_index);
> +}
> +
>  int ccu_mux_helper_determine_rate(struct ccu_common *common,
>   struct ccu_mux_internal *cm,
>   struct clk_rate_request *req,
> @@ -89,22 +97,37 @@ int ccu_mux_helper_determine_rate(struct ccu_common 
> *common,
> best_rate = round(cm, best_parent, _parent_rate,
>   req->rate, data);
>
> +   /*
> +* parent_rate might have been modified by our clock.
> +* Re-apply the pre-divider if there's one, and give

Might want to reword the comments to match the new name.

> +* the actual frequency the parent needs to run at.
> +*/
> +   best_parent_rate = ccu_mux_helper_unapply_prediv(common, cm, 
> -1,
> +
> adj_parent_rate);
> +
> goto out;
> }
>
> for (i = 0; i < clk_hw_get_num_parents(hw); i++) {
> -   unsigned long tmp_rate, parent_rate, adj_parent_rate;
> +   unsigned long tmp_rate, parent_rate;
> struct clk_hw *parent;
>
> parent = clk_hw_get_parent_by_index(hw, i);
> if (!parent)
> continue;
>
> -   parent_rate = clk_hw_get_rate(parent);
> -   adj_parent_rate = ccu_mux_helper_apply_prediv(common, cm, i,
> - parent_rate);
> +   parent_rate = ccu_mux_helper_apply_prediv(common, cm, i,
> + 
> clk_hw_get_rate(parent));
> +
> +   tmp_rate = round(cm, parent, _rate, req->rate, data);
>
> -   tmp_rate = round(cm, parent, _parent_rate, req->rate, 
> data);
> +   /*
> +* parent_rate might have been modified by our clock.
> +* Re-apply the pre-divider if there's one, and give

Same here. Otherwise,

Acked-by: Chen-Yu Tsai 

> +* the actual frequency the parent needs to run at.
> +*/
> +   parent_rate = ccu_mux_helper_unapply_prediv(common, cm, i,
> +   parent_rate);
> if (tmp_rate == req->rate) {
> best_parent = parent;
> best_parent_rate = parent_rate;
> --
> git-series 0.8.11

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 6/20] clk: sunxi-ng: mux: Change pre-divider application function prototype

[Chen-Yu Tsai]

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
 wrote:
> The current function name is a bit confusing, and doesn't really allow to
> create an explicit function to reverse the operation.
>
> We also for now change the parent rate through a pointer, while we don't
> return anything.
>
> In order to be less confusing, and easier to use for downstream users,
> change the function name to something hopefully clearer, and return the
> adjusted rate instead of changing the pointer.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 5/20] clk: sunxi-ng: mux: split out the pre-divider computation code

[Chen-Yu Tsai]

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
 wrote:
> The pre-divider retrieval code was merged into the function to apply the
> current pre-divider onto the parent clock rate so that we can use that
> adjusted value to do our factors computation.
>
> However, since we'll need to do the reverse operation, we need to split out
> that code into a function that will be shared.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Seems this would conflict with my "clk: sunxi-ng: Support multiple variable
pre-dividers" patch though. We'll see how this works out.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 4/20] clk: sunxi-ng: mux: Don't just rely on the parent for CLK_SET_RATE_PARENT

[Chen-Yu Tsai]

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
 wrote:
> The current code only rely on the parent to change its rate in the case
> where CLK_SET_RATE_PARENT is set.
>
> However, some clock rates might be obtained only through a modification of
> the parent and the clock divider. Just rely on the round rate of the clocks
> to give us the best computation that might be achieved for a given rate.
>
> round_rate functions now need to honor CLK_SET_RATE_PARENT, but either the
> functions already do that if they modify the parent, or don't modify the
> praents at all.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 3/20] clk: sunxi-ng: div: Switch to divider_round_rate

[Chen-Yu Tsai]

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
 wrote:
> divider_round_rate already evaluates changing the parent rate if

  ^^^ Might want to update this, as you are now using the new function
  you added in patch 1.

> CLK_SET_RATE_PARENT is set. Now that we can do that on muxes too, let's
> just use it.
>
> Signed-off-by: Maxime Ripard 

Otherwise,

Acked-by: Chen-Yu Tsai 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 2/20] clk: sunxi-ng: Pass the parent and a pointer to the clocks round rate

[Chen-Yu Tsai]

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
 wrote:
> The clocks might need to modify their parent clocks. In order to make that
> possible, give them access to the parent clock being evaluated, and to a
> pointer to the parent rate so that they can modify it if needed.
>
> Signed-off-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 3/8] clk: sunxi-ng: Add class of phase clocks supporting MMC new timing modes

[Chen-Yu Tsai]

Hi,

On Thu, May 4, 2017 at 4:34 AM, Maxime Ripard
 wrote:
> Hi,
>
> On Wed, May 03, 2017 at 11:16:53AM +0800, Chen-Yu Tsai wrote:
>> The MMC clocks on newer SoCs, such as the A83T and H3, support the
>> "new timing mode". Under this mode, the output of the clock is divided
>> by 2, and the clock delays no longer apply.
>>
>> Due to how the clock tree is modeled and setup, we need to model
>> this function in two places, the master mmc clock and the two
>> child phase clocks. In the mmc clock, we can easily model the
>> mode bit as an extra variable post-divider. In the phase clocks,
>> we check the bit and return -ENOTSUPP if the bit is set, signaling
>> that the phase clocks are not to be used.
>>
>> This patch introduces a class of phase clocks that checks the
>> timing mode bit.
>
> We've been over this quite some times already...
>
> How do you retrieve the mode used in the clock so that you can also
> switch the MMC driver in the new mode?

This part is covered. As mentioned above, the phase clks will return
-ENOTSUPP if the mmc clk is set in the new timing mode. The MMC driver
would try getting the current phase, check if it fails, and if it does,
realizes the clk is in new timing mode, and will switch the mmc controller
to it as well. I think this semantic fits the hardware well enough,
though it might be confusing without the accompanying comments.

See this commit for an example on how it should work.
https://github.com/wens/linux/commit/41e386f1f945a0a135a20a00601b977a001353da

> And do you prevent that from happening on the DT we already have that
> use the old clock drivers that do not support this new timing at all?

I admit this is not taken care of in this patch. Mostly because there
is no existing DT for the A83T to cater to. For the H3 and other SoCs
that do, we need some way of asking the CCU to switch the mode.

IIRC the output and sample clocks do not support a phase delay of 0.
So what if we design the semantic for this class of clocks as, if
phase == 0, switch to new timing mode, otherwise use old timing mode?
That would allow us to support this without adding extra functions,
and kind of matches what the hardware does. If you're using the new
timing mode, the delays in the mmc clk are bypassed.

Regards
ChenYu

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH] pinctrl: use non-devm kmalloc versions for free functions

[Andre Przywara]

When a pinctrl driver gets interrupted during its probe process
(returning -EPROBE_DEFER), the devres system cleans up all allocated
resources. During this process it calls pinmux_generic_free_functions()
and pinctrl_generic_free_groups(), which in turn use managed kmalloc
calls for temporarily allocating some memory. Now those calls seem to
get added to the devres list, but are apparently not covered by the
cleanup process, because this is actually just running and iterating the
existing list. This leads to those mallocs being left with the device,
which the devres manager complains about when the driver eventually gets
probed again:
[0.825239] [ cut here ]
[0.825256] WARNING: CPU: 1 PID: 89 at drivers/base/dd.c:349 
driver_probe_device+0x2ac/0x2e8
[0.825258] Modules linked in:
[0.825262]
[0.825270] CPU: 1 PID: 89 Comm: kworker/1:1 Not tainted 4.11.0 #307
[0.825272] Hardware name: Pine64+ (DT)
[0.825283] Workqueue: events deferred_probe_work_func
[0.825288] task: 80007c19c100 task.stack: 80007c16c000
[0.825292] PC is at driver_probe_device+0x2ac/0x2e8
[0.825296] LR is at driver_probe_device+0x108/0x2e8
[0.825300] pc : [] lr : [] pstate: 
2045

This warning is triggered because the devres list is not empty. In this
case the allocations were using 0 bytes, so no real leaks, but still this
ugly warning.
Looking more closely at these *cleanup* functions, devm_kzalloc() is actually
not needed, because the memory is just allocated temporarily and can be
freed just before returning from this function.
So fix this issue by using the bog standard kcalloc() call instead of
devm_kzalloc() and kfree()ing the memory at the end.

This fixes above warnings on boot, which can be observed on *some* builds
for the Pine64, where the pinctrl driver gets loaded early, but it missing
resources, so gets deferred and is loaded again (successfully) later.
kernelci caught this as well [1].

Signed-off-by: Andre Przywara 

[1] 
https://storage.kernelci.org/net-next/master/v4.11-rc8-2122-gc08bac03d289/arm64/defconfig/lab-baylibre-seattle/boot-sun50i-a64-pine64-plus.html
---
Hi,

not sure this is the right fix, I am open to suggestions.

Cheers,
Andre.

 drivers/pinctrl/core.c   | 5 +++--
 drivers/pinctrl/pinmux.c | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 32822b0d..5198415 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -690,8 +690,8 @@ static void pinctrl_generic_free_groups(struct pinctrl_dev 
*pctldev)
void **slot;
int i = 0;
 
-   indices = devm_kzalloc(pctldev->dev, sizeof(*indices) *
-  pctldev->num_groups, GFP_KERNEL);
+   indices = kcalloc(pctldev->num_groups, sizeof(*indices),
+ GFP_KERNEL);
if (!indices)
return;
 
@@ -704,6 +704,7 @@ static void pinctrl_generic_free_groups(struct pinctrl_dev 
*pctldev)
radix_tree_delete(>pin_group_tree, indices[i]);
devm_kfree(pctldev->dev, group);
}
+   kfree(indices);
 
pctldev->num_groups = 0;
 }
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 29ad315..6a70339 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -836,8 +836,8 @@ void pinmux_generic_free_functions(struct pinctrl_dev 
*pctldev)
void **slot;
int i = 0;
 
-   indices = devm_kzalloc(pctldev->dev, sizeof(*indices) *
-  pctldev->num_functions, GFP_KERNEL);
+   indices = kcalloc(pctldev->num_functions, sizeof(*indices),
+ GFP_KERNEL);
if (!indices)
return;
 
@@ -850,6 +850,7 @@ void pinmux_generic_free_functions(struct pinctrl_dev 
*pctldev)
radix_tree_delete(>pin_function_tree, indices[i]);
devm_kfree(pctldev->dev, function);
}
+   kfree(indices);
 
pctldev->num_functions = 0;
 }
-- 
2.8.2

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 3/8] clk: sunxi-ng: Add class of phase clocks supporting MMC new timing modes

[Maxime Ripard]

Hi,

On Wed, May 03, 2017 at 11:16:53AM +0800, Chen-Yu Tsai wrote:
> The MMC clocks on newer SoCs, such as the A83T and H3, support the
> "new timing mode". Under this mode, the output of the clock is divided
> by 2, and the clock delays no longer apply.
> 
> Due to how the clock tree is modeled and setup, we need to model
> this function in two places, the master mmc clock and the two
> child phase clocks. In the mmc clock, we can easily model the
> mode bit as an extra variable post-divider. In the phase clocks,
> we check the bit and return -ENOTSUPP if the bit is set, signaling
> that the phase clocks are not to be used.
> 
> This patch introduces a class of phase clocks that checks the
> timing mode bit.

We've been over this quite some times already...

How do you retrieve the mode used in the clock so that you can also
switch the MMC driver in the new mode?

And do you prevent that from happening on the DT we already have that
use the old clock drivers that do not support this new timing at all?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
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.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH] clk: sunxi-ng: a31: Correct lcd1-ch1 clock register offset

[Maxime Ripard]

On Wed, May 03, 2017 at 11:13:46AM +0800, Chen-Yu Tsai wrote:
> The register offset for the lcd1-ch1 clock was incorrectly pointing to
> the lcd0-ch1 clock. This resulted in the lcd0-ch1 clock being disabled
> when the clk core disables unused clocks. This then stops the simplefb
> HDMI output path.
> 
> Reported-by: Bob Ham 
> Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
> Cc: sta...@vger.kernel.org # 4.9.x-
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
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.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [linux-sunxi] Re: [PATCH] sun7i: Add support for Olimex A20-OLinuXino-LIME2-eMMC

[Icenowy Zheng]

于 2017年5月4日 GMT+08:00 上午12:50:52, Jagan Teki  写到:
>On Wednesday 03 May 2017 05:48 PM, Olliver Schinagl wrote:
>> This patch adds support for the Olimex OLinuXino Lime2 with eMMC
>flash
>> storage.
>>
>https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-LIME2-eMMC/
>>
>> It is a assembly variant of the regular Lime2 but featuring eMMC for
>> storage.
>>
>> Signed-off-by: Olliver Schinagl 
>> ---
>>
>> Note: for the board to work properly, the updated eMMC dts variant
>needs to
>> be updated from upstream.
>>
>>  board/sunxi/MAINTAINERS|  5 +
>>  configs/A20-OLinuXino-Lime2-eMMC_defconfig | 33
>++
>>  2 files changed, 38 insertions(+)
>>  create mode 100644 configs/A20-OLinuXino-Lime2-eMMC_defconfig
>>
>> diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
>> index 2321b8b08f..84f91fd10b 100644
>> --- a/board/sunxi/MAINTAINERS
>> +++ b/board/sunxi/MAINTAINERS
>> @@ -89,6 +89,11 @@ M:Iain Paton 
>>  S:  Maintained
>>  F:  configs/A20-OLinuXino-Lime2_defconfig
>>
>> +A20-OLINUXINO-LIME2-EMMC BOARD
>> +M:  Olliver Schinagl 
>> +S:  Maintained
>> +F:  configs/A20-OLinuXino-Lime2-eMMC_defconfig
>> +
>>  A33-OLINUXINO BOARD
>>  M:  Stefan Mavrodiev 
>>  S:  Maintained
>> diff --git a/configs/A20-OLinuXino-Lime2-eMMC_defconfig
>b/configs/A20-OLinuXino-Lime2-eMMC_defconfig
>
>I guess you used the latest, right? I got the below error with 4.7.1
>and 
>even buildman does.
>
>arm-linux-gnueabi-ld.bfd: u-boot-spl section `.u_boot_list' will not
>fit 
>in region `.sram'
>arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 88 bytes
>arm-linux-gnueabi-ld.bfd: u-boot-spl: Not enough room for program 
>headers, try linking with -N
>arm-linux-gnueabi-ld.bfd: final link failed: Bad value

Try a newer GCC?

>
>thanks!

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH] sun7i: Add support for Olimex A20-OLinuXino-LIME2-eMMC

[Jagan Teki]

On Wednesday 03 May 2017 05:48 PM, Olliver Schinagl wrote:

This patch adds support for the Olimex OLinuXino Lime2 with eMMC flash
storage.
https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-LIME2-eMMC/

It is a assembly variant of the regular Lime2 but featuring eMMC for
storage.

Signed-off-by: Olliver Schinagl 
---

Note: for the board to work properly, the updated eMMC dts variant needs to
be updated from upstream.

 board/sunxi/MAINTAINERS|  5 +
 configs/A20-OLinuXino-Lime2-eMMC_defconfig | 33 ++
 2 files changed, 38 insertions(+)
 create mode 100644 configs/A20-OLinuXino-Lime2-eMMC_defconfig

diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 2321b8b08f..84f91fd10b 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -89,6 +89,11 @@ M:   Iain Paton 
 S: Maintained
 F: configs/A20-OLinuXino-Lime2_defconfig

+A20-OLINUXINO-LIME2-EMMC BOARD
+M: Olliver Schinagl 
+S: Maintained
+F: configs/A20-OLinuXino-Lime2-eMMC_defconfig
+
 A33-OLINUXINO BOARD
 M: Stefan Mavrodiev 
 S: Maintained
diff --git a/configs/A20-OLinuXino-Lime2-eMMC_defconfig 
b/configs/A20-OLinuXino-Lime2-eMMC_defconfig


I guess you used the latest, right? I got the below error with 4.7.1 and 
even buildman does.


arm-linux-gnueabi-ld.bfd: u-boot-spl section `.u_boot_list' will not fit 
in region `.sram'

arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 88 bytes
arm-linux-gnueabi-ld.bfd: u-boot-spl: Not enough room for program 
headers, try linking with -N

arm-linux-gnueabi-ld.bfd: final link failed: Bad value

thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

--
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [U-Boot] [PATCH] sunxi: add support for Banana Pi M2 Plus board

[Jagan Teki]

On Wed, May 3, 2017 at 9:15 PM, Icenowy Zheng  wrote:
> Banana Pi M2 Plus is an Allwinner H3-based SBC by Sinovoip, which has
> already mainline device tree file that have landed into U-Boot source
> tree.
>
> Add a defconfig file for it and add the MAINTAINERS items.
>
> Signed-off-by: Icenowy Zheng 

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH] sunxi: add support for Banana Pi M2 Plus board

[Icenowy Zheng]

Banana Pi M2 Plus is an Allwinner H3-based SBC by Sinovoip, which has
already mainline device tree file that have landed into U-Boot source
tree.

Add a defconfig file for it and add the MAINTAINERS items.

Signed-off-by: Icenowy Zheng 
---
 board/sunxi/MAINTAINERS|  5 +
 configs/Sinovoip_BPI_M2_Plus_defconfig | 20 
 2 files changed, 25 insertions(+)
 create mode 100644 configs/Sinovoip_BPI_M2_Plus_defconfig

diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index f39402b89c..1c8817375d 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -280,6 +280,11 @@ S: Maintained
 F: configs/Sinlinx_SinA33_defconfig
 W: http://linux-sunxi.org/Sinlinx_SinA33
 
+SINOVOIP BPI M2 PLUS H3 BOARD
+M: Icenowy Zheng 
+S: Maintained
+F: configs/Sinovoip_BPI_M2_Plus_defconfig
+
 SINOVOIP BPI M3 A83T BOARD
 M: VishnuPatekar 
 S: Maintained
diff --git a/configs/Sinovoip_BPI_M2_Plus_defconfig 
b/configs/Sinovoip_BPI_M2_Plus_defconfig
new file mode 100644
index 00..e8cd4fb9ec
--- /dev/null
+++ b/configs/Sinovoip_BPI_M2_Plus_defconfig
@@ -0,0 +1,20 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_MACH_SUN8I_H3=y
+CONFIG_DRAM_CLK=672
+CONFIG_DRAM_ZQ=3881979
+CONFIG_DRAM_ODT_EN=y
+CONFIG_MACPWR="PD6"
+CONFIG_MMC_SUNXI_SLOT_EXTRA=2
+CONFIG_DEFAULT_DEVICE_TREE="sun8i-h3-bananapi-m2-plus"
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_CONSOLE_MUX=y
+CONFIG_SPL=y
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_ISO_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_SUN8I_EMAC=y
+CONFIG_USB_EHCI_HCD=y
-- 
2.12.2

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Designware UART bug

[Olliver Schinagl]

Hey Tim,

On 03-05-17 16:22, Tim Kryger wrote:

On Wed, May 3, 2017 at 4:26 AM, Olliver Schinagl  wrote:

Hey Chen-Yu

On 03-05-17 12:40, Chen-Yu Tsai wrote:


On Wed, May 3, 2017 at 6:17 PM, Olliver Schinagl 
wrote:


Hey Jamie,

Several years ago you wrote the glue-code [0] for the DW 8250 IP. Over
the
years various 'fixes' have been applied to resolve certain 'weird'
problems
that Tim tried to fix with [1].

After going over the datasheets and code with a comb several times now, I
think I may have found one (of a few others) reasons and would like both
your and Tim's thoughts here.

The current (and original) code [2] uses the register offset 0x1f for the
UART_USR register.

I searched far and wide, various datasheet of physical uarts (8250 -
16950)
and some IP cores and none seem to have the USR (and specifically the
USR[0]
bit) register, so it seems to be specific to the DW_apb_uart. However
looking at the only databook available to me [3] of the UART IP, I cannot
seem to find anything at register offset 0x1f.

The platform I'm using uses the Allwinner A20 SoC, which also features
the
DW uart IP and also here, there is nothing at offset 0x1f.

The intended register IS however actually at 0x7c.

My question is thus twofold.

Why was 0x1f used? Is this specific to a certain (version) UART or is
this a
long uncaught typo.



The original 8250 datasheets have registers at byte offsets. Note that the
registers are only 8 bits wide.


Yes, I did account for that difference :) Or rather, it should be the first
register after the scratchpad, but there is nothing after the scratchpad on
the 8250's.



On Allwinner, and many other platforms, the registers are still 8 bits
wide, but are 32bit-aligned, likely for aligned bus access. 0x7c = 0x1f <<
2.
The 8250 core accessor functions are supposed to handle this for you.


Actually, they are 32 bit registers, but only the lowest 8 are used, to
remain code-compatible with true 8 bitters. The end result, is the same of
course.

As for the shift, I see now!

readb(p->membase + (offset << p->regshift));

And indeed, the regular defines are all indeed 8 bit offsets. Oversight on
my part, and I changed the comment to make this slightly more clear, which
goes into my greater uart series.

Thanks Chen-Yu for pointing this oversight of mine out!



ChenYu


Tim, assuming it is a typo, could this the cause which made you implement
[1]? From what I understand, you keep writing the LCR until it takes.


So with ChenYu's explanation, the USR register holds a valid status, but it
was and is never checked and thus the below part is still a valid question?



Initially, the UART_IIR_BUSY check looked like this:
if (serial8250_handle_irq(p, iir)) {
return 1;
} else if ((iir & UART_IIR_BUSY) == UART_IIR_BUSY) {
/* Clear the USR and write the LCR again. */
(void)p->serial_in(p, d->usr_reg);
p->serial_out(p, UART_LCR, d->last_lcr);

return 1;
}

what I'm missing here is, that if UART_IIR_BUSY is set, we have to:
* check the d->usr_reg (UART_USR) bit 0
* wait until it becomes cleared (do not allow new data to be pushed out,
optionally force the data to be pushed out after a timeout)
* write LCR register (and check if it took (and no longer loop over the
LCR
to see if the values stuck, in theory)).
* if we never get un-busy, something is wrong?

All of this btw is currently moot anyway, as the only way to get into the
(else) if, is if serial8250_handle_irq returns false. And from what I can
see, this is only if iir == UART_IIR_NO_IRQ, in which case we never ever
clear the USR and thus never ever clear the UART_IIR_BUSY flag.


especially this point is important I suppose, hence the need for the
workaround [1].


I'm not clear on what question you are actually asking here.

The original code didn't work since multiple register writes may occur
after the initial failed LCR write while interrupts are still disabled.

Thus the driver must read back LCR to ensure writes are going through
immediately rather than rely upon an interrupt that can be delayed.


Ok, so as far as I understand (from the datasheet) the intended way to 
do this would be to check for the BUSY IRQ & USR[0] IRQ and if it is 
busy, (re-write) the LCR. We no longer do this because it did not work 
due to the delayed interrupt.


So one question is, why are we not checking the USR[0] reg whilst doing 
the loop? Is that register not there for exactly that purpose? But I 
guess brute-forcing it works more reliable I suppose then.


But secondly, when is the UART_IIR_BUSY interrupt handled? And it not 
being handled, could that be the actual reason things where failing? (Or 
as I read somewhere a silicon bug?)


Right now, we have serial8250_handle_irq() and if that returns 0, we 
check if we (still) have an unhandled UART_IIR_BUSY interrupt.
But the only way for 

[linux-sunxi] [PATCHv2] sun7i: Add support for Olimex A20-OLinuXino-LIME2-eMMC

[Olliver Schinagl]

This patch adds support for the Olimex OLinuXino Lime2 with eMMC flash
storage.
https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-LIME2-eMMC/

It is a assembly variant of the regular Lime2 but featuring eMMC for
storage.

Signed-off-by: Olliver Schinagl 
---
Jagan,

I was fairly certain that I was updated, guess I was wrong! Sorry.

Changes since v1:
rebase with master

Note: for the board to work properly, the updated eMMC dts variant needs to
be resynced from upstream.

 board/sunxi/MAINTAINERS|  5 +
 configs/A20-OLinuXino-Lime2-eMMC_defconfig | 36 ++
 2 files changed, 41 insertions(+)
 create mode 100644 configs/A20-OLinuXino-Lime2-eMMC_defconfig

diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index f39402b89c..24235a71a7 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -89,6 +89,11 @@ M:   Iain Paton 
 S: Maintained
 F: configs/A20-OLinuXino-Lime2_defconfig
 
+A20-OLINUXINO-LIME2-EMMC BOARD
+M: Olliver Schinagl 
+S: Maintained
+F: configs/A20-OLinuXino-Lime2-eMMC_defconfig
+
 A33-OLINUXINO BOARD
 M: Stefan Mavrodiev 
 S: Maintained
diff --git a/configs/A20-OLinuXino-Lime2-eMMC_defconfig 
b/configs/A20-OLinuXino-Lime2-eMMC_defconfig
new file mode 100644
index 00..034ae983a5
--- /dev/null
+++ b/configs/A20-OLinuXino-Lime2-eMMC_defconfig
@@ -0,0 +1,36 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_MACH_SUN7I=y
+CONFIG_DRAM_CLK=384
+CONFIG_MMC0_CD_PIN="PH1"
+CONFIG_MMC_SUNXI_SLOT_EXTRA=2
+CONFIG_USB0_VBUS_PIN="PC17"
+CONFIG_USB0_VBUS_DET="PH5"
+CONFIG_I2C1_ENABLE=y
+CONFIG_SATAPWR="PC3"
+CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-olinuxino-lime2-emmc"
+CONFIG_AHCI=y
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL=y
+CONFIG_SPL_I2C_SUPPORT=y
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_DFU=y
+CONFIG_CMD_USB_MASS_STORAGE=y
+# CONFIG_CMD_FPGA is not set
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_ISO_PARTITION is not set
+# CONFIG_SPL_PARTITION_UUIDS is not set
+CONFIG_DFU_RAM=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_RGMII=y
+CONFIG_SUN7I_GMAC=y
+CONFIG_AXP_ALDO3_VOLT=2800
+CONFIG_AXP_ALDO4_VOLT=2800
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_MUSB_GADGET=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_G_DNL_MANUFACTURER="Allwinner Technology"
+CONFIG_G_DNL_VENDOR_NUM=0x1f3a
+CONFIG_G_DNL_PRODUCT_NUM=0x1010
-- 
2.11.0

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [U-Boot] [PATCH] sun7i: Add support for Olimex A20-OLinuXino-LIME2-eMMC

[Jagan Teki]

On Wed, May 3, 2017 at 5:48 PM, Olliver Schinagl  wrote:
> This patch adds support for the Olimex OLinuXino Lime2 with eMMC flash
> storage.
> https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-LIME2-eMMC/
>
> It is a assembly variant of the regular Lime2 but featuring eMMC for
> storage.
>
> Signed-off-by: Olliver Schinagl 
> ---
>
> Note: for the board to work properly, the updated eMMC dts variant needs to
> be updated from upstream.
>
>  board/sunxi/MAINTAINERS|  5 +
>  configs/A20-OLinuXino-Lime2-eMMC_defconfig | 33 
> ++
>  2 files changed, 38 insertions(+)
>  create mode 100644 configs/A20-OLinuXino-Lime2-eMMC_defconfig
>
> diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
> index 2321b8b08f..84f91fd10b 100644
> --- a/board/sunxi/MAINTAINERS
> +++ b/board/sunxi/MAINTAINERS
> @@ -89,6 +89,11 @@ M:   Iain Paton 
>  S: Maintained
>  F: configs/A20-OLinuXino-Lime2_defconfig
>
> +A20-OLINUXINO-LIME2-EMMC BOARD
> +M: Olliver Schinagl 
> +S: Maintained
> +F: configs/A20-OLinuXino-Lime2-eMMC_defconfig
> +
>  A33-OLINUXINO BOARD
>  M: Stefan Mavrodiev 
>  S: Maintained
> diff --git a/configs/A20-OLinuXino-Lime2-eMMC_defconfig 
> b/configs/A20-OLinuXino-Lime2-eMMC_defconfig
> new file mode 100644
> index 00..1369d2d90b
> --- /dev/null
> +++ b/configs/A20-OLinuXino-Lime2-eMMC_defconfig
> @@ -0,0 +1,33 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_SUNXI=y
> +CONFIG_MACH_SUN7I=y
> +CONFIG_DRAM_CLK=384
> +CONFIG_MMC0_CD_PIN="PH1"
> +CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> +CONFIG_USB0_VBUS_PIN="PC17"
> +CONFIG_USB0_VBUS_DET="PH5"
> +CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-olinuxino-lime2-emmc"
> +CONFIG_AHCI=y
> +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> +CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,SATAPWR=SUNXI_GPC(3)"
> +CONFIG_SPL=y

These were moved to Kconfig, please sync with latest.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 1/20] clk: divider: Make divider_round_rate take the parent clock

[Chen-Yu Tsai]

On Wed, May 3, 2017 at 7:59 PM, Maxime Ripard
 wrote:
> So far, divider_round_rate only considers the parent clock returned by
> clk_hw_get_parent.
>
> This works fine on clocks that have a single parents, this doesn't work on
> muxes, since we will only consider the first parent, while other parents
> may totally be able to provide a better combination.
>
> Clocks in that case cannot use divider_round_rate, so would have to come up
> with a very similar logic to work around it. Instead of having to do
> something like this, and duplicate that logic everywhere, create a
> divider_round_rate parent to allow caller to give an additional parameter
> for the parent clock to consider.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/clk/clk-divider.c| 26 ++
>  include/linux/clk-provider.h |  4 
>  2 files changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index 96386ffc8483..48750439b1cd 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -275,7 +275,8 @@ static int _next_div(const struct clk_div_table *table, 
> int div,
> return div;
>  }
>
> -static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
> +static int clk_divider_bestdiv(struct clk_hw *hw, struct clk_hw *parent,
> +  unsigned long rate,
>unsigned long *best_parent_rate,
>const struct clk_div_table *table, u8 width,
>unsigned long flags)
> @@ -314,8 +315,7 @@ static int clk_divider_bestdiv(struct clk_hw *hw, 
> unsigned long rate,
> *best_parent_rate = parent_rate_saved;
> return i;
> }
> -   parent_rate = clk_hw_round_rate(clk_hw_get_parent(hw),
> -  rate * i);
> +   parent_rate = clk_hw_round_rate(parent, rate * i);
> now = DIV_ROUND_UP_ULL((u64)parent_rate, i);
> if (_is_best_div(rate, now, best, flags)) {
> bestdiv = i;
> @@ -326,22 +326,32 @@ static int clk_divider_bestdiv(struct clk_hw *hw, 
> unsigned long rate,
>
> if (!bestdiv) {
> bestdiv = _get_maxdiv(table, width, flags);
> -   *best_parent_rate = clk_hw_round_rate(clk_hw_get_parent(hw), 
> 1);
> +   *best_parent_rate = clk_hw_round_rate(parent, 1);
> }
>
> return bestdiv;
>  }
>
> -long divider_round_rate(struct clk_hw *hw, unsigned long rate,
> -   unsigned long *prate, const struct clk_div_table 
> *table,
> -   u8 width, unsigned long flags)
> +long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
> +  unsigned long rate, unsigned long *prate,
> +  const struct clk_div_table *table,
> +  u8 width, unsigned long flags)
>  {
> int div;
>
> -   div = clk_divider_bestdiv(hw, rate, prate, table, width, flags);
> +   div = clk_divider_bestdiv(hw, parent, rate, prate, table, width, 
> flags);
>
> return DIV_ROUND_UP_ULL((u64)*prate, div);
>  }
> +EXPORT_SYMBOL_GPL(divider_round_rate_parent);
> +
> +long divider_round_rate(struct clk_hw *hw, unsigned long rate,
> +   unsigned long *prate, const struct clk_div_table 
> *table,
> +   u8 width, unsigned long flags)
> +{
> +   return divider_round_rate_parent(hw, clk_hw_get_parent(hw), rate, 
> prate,
> +table, width, flags);
> +}
>  EXPORT_SYMBOL_GPL(divider_round_rate);

Could this be made a static inline instead? Otherwise,

Reviewed-by: Chen-Yu Tsai 

>
>  static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index a428aec36ace..14102f783f64 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -412,6 +412,10 @@ extern const struct clk_ops clk_divider_ro_ops;
>  unsigned long divider_recalc_rate(struct clk_hw *hw, unsigned long 
> parent_rate,
> unsigned int val, const struct clk_div_table *table,
> unsigned long flags);
> +long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
> +  unsigned long rate, unsigned long *prate,
> +  const struct clk_div_table *table,
> +  u8 width, unsigned long flags);
>  long divider_round_rate(struct clk_hw *hw, unsigned long rate,
> unsigned long *prate, const struct clk_div_table *table,
> u8 width, unsigned long flags);
> --
> git-series 0.8.11

-- 
You received this message 

[linux-sunxi] [PATCH] sun7i: Add support for Olimex A20-OLinuXino-LIME2-eMMC

[Olliver Schinagl]

This patch adds support for the Olimex OLinuXino Lime2 with eMMC flash
storage.
https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-LIME2-eMMC/

It is a assembly variant of the regular Lime2 but featuring eMMC for
storage.

Signed-off-by: Olliver Schinagl 
---

Note: for the board to work properly, the updated eMMC dts variant needs to
be updated from upstream.

 board/sunxi/MAINTAINERS|  5 +
 configs/A20-OLinuXino-Lime2-eMMC_defconfig | 33 ++
 2 files changed, 38 insertions(+)
 create mode 100644 configs/A20-OLinuXino-Lime2-eMMC_defconfig

diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 2321b8b08f..84f91fd10b 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -89,6 +89,11 @@ M:   Iain Paton 
 S: Maintained
 F: configs/A20-OLinuXino-Lime2_defconfig
 
+A20-OLINUXINO-LIME2-EMMC BOARD
+M: Olliver Schinagl 
+S: Maintained
+F: configs/A20-OLinuXino-Lime2-eMMC_defconfig
+
 A33-OLINUXINO BOARD
 M: Stefan Mavrodiev 
 S: Maintained
diff --git a/configs/A20-OLinuXino-Lime2-eMMC_defconfig 
b/configs/A20-OLinuXino-Lime2-eMMC_defconfig
new file mode 100644
index 00..1369d2d90b
--- /dev/null
+++ b/configs/A20-OLinuXino-Lime2-eMMC_defconfig
@@ -0,0 +1,33 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_MACH_SUN7I=y
+CONFIG_DRAM_CLK=384
+CONFIG_MMC0_CD_PIN="PH1"
+CONFIG_MMC_SUNXI_SLOT_EXTRA=2
+CONFIG_USB0_VBUS_PIN="PC17"
+CONFIG_USB0_VBUS_DET="PH5"
+CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-olinuxino-lime2-emmc"
+CONFIG_AHCI=y
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,SATAPWR=SUNXI_GPC(3)"
+CONFIG_SPL=y
+CONFIG_SPL_I2C_SUPPORT=y
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_DFU=y
+CONFIG_CMD_USB_MASS_STORAGE=y
+# CONFIG_CMD_FPGA is not set
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_ISO_PARTITION is not set
+# CONFIG_SPL_PARTITION_UUIDS is not set
+CONFIG_DFU_RAM=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_AXP_ALDO3_VOLT=2800
+CONFIG_AXP_ALDO4_VOLT=2800
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_MUSB_GADGET=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_G_DNL_MANUFACTURER="Allwinner Technology"
+CONFIG_G_DNL_VENDOR_NUM=0x1f3a
+CONFIG_G_DNL_PRODUCT_NUM=0x1010
-- 
2.11.0

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 16/20] dt-bindings: display: sun4i: Add HDMI display bindings

[Maxime Ripard]

One of the possible output of the display pipeline, on the SoCs that have
it, is the HDMI controller.

Add a binding for it.

Acked-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 79 +++-
 1 file changed, 79 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 57a8d0610062..91ce2c920750 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -4,6 +4,34 @@ Allwinner A10 Display Pipeline
 The Allwinner A10 Display pipeline is composed of several components
 that are going to be documented below:
 
+HDMI Encoder
+
+
+The HDMI Encoder supports the HDMI video and audio outputs, and does
+CEC. It is one end of the pipeline.
+
+Required properties:
+  - compatible: value must be one of:
+* allwinner,sun5i-a10s-hdmi
+  - reg: base address and size of memory-mapped region
+  - interrupts: interrupt associated to this IP
+  - clocks: phandles to the clocks feeding the HDMI encoder
+* ahb: the HDMI interface clock
+* mod: the HDMI module clock
+* pll-0: the first video PLL
+* pll-1: the second video PLL
+  - clock-names: the clock names mentioned above
+  - dmas: phandles to the DMA channels used by the HDMI encoder
+* ddc-tx: The channel for DDC transmission
+* ddc-rx: The channel for DDC reception
+* audio-tx: The channel used for audio transmission
+  - dma-names: the channel names mentioned above
+
+  - 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.
+
 TV Encoder
 --
 
@@ -173,6 +201,57 @@ panel: panel {
};
 };
 
+connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <_out_con>;
+   };
+   };
+};
+
+hdmi: hdmi@01c16000 {
+   compatible = "allwinner,sun5i-a10s-hdmi";
+   reg = <0x01c16000 0x1000>;
+   interrupts = <58>;
+   clocks = < CLK_AHB_HDMI>, < CLK_HDMI>,
+< CLK_PLL_VIDEO0_2X>,
+< CLK_PLL_VIDEO1_2X>;
+   clock-names = "ahb", "mod", "pll-0", "pll-1";
+   dmas = < SUN4I_DMA_NORMAL 16>,
+  < SUN4I_DMA_NORMAL 16>,
+  < SUN4I_DMA_DEDICATED 24>;
+   dma-names = "ddc-tx", "ddc-rx", "audio-tx";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   hdmi_in_tcon0: endpoint {
+   remote-endpoint = <_out_hdmi>;
+   };
+   };
+
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   hdmi_out_con: endpoint {
+   remote-endpoint = <_con_in>;
+   };
+   };
+   };
+};
+
 tve0: tv-encoder@01c0a000 {
compatible = "allwinner,sun4i-a10-tv-encoder";
reg = <0x01c0a000 0x1000>;
-- 
git-series 0.8.11

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 15/20] drm/sun4i: Ignore the generic connectors for components

[Maxime Ripard]

The generic connectors such as hdmi-connector doesn't have any driver in,
so if they are added to the component list, we will be waiting forever for
a non-existing driver to probe.

Add a list of the connectors we want to ignore when building our component
list.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_drv.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 8ddd72cd5873..8c9d2e36be55 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -164,6 +164,11 @@ static const struct component_master_ops 
sun4i_drv_master_ops = {
.unbind = sun4i_drv_unbind,
 };
 
+static bool sun4i_drv_node_is_connector(struct device_node *node)
+{
+   return of_device_is_compatible(node, "hdmi-connector");
+}
+
 static bool sun4i_drv_node_is_frontend(struct device_node *node)
 {
return of_device_is_compatible(node, 
"allwinner,sun5i-a13-display-frontend") ||
@@ -204,7 +209,8 @@ static int sun4i_drv_add_endpoints(struct device *dev,
!of_device_is_available(node))
return 0;
 
-   if (!sun4i_drv_node_is_frontend(node)) {
+   if (!sun4i_drv_node_is_connector(node) &&
+   !sun4i_drv_node_is_frontend(node)) {
/* Add current component */
DRM_DEBUG_DRIVER("Adding component %s\n",
 of_node_full_name(node));
-- 
git-series 0.8.11

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 14/20] drm/sun4i: tcon: multiply the vtotal when not in interlace

[Maxime Ripard]

It appears that the total vertical resolution needs to be doubled when
we're not in interlaced. Make sure that is the case.

Signed-off-by: Maxime Ripard 
---
 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 0f91ec8a4b26..efa079c1a3f5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -272,9 +272,9 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
/* Set vertical display timings */
bp = mode->crtc_vtotal - mode->crtc_vsync_start;
DRM_DEBUG_DRIVER("Setting vertical total %d, backporch %d\n",
-mode->vtotal, bp);
+mode->crtc_vtotal, bp);
regmap_write(tcon->regs, SUN4I_TCON1_BASIC4_REG,
-SUN4I_TCON1_BASIC4_V_TOTAL(mode->vtotal) |
+SUN4I_TCON1_BASIC4_V_TOTAL(mode->crtc_vtotal * 2) |
 SUN4I_TCON1_BASIC4_V_BACKPORCH(bp));
 
/* Set Hsync and Vsync length */
-- 
git-series 0.8.11

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 13/20] drm/sun4i: tcon: Change vertical total size computation inconsistency

[Maxime Ripard]

Both TCON channels need to have the resolution doubled, since the size the
hardware is going to use is whatever we put in the register divided by two.

However, we handle it differently for the two channels: in the channel 0,
our register access macro does the multiplication of the value passed as
paremeter, while in the channel 1, the macro doesn't do this, and we need
to do it before calling it.

Make this consistent by aligning the channel 0 with the channel 1
behaviour.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 86a806fae9fb..0f91ec8a4b26 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -190,7 +190,7 @@ void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
 
/* Set vertical display timings */
regmap_write(tcon->regs, SUN4I_TCON0_BASIC2_REG,
-SUN4I_TCON0_BASIC2_V_TOTAL(mode->crtc_vtotal) |
+SUN4I_TCON0_BASIC2_V_TOTAL(mode->crtc_vtotal * 2) |
 SUN4I_TCON0_BASIC2_V_BACKPORCH(bp));
 
/* Set Hsync and Vsync length */
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index 0350936b413c..3517122ee679 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -51,7 +51,7 @@
 #define SUN4I_TCON0_BASIC1_H_BACKPORCH(bp) (((bp) - 1) & 0xfff)
 
 #define SUN4I_TCON0_BASIC2_REG 0x50
-#define SUN4I_TCON0_BASIC2_V_TOTAL(total)  total) * 2) & 
0x1fff) << 16)
+#define SUN4I_TCON0_BASIC2_V_TOTAL(total)  (((total) & 0x1fff) << 
16)
 #define SUN4I_TCON0_BASIC2_V_BACKPORCH(bp) (((bp) - 1) & 0xfff)
 
 #define SUN4I_TCON0_BASIC3_REG 0x54
-- 
git-series 0.8.11

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 2/20] clk: sunxi-ng: Pass the parent and a pointer to the clocks round rate

[Maxime Ripard]

The clocks might need to modify their parent clocks. In order to make that
possible, give them access to the parent clock being evaluated, and to a
pointer to the parent rate so that they can modify it if needed.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu_div.c  |  7 ---
 drivers/clk/sunxi-ng/ccu_mp.c   |  7 ---
 drivers/clk/sunxi-ng/ccu_mult.c | 11 ++-
 drivers/clk/sunxi-ng/ccu_mux.c  |  8 +---
 drivers/clk/sunxi-ng/ccu_mux.h  |  3 ++-
 drivers/clk/sunxi-ng/ccu_nkm.c  |  7 ---
 6 files changed, 25 insertions(+), 18 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_div.c b/drivers/clk/sunxi-ng/ccu_div.c
index 4057e6021aa9..a489f18a3c01 100644
--- a/drivers/clk/sunxi-ng/ccu_div.c
+++ b/drivers/clk/sunxi-ng/ccu_div.c
@@ -14,7 +14,8 @@
 #include "ccu_div.h"
 
 static unsigned long ccu_div_round_rate(struct ccu_mux_internal *mux,
-   unsigned long parent_rate,
+   struct clk_hw *parent,
+   unsigned long *parent_rate,
unsigned long rate,
void *data)
 {
@@ -26,10 +27,10 @@ static unsigned long ccu_div_round_rate(struct 
ccu_mux_internal *mux,
 * several parents, while we might be called to evaluate
 * several different parents.
 */
-   val = divider_get_val(rate, parent_rate, cd->div.table, cd->div.width,
+   val = divider_get_val(rate, *parent_rate, cd->div.table, cd->div.width,
  cd->div.flags);
 
-   return divider_recalc_rate(>common.hw, parent_rate, val,
+   return divider_recalc_rate(>common.hw, *parent_rate, val,
   cd->div.table, cd->div.flags);
 }
 
diff --git a/drivers/clk/sunxi-ng/ccu_mp.c b/drivers/clk/sunxi-ng/ccu_mp.c
index b583f186a804..de02e6c386d8 100644
--- a/drivers/clk/sunxi-ng/ccu_mp.c
+++ b/drivers/clk/sunxi-ng/ccu_mp.c
@@ -41,7 +41,8 @@ static void ccu_mp_find_best(unsigned long parent, unsigned 
long rate,
 }
 
 static unsigned long ccu_mp_round_rate(struct ccu_mux_internal *mux,
-  unsigned long parent_rate,
+  struct clk_hw *hw,
+  unsigned long *parent_rate,
   unsigned long rate,
   void *data)
 {
@@ -52,9 +53,9 @@ static unsigned long ccu_mp_round_rate(struct 
ccu_mux_internal *mux,
max_m = cmp->m.max ?: 1 << cmp->m.width;
max_p = cmp->p.max ?: 1 << ((1 << cmp->p.width) - 1);
 
-   ccu_mp_find_best(parent_rate, rate, max_m, max_p, , );
+   ccu_mp_find_best(*parent_rate, rate, max_m, max_p, , );
 
-   return parent_rate / p / m;
+   return *parent_rate / p / m;
 }
 
 static void ccu_mp_disable(struct clk_hw *hw)
diff --git a/drivers/clk/sunxi-ng/ccu_mult.c b/drivers/clk/sunxi-ng/ccu_mult.c
index 671141359895..6ee7ba0738fb 100644
--- a/drivers/clk/sunxi-ng/ccu_mult.c
+++ b/drivers/clk/sunxi-ng/ccu_mult.c
@@ -33,9 +33,10 @@ static void ccu_mult_find_best(unsigned long parent, 
unsigned long rate,
 }
 
 static unsigned long ccu_mult_round_rate(struct ccu_mux_internal *mux,
-   unsigned long parent_rate,
-   unsigned long rate,
-   void *data)
+struct clk_hw *parent,
+unsigned long *parent_rate,
+unsigned long rate,
+void *data)
 {
struct ccu_mult *cm = data;
struct _ccu_mult _cm;
@@ -47,9 +48,9 @@ static unsigned long ccu_mult_round_rate(struct 
ccu_mux_internal *mux,
else
_cm.max = (1 << cm->mult.width) + cm->mult.offset - 1;
 
-   ccu_mult_find_best(parent_rate, rate, &_cm);
+   ccu_mult_find_best(*parent_rate, rate, &_cm);
 
-   return parent_rate * _cm.mult;
+   return *parent_rate * _cm.mult;
 }
 
 static void ccu_mult_disable(struct clk_hw *hw)
diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
index c6bb1f523232..bae735e252b6 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.c
+++ b/drivers/clk/sunxi-ng/ccu_mux.c
@@ -61,7 +61,8 @@ int ccu_mux_helper_determine_rate(struct ccu_common *common,
  struct ccu_mux_internal *cm,
  struct clk_rate_request *req,
  unsigned long (*round)(struct 
ccu_mux_internal *,
-unsigned long,
+struct clk_hw *,
+unsigned long *,
 

[linux-sunxi] [PATCH v2 4/20] clk: sunxi-ng: mux: Don't just rely on the parent for CLK_SET_RATE_PARENT

[Maxime Ripard]

The current code only rely on the parent to change its rate in the case
where CLK_SET_RATE_PARENT is set.

However, some clock rates might be obtained only through a modification of
the parent and the clock divider. Just rely on the round rate of the clocks
to give us the best computation that might be achieved for a given rate.

round_rate functions now need to honor CLK_SET_RATE_PARENT, but either the
functions already do that if they modify the parent, or don't modify the
praents at all.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu_mux.c | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
index bae735e252b6..58b6e349a0ed 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.c
+++ b/drivers/clk/sunxi-ng/ccu_mux.c
@@ -95,19 +95,7 @@ int ccu_mux_helper_determine_rate(struct ccu_common *common,
if (!parent)
continue;
 
-   if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
-   struct clk_rate_request parent_req = *req;
-   int ret = __clk_determine_rate(parent, _req);
-
-   if (ret)
-   continue;
-
-   parent_rate = parent_req.rate;
-   } else {
-   parent_rate = clk_hw_get_rate(parent);
-   }
-
-   adj_parent_rate = parent_rate;
+   adj_parent_rate = parent_rate = clk_hw_get_rate(parent);
ccu_mux_helper_adjust_parent_for_prediv(common, cm, i,
_parent_rate);
 
-- 
git-series 0.8.11

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 9/20] drm/sun4i: tcon: Add channel debug

[Maxime Ripard]

While all functions have debug logs, the channel enable and disable are not
logged. Make sure this is the case.

Acked-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 
 1 file changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 9a83a85529ac..66a5bb9b85e9 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -54,6 +54,8 @@ EXPORT_SYMBOL(sun4i_tcon_enable);
 
 void sun4i_tcon_channel_disable(struct sun4i_tcon *tcon, int channel)
 {
+   DRM_DEBUG_DRIVER("Disabling TCON channel %d\n", channel);
+
/* Disable the TCON's channel */
if (channel == 0) {
regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
@@ -71,6 +73,8 @@ EXPORT_SYMBOL(sun4i_tcon_channel_disable);
 
 void sun4i_tcon_channel_enable(struct sun4i_tcon *tcon, int channel)
 {
+   DRM_DEBUG_DRIVER("Enabling TCON channel %d\n", channel);
+
/* Enable the TCON's channel */
if (channel == 0) {
regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
-- 
git-series 0.8.11

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 20/20] ARM: sun5i: a10s-olinuxino: Enable HDMI

[Maxime Ripard]

The A10s Olinuxino has an HDMI connector. Make sure we can use it.

Acked-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 29 +-
 1 file changed, 29 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts 
b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
index 894f874a5beb..1d13b6407222 100644
--- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
@@ -63,6 +63,17 @@
stdout-path = "serial0:115200n8";
};
 
+   connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <_out_con>;
+   };
+   };
+   };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -76,6 +87,10 @@
};
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
@@ -91,6 +106,16 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
+_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <_con_in>;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
@@ -248,6 +273,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
-- 
git-series 0.8.11

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 12/20] drm/sun4i: tcon: Fix tcon channel 1 backporch calculation

[Maxime Ripard]

It seems like what's called a backporch in the datasheet is actually the
backporch plus the sync period. Fix that in our driver.

Acked-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 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 1c609d808b86..86a806fae9fb 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -262,7 +262,7 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
 SUN4I_TCON1_BASIC2_Y(mode->crtc_vdisplay));
 
/* Set horizontal display timings */
-   bp = mode->crtc_htotal - mode->crtc_hsync_end;
+   bp = mode->crtc_htotal - mode->crtc_hsync_start;
DRM_DEBUG_DRIVER("Setting horizontal total %d, backporch %d\n",
 mode->htotal, bp);
regmap_write(tcon->regs, SUN4I_TCON1_BASIC3_REG,
@@ -270,7 +270,7 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
 SUN4I_TCON1_BASIC3_H_BACKPORCH(bp));
 
/* Set vertical display timings */
-   bp = mode->crtc_vtotal - mode->crtc_vsync_end;
+   bp = mode->crtc_vtotal - mode->crtc_vsync_start;
DRM_DEBUG_DRIVER("Setting vertical total %d, backporch %d\n",
 mode->vtotal, bp);
regmap_write(tcon->regs, SUN4I_TCON1_BASIC4_REG,
-- 
git-series 0.8.11

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 11/20] drm/sun4i: tcon: Switch mux on only for composite

[Maxime Ripard]

Even though that mux is undocumented, it seems like it needs to be set to 1
when using composite, and 0 when using HDMI.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c |  9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 0204d9fadb66..1c609d808b86 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -111,16 +111,23 @@ EXPORT_SYMBOL(sun4i_tcon_enable_vblank);
 void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel,
struct drm_encoder *encoder)
 {
+   u32 val;
+
if (!tcon->quirks->has_unknown_mux)
return;
 
if (channel != 1)
return;
 
+   if (encoder->encoder_type == DRM_MODE_ENCODER_TVDAC)
+   val = 1;
+   else
+   val = 0;
+
/*
 * FIXME: Undocumented bits
 */
-   regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, 1);
+   regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, val);
 }
 EXPORT_SYMBOL(sun4i_tcon_set_mux);
 
-- 
git-series 0.8.11

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 10/20] drm/sun4i: tcon: Move the muxing out of the mode set function

[Maxime Ripard]

The muxing can actually happen on both channels on some SoCs, so it makes
more sense to just move it out of the sun4i_tcon1_mode_set function and
create a separate function that needs to be called by the encoders.

Let's do that and convert the existing drivers.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_rgb.c  |  1 +
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 22 --
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  2 ++
 drivers/gpu/drm/sun4i/sun4i_tv.c   |  1 +
 4 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index 67f0b91a99de..3003d290c635 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -175,6 +175,7 @@ static void sun4i_rgb_encoder_mode_set(struct drm_encoder 
*encoder,
struct sun4i_tcon *tcon = rgb->tcon;
 
sun4i_tcon0_mode_set(tcon, mode);
+   sun4i_tcon_set_mux(tcon, 0, encoder);
 
clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 66a5bb9b85e9..0204d9fadb66 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -108,6 +108,22 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, 
bool enable)
 }
 EXPORT_SYMBOL(sun4i_tcon_enable_vblank);
 
+void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel,
+   struct drm_encoder *encoder)
+{
+   if (!tcon->quirks->has_unknown_mux)
+   return;
+
+   if (channel != 1)
+   return;
+
+   /*
+* FIXME: Undocumented bits
+*/
+   regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, 1);
+}
+EXPORT_SYMBOL(sun4i_tcon_set_mux);
+
 static int sun4i_tcon_get_clk_delay(struct drm_display_mode *mode,
int channel)
 {
@@ -266,12 +282,6 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG,
   SUN4I_TCON_GCTL_IOMAP_MASK,
   SUN4I_TCON_GCTL_IOMAP_TCON1);
-
-   /*
-* FIXME: Undocumented bits
-*/
-   if (tcon->quirks->has_unknown_mux)
-   regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, 1);
 }
 EXPORT_SYMBOL(sun4i_tcon1_mode_set);
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index f636343a935d..0350936b413c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -190,6 +190,8 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, bool 
enable);
 /* Mode Related Controls */
 void sun4i_tcon_switch_interlace(struct sun4i_tcon *tcon,
 bool enable);
+void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel,
+   struct drm_encoder *encoder);
 void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
  struct drm_display_mode *mode);
 void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index 49c49431a053..03c494b8159c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -393,6 +393,7 @@ static void sun4i_tv_mode_set(struct drm_encoder *encoder,
const struct tv_mode *tv_mode = sun4i_tv_find_tv_by_mode(mode);
 
sun4i_tcon1_mode_set(tcon, mode);
+   sun4i_tcon_set_mux(tcon, 1, encoder);
 
/* Enable and map the DAC to the output */
regmap_update_bits(tv->regs, SUN4I_TVE_EN_REG,
-- 
git-series 0.8.11

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 17/20] dt-bindings: display: sun4i: Add allwinner,tcon-channel property

[Maxime Ripard]

The Allwinner Timings Controller has two, mutually exclusive, channels.
When the binding has been introduced, it was assumed that there would be
only a single user per channel in the system.

While this is likely for the channel 0 which only connects to LCD displays,
it turns out that the channel 1 can be connected to multiple controllers in
the SoC (HDMI and TV encoders for example). And while the simultaneous use
of HDMI and TV outputs cannot be achieved, switching from one to the other
at runtime definitely sounds plausible.

Add an extra property, allwinner,tcon-channel, to specify for a given
endpoint which TCON channel it is connected to, while falling back to the
previous mechanism if that property is missing.

Acked-by: Chen-Yu Tsai 
Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 11 ---
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 91ce2c920750..acdc0c17c00e 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -75,10 +75,13 @@ Required properties:
   Documentation/devicetree/bindings/media/video-interfaces.txt. The
   first port should be the input endpoint, the second one the output
 
-  The output should have two endpoints. The first is the block
-  connected to the TCON channel 0 (usually a panel or a bridge), the
-  second the block connected to the TCON channel 1 (usually the TV
-  encoder)
+  The output may have multiple endpoints. The TCON has two channels,
+  usually with the first channel being used for the panels interfaces
+  (RGB, LVDS, etc.), and the second being used for the outputs that
+  require another controller (TV Encoder, HDMI, etc.). The endpoints
+  will take an extra property, allwinner,tcon-channel, to specify the
+  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, there is one more clock required:
- 'tcon-ch1': The clock driving the TCON channel 1
-- 
git-series 0.8.11

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 8/20] clk: sunxi-ng: sun5i: Export video PLLs

[Maxime Ripard]

The video PLLs are used directly by the HDMI controller. Export them so
that we can use them in our DT node.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu-sun5i.h  | 6 --
 include/dt-bindings/clock/sun5i-ccu.h | 3 +++
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun5i.h b/drivers/clk/sunxi-ng/ccu-sun5i.h
index 8144487eb7ca..93a275fbd9a9 100644
--- a/drivers/clk/sunxi-ng/ccu-sun5i.h
+++ b/drivers/clk/sunxi-ng/ccu-sun5i.h
@@ -28,15 +28,17 @@
 #define CLK_PLL_AUDIO_4X   6
 #define CLK_PLL_AUDIO_8X   7
 #define CLK_PLL_VIDEO0 8
-#define CLK_PLL_VIDEO0_2X  9
+
+/* The PLL_VIDEO0_2X is exported for HDMI */
+
 #define CLK_PLL_VE 10
 #define CLK_PLL_DDR_BASE   11
 #define CLK_PLL_DDR12
 #define CLK_PLL_DDR_OTHER  13
 #define CLK_PLL_PERIPH 14
 #define CLK_PLL_VIDEO1 15
-#define CLK_PLL_VIDEO1_2X  16
 
+/* The PLL_VIDEO1_2X is exported for HDMI */
 /* The CPU clock is exported */
 
 #define CLK_AXI18
diff --git a/include/dt-bindings/clock/sun5i-ccu.h 
b/include/dt-bindings/clock/sun5i-ccu.h
index aeb2e2f781fb..81f34d477aeb 100644
--- a/include/dt-bindings/clock/sun5i-ccu.h
+++ b/include/dt-bindings/clock/sun5i-ccu.h
@@ -19,6 +19,9 @@
 
 #define CLK_HOSC   1
 
+#define CLK_PLL_VIDEO0_2X  9
+
+#define CLK_PLL_VIDEO1_2X  16
 #define CLK_CPU17
 
 #define CLK_AHB_OTG23
-- 
git-series 0.8.11

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 19/20] ARM: sun5i: a10s: Add the HDMI controller node

[Maxime Ripard]

The A10s has an HDMI controller connected to the second TCON channel. Add
it to our DT.

Since the TV Encoder was the only channel 1 user so far, also add the
property now that we have several users.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-a10s.dtsi | 50 -
 arch/arm/boot/dts/sun5i.dtsi  |  1 +-
 2 files changed, 51 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi 
b/arch/arm/boot/dts/sun5i-a10s.dtsi
index 1e38ff80366c..c9d4ee12599d 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -71,7 +71,49 @@
};
};
 
+   display-engine {
+   compatible = "allwinner,sun5i-a10s-display-engine",
+"allwinner,sun5i-a13-display-engine";
+   allwinner,pipelines = <>;
+   };
+
soc@01c0 {
+   hdmi: hdmi@01c16000 {
+   compatible = "allwinner,sun5i-a10s-hdmi";
+   reg = <0x01c16000 0x1000>;
+   interrupts = <58>;
+   clocks = < CLK_AHB_HDMI>, < CLK_HDMI>,
+< CLK_PLL_VIDEO0_2X>,
+< CLK_PLL_VIDEO1_2X>;
+   clock-names = "ahb", "mod", "pll-0", "pll-1";
+   dmas = < SUN4I_DMA_NORMAL 16>,
+  < SUN4I_DMA_NORMAL 16>,
+  < SUN4I_DMA_DEDICATED 24>;
+   dma-names = "ddc-tx", "ddc-rx", "audio-tx";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   hdmi_in: port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   hdmi_in_tcon0: endpoint {
+   remote-endpoint = 
<_out_hdmi>;
+   };
+   };
+
+   hdmi_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+   };
+   };
+   };
+
pwm: pwm@01c20e00 {
compatible = "allwinner,sun5i-a10s-pwm";
reg = <0x01c20e00 0xc>;
@@ -128,3 +170,11 @@
 
 _a {
 };
+
+_out {
+   tcon0_out_hdmi: endpoint@2 {
+   reg = <2>;
+   remote-endpoint = <_in_tcon0>;
+   allwinner,tcon-channel = <1>;
+   };
+};
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 5175f9cc9bed..0e29f1d98a9e 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -272,6 +272,7 @@
tcon0_out_tve0: endpoint@1 {
reg = <1>;
remote-endpoint = 
<_in_tcon0>;
+   allwinner,tcon-channel = <1>;
};
};
};
-- 
git-series 0.8.11

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 3/20] clk: sunxi-ng: div: Switch to divider_round_rate

[Maxime Ripard]

divider_round_rate already evaluates changing the parent rate if
CLK_SET_RATE_PARENT is set. Now that we can do that on muxes too, let's
just use it.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu_div.c | 27 ---
 1 file changed, 4 insertions(+), 23 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_div.c b/drivers/clk/sunxi-ng/ccu_div.c
index a489f18a3c01..419463375bc1 100644
--- a/drivers/clk/sunxi-ng/ccu_div.c
+++ b/drivers/clk/sunxi-ng/ccu_div.c
@@ -20,18 +20,11 @@ static unsigned long ccu_div_round_rate(struct 
ccu_mux_internal *mux,
void *data)
 {
struct ccu_div *cd = data;
-   unsigned long val;
-
-   /*
-* We can't use divider_round_rate that assumes that there's
-* several parents, while we might be called to evaluate
-* several different parents.
-*/
-   val = divider_get_val(rate, *parent_rate, cd->div.table, cd->div.width,
- cd->div.flags);
 
-   return divider_recalc_rate(>common.hw, *parent_rate, val,
-  cd->div.table, cd->div.flags);
+   return divider_round_rate_parent(>common.hw, parent,
+rate, parent_rate,
+cd->div.table, cd->div.width,
+cd->div.flags);
 }
 
 static void ccu_div_disable(struct clk_hw *hw)
@@ -78,18 +71,6 @@ static int ccu_div_determine_rate(struct clk_hw *hw,
 {
struct ccu_div *cd = hw_to_ccu_div(hw);
 
-   if (clk_hw_get_num_parents(hw) == 1) {
-   req->rate = divider_round_rate(hw, req->rate,
-  >best_parent_rate,
-  cd->div.table,
-  cd->div.width,
-  cd->div.flags);
-
-   req->best_parent_hw = clk_hw_get_parent(hw);
-
-   return 0;
-   }
-
return ccu_mux_helper_determine_rate(>common, >mux,
 req, ccu_div_round_rate, cd);
 }
-- 
git-series 0.8.11

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 1/20] clk: divider: Make divider_round_rate take the parent clock

[Maxime Ripard]

So far, divider_round_rate only considers the parent clock returned by
clk_hw_get_parent.

This works fine on clocks that have a single parents, this doesn't work on
muxes, since we will only consider the first parent, while other parents
may totally be able to provide a better combination.

Clocks in that case cannot use divider_round_rate, so would have to come up
with a very similar logic to work around it. Instead of having to do
something like this, and duplicate that logic everywhere, create a
divider_round_rate parent to allow caller to give an additional parameter
for the parent clock to consider.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/clk-divider.c| 26 ++
 include/linux/clk-provider.h |  4 
 2 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 96386ffc8483..48750439b1cd 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -275,7 +275,8 @@ static int _next_div(const struct clk_div_table *table, int 
div,
return div;
 }
 
-static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
+static int clk_divider_bestdiv(struct clk_hw *hw, struct clk_hw *parent,
+  unsigned long rate,
   unsigned long *best_parent_rate,
   const struct clk_div_table *table, u8 width,
   unsigned long flags)
@@ -314,8 +315,7 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned 
long rate,
*best_parent_rate = parent_rate_saved;
return i;
}
-   parent_rate = clk_hw_round_rate(clk_hw_get_parent(hw),
-  rate * i);
+   parent_rate = clk_hw_round_rate(parent, rate * i);
now = DIV_ROUND_UP_ULL((u64)parent_rate, i);
if (_is_best_div(rate, now, best, flags)) {
bestdiv = i;
@@ -326,22 +326,32 @@ static int clk_divider_bestdiv(struct clk_hw *hw, 
unsigned long rate,
 
if (!bestdiv) {
bestdiv = _get_maxdiv(table, width, flags);
-   *best_parent_rate = clk_hw_round_rate(clk_hw_get_parent(hw), 1);
+   *best_parent_rate = clk_hw_round_rate(parent, 1);
}
 
return bestdiv;
 }
 
-long divider_round_rate(struct clk_hw *hw, unsigned long rate,
-   unsigned long *prate, const struct clk_div_table *table,
-   u8 width, unsigned long flags)
+long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
+  unsigned long rate, unsigned long *prate,
+  const struct clk_div_table *table,
+  u8 width, unsigned long flags)
 {
int div;
 
-   div = clk_divider_bestdiv(hw, rate, prate, table, width, flags);
+   div = clk_divider_bestdiv(hw, parent, rate, prate, table, width, flags);
 
return DIV_ROUND_UP_ULL((u64)*prate, div);
 }
+EXPORT_SYMBOL_GPL(divider_round_rate_parent);
+
+long divider_round_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long *prate, const struct clk_div_table *table,
+   u8 width, unsigned long flags)
+{
+   return divider_round_rate_parent(hw, clk_hw_get_parent(hw), rate, prate,
+table, width, flags);
+}
 EXPORT_SYMBOL_GPL(divider_round_rate);
 
 static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index a428aec36ace..14102f783f64 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -412,6 +412,10 @@ extern const struct clk_ops clk_divider_ro_ops;
 unsigned long divider_recalc_rate(struct clk_hw *hw, unsigned long parent_rate,
unsigned int val, const struct clk_div_table *table,
unsigned long flags);
+long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
+  unsigned long rate, unsigned long *prate,
+  const struct clk_div_table *table,
+  u8 width, unsigned long flags);
 long divider_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *prate, const struct clk_div_table *table,
u8 width, unsigned long flags);
-- 
git-series 0.8.11

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 5/20] clk: sunxi-ng: mux: split out the pre-divider computation code

[Maxime Ripard]

The pre-divider retrieval code was merged into the function to apply the
current pre-divider onto the parent clock rate so that we can use that
adjusted value to do our factors computation.

However, since we'll need to do the reverse operation, we need to split out
that code into a function that will be shared.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu_mux.c | 32 
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
index 58b6e349a0ed..3eb23d4e6534 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.c
+++ b/drivers/clk/sunxi-ng/ccu_mux.c
@@ -15,24 +15,20 @@
 #include "ccu_gate.h"
 #include "ccu_mux.h"
 
-void ccu_mux_helper_adjust_parent_for_prediv(struct ccu_common *common,
-struct ccu_mux_internal *cm,
-int parent_index,
-unsigned long *parent_rate)
+static u16 ccu_mux_get_prediv(struct ccu_common *common,
+ struct ccu_mux_internal *cm,
+ int parent_index)
 {
u16 prediv = 1;
u32 reg;
-   int i;
 
if (!((common->features & CCU_FEATURE_FIXED_PREDIV) ||
  (common->features & CCU_FEATURE_VARIABLE_PREDIV) ||
  (common->features & CCU_FEATURE_ALL_PREDIV)))
-   return;
+   return 1;
 
-   if (common->features & CCU_FEATURE_ALL_PREDIV) {
-   *parent_rate = *parent_rate / common->prediv;
-   return;
-   }
+   if (common->features & CCU_FEATURE_ALL_PREDIV)
+   return common->prediv;
 
reg = readl(common->base + common->reg);
if (parent_index < 0) {
@@ -40,10 +36,13 @@ void ccu_mux_helper_adjust_parent_for_prediv(struct 
ccu_common *common,
parent_index &= (1 << cm->width) - 1;
}
 
-   if (common->features & CCU_FEATURE_FIXED_PREDIV)
+   if (common->features & CCU_FEATURE_FIXED_PREDIV) {
+   int i;
+
for (i = 0; i < cm->n_predivs; i++)
if (parent_index == cm->fixed_predivs[i].index)
prediv = cm->fixed_predivs[i].div;
+   }
 
if (common->features & CCU_FEATURE_VARIABLE_PREDIV)
if (parent_index == cm->variable_prediv.index) {
@@ -54,7 +53,16 @@ void ccu_mux_helper_adjust_parent_for_prediv(struct 
ccu_common *common,
prediv = div + 1;
}
 
-   *parent_rate = *parent_rate / prediv;
+   return prediv;
+}
+
+void ccu_mux_helper_adjust_parent_for_prediv(struct ccu_common *common,
+struct ccu_mux_internal *cm,
+int parent_index,
+unsigned long *parent_rate)
+{
+   *parent_rate = *parent_rate / ccu_mux_get_prediv(common, cm,
+parent_index);
 }
 
 int ccu_mux_helper_determine_rate(struct ccu_common *common,
-- 
git-series 0.8.11

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH v2 0/20] drm: sun4i: Add support for the HDMI controller

[Maxime Ripard]

Hi,

Here is an attempt at getting the HDMI controller running.

This HDMI controller is found on a number of old Allwinner SoCs (A10, A10s,
A20, A31).

This driver only supports for now the A10s because it was an easy target,
being very close to the A13 that is already supported by our DRM driver.

There's nothing out of the extraordinary there, except maybe the clock
setup. All the internal clocks (TMDS, DDC) have been modeled using the
common clock framework, the TMDS clock being the parent of the DDC one.

While this might sound overkill, other SoC have a different, external
source for the DDC clock, which will be easier to support through the clock
framework.

The IP also supports audio (through an already supported i2s controller,
and some missing configuration in the HDMI controller) and CEC. Both will
come eventually.

Let me know what you think!
Maxime

Changes from v1:
  - Fixed typos in the CCU header and the HDMI code
  - Reintroduced the comment for the backporch timings
  - Renamed the hdmi node to hdmi, instead of hdmi0
  - Added support for hdmi-connector
  - Added a separate Kconfig option for the HDMI support
  - Changed the TCON muxing configuration for an explicit call in the
TCON's "clients"
  - Fixed the initialisation sequence that was clearing the clocks bits
  - Constified the HDMI's structures and removed whitespaces errors
  - Fixed an issue in the sunxi-ng code that was not reporting the proper
parent clock rate if it was modified
  - Removed unused headers
  - Removed CLK_SET_RATE_PARENT for the DDC clock
  - Used the DDC address defines
  - Removed the interlace flag that wasn't supported at the moment
  - Moved most of the HDMI encoder init to the bind function like we do for
the other encoders
  - Switched to drm_of_find_possible_crtcs
  - Removed the extra printk that were still in my code
  - Rebased on top of linux-next
  - Removed the patch changing the divider_round_rate prototype to
introduce a new function instead that takes the parent clock to
evaluate
  - Added a clk_set_rate for the hdmi module clock
  - Fixed the V_TOTAL TCON ch0 calculation to be consistent with ch1's
  - Defined all registers, and remove the TODOs
  - Fixed the EDID issues by increasing the timeout.
  - Added an atomic_check to prevent the DBLCLK modes to be used, as it is
not supported yet
  - Updated the binding to add the interrupts and DMA channels

Maxime Ripard (20):
  clk: divider: Make divider_round_rate take the parent clock
  clk: sunxi-ng: Pass the parent and a pointer to the clocks round rate
  clk: sunxi-ng: div: Switch to divider_round_rate
  clk: sunxi-ng: mux: Don't just rely on the parent for CLK_SET_RATE_PARENT
  clk: sunxi-ng: mux: split out the pre-divider computation code
  clk: sunxi-ng: mux: Change pre-divider application function prototype
  clk: sunxi-ng: mux: Re-adjust parent rate
  clk: sunxi-ng: sun5i: Export video PLLs
  drm/sun4i: tcon: Add channel debug
  drm/sun4i: tcon: Move the muxing out of the mode set function
  drm/sun4i: tcon: Switch mux on only for composite
  drm/sun4i: tcon: Fix tcon channel 1 backporch calculation
  drm/sun4i: tcon: Change vertical total size computation inconsistency
  drm/sun4i: tcon: multiply the vtotal when not in interlace
  drm/sun4i: Ignore the generic connectors for components
  dt-bindings: display: sun4i: Add HDMI display bindings
  dt-bindings: display: sun4i: Add allwinner,tcon-channel property
  drm/sun4i: Add HDMI support
  ARM: sun5i: a10s: Add the HDMI controller node
  ARM: sun5i: a10s-olinuxino: Enable HDMI

 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt |  90 +-
 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts  |  29 +-
 arch/arm/boot/dts/sun5i-a10s.dtsi |  50 +-
 arch/arm/boot/dts/sun5i.dtsi  |   1 +-
 drivers/clk/clk-divider.c |  26 +-
 drivers/clk/sunxi-ng/ccu-sun5i.h  |   6 +-
 drivers/clk/sunxi-ng/ccu_div.c|  38 +-
 drivers/clk/sunxi-ng/ccu_mp.c |  15 +-
 drivers/clk/sunxi-ng/ccu_mult.c   |  19 +-
 drivers/clk/sunxi-ng/ccu_mux.c|  90 +-
 drivers/clk/sunxi-ng/ccu_mux.h|  11 +-
 drivers/clk/sunxi-ng/ccu_nkm.c|   7 +-
 drivers/gpu/drm/sun4i/Kconfig |   9 +-
 drivers/gpu/drm/sun4i/Makefile|   6 +-
 drivers/gpu/drm/sun4i/sun4i_drv.c |   8 +-
 drivers/gpu/drm/sun4i/sun4i_hdmi.h| 157 ++-
 drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c| 127 ++-
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c| 493 +++-
 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c   | 225 +++-
 drivers/gpu/drm/sun4i/sun4i_rgb.c  

[linux-sunxi] [PATCH v2 18/20] drm/sun4i: Add HDMI support

[Maxime Ripard]

The earlier Allwinner SoCs (A10, A10s, A20, A31) have an embedded HDMI
controller.

That HDMI controller is able to do audio and CEC, but those have been left
out for now.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/Kconfig   |   9 +-
 drivers/gpu/drm/sun4i/Makefile  |   6 +-
 drivers/gpu/drm/sun4i/sun4i_hdmi.h  | 157 +++-
 drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c  | 127 +-
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c  | 493 +-
 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 225 ++-
 6 files changed, 1017 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi.h
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c

diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index a4b357db8856..35299c4e2594 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -12,3 +12,12 @@ config DRM_SUN4I
  Choose this option if you have an Allwinner SoC with a
  Display Engine. If M is selected the module will be called
  sun4i-drm.
+
+if DRM_SUN4I
+config DRM_SUN4I_HDMI
+   tristate "Allwinner A10 HDMI Controller Support"
+   help
+ Choose this option if you have an Allwinner SoC with an HDMI
+ controller.
+
+endif
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 59b757350a1f..c09bf8093710 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -11,3 +11,9 @@ obj-$(CONFIG_DRM_SUN4I)   += sun4i-drm.o 
sun4i-tcon.o
 obj-$(CONFIG_DRM_SUN4I)+= sun4i_backend.o
 obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
 obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
+
+sun4i-drm-hdmi-y += sun4i_hdmi_enc.o
+sun4i-drm-hdmi-y += sun4i_hdmi_ddc_clk.o
+sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
+
+obj-$(CONFIG_DRM_SUN4I_HDMI)   += sun4i-drm-hdmi.o
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
new file mode 100644
index ..40d57b195b48
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
@@ -0,0 +1,157 @@
+/*
+ * Copyright (C) 2016 Maxime Ripard
+ *
+ * Maxime Ripard 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#ifndef _SUN4I_HDMI_H_
+#define _SUN4I_HDMI_H_
+
+#include 
+#include 
+
+#define SUN4I_HDMI_CTRL_REG0x004
+#define SUN4I_HDMI_CTRL_ENABLE BIT(31)
+
+#define SUN4I_HDMI_IRQ_REG 0x008
+#define SUN4I_HDMI_IRQ_STA_MASK0x73
+#define SUN4I_HDMI_IRQ_STA_FIFO_OF BIT(1)
+#define SUN4I_HDMI_IRQ_STA_FIFO_UF BIT(0)
+
+#define SUN4I_HDMI_HPD_REG 0x00c
+#define SUN4I_HDMI_HPD_HIGHBIT(0)
+
+#define SUN4I_HDMI_VID_CTRL_REG0x010
+#define SUN4I_HDMI_VID_CTRL_ENABLE BIT(31)
+#define SUN4I_HDMI_VID_CTRL_HDMI_MODE  BIT(30)
+
+#define SUN4I_HDMI_VID_TIMING_ACT_REG  0x014
+#define SUN4I_HDMI_VID_TIMING_BP_REG   0x018
+#define SUN4I_HDMI_VID_TIMING_FP_REG   0x01c
+#define SUN4I_HDMI_VID_TIMING_SPW_REG  0x020
+
+#define SUN4I_HDMI_VID_TIMING_X(x) x) - 1) & GENMASK(11, 0)))
+#define SUN4I_HDMI_VID_TIMING_Y(y) y) - 1) & GENMASK(11, 0)) 
<< 16)
+
+#define SUN4I_HDMI_VID_TIMING_POL_REG  0x024
+#define SUN4I_HDMI_VID_TIMING_POL_TX_CLK(0x3e0 << 16)
+#define SUN4I_HDMI_VID_TIMING_POL_VSYNCBIT(1)
+#define SUN4I_HDMI_VID_TIMING_POL_HSYNCBIT(0)
+
+#define SUN4I_HDMI_AVI_INFOFRAME_REG(n)(0x080 + (n))
+
+#define SUN4I_HDMI_PAD_CTRL0_REG   0x200
+#define SUN4I_HDMI_PAD_CTRL0_BIASENBIT(31)
+#define SUN4I_HDMI_PAD_CTRL0_LDOCENBIT(30)
+#define SUN4I_HDMI_PAD_CTRL0_LDODENBIT(29)
+#define SUN4I_HDMI_PAD_CTRL0_PWENC BIT(28)
+#define SUN4I_HDMI_PAD_CTRL0_PWEND BIT(27)
+#define SUN4I_HDMI_PAD_CTRL0_PWENG BIT(26)
+#define SUN4I_HDMI_PAD_CTRL0_CKEN  BIT(25)
+#define SUN4I_HDMI_PAD_CTRL0_TXEN  BIT(23)
+
+#define SUN4I_HDMI_PAD_CTRL1_REG   0x204
+#define SUN4I_HDMI_PAD_CTRL1_AMP_OPT   BIT(23)
+#define SUN4I_HDMI_PAD_CTRL1_AMPCK_OPT BIT(22)
+#define SUN4I_HDMI_PAD_CTRL1_EMP_OPT   BIT(20)
+#define SUN4I_HDMI_PAD_CTRL1_EMPCK_OPT BIT(19)
+#define SUN4I_HDMI_PAD_CTRL1_REG_DEN   BIT(15)
+#define SUN4I_HDMI_PAD_CTRL1_REG_DENCK BIT(14)
+#define SUN4I_HDMI_PAD_CTRL1_REG_EMP(n)(((n) & 7) << 10)
+#define 

[linux-sunxi] [PATCH v2 6/20] clk: sunxi-ng: mux: Change pre-divider application function prototype

[Maxime Ripard]

The current function name is a bit confusing, and doesn't really allow to
create an explicit function to reverse the operation.

We also for now change the parent rate through a pointer, while we don't
return anything.

In order to be less confusing, and easier to use for downstream users,
change the function name to something hopefully clearer, and return the
adjusted rate instead of changing the pointer.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu_div.c  |  8 
 drivers/clk/sunxi-ng/ccu_mp.c   |  8 
 drivers/clk/sunxi-ng/ccu_mult.c |  8 
 drivers/clk/sunxi-ng/ccu_mux.c  | 29 -
 drivers/clk/sunxi-ng/ccu_mux.h  |  8 
 5 files changed, 28 insertions(+), 33 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_div.c b/drivers/clk/sunxi-ng/ccu_div.c
index 419463375bc1..c0e5c10d0091 100644
--- a/drivers/clk/sunxi-ng/ccu_div.c
+++ b/drivers/clk/sunxi-ng/ccu_div.c
@@ -59,8 +59,8 @@ static unsigned long ccu_div_recalc_rate(struct clk_hw *hw,
val = reg >> cd->div.shift;
val &= (1 << cd->div.width) - 1;
 
-   ccu_mux_helper_adjust_parent_for_prediv(>common, >mux, -1,
-   _rate);
+   parent_rate = ccu_mux_helper_apply_prediv(>common, >mux, -1,
+ parent_rate);
 
return divider_recalc_rate(hw, parent_rate, val, cd->div.table,
   cd->div.flags);
@@ -83,8 +83,8 @@ static int ccu_div_set_rate(struct clk_hw *hw, unsigned long 
rate,
unsigned long val;
u32 reg;
 
-   ccu_mux_helper_adjust_parent_for_prediv(>common, >mux, -1,
-   _rate);
+   parent_rate = ccu_mux_helper_apply_prediv(>common, >mux, -1,
+ parent_rate);
 
val = divider_get_val(rate, parent_rate, cd->div.table, cd->div.width,
  cd->div.flags);
diff --git a/drivers/clk/sunxi-ng/ccu_mp.c b/drivers/clk/sunxi-ng/ccu_mp.c
index de02e6c386d8..b917ad7a386c 100644
--- a/drivers/clk/sunxi-ng/ccu_mp.c
+++ b/drivers/clk/sunxi-ng/ccu_mp.c
@@ -87,8 +87,8 @@ static unsigned long ccu_mp_recalc_rate(struct clk_hw *hw,
u32 reg;
 
/* Adjust parent_rate according to pre-dividers */
-   ccu_mux_helper_adjust_parent_for_prediv(>common, >mux,
-   -1, _rate);
+   parent_rate = ccu_mux_helper_apply_prediv(>common, >mux, -1,
+ parent_rate);
 
reg = readl(cmp->common.base + cmp->common.reg);
 
@@ -123,8 +123,8 @@ static int ccu_mp_set_rate(struct clk_hw *hw, unsigned long 
rate,
u32 reg;
 
/* Adjust parent_rate according to pre-dividers */
-   ccu_mux_helper_adjust_parent_for_prediv(>common, >mux,
-   -1, _rate);
+   parent_rate = ccu_mux_helper_apply_prediv(>common, >mux, -1,
+ parent_rate);
 
max_m = cmp->m.max ?: 1 << cmp->m.width;
max_p = cmp->p.max ?: 1 << ((1 << cmp->p.width) - 1);
diff --git a/drivers/clk/sunxi-ng/ccu_mult.c b/drivers/clk/sunxi-ng/ccu_mult.c
index 6ee7ba0738fb..20d0300867f2 100644
--- a/drivers/clk/sunxi-ng/ccu_mult.c
+++ b/drivers/clk/sunxi-ng/ccu_mult.c
@@ -88,8 +88,8 @@ static unsigned long ccu_mult_recalc_rate(struct clk_hw *hw,
val = reg >> cm->mult.shift;
val &= (1 << cm->mult.width) - 1;
 
-   ccu_mux_helper_adjust_parent_for_prediv(>common, >mux, -1,
-   _rate);
+   parent_rate = ccu_mux_helper_apply_prediv(>common, >mux, -1,
+ parent_rate);
 
return parent_rate * (val + cm->mult.offset);
 }
@@ -116,8 +116,8 @@ static int ccu_mult_set_rate(struct clk_hw *hw, unsigned 
long rate,
else
ccu_frac_helper_disable(>common, >frac);
 
-   ccu_mux_helper_adjust_parent_for_prediv(>common, >mux, -1,
-   _rate);
+   parent_rate = ccu_mux_helper_apply_prediv(>common, >mux, -1,
+ parent_rate);
 
_cm.min = cm->mult.min;
 
diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
index 3eb23d4e6534..c33210972581 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.c
+++ b/drivers/clk/sunxi-ng/ccu_mux.c
@@ -56,13 +56,12 @@ static u16 ccu_mux_get_prediv(struct ccu_common *common,
return prediv;
 }
 
-void ccu_mux_helper_adjust_parent_for_prediv(struct ccu_common *common,
-struct ccu_mux_internal *cm,
-int parent_index,
-unsigned long *parent_rate)
+unsigned long ccu_mux_helper_apply_prediv(struct ccu_common *common,
+ 

[linux-sunxi] [PATCH v2 7/20] clk: sunxi-ng: mux: Re-adjust parent rate

[Maxime Ripard]

Currently, the parent rate given back to the clock framework in our
request is the original parent rate we calculated before trying to round
the rate of our clock.

This works fine unless our clock also changes its parent rate, in which
case we will simply ignore that change and still use the previous parent
rate.

Create a new function to re-adjust the parent rate to take the pre-dividers
into account, and give that back to the clock framework.

Signed-off-by: Maxime Ripard 
---
 drivers/clk/sunxi-ng/ccu_mux.c | 33 -
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
index c33210972581..1ce62cc23f8a 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.c
+++ b/drivers/clk/sunxi-ng/ccu_mux.c
@@ -64,6 +64,14 @@ unsigned long ccu_mux_helper_apply_prediv(struct ccu_common 
*common,
return parent_rate / ccu_mux_get_prediv(common, cm, parent_index);
 }
 
+unsigned long ccu_mux_helper_unapply_prediv(struct ccu_common *common,
+   struct ccu_mux_internal *cm,
+   int parent_index,
+   unsigned long parent_rate)
+{
+   return parent_rate * ccu_mux_get_prediv(common, cm, parent_index);
+}
+
 int ccu_mux_helper_determine_rate(struct ccu_common *common,
  struct ccu_mux_internal *cm,
  struct clk_rate_request *req,
@@ -89,22 +97,37 @@ int ccu_mux_helper_determine_rate(struct ccu_common *common,
best_rate = round(cm, best_parent, _parent_rate,
  req->rate, data);
 
+   /*
+* parent_rate might have been modified by our clock.
+* Re-apply the pre-divider if there's one, and give
+* the actual frequency the parent needs to run at.
+*/
+   best_parent_rate = ccu_mux_helper_unapply_prediv(common, cm, -1,
+
adj_parent_rate);
+
goto out;
}
 
for (i = 0; i < clk_hw_get_num_parents(hw); i++) {
-   unsigned long tmp_rate, parent_rate, adj_parent_rate;
+   unsigned long tmp_rate, parent_rate;
struct clk_hw *parent;
 
parent = clk_hw_get_parent_by_index(hw, i);
if (!parent)
continue;
 
-   parent_rate = clk_hw_get_rate(parent);
-   adj_parent_rate = ccu_mux_helper_apply_prediv(common, cm, i,
- parent_rate);
+   parent_rate = ccu_mux_helper_apply_prediv(common, cm, i,
+ 
clk_hw_get_rate(parent));
+
+   tmp_rate = round(cm, parent, _rate, req->rate, data);
 
-   tmp_rate = round(cm, parent, _parent_rate, req->rate, data);
+   /*
+* parent_rate might have been modified by our clock.
+* Re-apply the pre-divider if there's one, and give
+* the actual frequency the parent needs to run at.
+*/
+   parent_rate = ccu_mux_helper_unapply_prediv(common, cm, i,
+   parent_rate);
if (tmp_rate == req->rate) {
best_parent = parent;
best_parent_rate = parent_rate;
-- 
git-series 0.8.11

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Designware UART bug

[Olliver Schinagl]

Hey Chen-Yu

On 03-05-17 12:40, Chen-Yu Tsai wrote:

On Wed, May 3, 2017 at 6:17 PM, Olliver Schinagl  wrote:

Hey Jamie,

Several years ago you wrote the glue-code [0] for the DW 8250 IP. Over the
years various 'fixes' have been applied to resolve certain 'weird' problems
that Tim tried to fix with [1].

After going over the datasheets and code with a comb several times now, I
think I may have found one (of a few others) reasons and would like both
your and Tim's thoughts here.

The current (and original) code [2] uses the register offset 0x1f for the
UART_USR register.

I searched far and wide, various datasheet of physical uarts (8250 - 16950)
and some IP cores and none seem to have the USR (and specifically the USR[0]
bit) register, so it seems to be specific to the DW_apb_uart. However
looking at the only databook available to me [3] of the UART IP, I cannot
seem to find anything at register offset 0x1f.

The platform I'm using uses the Allwinner A20 SoC, which also features the
DW uart IP and also here, there is nothing at offset 0x1f.

The intended register IS however actually at 0x7c.

My question is thus twofold.

Why was 0x1f used? Is this specific to a certain (version) UART or is this a
long uncaught typo.


The original 8250 datasheets have registers at byte offsets. Note that the
registers are only 8 bits wide.
Yes, I did account for that difference :) Or rather, it should be the 
first register after the scratchpad, but there is nothing after the 
scratchpad on the 8250's.


On Allwinner, and many other platforms, the registers are still 8 bits
wide, but are 32bit-aligned, likely for aligned bus access. 0x7c = 0x1f << 2.
The 8250 core accessor functions are supposed to handle this for you.
Actually, they are 32 bit registers, but only the lowest 8 are used, to 
remain code-compatible with true 8 bitters. The end result, is the same 
of course.


As for the shift, I see now!

readb(p->membase + (offset << p->regshift));

And indeed, the regular defines are all indeed 8 bit offsets. Oversight 
on my part, and I changed the comment to make this slightly more clear, 
which goes into my greater uart series.


Thanks Chen-Yu for pointing this oversight of mine out!



ChenYu


Tim, assuming it is a typo, could this the cause which made you implement
[1]? From what I understand, you keep writing the LCR until it takes.
So with ChenYu's explanation, the USR register holds a valid status, but 
it was and is never checked and thus the below part is still a valid 
question?




Initially, the UART_IIR_BUSY check looked like this:
if (serial8250_handle_irq(p, iir)) {
return 1;
} else if ((iir & UART_IIR_BUSY) == UART_IIR_BUSY) {
/* Clear the USR and write the LCR again. */
(void)p->serial_in(p, d->usr_reg);
p->serial_out(p, UART_LCR, d->last_lcr);

return 1;
}

what I'm missing here is, that if UART_IIR_BUSY is set, we have to:
* check the d->usr_reg (UART_USR) bit 0
* wait until it becomes cleared (do not allow new data to be pushed out,
optionally force the data to be pushed out after a timeout)
* write LCR register (and check if it took (and no longer loop over the LCR
to see if the values stuck, in theory)).
* if we never get un-busy, something is wrong?

All of this btw is currently moot anyway, as the only way to get into the
(else) if, is if serial8250_handle_irq returns false. And from what I can
see, this is only if iir == UART_IIR_NO_IRQ, in which case we never ever
clear the USR and thus never ever clear the UART_IIR_BUSY flag.
especially this point is important I suppose, hence the need for the 
workaround [1].


Olliver


Olliver


[0]
https://github.com/torvalds/linux/commit/6b1a98d1c4851235d9b6764b3f7b7db7909fc760

[1]
https://github.com/torvalds/linux/commit/c49436b657d0a56a6ad90d14a7c3041add7cf64d

[2]
https://github.com/torvalds/linux/commit/6b1a98d1c4851235d9b6764b3f7b7db7909fc760#diff-d6e619fc4c51febf7880632fde5d0208R63

[3] http://linux-sunxi.org/images/d/d2/Dw_apb_uart_db.pdf

--
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.
For more options, visit https://groups.google.com/d/optout.


--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Designware UART bug

[Chen-Yu Tsai]

On Wed, May 3, 2017 at 6:17 PM, Olliver Schinagl  wrote:
> Hey Jamie,
>
> Several years ago you wrote the glue-code [0] for the DW 8250 IP. Over the
> years various 'fixes' have been applied to resolve certain 'weird' problems
> that Tim tried to fix with [1].
>
> After going over the datasheets and code with a comb several times now, I
> think I may have found one (of a few others) reasons and would like both
> your and Tim's thoughts here.
>
> The current (and original) code [2] uses the register offset 0x1f for the
> UART_USR register.
>
> I searched far and wide, various datasheet of physical uarts (8250 - 16950)
> and some IP cores and none seem to have the USR (and specifically the USR[0]
> bit) register, so it seems to be specific to the DW_apb_uart. However
> looking at the only databook available to me [3] of the UART IP, I cannot
> seem to find anything at register offset 0x1f.
>
> The platform I'm using uses the Allwinner A20 SoC, which also features the
> DW uart IP and also here, there is nothing at offset 0x1f.
>
> The intended register IS however actually at 0x7c.
>
> My question is thus twofold.
>
> Why was 0x1f used? Is this specific to a certain (version) UART or is this a
> long uncaught typo.

The original 8250 datasheets have registers at byte offsets. Note that the
registers are only 8 bits wide.

On Allwinner, and many other platforms, the registers are still 8 bits
wide, but are 32bit-aligned, likely for aligned bus access. 0x7c = 0x1f << 2.
The 8250 core accessor functions are supposed to handle this for you.

ChenYu

> Tim, assuming it is a typo, could this the cause which made you implement
> [1]? From what I understand, you keep writing the LCR until it takes.
>
> Initially, the UART_IIR_BUSY check looked like this:
> if (serial8250_handle_irq(p, iir)) {
> return 1;
> } else if ((iir & UART_IIR_BUSY) == UART_IIR_BUSY) {
> /* Clear the USR and write the LCR again. */
> (void)p->serial_in(p, d->usr_reg);
> p->serial_out(p, UART_LCR, d->last_lcr);
>
> return 1;
> }
>
> what I'm missing here is, that if UART_IIR_BUSY is set, we have:
> * check the d->usr_reg (UART_USR) bit 0
> * wait until it becomes cleared (do not allow new data to be pushed out,
> optionally force the data to be pushed out)
> * write LCR register (and check if it took (and no longer loop over the LCR
> to see if the values stuck, in theory).
> * if we never get un-busy, something is wrong?
>
> All of this btw is currently moot anyway, as the only way to get into the
> (else) if, is if serial8250_handle_irq returns false. And from what I can
> see, this is only if iir == UART_IIR_NO_IRQ, in which case we never ever
> clear the USR and thus never ever clear the UART_IIR_BUSY flag.
>
> Olliver
>
>
> [0]
> https://github.com/torvalds/linux/commit/6b1a98d1c4851235d9b6764b3f7b7db7909fc760
>
> [1]
> https://github.com/torvalds/linux/commit/c49436b657d0a56a6ad90d14a7c3041add7cf64d
>
> [2]
> https://github.com/torvalds/linux/commit/6b1a98d1c4851235d9b6764b3f7b7db7909fc760#diff-d6e619fc4c51febf7880632fde5d0208R63
>
> [3] http://linux-sunxi.org/images/d/d2/Dw_apb_uart_db.pdf
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Designware UART bug

[Olliver Schinagl]

Hey Jamie,

Several years ago you wrote the glue-code [0] for the DW 8250 IP. Over 
the years various 'fixes' have been applied to resolve certain 'weird' 
problems that Tim tried to fix with [1].


After going over the datasheets and code with a comb several times now, 
I think I may have found one (of a few others) reasons and would like 
both your and Tim's thoughts here.


The current (and original) code [2] uses the register offset 0x1f for 
the UART_USR register.


I searched far and wide, various datasheet of physical uarts (8250 - 
16950) and some IP cores and none seem to have the USR (and specifically 
the USR[0] bit) register, so it seems to be specific to the DW_apb_uart. 
However looking at the only databook available to me [3] of the UART IP, 
I cannot seem to find anything at register offset 0x1f.


The platform I'm using uses the Allwinner A20 SoC, which also features 
the DW uart IP and also here, there is nothing at offset 0x1f.


The intended register IS however actually at 0x7c.

My question is thus twofold.

Why was 0x1f used? Is this specific to a certain (version) UART or is 
this a long uncaught typo.


Tim, assuming it is a typo, could this the cause which made you 
implement [1]? From what I understand, you keep writing the LCR until it 
takes.


Initially, the UART_IIR_BUSY check looked like this:
if (serial8250_handle_irq(p, iir)) {
return 1;
} else if ((iir & UART_IIR_BUSY) == UART_IIR_BUSY) {
/* Clear the USR and write the LCR again. */
(void)p->serial_in(p, d->usr_reg);
p->serial_out(p, UART_LCR, d->last_lcr);

return 1;
}

what I'm missing here is, that if UART_IIR_BUSY is set, we have:
* check the d->usr_reg (UART_USR) bit 0
* wait until it becomes cleared (do not allow new data to be pushed out, 
optionally force the data to be pushed out)
* write LCR register (and check if it took (and no longer loop over the 
LCR to see if the values stuck, in theory).

* if we never get un-busy, something is wrong?

All of this btw is currently moot anyway, as the only way to get into 
the (else) if, is if serial8250_handle_irq returns false. And from what 
I can see, this is only if iir == UART_IIR_NO_IRQ, in which case we 
never ever clear the USR and thus never ever clear the UART_IIR_BUSY flag.


Olliver


[0] 
https://github.com/torvalds/linux/commit/6b1a98d1c4851235d9b6764b3f7b7db7909fc760


[1] 
https://github.com/torvalds/linux/commit/c49436b657d0a56a6ad90d14a7c3041add7cf64d


[2] 
https://github.com/torvalds/linux/commit/6b1a98d1c4851235d9b6764b3f7b7db7909fc760#diff-d6e619fc4c51febf7880632fde5d0208R63


[3] http://linux-sunxi.org/images/d/d2/Dw_apb_uart_db.pdf

--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH 13/15] drm/sun4i: Add HDMI support

[Maxime Ripard]

On Wed, Apr 26, 2017 at 03:59:28PM +0800, Chen-Yu Tsai wrote:
> >> > +   writel(SUN4I_HDMI_VID_TIMING_X(mode->hdisplay) |
> >> > +  SUN4I_HDMI_VID_TIMING_Y(mode->vdisplay),
> >> > +  hdmi->base + SUN4I_HDMI_VID_TIMING_ACT_REG);
> >> > +
> >> > +   x = mode->htotal - mode->hsync_start;
> >> > +   y = mode->vtotal - mode->vsync_start;
> >>
> >> I'm a bit skeptical about this one. All the other parameters are not
> >> inclusive of other, why would this one be different? Shouldn't it
> >> be "Xtotal - Xsync_end" instead?
> >
> > By the usual meaning of backporch, you're right. However, Allwinner's
> > seems to have it's own, which is actually the backporch + sync length.
> >
> > We also have that on all the other connectors (and TCON), and this was
> > confirmed at the time using a scope on an RGB signal.
> 
> Yes. On the later SoCs such as the A31, the user manual actually has
> timing diagrams showing this.
> 
> Unlike the TCON, the HDMI controller's timings lists the front porch
> separately, instead of an all inclusive Xtotal. This is what made me
> look twice. This should be easy to confirm though. Since the HDMI modes
> are well known and can be exactly reproduced on our hardware, we can
> just check for any distortions or refresh rate errors.

This isn't as trivial as that. Screens usually have some tolerancies
on the timings, which will probably make it go unnoticed, even though
they are wrong.

> >>
> >> > +   writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
> >> > +  hdmi->base + SUN4I_HDMI_VID_TIMING_BP_REG);
> >> > +
> >> > +   x = mode->hsync_start - mode->hdisplay;
> >> > +   y = mode->vsync_start - mode->vdisplay;
> >> > +   writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
> >> > +  hdmi->base + SUN4I_HDMI_VID_TIMING_FP_REG);
> >> > +
> >> > +   x = mode->hsync_end - mode->hsync_start;
> >> > +   y = mode->vsync_end - mode->vsync_start;
> >> > +   writel(SUN4I_HDMI_VID_TIMING_X(x) | SUN4I_HDMI_VID_TIMING_Y(y),
> >> > +  hdmi->base + SUN4I_HDMI_VID_TIMING_SPW_REG);
> >> > +
> >> > +   val = SUN4I_HDMI_VID_TIMING_POL_TX_CLK;
> >> > +   if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> >> > +   val |= SUN4I_HDMI_VID_TIMING_POL_HSYNC;
> >> > +
> >> > +   if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> >> > +   val |= SUN4I_HDMI_VID_TIMING_POL_VSYNC;
> >> > +
> >> > +   writel(val, hdmi->base + SUN4I_HDMI_VID_TIMING_POL_REG);
> >>
> >> You don't handle the interlaced video here, even though you set
> >>
> >> hdmi->connector.interlace_allowed = true
> >>
> >> later.
> >
> > I'll fix that.
> >
> >> The double clock and double scan flags aren't handled either, though
> >> I don't understand which one is supposed to represent the need for the
> >> HDMI pixel repeater. AFAIK this is required for resolutions with pixel
> >> clocks lower than 25 MHz, the lower limit of HDMI's TMDS link.
> >
> > I'm not sure about this one though. I'd like to keep things quite
> > simple for now and build up on that once the basis is working. Is it
> > common in the wild?
> 
> If you drive the display at SDTV resolutions, then yes. Mode lines from
> my HDMI monitor:
> 
>   720x576i 50 720 732 795 864 576 580 586 625 flags: nhsync, nvsync,
> interlace, dblclk; type: driver
>   720x480i 60 720 739 801 858 480 488 494 525 flags: nhsync, nvsync,
> interlace, dblclk; type: driver
>   720x480i 60 720 739 801 858 480 488 494 525 flags: nhsync, nvsync,
> interlace, dblclk; type: driver
> 
> AFAIK these are standard modes that all devices should support. Whether
> they are used daily is another thing. Maybe block modes with dblclk
> in .mode_fixup for now?

That would rather be atomic_check and / or mode_valid, but yeah, I can
do that.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
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.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature