date:20180104

[linux-sunxi] Re: [PATCH 06/11] dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline

2018-01-04 Thread Icenowy Zheng



于 2018年1月4日 GMT+08:00 上午5:32:26, "Jernej Škrabec"  写到:
>Hi Rob,
>
>Dne sreda, 03. januar 2018 ob 21:21:54 CET je Rob Herring napisal(a):
>> On Sat, Dec 30, 2017 at 10:01:58PM +0100, Jernej Skrabec wrote:
>> > This commit adds all necessary compatibles and descriptions needed
>to
>> > implement A83T HDMI pipeline.
>> > 
>> > Mixer is already properly described, so only compatible is added.
>> > 
>> > However, A83T TCON1, which is connected to HDMI, doesn't have
>channel 0,
>> > contrary to all TCONs currently described. Because of that, TCON
>> > documentation is extended.
>> > 
>> > A83T features Synopsys DW HDMI controller with a custom PHY which
>looks
>> > like Synopsys Gen2 PHY with few additions. Since there is no
>> > documentation, needed properties were found out through
>experimentation
>> > and reading BSP code.
>> > 
>> > At the end, example is added for newer SoCs, which features DE2 and
>DW
>> > HDMI.
>> > 
>> > Signed-off-by: Jernej Skrabec 
>> > ---
>> > 
>> >  .../bindings/display/sunxi/sun4i-drm.txt   | 188
>> >  - 1 file changed, 181 insertions(+), 7
>deletions(-)
>> > 
>> > diff --git
>a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
>> > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
>index
>> > 9f073af4c711..3eca258096a5 100644
>> > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
>> > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
>> > 
>> > @@ -64,6 +64,40 @@ Required properties:
>> >  first port should be the input endpoint. The second should be
>the
>> >  output, usually to an HDMI connector.
>> > 
>> > +DWC HDMI TX Encoder
>> > +-
>> > +
>> > +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX
>controller IP
>> > +with Allwinner's own PHY IP. It supports audio and video outputs
>and CEC.
>> > +
>> > +These DT bindings follow the Synopsys DWC HDMI TX bindings defined
>in
>> > +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with
>the
>> > +following device-specific properties.
>> > +
>> > +Required properties:
>> > +
>> > +  - compatible: value must be one of:
>> > +* "allwinner,sun8i-a83t-dw-hdmi"
>> > +  - reg: two pairs of base address and size of memory-mapped
>region,
>> > first
>> > +for controller and second for PHY
>> > +registers.
>> 
>> Seems like the phy should be a separate node and use the phy binding.
>> You can use the phy binding even if you don't use the kernel phy
>> framework...
>
>Unfortunately, it's not so straighforward. Phy is actually accessed
>through 
>I2C implemented in HDMI controller. Second memory region in this case
>has 
>small influence on phy. However, it has big influence on controller.

To be honest you used inaccurate word. Use "glue" directly
here may be more accurate.

>For 
>example, magic number has to be written in one register in second
>memory 
>region in order to unlock read access to any register from first memory
>region 
>(controller). However, they shouldn't be merged to one region, because
>first 
>memory region requires byte access while second memory region can be
>accessed 
>per byte or word.
>
>To complicate things more, later I want to add support for another SoC
>which 
>has same glue layer (unlocking read access, etc.) and uses memory
>mapped phy 
>registers in second memory region.
>
>I think current binding is the least complicated way to represent this.
>
>> 
>> > +  - reg-io-width: See dw_hdmi.txt. Shall be 1.
>> > +  - interrupts: HDMI interrupt number
>> > +  - clocks: phandles to the clocks feeding the HDMI encoder
>> > +* iahb: the HDMI bus clock
>> > +* isfr: the HDMI register clock
>> > +* tmds: the HDMI tmds clock
>> > +  - clock-names: the clock names mentioned above
>> > +  - resets: phandles to the reset controllers driving the encoder
>> > +* ctrl: the reset line for the controller
>> > +* phy: the reset line for the PHY
>> > +  - reset-names: the reset 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
>> >  --
>> > 
>> > @@ -94,18 +128,17 @@ Required properties:
>> > * allwinner,sun7i-a20-tcon
>> > * allwinner,sun8i-a33-tcon
>> > * allwinner,sun8i-a83t-tcon-lcd
>> > 
>> > +   * allwinner,sun8i-a83t-tcon-tv
>> > 
>> > * allwinner,sun8i-v3s-tcon
>> >   
>> >   - reg: base address and size of memory-mapped region
>> >   - interrupts: interrupt associated to this IP
>> > 
>> > - - clocks: phandles to the clocks feeding the TCON. Three are
>needed:
>> > 
>> > + - clocks: phandles to the clocks feeding the TCON. One is needed:
>> > - 'ahb': the interface clocks
>> > 
>> > -

[linux-sunxi] Re: [PATCH 06/11] dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline

2018-01-04 Thread Icenowy Zheng



于 2018年1月5日 GMT+08:00 上午2:52:10, Maxime Ripard 
 写到:
>On Wed, Jan 03, 2018 at 10:32:26PM +0100, Jernej Škrabec wrote:
>> Hi Rob,
>> 
>> Dne sreda, 03. januar 2018 ob 21:21:54 CET je Rob Herring napisal(a):
>> > On Sat, Dec 30, 2017 at 10:01:58PM +0100, Jernej Skrabec wrote:
>> > > This commit adds all necessary compatibles and descriptions
>needed to
>> > > implement A83T HDMI pipeline.
>> > > 
>> > > Mixer is already properly described, so only compatible is added.
>> > > 
>> > > However, A83T TCON1, which is connected to HDMI, doesn't have
>channel 0,
>> > > contrary to all TCONs currently described. Because of that, TCON
>> > > documentation is extended.
>> > > 
>> > > A83T features Synopsys DW HDMI controller with a custom PHY which
>looks
>> > > like Synopsys Gen2 PHY with few additions. Since there is no
>> > > documentation, needed properties were found out through
>experimentation
>> > > and reading BSP code.
>> > > 
>> > > At the end, example is added for newer SoCs, which features DE2
>and DW
>> > > HDMI.
>> > > 
>> > > Signed-off-by: Jernej Skrabec 
>> > > ---
>> > > 
>> > >  .../bindings/display/sunxi/sun4i-drm.txt   | 188
>> > >  - 1 file changed, 181 insertions(+), 7
>deletions(-)
>> > > 
>> > > diff --git
>a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
>> > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
>index
>> > > 9f073af4c711..3eca258096a5 100644
>> > > ---
>a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
>> > > +++
>b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
>> > > 
>> > > @@ -64,6 +64,40 @@ Required properties:
>> > >  first port should be the input endpoint. The second should
>be the
>> > >  output, usually to an HDMI connector.
>> > > 
>> > > +DWC HDMI TX Encoder
>> > > +-
>> > > +
>> > > +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX
>controller IP
>> > > +with Allwinner's own PHY IP. It supports audio and video outputs
>and CEC.
>> > > +
>> > > +These DT bindings follow the Synopsys DWC HDMI TX bindings
>defined in
>> > > +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
>with the
>> > > +following device-specific properties.
>> > > +
>> > > +Required properties:
>> > > +
>> > > +  - compatible: value must be one of:
>> > > +* "allwinner,sun8i-a83t-dw-hdmi"
>> > > +  - reg: two pairs of base address and size of memory-mapped
>region,
>> > > first
>> > > +for controller and second for PHY
>> > > +registers.
>> > 
>> > Seems like the phy should be a separate node and use the phy
>binding.
>> > You can use the phy binding even if you don't use the kernel phy
>> > framework...
>> 
>> Unfortunately, it's not so straighforward. Phy is actually accessed
>through 
>> I2C implemented in HDMI controller. Second memory region in this case
>has 
>> small influence on phy. However, it has big influence on controller.
>For 
>> example, magic number has to be written in one register in second
>memory 
>> region in order to unlock read access to any register from first
>memory region 
>> (controller). However, they shouldn't be merged to one region,
>because first 
>> memory region requires byte access while second memory region can be
>accessed 
>> per byte or word.
>> 
>> To complicate things more, later I want to add support for another
>SoC which 
>> has same glue layer (unlocking read access, etc.) and uses memory
>mapped phy 
>> registers in second memory region.
>> 
>> I think current binding is the least complicated way to represent
>this.
>
>I agree with Rob here. I did a similar thing for the DSI patches I've
>sent a few monthes ago and it turned out to not be that difficult, so
>I'm sure you can come up with something :)

In A83T/H3/A64/H5/R40 this part is not purely a PHY.
It controls the access of main controller's register (e.g. read/write
lock and register obfuscation). So it should be called a "glue"
with PHY part (and on A83T seems a pure glue) but not a simple
 PHY.

>
>Maxime
>
>-- 
>Maxime Ripard, Free Electrons
>Embedded Linux and Kernel engineering
>http://free-electrons.com
>
>___
>linux-arm-kernel mailing list
>linux-arm-ker...@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
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] Re: H3 SID eFuse write failure issue for ROTPK_HASH field

2018-01-04 Thread Icenowy Zheng



于 2018年1月5日 GMT+08:00 上午10:41:51, Jun Nie  写到:
>2018-01-04 22:53 GMT+08:00 Maxime Ripard
>:
>> On Fri, Dec 29, 2017 at 05:35:51PM +0800, Jun Nie wrote:
>>> Hi Bernhard,
>>>
>>> Resend this mail with CCing mail list so that more people can see
>this
>>> issue and may have answer. Also correct register access code I use
>as
>>> I send wrong version code in last mail.
>>>
>>> I see sunxi-tool patch a3ce5f9f and you also mentioned that writing
>value is OK
>>> with register based method in google group. Do you have eFuse
>writing
>>> code that works? I can write OEM_PROGRAM and THERMAL_SENSOR with
>below
>>> code. But when I write ROTPK_HASH, eFuse is not changed.
>>
>> I'm not sure if this is still relevant, but some of the older SoCs
>> were allegedly needing to toggle one pin low in order to program the
>> fuses (VDDQE on the A20) before writing to it.
>>
>> I have no idea whether it's still there on the H3 though, and no one
>> ever tried it as far as I'm aware.
>>
>> Maxime
>
>Maxime,
>
>Thanks for sharing this info! Did you remember what pin is needed to
>toggle? The toggling is needed for any eFuse field program, or just
>some fields of eFuse?

I think it's all.

>
>Best Regards.
>Jun
>
>>
>> --
>> 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.

[linux-sunxi] Re: H3 SID eFuse write failure issue for ROTPK_HASH field

2018-01-04 Thread Jun Nie

2018-01-04 22:53 GMT+08:00 Maxime Ripard :
> On Fri, Dec 29, 2017 at 05:35:51PM +0800, Jun Nie wrote:
>> Hi Bernhard,
>>
>> Resend this mail with CCing mail list so that more people can see this
>> issue and may have answer. Also correct register access code I use as
>> I send wrong version code in last mail.
>>
>> I see sunxi-tool patch a3ce5f9f and you also mentioned that writing value is 
>> OK
>> with register based method in google group. Do you have eFuse writing
>> code that works? I can write OEM_PROGRAM and THERMAL_SENSOR with below
>> code. But when I write ROTPK_HASH, eFuse is not changed.
>
> I'm not sure if this is still relevant, but some of the older SoCs
> were allegedly needing to toggle one pin low in order to program the
> fuses (VDDQE on the A20) before writing to it.
>
> I have no idea whether it's still there on the H3 though, and no one
> ever tried it as far as I'm aware.
>
> Maxime

Maxime,

Thanks for sharing this info! Did you remember what pin is needed to
toggle? The toggling is needed for any eFuse field program, or just
some fields of eFuse?

Best Regards.
Jun

>
> --
> 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.

[linux-sunxi] Re: [PATCH v2 1/3] drm/sun4i: hdmi: Check for unset best_parent in sun4i_tmds_determine_rate

2018-01-04 Thread Jonathan Liu

Hi Maxime,

On 5 January 2018 at 06:56, Maxime Ripard
 wrote:
> On Tue, Dec 26, 2017 at 10:12:25PM +1100, Jonathan Liu wrote:
>> We should check if the best match has been set before comparing it.
>>
>> Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
>> Signed-off-by: Jonathan Liu 
>> ---
>>  drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c 
>> b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
>> index dc332ea56f6c..4d235e5ea31c 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
>> @@ -102,7 +102,7 @@ static int sun4i_tmds_determine_rate(struct clk_hw *hw,
>>   goto out;
>>   }
>>
>> - if (abs(rate - rounded / i) <
>> + if (!best_parent || abs(rate - rounded / i) <
>
> Why is that causing any issue?
>
> If best_parent is set to 0...
>
>>   abs(rate - best_parent / best_div)) {
>
> ... the value returned here is going to be rate, which is going to be
> higher than the first part of the comparison meaning ...
>
>>   best_parent = rounded;
>
> ... that best_parent is going to be set there.

Consider the following:
rate = 8350
rounded = ideal * 2

It is possible that if "rounded = clk_hw_round_rate(parent, ideal)"
gives high enough values that the condition "abs(rate - rounded / i) <
abs(rate - best_parent / best_div)" is never met.

Then you can end up with:
req->rate = 0
req->best_parent_rate = 0
req->best_parent_hw = ...

Also, the sun4i_tmds_calc_divider function has a similar check.

Regards,
Jonathan

-- 
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 0/8] ARM: sun9i: SMP support with Multi-Cluster Power Management

2018-01-04 Thread Nicolas Pitre

On Thu, 4 Jan 2018, Chen-Yu Tsai wrote:

> Nicolas mentioned that the MCPM framework is likely overkill in our
> case [4]. However the framework does provide cluster/core state tracking
> and proper sequencing of cache related operations. We could rework
> the code to use standard smp_ops, but I would like to actually get
> a working version in first.
> 
> [...] For now however I'm using a
> dedicated single thread workqueue. CPU and cluster power off work is
> queued from the .{cpu,cluster}_powerdown_prepare callbacks. This solution
> is somewhat heavy, as I have a total of 10 static work structs. It might
> also be a bit racy, as nothing prevents the system from bringing a core
> back before the asynchronous work shuts it down. This would likely
> happen under a heavily loaded system with a scheduler that brings cores
> in and out of the system frequently. In simple use-cases it performs OK.

If you know up front your code is racy then this doesn't fully qualify 
as a "working version". Furthermore you're trading custom cluster/core 
state tracking for workqueue handling which doesn't look like a winning 
tradeoff to me. Especially given you can't have asynchronous CPU wakeups 
in hardware from an IRQ to deal with then the state tracking becomes 
very simple.

If you hook into struct smp_operations directly, you'll have direct 
access to both .cpu_die and .cpu_kill methods which are executed on the 
target CPU and on a different CPU respectively, which is exactly what 
you need. Those calls are already serialized with .smp_boot_secondary so 
you don't have to worry about races. The only thing you need to protect 
against races is your cluster usage count. Your code will end up being 
simpler than what you have now. See arch/arm/mach-hisi/platmcpm.c for 
example.

Nicolas

-- 
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/3] drm/sun4i: hdmi: Check for unset best_parent in sun4i_tmds_determine_rate

2018-01-04 Thread Maxime Ripard

Hi,

On Tue, Dec 26, 2017 at 10:12:25PM +1100, Jonathan Liu wrote:
> We should check if the best match has been set before comparing it.
> 
> Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
> Signed-off-by: Jonathan Liu 
> ---
>  drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c 
> b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
> index dc332ea56f6c..4d235e5ea31c 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
> @@ -102,7 +102,7 @@ static int sun4i_tmds_determine_rate(struct clk_hw *hw,
>   goto out;
>   }
>  
> - if (abs(rate - rounded / i) <
> + if (!best_parent || abs(rate - rounded / i) <

Why is that causing any issue?

If best_parent is set to 0...

>   abs(rate - best_parent / best_div)) {

... the value returned here is going to be rate, which is going to be
higher than the first part of the comparison meaning ...

>   best_parent = rounded;

... that best_parent is going to be set there.

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 01/11] clk: sunxi-ng: Don't set k if width is 0 for nkmp plls

2018-01-04 Thread Jernej Škrabec

Hi,

Dne četrtek, 04. januar 2018 ob 15:45:18 CET je Chen-Yu Tsai napisal(a):
> On Sun, Dec 31, 2017 at 5:01 AM, Jernej Skrabec  
wrote:
> > For example, A83T have nmp plls which are modelled as nkmp plls. Since k
> > is not specified, it has offset 0, shift 0 and lowest value 1. This
> > means that LSB bit is always set to 1, which may change clock rate.
> > 
> > Fix that by applying k factor only if k width is greater than 0.
> > 
> > Signed-off-by: Jernej Skrabec 
> > ---
> > 
> >  drivers/clk/sunxi-ng/ccu_nkmp.c | 21 +
> >  1 file changed, 13 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c
> > b/drivers/clk/sunxi-ng/ccu_nkmp.c index e58c95787f94..709f528af2b3 100644
> > --- a/drivers/clk/sunxi-ng/ccu_nkmp.c
> > +++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
> > @@ -81,7 +81,7 @@ static unsigned long ccu_nkmp_recalc_rate(struct clk_hw
> > *hw,> 
> > unsigned long parent_rate)
> >  
> >  {
> >  
> > struct ccu_nkmp *nkmp = hw_to_ccu_nkmp(hw);
> > 
> > -   unsigned long n, m, k, p;
> > +   unsigned long n, m, k = 1, p;
> > 
> > u32 reg;
> > 
> > reg = readl(nkmp->common.base + nkmp->common.reg);
> > 
> > @@ -92,11 +92,13 @@ static unsigned long ccu_nkmp_recalc_rate(struct
> > clk_hw *hw,> 
> > if (!n)
> > 
> > n++;
> > 
> > -   k = reg >> nkmp->k.shift;
> > -   k &= (1 << nkmp->k.width) - 1;
> > -   k += nkmp->k.offset;
> > -   if (!k)
> > -   k++;
> > +   if (nkmp->k.width) {
> > +   k = reg >> nkmp->k.shift;
> > +   k &= (1 << nkmp->k.width) - 1;
> > +   k += nkmp->k.offset;
> > +   if (!k)
> > +   k++;
> > +   }
> 
> The conditional shouldn't be necessary. With nkmp->k.width = 0,
> you'd simply get k & 0, which is 0, which then gets bumped up to 1,
> unless k.offset > 1, which would be a bug.
> 
> > m = reg >> nkmp->m.shift;
> > m &= (1 << nkmp->m.width) - 1;
> > 
> > @@ -153,12 +155,15 @@ static int ccu_nkmp_set_rate(struct clk_hw *hw,
> > unsigned long rate,> 
> > reg = readl(nkmp->common.base + nkmp->common.reg);
> > reg &= ~GENMASK(nkmp->n.width + nkmp->n.shift - 1, nkmp->n.shift);
> > 
> > -   reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift);
> > +   if (nkmp->k.width)
> > +   reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1,
> > +   nkmp->k.shift);
> > 
> > reg &= ~GENMASK(nkmp->m.width + nkmp->m.shift - 1, nkmp->m.shift);
> > reg &= ~GENMASK(nkmp->p.width + nkmp->p.shift - 1, nkmp->p.shift);
> > 
> > reg |= (_nkmp.n - nkmp->n.offset) << nkmp->n.shift;
> > 
> > -   reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
> > +   if (nkmp->k.width)
> > +   reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
> 
> I think a better way would be
> 
> reg |= ((_nkmp.k - nkmp->k.offset) << nkmp->k.shift) &
>GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift);
> 
> And do this for all the factors, not just k. This pattern is what
> regmap_update_bits does, which seems much safer. I wonder what
> GENMASK() with a negative value would do though...

You're right, GENMASK(-1, 0) equals 0 (calculated by hand, not tested). This 
seems much more elegant solution. 

Semi-related question: All nmp PLLs have much wider N range than real nkmp 
PLLs. This causes integer overflow when using nkmp formula from datasheet. 
Usually, N is 1-256 for nmp PLLs, which means that for very high N factors, it 
overflows. This also causes issue that M factor is never higher than 1.

I was wondering, if patch would be acceptable which would change this formula:

RATE = (24MHz * N * K) / (M * P)

to this:

RATE ((24MHz / M) * N * K) / P

I checked all M factors and are all in 1-4 or 1-2 range, which means it 
wouldn't have any impact for real nkmp PLLs when parent is 24 MHz clock which 
is probably always.

What do you think?

I discovered that when I tried to set A83T PLL_VIDEO to 346.5 MHz which is 
possible only when above formula is changed.

Best regards,
Jernej

> 
> ChenYu
> 
> > reg |= (_nkmp.m - nkmp->m.offset) << nkmp->m.shift;
> > reg |= ilog2(_nkmp.p) << nkmp->p.shift;
> > 
> > --
> > 2.15.1




-- 
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 06/11] dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline

2018-01-04 Thread Maxime Ripard

On Wed, Jan 03, 2018 at 10:32:26PM +0100, Jernej Škrabec wrote:
> Hi Rob,
> 
> Dne sreda, 03. januar 2018 ob 21:21:54 CET je Rob Herring napisal(a):
> > On Sat, Dec 30, 2017 at 10:01:58PM +0100, Jernej Skrabec wrote:
> > > This commit adds all necessary compatibles and descriptions needed to
> > > implement A83T HDMI pipeline.
> > > 
> > > Mixer is already properly described, so only compatible is added.
> > > 
> > > However, A83T TCON1, which is connected to HDMI, doesn't have channel 0,
> > > contrary to all TCONs currently described. Because of that, TCON
> > > documentation is extended.
> > > 
> > > A83T features Synopsys DW HDMI controller with a custom PHY which looks
> > > like Synopsys Gen2 PHY with few additions. Since there is no
> > > documentation, needed properties were found out through experimentation
> > > and reading BSP code.
> > > 
> > > At the end, example is added for newer SoCs, which features DE2 and DW
> > > HDMI.
> > > 
> > > Signed-off-by: Jernej Skrabec 
> > > ---
> > > 
> > >  .../bindings/display/sunxi/sun4i-drm.txt   | 188
> > >  - 1 file changed, 181 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index
> > > 9f073af4c711..3eca258096a5 100644
> > > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > 
> > > @@ -64,6 +64,40 @@ Required properties:
> > >  first port should be the input endpoint. The second should be the
> > >  output, usually to an HDMI connector.
> > > 
> > > +DWC HDMI TX Encoder
> > > +-
> > > +
> > > +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
> > > +with Allwinner's own PHY IP. It supports audio and video outputs and CEC.
> > > +
> > > +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
> > > +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the
> > > +following device-specific properties.
> > > +
> > > +Required properties:
> > > +
> > > +  - compatible: value must be one of:
> > > +* "allwinner,sun8i-a83t-dw-hdmi"
> > > +  - reg: two pairs of base address and size of memory-mapped region,
> > > first
> > > +for controller and second for PHY
> > > +registers.
> > 
> > Seems like the phy should be a separate node and use the phy binding.
> > You can use the phy binding even if you don't use the kernel phy
> > framework...
> 
> Unfortunately, it's not so straighforward. Phy is actually accessed through 
> I2C implemented in HDMI controller. Second memory region in this case has 
> small influence on phy. However, it has big influence on controller. For 
> example, magic number has to be written in one register in second memory 
> region in order to unlock read access to any register from first memory 
> region 
> (controller). However, they shouldn't be merged to one region, because first 
> memory region requires byte access while second memory region can be accessed 
> per byte or word.
> 
> To complicate things more, later I want to add support for another SoC which 
> has same glue layer (unlocking read access, etc.) and uses memory mapped phy 
> registers in second memory region.
> 
> I think current binding is the least complicated way to represent this.

I agree with Rob here. I did a similar thing for the DSI patches I've
sent a few monthes ago and it turned out to not be that difficult, so
I'm sure you can come up with something :)

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.

[linux-sunxi] Re: [PATCH 08/11] drm/sun4i: Add support for A83T second DE2 mixer

2018-01-04 Thread Maxime Ripard

On Sat, Dec 30, 2017 at 10:02:00PM +0100, Jernej Skrabec wrote:
> It supports 1 VI and 1 UI plane and HW scaling on both planes.
> 
> Signed-off-by: Jernej Skrabec 

Acked-by: Maxime Ripard 

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 07/11] drm/sun4i: Add support for A83T second TCON

2018-01-04 Thread Maxime Ripard

Hi,

On Sat, Dec 30, 2017 at 10:01:59PM +0100, Jernej Skrabec wrote:
> This TCON doesn't have channel 0, so quirk has_channel_0 is added in the
> process.
> 
> Signed-off-by: Jernej Skrabec 

Ideally, this should be split in two patches, one to add the new flag,
and one to add the support for the A83t TCON-TV.

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] [PATCH v4 0/2] Initial Allwinner V3s CSI Support

2018-01-04 Thread 'Ondřej Jirman' via linux-sunxi

On Thu, Jan 04, 2018 at 03:06:25PM +0100, Maxime Ripard wrote:
> On Mon, Dec 25, 2017 at 09:58:02AM +0100, Ondřej Jirman wrote:
> > Hello,
> > 
> > On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> > > Hi,
> > > 
> > > On Fri, 22 Dec 2017 14:46:48 +0100
> > > Ondřej Jirman  wrote:
> > > 
> > > > Hello,
> > > > 
> > > > Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> > > > > 
> > > > > Test input 0:
> > > > > 
> > > > > Control ioctls:
> > > > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not 
> > > > > Supported)
> > > > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not 
> > > > > Supported)
> > > > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > > > Standard Controls: 0 Private Controls: 0
> > > > 
> > > > I'm not sure if your driver passes control queries to the subdev. It
> > > > did not originally, and I'm not sure you picked up the change from my
> > > > version of the driver. "Not supported" here seems to indicate that it
> > > > does not.
> > > > 
> > > > I'd be interested what's the recommended practice here. It sure helps
> > > > with some apps that expect to be able to modify various input controls
> > > > directly on the /dev/video# device. These are then supported out of the
> > > > box.
> > > > 
> > > > It's a one-line change. See:
> > > > 
> > > > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > > > heriting-controls
> > > 
> > > I think this is a feature and not affect the driver's main function.
> > > I just focused on making the CSI main function to work properly in 
> > > the initial version. Is this feature mandatory or most commonly used?
> > 
> > I grepped the platform/ code and it seems, that inheriting controls
> > from subdevs is pretty common for input drivers. (there are varying
> > approaches though, some inherit by hand in the link function, some
> > just register and empty ctrl_handler on the v4l2_dev and leave the
> > rest to the core).
> > 
> > Practically, I haven't found a common app that would allow me to enter
> > both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
> > themselves, but it would be better if current controls were available
> > at the /dev/video0 device automatically.
> > 
> > It's much simpler for the userspace apps than the alternative, which
> > is trying to identify the correct subdev that is currently
> > associated with the CSI driver at runtime, which is not exactly
> > straightforward and requires much more code, than a few lines in
> > the kernel, that are required to inherit controls:
> 
> And it becomes much more complicated once you have the same controls
> on the v4l2 device and subdevice, which is not that uncommon.

Hi Maxime,

I don't think you understand the issue. In your hypothetical situation, if the
CSI device will have any controls in the future, the merging of controls from
subdev will be done automatically anyway, it's not some optional feature.

Also userspace will not get any more complicated than without my proposed change
to the driver. It will be at most the same as without the change if any subdev
controls are masked by the CSI device controls.

This CSI driver has no controls anyway. All my change does is create an empty
handler for future controls of the CSI driver, so that apps can depend on this
merging behavior right now, and not wait until someone adds the first control
to the CSI driver.

regards,
  o.j.

> 
> 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.

[linux-sunxi] Re: [PATCH v2 0/8] ARM: sun9i: SMP support with Multi-Cluster Power Management

2018-01-04 Thread Maxime Ripard

On Thu, Jan 04, 2018 at 10:37:46PM +0800, Chen-Yu Tsai wrote:
> This is v2 of my sun9i SMP support with MCPM series which was started
> over two years ago [1]. We've tried to implement PSCI for both the A80
> and A83T. Results were not promising. The issue is that these two chips
> have a broken security extensions implementation. If a specific bit is
> not burned in its e-fuse, most if not all security protections don't
> work [2]. Even worse, non-secure access to the GIC become secure. This
> requires a crazy workaround in the GIC driver which probably doesn't work
> in all cases [3].
> 
> Nicolas mentioned that the MCPM framework is likely overkill in our
> case [4]. However the framework does provide cluster/core state tracking
> and proper sequencing of cache related operations. We could rework
> the code to use standard smp_ops, but I would like to actually get
> a working version in first.
> 
> Much of the sunxi-specific MCPM code is derived from Allwinner code and
> documentation, with some references to the other MCPM implementations,
> as well as the Cortex's Technical Reference Manuals for the power
> sequencing info.
> 
> One major difference compared to other platforms is we currently do not
> have a standalone PMU or other embedded firmware to do the actually power
> sequencing. All power/reset control is done by the kernel. Nicolas
> mentioned that a new optional callback should be added in cases where the
> kernel has to do the actual power down [5]. For now however I'm using a
> dedicated single thread workqueue. CPU and cluster power off work is
> queued from the .{cpu,cluster}_powerdown_prepare callbacks. This solution
> is somewhat heavy, as I have a total of 10 static work structs. It might
> also be a bit racy, as nothing prevents the system from bringing a core
> back before the asynchronous work shuts it down. This would likely
> happen under a heavily loaded system with a scheduler that brings cores
> in and out of the system frequently. In simple use-cases it performs OK.

It all looks sane to me
Acked-by: Maxime Ripard 

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 01/11] clk: sunxi-ng: Don't set k if width is 0 for nkmp plls

2018-01-04 Thread Chen-Yu Tsai

On Sun, Dec 31, 2017 at 5:01 AM, Jernej Skrabec  wrote:
> For example, A83T have nmp plls which are modelled as nkmp plls. Since k
> is not specified, it has offset 0, shift 0 and lowest value 1. This
> means that LSB bit is always set to 1, which may change clock rate.
>
> Fix that by applying k factor only if k width is greater than 0.
>
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/clk/sunxi-ng/ccu_nkmp.c | 21 +
>  1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c b/drivers/clk/sunxi-ng/ccu_nkmp.c
> index e58c95787f94..709f528af2b3 100644
> --- a/drivers/clk/sunxi-ng/ccu_nkmp.c
> +++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
> @@ -81,7 +81,7 @@ static unsigned long ccu_nkmp_recalc_rate(struct clk_hw *hw,
> unsigned long parent_rate)
>  {
> struct ccu_nkmp *nkmp = hw_to_ccu_nkmp(hw);
> -   unsigned long n, m, k, p;
> +   unsigned long n, m, k = 1, p;
> u32 reg;
>
> reg = readl(nkmp->common.base + nkmp->common.reg);
> @@ -92,11 +92,13 @@ static unsigned long ccu_nkmp_recalc_rate(struct clk_hw 
> *hw,
> if (!n)
> n++;
>
> -   k = reg >> nkmp->k.shift;
> -   k &= (1 << nkmp->k.width) - 1;
> -   k += nkmp->k.offset;
> -   if (!k)
> -   k++;
> +   if (nkmp->k.width) {
> +   k = reg >> nkmp->k.shift;
> +   k &= (1 << nkmp->k.width) - 1;
> +   k += nkmp->k.offset;
> +   if (!k)
> +   k++;
> +   }

The conditional shouldn't be necessary. With nkmp->k.width = 0,
you'd simply get k & 0, which is 0, which then gets bumped up to 1,
unless k.offset > 1, which would be a bug.

>
> m = reg >> nkmp->m.shift;
> m &= (1 << nkmp->m.width) - 1;
> @@ -153,12 +155,15 @@ static int ccu_nkmp_set_rate(struct clk_hw *hw, 
> unsigned long rate,
>
> reg = readl(nkmp->common.base + nkmp->common.reg);
> reg &= ~GENMASK(nkmp->n.width + nkmp->n.shift - 1, nkmp->n.shift);
> -   reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift);
> +   if (nkmp->k.width)
> +   reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1,
> +   nkmp->k.shift);
> reg &= ~GENMASK(nkmp->m.width + nkmp->m.shift - 1, nkmp->m.shift);
> reg &= ~GENMASK(nkmp->p.width + nkmp->p.shift - 1, nkmp->p.shift);
>
> reg |= (_nkmp.n - nkmp->n.offset) << nkmp->n.shift;
> -   reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
> +   if (nkmp->k.width)
> +   reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;

I think a better way would be

reg |= ((_nkmp.k - nkmp->k.offset) << nkmp->k.shift) &
   GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift);

And do this for all the factors, not just k. This pattern is what
regmap_update_bits does, which seems much safer. I wonder what
GENMASK() with a negative value would do though...

ChenYu

> reg |= (_nkmp.m - nkmp->m.offset) << nkmp->m.shift;
> reg |= ilog2(_nkmp.p) << nkmp->p.shift;
>
> --
> 2.15.1
>

-- 
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: H3 SID eFuse write failure issue for ROTPK_HASH field

2018-01-04 Thread Maxime Ripard

On Fri, Dec 29, 2017 at 05:35:51PM +0800, Jun Nie wrote:
> Hi Bernhard,
> 
> Resend this mail with CCing mail list so that more people can see this
> issue and may have answer. Also correct register access code I use as
> I send wrong version code in last mail.
> 
> I see sunxi-tool patch a3ce5f9f and you also mentioned that writing value is 
> OK
> with register based method in google group. Do you have eFuse writing
> code that works? I can write OEM_PROGRAM and THERMAL_SENSOR with below
> code. But when I write ROTPK_HASH, eFuse is not changed.

I'm not sure if this is still relevant, but some of the older SoCs
were allegedly needing to toggle one pin low in order to program the
fuses (VDDQE on the A20) before writing to it.

I have no idea whether it's still there on the H3 though, and no one
ever tried it as far as I'm aware.

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] [PATCH v2 3/8] ARM: dts: sun9i: Add CPUCFG device node for A80 dtsi

2018-01-04 Thread Chen-Yu Tsai

CPUCFG is a collection of registers that are mapped to the SoC's signals
from each individual processor core and associated peripherals, such as
resets for processors, L1/L2 cache and other things.

These registers are used for SMP bringup and CPU hotplugging.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun9i-a80.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index 85fb800af8ab..85ecb4d64cfd 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -363,6 +363,11 @@
#reset-cells = <1>;
};
 
+   cpucfg@170 {
+   compatible = "allwinner,sun9i-a80-cpucfg";
+   reg = <0x0170 0x100>;
+   };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun9i-a80-mmc";
reg = <0x01c0f000 0x1000>;
-- 
2.15.1

-- 
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/8] ARM: sun9i: mcpm: Support CPU/cluster power down and hotplugging for cpu1~7

2018-01-04 Thread Chen-Yu Tsai

This patch adds common code used to power down all cores and clusters.
The code is quite long. The common MCPM library does not provide a
callback for doing the actual power down sequence. Instead it assumes
some other part (maybe a power management coprocessor) will handle it.
Since our platform does not have this, we resort to using a single thread
workqueue, based on how our work should be done in the order they were
queued, so the cluster power down code does not execute before the core
power down code. Though the scenario is not catastrophic, it will leave
the cluster on and using power.

This might be a bit racy, as nothing prevents the system from bringing a
core or cluster back before the asynchronous work shuts it down. This would
likely happen under a heavily loaded system with a scheduler that brings
cores in and out of the system frequently. It would either result in a
stall on a single core, or worse, hang the system if a cluster is abruptly
turned off. In simple use-cases it performs OK.

The primary core (cpu0) requires setting flags to have the BROM bounce
execution to the SMP software entry code. This is done in a subsequent
patch to keep the changes cleanly separated.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/mach-sunxi/mcpm.c | 170 +++--
 1 file changed, 165 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-sunxi/mcpm.c b/arch/arm/mach-sunxi/mcpm.c
index 30719998f3f0..ddc26b5fec48 100644
--- a/arch/arm/mach-sunxi/mcpm.c
+++ b/arch/arm/mach-sunxi/mcpm.c
@@ -12,9 +12,12 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -30,6 +33,9 @@
 #define CPUCFG_CX_CTRL_REG0_L2_RST_DISABLE_A15 BIT(0)
 #define CPUCFG_CX_CTRL_REG1(c) (0x10 * (c) + 0x4)
 #define CPUCFG_CX_CTRL_REG1_ACINACTM   BIT(0)
+#define CPUCFG_CX_STATUS(c)(0x30 + 0x4 * (c))
+#define CPUCFG_CX_STATUS_STANDBYWFI(n) BIT(16 + (n))
+#define CPUCFG_CX_STATUS_STANDBYWFIL2  BIT(0)
 #define CPUCFG_CX_RST_CTRL(c)  (0x80 + 0x4 * (c))
 #define CPUCFG_CX_RST_CTRL_DBG_SOC_RST BIT(24)
 #define CPUCFG_CX_RST_CTRL_ETM_RST(n)  BIT(20 + (n))
@@ -237,6 +243,30 @@ static int sunxi_cluster_powerup(unsigned int cluster)
return 0;
 }
 
+struct sunxi_mcpm_work {
+   struct work_struct work;
+   unsigned int cpu;
+   unsigned int cluster;
+};
+
+static struct workqueue_struct *sunxi_mcpm_wq;
+static struct sunxi_mcpm_work sunxi_mcpm_cpu_down_work[2][4];
+static struct sunxi_mcpm_work sunxi_mcpm_cluster_down_work[2];
+
+static void sunxi_cpu_powerdown_prepare(unsigned int cpu, unsigned int cluster)
+{
+   gic_cpu_if_down(0);
+
+   queue_work(sunxi_mcpm_wq,
+  _mcpm_cpu_down_work[cluster][cpu].work);
+}
+
+static void sunxi_cluster_powerdown_prepare(unsigned int cluster)
+{
+   queue_work(sunxi_mcpm_wq,
+  _mcpm_cluster_down_work[cluster].work);
+}
+
 static void sunxi_cpu_cache_disable(void)
 {
/* Disable and flush the local CPU cache. */
@@ -286,11 +316,116 @@ static void sunxi_cluster_cache_disable(void)
writel(reg, cpucfg_base + CPUCFG_CX_CTRL_REG1(cluster));
 }
 
+static int sunxi_do_cpu_powerdown(unsigned int cpu, unsigned int cluster)
+{
+   u32 reg;
+
+   pr_debug("%s: cpu %u cluster %u\n", __func__, cpu, cluster);
+   if (cpu >= SUNXI_CPUS_PER_CLUSTER || cluster >= SUNXI_NR_CLUSTERS)
+   return -EINVAL;
+
+   /* gate processor power */
+   reg = readl(prcm_base + PRCM_PWROFF_GATING_REG(cluster));
+   reg |= PRCM_PWROFF_GATING_REG_CORE(cpu);
+   writel(reg, prcm_base + PRCM_PWROFF_GATING_REG(cluster));
+   udelay(20);
+
+   /* close power switch */
+   sunxi_cpu_power_switch_set(cpu, cluster, false);
+
+   return 0;
+}
+
+static int sunxi_do_cluster_powerdown(unsigned int cluster)
+{
+   u32 reg;
+
+   pr_debug("%s: cluster %u\n", __func__, cluster);
+   if (cluster >= SUNXI_NR_CLUSTERS)
+   return -EINVAL;
+
+   /* assert cluster resets */
+   pr_debug("%s: assert cluster reset\n", __func__);
+   reg = readl(cpucfg_base + CPUCFG_CX_RST_CTRL(cluster));
+   reg &= ~CPUCFG_CX_RST_CTRL_DBG_SOC_RST;
+   reg &= ~CPUCFG_CX_RST_CTRL_H_RST;
+   reg &= ~CPUCFG_CX_RST_CTRL_L2_RST;
+   writel(reg, cpucfg_base + CPUCFG_CX_RST_CTRL(cluster));
+
+   /* gate cluster power */
+   pr_debug("%s: gate cluster power\n", __func__);
+   reg = readl(prcm_base + PRCM_PWROFF_GATING_REG(cluster));
+   reg |= PRCM_PWROFF_GATING_REG_CLUSTER;
+   writel(reg, prcm_base + PRCM_PWROFF_GATING_REG(cluster));
+   udelay(20);
+
+   return 0;
+}
+
+static struct sunxi_mcpm_work *to_sunxi_mcpm_work(struct work_struct *work)
+{
+   return container_of(work, struct sunxi_mcpm_work, work);
+}
+
+/* async. work functions to bring down cpus and clusters */
+static void sunxi_cpu_powerdown(struct work_struct

[linux-sunxi] [PATCH v2 7/8] ARM: sun9i: mcpm: Support cpu0 hotplug

2018-01-04 Thread Chen-Yu Tsai

The BROM has a branch that checks if the primary core is hotplugging.
If the magic flag is set, execution jumps to the address set in the
software entry register. (Secondary cores always branch to the that
address.)

This patch sets the flags that makes BROM jump execution on the
primary core (cpu0) to the SMP software entry code when the core is
powered back up. After it is re-integrated into the system, the flag
is cleared.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/mach-sunxi/mcpm.c | 54 +++---
 1 file changed, 51 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-sunxi/mcpm.c b/arch/arm/mach-sunxi/mcpm.c
index ddc26b5fec48..c8d74c783644 100644
--- a/arch/arm/mach-sunxi/mcpm.c
+++ b/arch/arm/mach-sunxi/mcpm.c
@@ -56,8 +56,12 @@
 #define PRCM_PWR_SWITCH_REG(c, cpu)(0x140 + 0x10 * (c) + 0x4 * (cpu))
 #define PRCM_CPU_SOFT_ENTRY_REG0x164
 
+#define CPU0_SUPPORT_HOTPLUG_MAGIC00xFA50392F
+#define CPU0_SUPPORT_HOTPLUG_MAGIC10x790DCA3A
+
 static void __iomem *cpucfg_base;
 static void __iomem *prcm_base;
+static void __iomem *sram_b_smp_base;
 
 static bool sunxi_core_is_cortex_a15(unsigned int core, unsigned int cluster)
 {
@@ -116,6 +120,17 @@ static int sunxi_cpu_power_switch_set(unsigned int cpu, 
unsigned int cluster,
return 0;
 }
 
+static void sunxi_cpu0_hotplug_support_set(bool enable)
+{
+   if (enable) {
+   writel(CPU0_SUPPORT_HOTPLUG_MAGIC0, sram_b_smp_base);
+   writel(CPU0_SUPPORT_HOTPLUG_MAGIC1, sram_b_smp_base + 0x4);
+   } else {
+   writel(0x0, sram_b_smp_base);
+   writel(0x0, sram_b_smp_base + 0x4);
+   }
+}
+
 static int sunxi_cpu_powerup(unsigned int cpu, unsigned int cluster)
 {
u32 reg;
@@ -124,6 +139,10 @@ static int sunxi_cpu_powerup(unsigned int cpu, unsigned 
int cluster)
if (cpu >= SUNXI_CPUS_PER_CLUSTER || cluster >= SUNXI_NR_CLUSTERS)
return -EINVAL;
 
+   /* Set hotplug support magic flags for cpu0 */
+   if (cluster == 0 && cpu == 0)
+   sunxi_cpu0_hotplug_support_set(true);
+
/* assert processor power-on reset */
reg = readl(prcm_base + PRCM_CPU_PO_RST_CTRL(cluster));
reg &= ~PRCM_CPU_PO_RST_CTRL_CORE(cpu);
@@ -406,6 +425,13 @@ static void sunxi_cluster_powerdown(struct work_struct 
*_work)
sunxi_do_cluster_powerdown(cluster);
 }
 
+static void sunxi_cpu_is_up(unsigned int cpu, unsigned int cluster)
+{
+   /* Clear hotplug support magic flags for cpu0 */
+   if (cluster == 0 && cpu == 0)
+   sunxi_cpu0_hotplug_support_set(false);
+}
+
 static int sunxi_wait_for_powerdown(unsigned int cpu, unsigned int cluster)
 {
int ret;
@@ -425,6 +451,7 @@ static const struct mcpm_platform_ops sunxi_power_ops = {
.cluster_powerdown_prepare = sunxi_cluster_powerdown_prepare,
.cpu_cache_disable = sunxi_cpu_cache_disable,
.cluster_cache_disable = sunxi_cluster_cache_disable,
+   .cpu_is_up = sunxi_cpu_is_up,
.wait_for_powerdown= sunxi_wait_for_powerdown,
 };
 
@@ -484,7 +511,7 @@ static void sunxi_mcpm_setup_entry_point(void)
 
 static int __init sunxi_mcpm_init(void)
 {
-   struct device_node *cpucfg_node, *node;
+   struct device_node *cpucfg_node, *sram_node, *node;
struct resource res;
int ret;
int i, j;
@@ -525,12 +552,26 @@ static int __init sunxi_mcpm_init(void)
goto err_put_cpucfg_node;
}
 
+   sram_node = of_find_compatible_node(NULL, NULL,
+   "allwinner,sun9i-a80-smp-sram");
+   if (!sram_node) {
+   ret = -ENODEV;
+   goto err_unmap_release_cpucfg;
+   }
+
+   sram_b_smp_base = of_io_request_and_map(sram_node, 0, "sunxi-mcpm");
+   if (IS_ERR(sram_b_smp_base)) {
+   ret = PTR_ERR(sram_b_smp_base);
+   pr_err("%s: failed to map secure SRAM\n", __func__);
+   goto err_put_sram_node;
+   }
+
/* Initialize our strictly ordered workqueue */
sunxi_mcpm_wq = alloc_ordered_workqueue("%s", 0, "sunxi-mcpm");
if (!sunxi_mcpm_wq) {
ret = -ENOMEM;
pr_err("%s: failed to create our workqueue\n", __func__);
-   goto err_unmap_release_cpucfg;
+   goto err_unmap_release_secure_sram;
}
 
/* Initialize power down work */
@@ -556,8 +597,9 @@ static int __init sunxi_mcpm_init(void)
if (ret)
goto err_destroy_workqueue;
 
-   /* We don't need the CPUCFG device node anymore */
+   /* We don't need the CPUCFG and SRAM device nodes anymore */
of_node_put(cpucfg_node);
+   of_node_put(sram_node);
 
/* Set the hardware entry point address */
sunxi_mcpm_setup_entry_point();
@@ -571,6 +613,12 @@ static int __init sunxi_mcpm_init(void)

[linux-sunxi] [PATCH v2 4/8] ARM: dts: sun9i: Add PRCM device node for the A80 dtsi

2018-01-04 Thread Chen-Yu Tsai

The PRCM is a collection of clock controls, reset controls, and various
power switches/gates. Some of these can be independently listed and
supported, while a number of CPU related ones are used in tandem with
CPUCFG for SMP bringup and CPU hotplugging.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun9i-a80.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index 85ecb4d64cfd..bf4d40e8359f 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -709,6 +709,11 @@
interrupts = ;
};
 
+   prcm@8001400 {
+   compatible = "allwinner,sun9i-a80-prcm";
+   reg = <0x08001400 0x200>;
+   };
+
apbs_rst: reset@80014b0 {
reg = <0x080014b0 0x4>;
compatible = "allwinner,sun6i-a31-clock-reset";
-- 
2.15.1

-- 
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/8] ARM: sun9i: SMP support with Multi-Cluster Power Management

2018-01-04 Thread Chen-Yu Tsai

This is v2 of my sun9i SMP support with MCPM series which was started
over two years ago [1]. We've tried to implement PSCI for both the A80
and A83T. Results were not promising. The issue is that these two chips
have a broken security extensions implementation. If a specific bit is
not burned in its e-fuse, most if not all security protections don't
work [2]. Even worse, non-secure access to the GIC become secure. This
requires a crazy workaround in the GIC driver which probably doesn't work
in all cases [3].

Nicolas mentioned that the MCPM framework is likely overkill in our
case [4]. However the framework does provide cluster/core state tracking
and proper sequencing of cache related operations. We could rework
the code to use standard smp_ops, but I would like to actually get
a working version in first.

Much of the sunxi-specific MCPM code is derived from Allwinner code and
documentation, with some references to the other MCPM implementations,
as well as the Cortex's Technical Reference Manuals for the power
sequencing info.

One major difference compared to other platforms is we currently do not
have a standalone PMU or other embedded firmware to do the actually power
sequencing. All power/reset control is done by the kernel. Nicolas
mentioned that a new optional callback should be added in cases where the
kernel has to do the actual power down [5]. For now however I'm using a
dedicated single thread workqueue. CPU and cluster power off work is
queued from the .{cpu,cluster}_powerdown_prepare callbacks. This solution
is somewhat heavy, as I have a total of 10 static work structs. It might
also be a bit racy, as nothing prevents the system from bringing a core
back before the asynchronous work shuts it down. This would likely
happen under a heavily loaded system with a scheduler that brings cores
in and out of the system frequently. In simple use-cases it performs OK.

Changes since v1:

  - Leading zeroes for device node addresses removed
  - Added device tree binding for SMP SRAM
  - Simplified Kconfig options
  - Switched to SPDX license identifier
  - Map CPU to device tree node and check compatible to see if it's
Cortex-A15 or Cortex-A7
  - Fix incorrect CPUCFG cluster status macro that prevented cluster
0 L2 cache WFI detection
  - Fixed reversed bit for turning off cluster
  - Put cluster in reset before turning off power (or it hangs)
  - Added dedicated workqueue for turning off power to cpus and clusters
  - Request CPUCFG and SRAM MMIO ranges
  - Some comments fixed or added
  - Some debug messages added

[1] http://www.spinics.net/lists/arm-kernel/msg418350.html
[2] https://lists.denx.de/pipermail/u-boot/2017-June/294637.html
[3] 
https://github.com/wens/linux/commit/c48654c1f737116e7a7660183c8c74fa91970528
[4] http://www.spinics.net/lists/arm-kernel/msg434160.html
[5] http://www.spinics.net/lists/arm-kernel/msg434408.html

Chen-Yu Tsai (8):
  ARM: sun9i: Support SMP on A80 with Multi-Cluster Power Management
(MCPM)
  ARM: dts: sun9i: Add CCI-400 device nodes for A80
  ARM: dts: sun9i: Add CPUCFG device node for A80 dtsi
  ARM: dts: sun9i: Add PRCM device node for the A80 dtsi
  ARM: sun9i: mcpm: Support CPU/cluster power down and hotplugging for
cpu1~7
  dt-bindings: ARM: sunxi: Document A80 SoC secure SRAM usage by SMP
hotplug
  ARM: sun9i: mcpm: Support cpu0 hotplug
  ARM: dts: sun9i: Add secure SRAM node used for MCPM SMP hotplug

 .../devicetree/bindings/arm/sunxi/smp-sram.txt |  44 ++
 arch/arm/boot/dts/sun9i-a80.dtsi   |  75 +++
 arch/arm/mach-sunxi/Kconfig|   2 +
 arch/arm/mach-sunxi/Makefile   |   1 +
 arch/arm/mach-sunxi/mcpm.c | 633 +
 5 files changed, 755 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/sunxi/smp-sram.txt
 create mode 100644 arch/arm/mach-sunxi/mcpm.c

-- 
2.15.1

-- 
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/8] ARM: dts: sun9i: Add secure SRAM node used for MCPM SMP hotplug

2018-01-04 Thread Chen-Yu Tsai

The A80 stores some magic flags in a portion of the secure SRAM. The
BROM jumps directly to the software entry point set by the SMP code
if the flags are set. This is required for CPU0 hotplugging.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun9i-a80.dtsi | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index bf4d40e8359f..b1c86b76ac3c 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -250,6 +250,25 @@
 */
ranges = <0 0 0 0x2000>;
 
+   sram_b: sram@2 {
+   /* 256 KiB secure SRAM at 0x2 */
+   compatible = "mmio-sram";
+   reg = <0x0002 0x4>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x0002 0x4>;
+
+   smp-sram@1000 {
+   /*
+* This is checked by BROM to determine if
+* cpu0 should jump to SMP entry vector
+*/
+   compatible = "allwinner,sun9i-a80-smp-sram";
+   reg = <0x1000 0x8>;
+   };
+   };
+
ehci0: usb@a0 {
compatible = "allwinner,sun9i-a80-ehci", "generic-ehci";
reg = <0x00a0 0x100>;
-- 
2.15.1

-- 
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 6/8] dt-bindings: ARM: sunxi: Document A80 SoC secure SRAM usage by SMP hotplug

2018-01-04 Thread Chen-Yu Tsai

On the Allwinner A80 SoC the BROM supports hotplugging the primary core
(cpu0) by checking two 32bit values at a specific location within the
secure SRAM block. This region needs to be reserved and accessible to
the SMP code.

Document its usage.

Signed-off-by: Chen-Yu Tsai 
---
 .../devicetree/bindings/arm/sunxi/smp-sram.txt | 44 ++
 1 file changed, 44 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/sunxi/smp-sram.txt

diff --git a/Documentation/devicetree/bindings/arm/sunxi/smp-sram.txt 
b/Documentation/devicetree/bindings/arm/sunxi/smp-sram.txt
new file mode 100644
index ..082e6a9382d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/sunxi/smp-sram.txt
@@ -0,0 +1,44 @@
+Allwinner SRAM for smp bringup:
+
+
+Allwinner's A80 SoC uses part of the secure sram for hotplugging of the
+primary core (cpu0). Once the core gets powered up it checks if a magic
+value is set at a specific location. If it is then the BROM will jump
+to the software entry address, instead of executing a standard boot.
+
+Therefore a reserved section sub-node has to be added to the mmio-sram
+declaration.
+
+Note that this is separate from the Allwinner SRAM controller found in
+../../sram/sunxi-sram.txt. This SRAM is secure only and not mappable to
+any device.
+
+Also there are no "secure-only" properties. The implementation should
+check if this SRAM is usable first.
+
+Required sub-node properties:
+- compatible : depending on the SoC this should be one of:
+   "allwinner,sun9i-a80-smp-sram"
+
+The rest of the properties should follow the generic mmio-sram discription
+found in ../../misc/sram.txt
+
+Example:
+
+   sram_b: sram@2 {
+   /* 256 KiB secure SRAM at 0x2 */
+   compatible = "mmio-sram";
+   reg = <0x0002 0x4>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x0002 0x4>;
+
+   smp-sram@1000 {
+   /*
+* This is checked by BROM to determine if
+* cpu0 should jump to SMP entry vector
+*/
+   compatible = "allwinner,sun9i-a80-smp-sram";
+   reg = <0x1000 0x8>;
+   };
+   };
-- 
2.15.1

-- 
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/8] ARM: sun9i: Support SMP on A80 with Multi-Cluster Power Management (MCPM)

2018-01-04 Thread Chen-Yu Tsai

The A80 is a big.LITTLE SoC with 1 cluster of 4 Cortex-A7s and
1 cluster of 4 Cortex-A15s.

This patch adds support to bring up the second cluster and thus all
cores using the common MCPM code. Core/cluster power down has not
been implemented, thus CPU hotplugging and big.LITTLE switcher is
not supported.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/mach-sunxi/Kconfig  |   2 +
 arch/arm/mach-sunxi/Makefile |   1 +
 arch/arm/mach-sunxi/mcpm.c   | 425 +++
 3 files changed, 428 insertions(+)
 create mode 100644 arch/arm/mach-sunxi/mcpm.c

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 58153cdf025b..53c4e7420cfb 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -47,5 +47,7 @@ config MACH_SUN9I
bool "Allwinner (sun9i) SoCs support"
default ARCH_SUNXI
select ARM_GIC
+   select MCPM if SMP
+   select ARM_CCI400_PORT_CTRL if SMP
 
 endif
diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
index 27b168f121a1..cd25d9d81257 100644
--- a/arch/arm/mach-sunxi/Makefile
+++ b/arch/arm/mach-sunxi/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_ARCH_SUNXI) += sunxi.o
+obj-$(CONFIG_MCPM) += mcpm.o
 obj-$(CONFIG_SMP) += platsmp.o
diff --git a/arch/arm/mach-sunxi/mcpm.c b/arch/arm/mach-sunxi/mcpm.c
new file mode 100644
index ..30719998f3f0
--- /dev/null
+++ b/arch/arm/mach-sunxi/mcpm.c
@@ -0,0 +1,425 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2015 Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai 
+ *
+ * arch/arm/mach-sunxi/mcpm.c
+ *
+ * Based on arch/arm/mach-exynos/mcpm-exynos.c and Allwinner code
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define SUNXI_CPUS_PER_CLUSTER 4
+#define SUNXI_NR_CLUSTERS  2
+
+#define CPUCFG_CX_CTRL_REG0(c) (0x10 * (c))
+#define CPUCFG_CX_CTRL_REG0_L1_RST_DISABLE(n)  BIT(n)
+#define CPUCFG_CX_CTRL_REG0_L1_RST_DISABLE_ALL 0xf
+#define CPUCFG_CX_CTRL_REG0_L2_RST_DISABLE_A7  BIT(4)
+#define CPUCFG_CX_CTRL_REG0_L2_RST_DISABLE_A15 BIT(0)
+#define CPUCFG_CX_CTRL_REG1(c) (0x10 * (c) + 0x4)
+#define CPUCFG_CX_CTRL_REG1_ACINACTM   BIT(0)
+#define CPUCFG_CX_RST_CTRL(c)  (0x80 + 0x4 * (c))
+#define CPUCFG_CX_RST_CTRL_DBG_SOC_RST BIT(24)
+#define CPUCFG_CX_RST_CTRL_ETM_RST(n)  BIT(20 + (n))
+#define CPUCFG_CX_RST_CTRL_ETM_RST_ALL (0xf << 20)
+#define CPUCFG_CX_RST_CTRL_DBG_RST(n)  BIT(16 + (n))
+#define CPUCFG_CX_RST_CTRL_DBG_RST_ALL (0xf << 16)
+#define CPUCFG_CX_RST_CTRL_H_RST   BIT(12)
+#define CPUCFG_CX_RST_CTRL_L2_RST  BIT(8)
+#define CPUCFG_CX_RST_CTRL_CX_RST(n)   BIT(4 + (n))
+#define CPUCFG_CX_RST_CTRL_CORE_RST(n) BIT(n)
+
+#define PRCM_CPU_PO_RST_CTRL(c)(0x4 + 0x4 * (c))
+#define PRCM_CPU_PO_RST_CTRL_CORE(n)   BIT(n)
+#define PRCM_CPU_PO_RST_CTRL_CORE_ALL  0xf
+#define PRCM_PWROFF_GATING_REG(c)  (0x100 + 0x4 * (c))
+#define PRCM_PWROFF_GATING_REG_CLUSTER BIT(4)
+#define PRCM_PWROFF_GATING_REG_CORE(n) BIT(n)
+#define PRCM_PWR_SWITCH_REG(c, cpu)(0x140 + 0x10 * (c) + 0x4 * (cpu))
+#define PRCM_CPU_SOFT_ENTRY_REG0x164
+
+static void __iomem *cpucfg_base;
+static void __iomem *prcm_base;
+
+static bool sunxi_core_is_cortex_a15(unsigned int core, unsigned int cluster)
+{
+   struct device_node *node;
+   int cpu = cluster * SUNXI_CPUS_PER_CLUSTER + core;
+
+   node = of_cpu_device_node_get(cpu);
+
+   /* In case of_cpu_device_node_get fails */
+   if (!node)
+   node = of_get_cpu_node(cpu, NULL);
+
+   if (!node) {
+   /*
+* There's no point in returning an error, since we
+* would be mid way in a core or cluster power sequence.
+*/
+   pr_err("%s: Couldn't get CPU cluster %u core %u device node\n",
+  __func__, cluster, core);
+
+   return false;
+   }
+
+   return of_device_is_compatible(node, "arm,cortex-a15");
+}
+
+static int sunxi_cpu_power_switch_set(unsigned int cpu, unsigned int cluster,
+ bool enable)
+{
+   u32 reg;
+
+   /* control sequence from Allwinner A80 user manual v1.2 PRCM section */
+   reg = readl(prcm_base + PRCM_PWR_SWITCH_REG(cluster, cpu));
+   if (enable) {
+   if (reg == 0x00) {
+   pr_debug("power clamp for cluster %u cpu %u already 
open\n",
+cluster, cpu);
+   return 0;
+   }
+
+   writel(0xff, prcm_base + PRCM_PWR_SWITCH_REG(cluster, cpu));
+   udelay(10);
+   writel(0xfe, prcm_base + PRCM_PWR_SWITCH_REG(cluster, cpu));
+   udelay(10);
+   writel(0xf8, prcm_base + PRCM_PWR_SWITCH_REG(cluster, cpu));
+   udelay(10);
+   writel(0xf0, prcm_base +

[linux-sunxi] Re: [PATCH 01/11] clk: sunxi-ng: Don't set k if width is 0 for nkmp plls

2018-01-04 Thread maxime . ripard

Hi,

On Sat, Dec 30, 2017 at 10:01:53PM +0100, Jernej Skrabec wrote:
> For example, A83T have nmp plls which are modelled as nkmp plls. Since k
> is not specified, it has offset 0, shift 0 and lowest value 1. This
> means that LSB bit is always set to 1, which may change clock rate.
> 
> Fix that by applying k factor only if k width is greater than 0.
> 
> Signed-off-by: Jernej Skrabec 

This looks fine...

> ---
>  drivers/clk/sunxi-ng/ccu_nkmp.c | 21 +
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c b/drivers/clk/sunxi-ng/ccu_nkmp.c
> index e58c95787f94..709f528af2b3 100644
> --- a/drivers/clk/sunxi-ng/ccu_nkmp.c
> +++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
> @@ -81,7 +81,7 @@ static unsigned long ccu_nkmp_recalc_rate(struct clk_hw *hw,
>   unsigned long parent_rate)
>  {
>   struct ccu_nkmp *nkmp = hw_to_ccu_nkmp(hw);
> - unsigned long n, m, k, p;
> + unsigned long n, m, k = 1, p;
>   u32 reg;
>  
>   reg = readl(nkmp->common.base + nkmp->common.reg);
> @@ -92,11 +92,13 @@ static unsigned long ccu_nkmp_recalc_rate(struct clk_hw 
> *hw,
>   if (!n)
>   n++;
>  
> - k = reg >> nkmp->k.shift;
> - k &= (1 << nkmp->k.width) - 1;
> - k += nkmp->k.offset;
> - if (!k)
> - k++;
> + if (nkmp->k.width) {
> + k = reg >> nkmp->k.shift;
> + k &= (1 << nkmp->k.width) - 1;
> + k += nkmp->k.offset;
> + if (!k)
> + k++;
> + }

... but could you add a comment there to explain why you're using a
different construct than the one used for the other factors?

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] [PATCH v4 0/2] Initial Allwinner V3s CSI Support

2018-01-04 Thread Maxime Ripard

On Mon, Dec 25, 2017 at 09:58:02AM +0100, Ondřej Jirman wrote:
> Hello,
> 
> On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> > Hi,
> > 
> > On Fri, 22 Dec 2017 14:46:48 +0100
> > Ondřej Jirman  wrote:
> > 
> > > Hello,
> > > 
> > > Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> > > > 
> > > > Test input 0:
> > > > 
> > > > Control ioctls:
> > > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not 
> > > > Supported)
> > > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > > Standard Controls: 0 Private Controls: 0
> > > 
> > > I'm not sure if your driver passes control queries to the subdev. It
> > > did not originally, and I'm not sure you picked up the change from my
> > > version of the driver. "Not supported" here seems to indicate that it
> > > does not.
> > > 
> > > I'd be interested what's the recommended practice here. It sure helps
> > > with some apps that expect to be able to modify various input controls
> > > directly on the /dev/video# device. These are then supported out of the
> > > box.
> > > 
> > > It's a one-line change. See:
> > > 
> > > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > > heriting-controls
> > 
> > I think this is a feature and not affect the driver's main function.
> > I just focused on making the CSI main function to work properly in 
> > the initial version. Is this feature mandatory or most commonly used?
> 
> I grepped the platform/ code and it seems, that inheriting controls
> from subdevs is pretty common for input drivers. (there are varying
> approaches though, some inherit by hand in the link function, some
> just register and empty ctrl_handler on the v4l2_dev and leave the
> rest to the core).
> 
> Practically, I haven't found a common app that would allow me to enter
> both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
> themselves, but it would be better if current controls were available
> at the /dev/video0 device automatically.
> 
> It's much simpler for the userspace apps than the alternative, which
> is trying to identify the correct subdev that is currently
> associated with the CSI driver at runtime, which is not exactly
> straightforward and requires much more code, than a few lines in
> the kernel, that are required to inherit controls:

And it becomes much more complicated once you have the same controls
on the v4l2 device and subdevice, which is not that uncommon.

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] [PATCH v4 0/2] Initial Allwinner V3s CSI Support

2018-01-04 Thread Maxime Ripard

On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> Hi,
> 
> On Fri, 22 Dec 2017 14:46:48 +0100
> Ondřej Jirman  wrote:
> 
> > Hello,
> > 
> > Yong Deng píše v Pá 22. 12. 2017 v 17:32 +0800:
> > > This patchset add initial support for Allwinner V3s CSI.
> > > 
> > > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > > and CSI1 is used for parallel interface. This is not documented in
> > > datasheet but by testing and guess.
> > > 
> > > This patchset implement a v4l2 framework driver and add a binding 
> > > documentation for it. 
> > > 
> > > Currently, the driver only support the parallel interface. And has been
> > > tested with a BT1120 signal which generating from FPGA. The following
> > > fetures are not support with this patchset:
> > >   - ISP 
> > >   - MIPI-CSI2
> > >   - Master clock for camera sensor
> > >   - Power regulator for the front end IC
> > > 
> > > Thanks for Ondřej Jirman's help.
> > > 
> > > Changes in v4:
> > >   * Deal with the CSI 'INNER QUEUE'.
> > > CSI will lookup the next dma buffer for next frame before the
> > > the current frame done IRQ triggered. This is not documented
> > > but reported by Ondřej Jirman.
> > > The BSP code has workaround for this too. It skip to mark the
> > > first buffer as frame done for VB2 and pass the second buffer
> > > to CSI in the first frame done ISR call. Then in second frame
> > > done ISR call, it mark the first buffer as frame done for VB2
> > > and pass the third buffer to CSI. And so on. The bad thing is
> > > that the first buffer will be written twice and the first frame
> > > is dropped even the queued buffer is sufficient.
> > > So, I make some improvement here. Pass the next buffer to CSI
> > > just follow starting the CSI. In this case, the first frame
> > > will be stored in first buffer, second frame in second buffer.
> > > This mothed is used to avoid dropping the first frame, it
> > > would also drop frame when lacking of queued buffer.
> > >   * Fix: using a wrong mbus_code when getting the supported formats
> > >   * Change all fourcc to pixformat
> > >   * Change some function names
> > > 
> > > Changes in v3:
> > >   * Get rid of struct sun6i_csi_ops
> > >   * Move sun6i-csi to new directory drivers/media/platform/sunxi
> > >   * Merge sun6i_csi.c and sun6i_csi_v3s.c into sun6i_csi.c
> > >   * Use generic fwnode endpoints parser
> > >   * Only support a single subdev to make things simple
> > >   * Many complaintion fix
> > > 
> > > Changes in v2: 
> > >   * Change sunxi-csi to sun6i-csi
> > >   * Rebase to media_tree master branch 
> > > 
> > > Following is the 'v4l2-compliance -s -f' output, I have test this
> > > with both interlaced and progressive signal:
> > > 
> > > # ./v4l2-compliance -s -f
> > > v4l2-compliance SHA   : 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1
> > > 
> > > Driver Info:
> > > Driver name   : sun6i-video
> > > Card type : sun6i-csi
> > > Bus info  : platform:csi
> > > Driver version: 4.15.0
> > > Capabilities  : 0x8421
> > > Video Capture
> > > Streaming
> > > Extended Pix Format
> > > Device Capabilities
> > > Device Caps   : 0x0421
> > > Video Capture
> > > Streaming
> > > Extended Pix Format
> > > 
> > > Compliance test for device /dev/video0 (not using libv4l2):
> > > 
> > > Required ioctls:
> > > test VIDIOC_QUERYCAP: OK
> > > 
> > > Allow for multiple opens:
> > > test second video open: OK
> > > test VIDIOC_QUERYCAP: OK
> > > test VIDIOC_G/S_PRIORITY: OK
> > > test for unlimited opens: OK
> > > 
> > > Debug ioctls:
> > > test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> > > test VIDIOC_LOG_STATUS: OK (Not Supported)
> > > 
> > > Input ioctls:
> > > test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> > > test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> > > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> > > test VIDIOC_ENUMAUDIO: OK (Not Supported)
> > > test VIDIOC_G/S/ENUMINPUT: OK
> > > test VIDIOC_G/S_AUDIO: OK (Not Supported)
> > > Inputs: 1 Audio Inputs: 0 Tuners: 0
> > > 
> > > Output ioctls:
> > > test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> > > test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> > > test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> > > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> > > test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> > > Outputs: 0 Audio Outputs: 0 Modulators: 0
> > > 
> > > Input/Output configuration ioctls:
> > > test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> > > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> > > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> > >

[linux-sunxi] Re: [PATCH v2] ARM: dts: sunxi: Add sid for a83t

2018-01-04 Thread Maxime Ripard

On Fri, Dec 22, 2017 at 06:11:52PM +0800, Chen-Yu Tsai wrote:
> On Fri, Dec 22, 2017 at 6:07 PM, Emmanuel Vadot  wrote:
> > On Fri, 22 Dec 2017 09:35:08 +0100
> > Maxime Ripard  wrote:
> >
> >> On Thu, Dec 21, 2017 at 07:09:03PM +0100, Emmanuel Vadot wrote:
> >> >
> >> >  Hi Maxime,
> >> >
> >> > On Thu, 21 Dec 2017 16:26:30 +0100
> >> > Maxime Ripard  wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > On Thu, Dec 21, 2017 at 09:19:24AM -0600, Kyle Evans wrote:
> >> > > > On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard
> >> > > >  wrote:
> >> > > > > Hi Kyle,
> >> > > > >
> >> > > > > On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevan...@ksu.edu wrote:
> >> > > > >> Allwinner a83t has a 1 KB sid block with efuse for security 
> >> > > > >> rootkey and
> >> > > > >> thermal calibration data, add node to describe it.
> >> > > > >>
> >> > > > >> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
> >> > > > >> supported in an external driver for FreeBSD.
> >> > > > >>
> >> > > > >> Signed-off-by: Kyle Evans 
> >> > > > >
> >> > > > > The patch looks fine in itself, but we've had a number of issues 
> >> > > > > with
> >> > > > > the register layout (and access patterns) in the past, so I'd 
> >> > > > > rather
> >> > > > > have something that works in Linux too if possible.
> >> > > >
> >> > > > I have a patch that I think should make it work fine on Linux [1], 
> >> > > > but
> >> > > > I'm afraid I have little to no capability to test it myself and so I
> >> > > > did not add it as well.
> >> > > >
> >> > > > I do know that the rootkey is offset 0x200 into the given space [2],
> >> > > > as is the case with the H3, and that the readout quirk is not needed.
> >> > > > I wasn't 100% sure that the a83t has 2Kbit worth of efuse space as 
> >> > > > the
> >> > > > H3, but I do know that thermal data can be found at 0x34 and 0x38 in
> >> > > > this space.
> >> > >
> >> > > Then maybe we should leave it aside until someone takes some time on
> >> > > the A83t.
> >> >
> >> >  Take some time on the Linux driver and do not apply this patch for
> >> > now you mean ?
> >>
> >> Yep.
> >>
> >> Maxime
> >
> >  Since linux doesn't have the compatible in it's driver what would
> > be the harm to add the node in the DTS ? If a quirks is needed because
> > some region is weird this would go in the driver right ? I don't see a
> > technical problem for adding this node right now.
> >  If Kyle confirm the lenght of the region and that no quirk is needed
> > will it be enough ?
> 
> I guess I wasn't very clear. I'm OK with the patch going in. The device
> node currently says nothing about how much efuse space there is. The
> memory region covers that and the control section, and the size matches
> what the memory map says.
> 
> The size and offset of the efuse space would be dealt with in the driver.

Let's merge it then.

Acked-by: Maxime Ripard 

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 06/11] dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline

[linux-sunxi] Re: [PATCH 06/11] dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline

Re: [linux-sunxi] Re: H3 SID eFuse write failure issue for ROTPK_HASH field

[linux-sunxi] Re: H3 SID eFuse write failure issue for ROTPK_HASH field

[linux-sunxi] Re: [PATCH v2 1/3] drm/sun4i: hdmi: Check for unset best_parent in sun4i_tmds_determine_rate

[linux-sunxi] Re: [PATCH v2 0/8] ARM: sun9i: SMP support with Multi-Cluster Power Management

[linux-sunxi] Re: [PATCH v2 1/3] drm/sun4i: hdmi: Check for unset best_parent in sun4i_tmds_determine_rate

[linux-sunxi] Re: [PATCH 01/11] clk: sunxi-ng: Don't set k if width is 0 for nkmp plls

[linux-sunxi] Re: [PATCH 06/11] dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline

[linux-sunxi] Re: [PATCH 08/11] drm/sun4i: Add support for A83T second DE2 mixer

[linux-sunxi] Re: [PATCH 07/11] drm/sun4i: Add support for A83T second TCON

Re: [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support

[linux-sunxi] Re: [PATCH v2 0/8] ARM: sun9i: SMP support with Multi-Cluster Power Management

[linux-sunxi] Re: [PATCH 01/11] clk: sunxi-ng: Don't set k if width is 0 for nkmp plls

[linux-sunxi] Re: H3 SID eFuse write failure issue for ROTPK_HASH field

[linux-sunxi] [PATCH v2 3/8] ARM: dts: sun9i: Add CPUCFG device node for A80 dtsi

[linux-sunxi] [PATCH v2 5/8] ARM: sun9i: mcpm: Support CPU/cluster power down and hotplugging for cpu1~7

[linux-sunxi] [PATCH v2 7/8] ARM: sun9i: mcpm: Support cpu0 hotplug

[linux-sunxi] [PATCH v2 4/8] ARM: dts: sun9i: Add PRCM device node for the A80 dtsi

[linux-sunxi] [PATCH v2 0/8] ARM: sun9i: SMP support with Multi-Cluster Power Management

[linux-sunxi] [PATCH v2 8/8] ARM: dts: sun9i: Add secure SRAM node used for MCPM SMP hotplug

[linux-sunxi] [PATCH v2 6/8] dt-bindings: ARM: sunxi: Document A80 SoC secure SRAM usage by SMP hotplug

[linux-sunxi] [PATCH v2 1/8] ARM: sun9i: Support SMP on A80 with Multi-Cluster Power Management (MCPM)

[linux-sunxi] Re: [PATCH 01/11] clk: sunxi-ng: Don't set k if width is 0 for nkmp plls

Re: [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support

Re: [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support

[linux-sunxi] Re: [PATCH v2] ARM: dts: sunxi: Add sid for a83t

27 matches

Site Navigation

Mail list logo

Footer information