[linux-sunxi] Re: [PATCH 0/4] ARM: sun7i: Convert sun7i SoC to sunxi-ng
Hi Priit, On Mon, Feb 27, 2017 at 11:09:10PM +0200, Priit Laes wrote: > Hi, > > This is serie brings another SoC into the sunxi-ng world. > > As mentioned in sun5i conversion, this is pretty much standard > stuff as all the required clocks were already implemented in > the sunxi-ng framework. Thanks a lot for that work. I think the A10 should be converted at the same time, and both would share the same driver. Fortunately, if I recall properly, both are not too far off. Thanks again, 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] Toggeling LDO3 causes crash/shutdown of the AXP209. Some verification help needed.
It seems like what Marcus suggested (turning off LDO3, setting voltage to minimum 0.7V, then turning on LDO3 and then increasing the voltage to 2.8V) works fine with the LIME2: i2c mw 0x34 0x12 0x1f i2c mw 0x34 0x29 0x00 i2c mw 0x34 0x12 0x5f i2c mw 0x34 0x29 0x58 I'm yet to test the other designs. Nothing is final at the moment since we are still testing, but probably the future hardware revisions would have 4.7 uF on LDO3 and LDO4 instead of 10 uF (LDO1 is always on, LDO2 is connected to the memory and turning it off naturally kills the board). On Monday, February 27, 2017 at 9:11:18 PM UTC+2, oliver wrote: > > Hey Lub > > On , Lyubcho Haralanov wrote: > > Hi, > > > > VR1 is not assembled (NA). It is not placed. Only pads are provided in > > case you don't want to power the camera from the AXP209 but > > externally, in which case you should place VR1 and disconnect the SMT > > jumper LDO3_2.8V_E. > > > > By original design the camera is powered only by the AXP209. > > > > Best regards, > > Lub > > Thanks for the explanation of the EVB :) > > Can you also elaborate on the 10 uF for all designs however? > > Some extra information, I ran some current tests on the LDO3 > power-up/shutdown and while 200 mA max sourcing current is never > reached, the chip does shut down before the max voltage has been > reached. For example setting ldo3 to max ( i2c mw 0x34 0x29 0x7f ) we > get screenshot 3v6.png where we can see the max voltage is only 2.32. > > Repeating the same test however with 2.3 V ( i2c mw 0x34 0x29 0x40 ) > yields 2V3.png, which also causes an AXP209 failure. This supprised me a > little, as I expected the 2.3V to actually work, as that is the voltage > we failed before. Also failure happens sooner and max current is lower. > > After some trial and error, we find that 1.95 V, in this case, still > works, but that I suppose really depends on the capacitance, but by no > means reliably! > > Due to the small timebase (50 uS) we cannot clearly see the power rail > dropping, but be assured, for the 2V3 and 3V6, power slowly drops as > capacitors discharge. > > > While this can and should be solved in hardware (smaller capacitor) > there's hundreds of thousands of boards in the wild with this > configuration and thus a software solution is needed. > > The AXP209 does have slew rate control, however this does not apply when > toggling the LDO3 output switch. What I thus propose, is a quirk-flag, > for buggy boards, where we set the minimal voltage, enable power and > than set the desired voltage, letting the internal slew rate control > slowly ramp up voltage. > > > > What I still would love to hear from you guys, is why this could be > happening. The spec-sheet does say 200 mA of sourcing capability. But it > seems this is not exactly true? At least not when toggling LDO3 via > reg12 for sure. > > Olliver > > > > > On Monday, February 27, 2017 at 2:33:08 PM UTC+2, Marcus Weseloh > > wrote: > > > >> Hi, > >> > >> 2017-02-27 13:11 GMT+01:00 oliver : > >> > >>> One is to remove C185 (10 microF) and the problem went away. > >>> Looking at other designs, cubieboard 1 for example, uses the same > >>> layout, but only 4.7 microF. So it seems that charging of all the > >>> capacitance (input C106) the board itself, the output (C185) may > >>> be too much for the AXP209. > >> > >> Great, that confirms my suspicion that the capacitance is the main > >> problem on the A20-SOM. The reference design for the A20 from > >> Allwinner also suggests 4.7uF on LDO3, Olimex probably used 10uF > >> there to keep the BOM smaller? > >> > >> At least on the A20-SOM-EVB we have another problem though (as > >> explained in an earlier mail): When then SOM is attached to the EVB, > >> the LDO3_2.8V rail on the SOM is powered from the EVB via +5V and a > >> DC converter. Even with the LDO3 voltage set to it's minimum, > >> turning on LDO3 shuts down the AXP immediately. Probably because the > >> AXP sees an external voltage applied to it's input, it might even > >> see reverse current flowing into it's ouput. I'd say that this is a > >> design flaw on the EVB. So at least on the A20-SOM-EVB combination, > >> LDO3 should never be be allowed to be switched on. > >> > >> Cheers, > >> > >> Marcus > > -- 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 v5 2/3] nvmem: sunxi-sid: add support for H3's SID controller
On Tue, Feb 28, 2017 at 03:27:14AM +0800, Icenowy Zheng wrote: > The H3 SoC have a bigger SID controller, which has its direct read > address at 0x200 position in the SID block, not 0x0. > > Also, H3 SID controller has some silicon bug that makes the direct read > value wrong at cold boot, add code to workaround the bug. (This bug has > already been fixed on A64 and later SoCs) > > Signed-off-by: Icenowy Zheng Acked-by: Maxime Ripard 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: [sunxi-tools PATCH] fel: add smc command
On Tue, 28 Feb 2017 05:14:27 +0800 Icenowy Zheng wrote: > 2017年2月28日 04:55于 Andre Przywara 写道： > > > > On Mon, 27 Feb 2017 05:48:48 +0200 > > Siarhei Siamashka wrote: > > > > > On Mon, 27 Feb 2017 02:22:08 + > > > André Przywara wrote: > > > > > > > On 27/02/17 01:20, Siarhei Siamashka wrote: > > > > > On Wed, 22 Feb 2017 17:08:47 + > > > > > Andre Przywara wrote: > > > > > > > > > >> If an SoC has the "secure boot" fuse burned, it will enter FEL > > > > >> mode in non-secure state, so with the SCR.NS bit set. Since in > > > > >> this mode the secure/non-secure state restrictions are actually > > > > >> observed, we suffer from several restrictions: > > > > >> - No access to the SID information (both via memory mapped and > > > > >> "register"). > > > > >> - No access to secure SRAM (SRAM A2 on H3/A64/H5). > > > > >> - No access to the secure side of the GIC, so it can't be > > > > >> configured to be accessible from non-secure world. > > > > >> - No RMR trigger on ARMv8 cores to bring the core into AArch64. > > > > >> Those limitations make a board pretty useless for many > > > > >> applications. > > > > >> > > > > >> However it has been found out that a simple "smc" call will > > > > >> immediately return from monitor mode, but with the NS bit > > > > >> cleared, so access to all secure peripherals is suddenly > > > > >> possible. > > > > >> > > > > >> Add a sunxi-fel command called "smc" which will issue exactly > > > > >> this instruction to make those boards useful in "secure boot" > > > > >> FEL mode. > > > > >> > > > > >> It should be given early in the command queue to given > > > > >> subsequent code full access to the system: > > > > >> $ ./sunxi-fel -v -p smc spl sunxi-spl.bin ... > > > > >> > > > > >> Signed-off-by: Andre Przywara > > > > >> > > > > >> --- > > > > >> Hi, > > > > >> > > > > >> if that sounds vaguely useful (it definitedly is for me to get > > > > >> the Remix Mini PC started), I can follow the Github process if > > > > >> you prefer that. > > > > >> > > > > >> Cheers, > > > > >> Andre. > > > > > > > > > > Hi Andre, > > > > > > > > > > Why don't we just do this automatically without adding a new > > > > > special command? > > > > > > > > > > We are not allowed to read the SCR register for detecting this > > > > > state, right? But can we still use some other detection method? > > > > > For example, maybe try to read SID and assume that we need the > > > > > SMC workaround if it reads back as zero? > > > > > > > > Yes, indeed I was thinking about exactly that ;-) > > > > From actually using this feature I realized that its usage is error > > > > prone: non-secure boards crash on calling it, secure board just > > > > don't work without it. > > > > And indeed there is no architectural way of checking whether you are > > > > running secure or non-secure (as reading a secure-only register like > > > > NSACR or SCR will trap, which means crash in our case). > > > > > > > > So (trying to) read the SID is indeed the best workaround I came up > > > > with: If it's all zero, we are probably secure and need the smc. > > > > There is still a slight chance that the SID is all zero even on a > > > > non-secure board (I think this was the case for some older SoCs?), > > > > so maybe we need an option to suppress using this heuristic? > > > > > > At least we should report every taken action in the sunxi-fel verbose > > > log (about the SMC workaround getting applied) because it greatly > > > simplifies troubleshooting. > > > > > > And IMHO having any options to suppress this workaround is a bit > > > premature until we encounter a real A64/H64/H5 chip where it fails > > > in the wild. > > > > > > Another variant of the detection heuristics could just use SRAM A2 > > > (well, not quite "SRAM", but the OpenRISC reset vector area). I'm > > > getting the following output on my Jide Remix Mini (Allwinner H64): > > > > > > $ ./sunxi-fel readl 0x40004 > > > 0x > > > > > > $ ./sunxi-fel smc > > > > > > $ ./sunxi-fel readl 0x40004 > > > 0x1500 > > > > > > We are either reading zero from there, or it is a hardwired OpenRISC > > > instruction L.NOP. > > > > Yeah, that sounds even better, but would be restricted to SoCs which > > have an OpenRISC. Not sure if that is actually a super set of > > secure-boot capable chips. > > I think R40 may be a secure-boot capable SoC without OpenRISC -- it have even > totally no secure SRAM! R40 has a different SoC ID, so we can easily implement a different check there. Of course in the case if R40 even needs this SMC workaround. -- Best regards, Siarhei Siamashka -- 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, v
Re: [linux-sunxi] Re: [sunxi-tools PATCH] fel: add smc command
On Mon, 27 Feb 2017 20:55:53 + Andre Przywara wrote: > On Mon, 27 Feb 2017 05:48:48 +0200 > Siarhei Siamashka wrote: > > > On Mon, 27 Feb 2017 02:22:08 + > > André Przywara wrote: > > > > > On 27/02/17 01:20, Siarhei Siamashka wrote: > > > > On Wed, 22 Feb 2017 17:08:47 + > > > > Andre Przywara wrote: > > > > > > > >> If an SoC has the "secure boot" fuse burned, it will enter FEL > > > >> mode in non-secure state, so with the SCR.NS bit set. Since in > > > >> this mode the secure/non-secure state restrictions are actually > > > >> observed, we suffer from several restrictions: > > > >> - No access to the SID information (both via memory mapped and > > > >> "register"). > > > >> - No access to secure SRAM (SRAM A2 on H3/A64/H5). > > > >> - No access to the secure side of the GIC, so it can't be > > > >> configured to be accessible from non-secure world. > > > >> - No RMR trigger on ARMv8 cores to bring the core into AArch64. > > > >> Those limitations make a board pretty useless for many > > > >> applications. > > > >> > > > >> However it has been found out that a simple "smc" call will > > > >> immediately return from monitor mode, but with the NS bit > > > >> cleared, so access to all secure peripherals is suddenly > > > >> possible. > > > >> > > > >> Add a sunxi-fel command called "smc" which will issue exactly > > > >> this instruction to make those boards useful in "secure boot" > > > >> FEL mode. > > > >> > > > >> It should be given early in the command queue to given > > > >> subsequent code full access to the system: > > > >> $ ./sunxi-fel -v -p smc spl sunxi-spl.bin ... > > > >> > > > >> Signed-off-by: Andre Przywara > > > >> > > > >> --- > > > >> Hi, > > > >> > > > >> if that sounds vaguely useful (it definitedly is for me to get > > > >> the Remix Mini PC started), I can follow the Github process if > > > >> you prefer that. > > > >> > > > >> Cheers, > > > >> Andre. > > > > > > > > Hi Andre, > > > > > > > > Why don't we just do this automatically without adding a new > > > > special command? > > > > > > > > We are not allowed to read the SCR register for detecting this > > > > state, right? But can we still use some other detection method? > > > > For example, maybe try to read SID and assume that we need the > > > > SMC workaround if it reads back as zero? > > > > > > Yes, indeed I was thinking about exactly that ;-) > > > From actually using this feature I realized that its usage is error > > > prone: non-secure boards crash on calling it, secure board just > > > don't work without it. > > > And indeed there is no architectural way of checking whether you are > > > running secure or non-secure (as reading a secure-only register like > > > NSACR or SCR will trap, which means crash in our case). > > > > > > So (trying to) read the SID is indeed the best workaround I came up > > > with: If it's all zero, we are probably secure and need the smc. > > > There is still a slight chance that the SID is all zero even on a > > > non-secure board (I think this was the case for some older SoCs?), > > > so maybe we need an option to suppress using this heuristic? > > > > At least we should report every taken action in the sunxi-fel verbose > > log (about the SMC workaround getting applied) because it greatly > > simplifies troubleshooting. > > > > And IMHO having any options to suppress this workaround is a bit > > premature until we encounter a real A64/H64/H5 chip where it fails > > in the wild. > > > > Another variant of the detection heuristics could just use SRAM A2 > > (well, not quite "SRAM", but the OpenRISC reset vector area). I'm > > getting the following output on my Jide Remix Mini (Allwinner H64): > > > > $ ./sunxi-fel readl 0x40004 > > 0x > > > > $ ./sunxi-fel smc > > > > $ ./sunxi-fel readl 0x40004 > > 0x1500 > > > > We are either reading zero from there, or it is a hardwired OpenRISC > > instruction L.NOP. > > Yeah, that sounds even better, but would be restricted to SoCs which > have an OpenRISC. Not sure if that is actually a super set of > secure-boot capable chips. There is no obligation to implement exactly the same solution for every SoC. > Only thing is that we need to add the address of "secure SRAM" to the > per-SoC data structure, but that may become useful for other purposes > in the future as well, I guess. We can even implement it as a simple check with just a single address of a word (or even byte), which needs to be compared with zero. Some SoCs may make use of NOPs from the delay slots of the OpenRISC reset vector in SRAM A2. The other SoCs may use their SID. Once we come to an agreement, could you please submit a pull request at github? We have travis-ci enabled there, so patches are at least automatically compile tested (on non-Linux systems too). -- Best regards, Siarhei Siamashka -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To
[linux-sunxi] Re: [PATCH v3] armv8: spl: Call spl_relocate_stack_gd for ARMv8
On Tue, Feb 28, 2017 at 02:13:21AM +, André Przywara wrote:
> Hi Tom, Simon,
>
> can we merge this patch for 2017.03 still?
> This fixes an SD card boot regression for arm64 SPLs for me, introduced
> shortly before -rc1.
This seems like a reasonable thing to bring in, yes. Thanks for the
reminder.
>
> Commit b3d2861eb20a ("spl: Remove overwrite of relocated malloc limit"),
> introduced just a few commits before -rc1, broke MMC boot for arm64
> (because malloc fails): The patch moves the simple_malloc setup into
> spl_relocate_stack_gd(), which so far wasn't actually called on arm64
> (see the patch below). So the malloc buffer was 0 bytes, malloc failed,
> the MMC driver couldn't find a boot device and gave up:
> U-Boot SPL 2017.03-rc2-00040-gb7b8021 (Feb 28 2017 - 00:41:35)
> DRAM: 1024 MiB
> Trying to boot from MMC1
> MMC Device 0 not found
> spl: could not find mmc device. error: -19
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
> This is the current situation since -rc1 for the Pine64, for instance.
>
> Now one solution to fix this is to actually revert b3d2861eb20a, which
> would move back to the old behaviour of using the SRAM malloc buffer for
> the whole of the SPL, which is fine for the MMC driver.
>
> But since Andrew's patch is correct, I'd rather merge Philipp's patch
> now, which solves a TODO and just calls spl_relocate_stack_gd(), so that
> we now get access to the proper (and much bigger) DRAM malloc buffer.
>
> Does that make sense?
> Can we merge Philipp's patch here (fixing the commenting style issue on
> the fly) to fix the regression?
>
> Cheers,
> Andre.
>
> > As part of the startup process for boards using the SPL, we need to
> > call spl_relocate_stack_gd. This is needed to set up malloc with its
> > DRAM buffer.
> >
> > Signed-off-by: Philipp Tomsich
> > Reviewed-by: Andre Przywara
> > Reviewed-by: Simon Glass
> > ---
> > arch/arm/lib/crt0_64.S | 13 +++--
> > 1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S
> > index 19c6a98..a7cead5 100644
> > --- a/arch/arm/lib/crt0_64.S
> > +++ b/arch/arm/lib/crt0_64.S
> > @@ -109,8 +109,17 @@ relocation_return:
> > */
> > bl c_runtime_cpu_setup /* still call old routine */
> > #endif /* !CONFIG_SPL_BUILD */
> > -
> > -/* TODO: For SPL, call spl_relocate_stack_gd() to alloc stack relocation */
> > +#if defined(CONFIG_SPL_BUILD)
> > + bl spl_relocate_stack_gd /* may return NULL */
> > + /* Perform 'sp = (x0 != NULL) ? x0 : sp' while working
> > +* around the constraint that conditional moves can not
> > +* have 'sp' as an operand
> > +*/
> > + mov x1, sp
> > + cmp x0, #0
> > + cselx0, x0, x1, ne
> > + mov sp, x0
> > +#endif
> >
> > /*
> > * Clear BSS section
> >
>
--
Tom
--
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: Digital signature
[linux-sunxi] Re: [PATCH v3] armv8: spl: Call spl_relocate_stack_gd for ARMv8
Hi Tom, Simon,
can we merge this patch for 2017.03 still?
This fixes an SD card boot regression for arm64 SPLs for me, introduced
shortly before -rc1.
Commit b3d2861eb20a ("spl: Remove overwrite of relocated malloc limit"),
introduced just a few commits before -rc1, broke MMC boot for arm64
(because malloc fails): The patch moves the simple_malloc setup into
spl_relocate_stack_gd(), which so far wasn't actually called on arm64
(see the patch below). So the malloc buffer was 0 bytes, malloc failed,
the MMC driver couldn't find a boot device and gave up:
U-Boot SPL 2017.03-rc2-00040-gb7b8021 (Feb 28 2017 - 00:41:35)
DRAM: 1024 MiB
Trying to boot from MMC1
MMC Device 0 not found
spl: could not find mmc device. error: -19
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
This is the current situation since -rc1 for the Pine64, for instance.
Now one solution to fix this is to actually revert b3d2861eb20a, which
would move back to the old behaviour of using the SRAM malloc buffer for
the whole of the SPL, which is fine for the MMC driver.
But since Andrew's patch is correct, I'd rather merge Philipp's patch
now, which solves a TODO and just calls spl_relocate_stack_gd(), so that
we now get access to the proper (and much bigger) DRAM malloc buffer.
Does that make sense?
Can we merge Philipp's patch here (fixing the commenting style issue on
the fly) to fix the regression?
Cheers,
Andre.
> As part of the startup process for boards using the SPL, we need to
> call spl_relocate_stack_gd. This is needed to set up malloc with its
> DRAM buffer.
>
> Signed-off-by: Philipp Tomsich
> Reviewed-by: Andre Przywara
> Reviewed-by: Simon Glass
> ---
> arch/arm/lib/crt0_64.S | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S
> index 19c6a98..a7cead5 100644
> --- a/arch/arm/lib/crt0_64.S
> +++ b/arch/arm/lib/crt0_64.S
> @@ -109,8 +109,17 @@ relocation_return:
> */
> bl c_runtime_cpu_setup /* still call old routine */
> #endif /* !CONFIG_SPL_BUILD */
> -
> -/* TODO: For SPL, call spl_relocate_stack_gd() to alloc stack relocation */
> +#if defined(CONFIG_SPL_BUILD)
> + bl spl_relocate_stack_gd /* may return NULL */
> + /* Perform 'sp = (x0 != NULL) ? x0 : sp' while working
> + * around the constraint that conditional moves can not
> + * have 'sp' as an operand
> + */
> + mov x1, sp
> + cmp x0, #0
> + cselx0, x0, x1, ne
> + mov sp, x0
> +#endif
>
> /*
> * Clear BSS section
>
--
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: PoC tvin2jpeg_h264 with veisp scaling
Hi. On Fri, 24 Feb 2017 05:55:31 -0800 (PST) Milos Ladni wrote: > Thank you Manuel! I did nothing, if there is thanks is for you. > > I managed to make a H264 decoder and it works fine. > Now i can run all four operation simultaneous but... > > Known bug: > For now the app can play source with 'num_ref_frames' greater or > equal to 1 but if i try to play source with 'num_ref_frames: 3' > simultaneous with 264Enc the app crash for unknown reasons. > If i play source with 'num_ref_frames: 1' it works ok.. > If i play source with 'num_ref_frames: 3' it works ok.. > If i run simultaneous only jpegEnc jpegDec and h264Dec all works no > matter what the value of 'num_ref_frames' is. > But when i want simultaneous h264Enc and h264Dec with source for > decoder with 'num_ref_frames: 3' the app crash.. > There is no problem if 'num_ref_frames: 1'.. > Very strange.. I am no sure why, h264Enc and h264Dec even do not use > the same subengine.. The application crashs(segfault?), and running under a debugger doesn't give any clues about what could be? You are now linking a lot of more libraries and is a bit scary, there can be bizarre interactions happening that could manifest as "inexplicable" segfaults. If this is the case in which the cause can't be found, then you should try to reduce and only link the absolute need libraries. (This is me talking without actually having run/tested you application.) Sorry for not be able to help you more, but there is no time to do more. > Which is the best time to lock the hardware? You set the hardware to do 1 task and only that task, and you wait until completed. This includes just reading registers, even within different subengines this can/could give undefined behavior. But you know, the problem is the /dev/cedarv driver, and the userside should not have to worry about this things. That is why for the proper driver, because with a V4L2 proper driver the hardware is "multiplexed" allowing "any" number of possible "simultaneous" concurrent tasks by any application. -- 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: [sunxi-tools PATCH] fel: add smc command
2017年2月28日 04:55于 Andre Przywara 写道： > > On Mon, 27 Feb 2017 05:48:48 +0200 > Siarhei Siamashka wrote: > > > On Mon, 27 Feb 2017 02:22:08 + > > André Przywara wrote: > > > > > On 27/02/17 01:20, Siarhei Siamashka wrote: > > > > On Wed, 22 Feb 2017 17:08:47 + > > > > Andre Przywara wrote: > > > > > > > >> If an SoC has the "secure boot" fuse burned, it will enter FEL > > > >> mode in non-secure state, so with the SCR.NS bit set. Since in > > > >> this mode the secure/non-secure state restrictions are actually > > > >> observed, we suffer from several restrictions: > > > >> - No access to the SID information (both via memory mapped and > > > >> "register"). > > > >> - No access to secure SRAM (SRAM A2 on H3/A64/H5). > > > >> - No access to the secure side of the GIC, so it can't be > > > >> configured to be accessible from non-secure world. > > > >> - No RMR trigger on ARMv8 cores to bring the core into AArch64. > > > >> Those limitations make a board pretty useless for many > > > >> applications. > > > >> > > > >> However it has been found out that a simple "smc" call will > > > >> immediately return from monitor mode, but with the NS bit > > > >> cleared, so access to all secure peripherals is suddenly > > > >> possible. > > > >> > > > >> Add a sunxi-fel command called "smc" which will issue exactly > > > >> this instruction to make those boards useful in "secure boot" > > > >> FEL mode. > > > >> > > > >> It should be given early in the command queue to given > > > >> subsequent code full access to the system: > > > >> $ ./sunxi-fel -v -p smc spl sunxi-spl.bin ... > > > >> > > > >> Signed-off-by: Andre Przywara > > > >> > > > >> --- > > > >> Hi, > > > >> > > > >> if that sounds vaguely useful (it definitedly is for me to get > > > >> the Remix Mini PC started), I can follow the Github process if > > > >> you prefer that. > > > >> > > > >> Cheers, > > > >> Andre. > > > > > > > > Hi Andre, > > > > > > > > Why don't we just do this automatically without adding a new > > > > special command? > > > > > > > > We are not allowed to read the SCR register for detecting this > > > > state, right? But can we still use some other detection method? > > > > For example, maybe try to read SID and assume that we need the > > > > SMC workaround if it reads back as zero? > > > > > > Yes, indeed I was thinking about exactly that ;-) > > > From actually using this feature I realized that its usage is error > > > prone: non-secure boards crash on calling it, secure board just > > > don't work without it. > > > And indeed there is no architectural way of checking whether you are > > > running secure or non-secure (as reading a secure-only register like > > > NSACR or SCR will trap, which means crash in our case). > > > > > > So (trying to) read the SID is indeed the best workaround I came up > > > with: If it's all zero, we are probably secure and need the smc. > > > There is still a slight chance that the SID is all zero even on a > > > non-secure board (I think this was the case for some older SoCs?), > > > so maybe we need an option to suppress using this heuristic? > > > > At least we should report every taken action in the sunxi-fel verbose > > log (about the SMC workaround getting applied) because it greatly > > simplifies troubleshooting. > > > > And IMHO having any options to suppress this workaround is a bit > > premature until we encounter a real A64/H64/H5 chip where it fails > > in the wild. > > > > Another variant of the detection heuristics could just use SRAM A2 > > (well, not quite "SRAM", but the OpenRISC reset vector area). I'm > > getting the following output on my Jide Remix Mini (Allwinner H64): > > > > $ ./sunxi-fel readl 0x40004 > > 0x > > > > $ ./sunxi-fel smc > > > > $ ./sunxi-fel readl 0x40004 > > 0x1500 > > > > We are either reading zero from there, or it is a hardwired OpenRISC > > instruction L.NOP. > > Yeah, that sounds even better, but would be restricted to SoCs which > have an OpenRISC. Not sure if that is actually a super set of > secure-boot capable chips. I think R40 may be a secure-boot capable SoC without OpenRISC -- it have even totally no secure SRAM! > > Only thing is that we need to add the address of "secure SRAM" to the > per-SoC data structure, but that may become useful for other purposes > in the future as well, I guess. > > Cheers, > Andre. > > -- > 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
[linux-sunxi] [PATCH 2/4] clk: sunxi-ng: Add sun7i-a20 CCU driver
Introduce a clock controller driver for sun7i A20 SoC.
Signed-off-by: Priit Laes
---
drivers/clk/sunxi-ng/Kconfig | 11 +
drivers/clk/sunxi-ng/Makefile|1 +
drivers/clk/sunxi-ng/ccu-sun7i-a20.c | 1068 ++
drivers/clk/sunxi-ng/ccu-sun7i-a20.h | 121
4 files changed, 1201 insertions(+)
create mode 100644 drivers/clk/sunxi-ng/ccu-sun7i-a20.c
create mode 100644 drivers/clk/sunxi-ng/ccu-sun7i-a20.h
diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index 695bbf9..4f436ab 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -85,6 +85,17 @@ config SUN6I_A31_CCU
select SUNXI_CCU_PHASE
default MACH_SUN6I
+config SUN7I_A20_CCU
+ bool "Support for the Allwinner A20 CCU"
+ select SUNXI_CCU_DIV
+ select SUNXI_CCU_MULT
+ select SUNXI_CCU_NK
+ select SUNXI_CCU_NKM
+ select SUNXI_CCU_NM
+ select SUNXI_CCU_MP
+ select SUNXI_CCU_PHASE
+ default MACH_SUN7I
+
config SUN8I_A23_CCU
bool "Support for the Allwinner A23 CCU"
select SUNXI_CCU_DIV
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 6feaac0..bedda5b 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_SUNXI_CCU_MP)+= ccu_mp.o
obj-$(CONFIG_SUN50I_A64_CCU) += ccu-sun50i-a64.o
obj-$(CONFIG_SUN5I_CCU)+= ccu-sun5i.o
obj-$(CONFIG_SUN6I_A31_CCU)+= ccu-sun6i-a31.o
+obj-$(CONFIG_SUN7I_A20_CCU)+= ccu-sun7i-a20.o
obj-$(CONFIG_SUN8I_A23_CCU)+= ccu-sun8i-a23.o
obj-$(CONFIG_SUN8I_A33_CCU)+= ccu-sun8i-a33.o
obj-$(CONFIG_SUN8I_H3_CCU) += ccu-sun8i-h3.o
diff --git a/drivers/clk/sunxi-ng/ccu-sun7i-a20.c
b/drivers/clk/sunxi-ng/ccu-sun7i-a20.c
new file mode 100644
index 000..90d2f13
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sun7i-a20.c
@@ -0,0 +1,1068 @@
+/*
+ * Copyright (c) 2017 Priit Laes. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+
+#include "ccu_common.h"
+#include "ccu_reset.h"
+
+#include "ccu_div.h"
+#include "ccu_gate.h"
+#include "ccu_mp.h"
+#include "ccu_mult.h"
+#include "ccu_nk.h"
+#include "ccu_nkm.h"
+#include "ccu_nkmp.h"
+#include "ccu_nm.h"
+#include "ccu_phase.h"
+
+#include "ccu-sun7i-a20.h"
+
+/*
+ * PLL1 - Core clock
+ *
+ * TODO: sigma-delta pattern bits 2 & 3
+ * TODO: PLL1 tuning register
+ */
+static struct ccu_nkmp pll_core_clk = {
+ .enable = BIT(31),
+ .n = _SUNXI_CCU_MULT_OFFSET(8, 5, 0),
+ .k = _SUNXI_CCU_MULT(4, 2),
+ .m = _SUNXI_CCU_DIV(0, 2),
+ .p = _SUNXI_CCU_DIV(16, 2),
+ .common = {
+ .reg= 0x000,
+ .hw.init= CLK_HW_INIT("pll-core",
+ "hosc",
+ &ccu_nkmp_ops,
+ 0),
+ },
+};
+
+/* PLL2 - Audio clock */
+static struct ccu_nm pll_audio_base_clk = {
+ .enable = BIT(31),
+ .n = _SUNXI_CCU_MULT_OFFSET(8, 7, 0),
+ .m = _SUNXI_CCU_DIV_OFFSET(0, 5, 0),
+ .common = {
+ .reg= 0x008,
+ .hw.init= CLK_HW_INIT("pll-audio-base",
+ "hosc",
+ &ccu_nm_ops,
+ 0),
+ },
+
+};
+
+/* PLL3 - Video0 clock */
+static struct ccu_mult pll_video0_clk = {
+ .enable = BIT(31),
+ .mult = _SUNXI_CCU_MULT_OFFSET_MIN_MAX(0, 7, 0, 9, 127),
+ .frac = _SUNXI_CCU_FRAC(BIT(15), BIT(14),
+ 27000, 29700),
+ .common = {
+ .reg= 0x010,
+ .features = (CCU_FEATURE_FRACTIONAL |
+ CCU_FEATURE_ALL_PREDIV),
+ .prediv = 8,
+ .hw.init= CLK_HW_INIT("pll-video0",
+ "hosc",
+ &ccu_mult_ops,
+ 0),
+ },
+};
+
+/* PLL4 - VE clock */
+static struct ccu_nkmp pll_ve_clk = {
+ .enable = BIT(31),
+ .n = _SUNXI_CCU_MULT_OFFSET(8, 5, 0),
+ .k = _SUNXI_CCU_MULT(4, 2)
[linux-sunxi] [PATCH 0/4] ARM: sun7i: Convert sun7i SoC to sunxi-ng
Hi, This is serie brings another SoC into the sunxi-ng world. As mentioned in sun5i conversion, this is pretty much standard stuff as all the required clocks were already implemented in the sunxi-ng framework. Priit Laes (4): clk: sunxi-ng: Add clocks and reset indices for sun7i-a20 SoC clk: sunxi-ng: Add sun7i-a20 CCU driver ARM: sun7i: Convert to CCU dt-bindings: List devicetree binding for the CCU of Allwinner A20 .../devicetree/bindings/clock/sunxi-ccu.txt|1 + arch/arm/boot/dts/sun7i-a20.dtsi | 719 ++--- drivers/clk/sunxi-ng/Kconfig | 11 + drivers/clk/sunxi-ng/Makefile |1 + drivers/clk/sunxi-ng/ccu-sun7i-a20.c | 1068 drivers/clk/sunxi-ng/ccu-sun7i-a20.h | 121 +++ include/dt-bindings/clock/sun7i-ccu.h | 127 +++ include/dt-bindings/reset/sun7i-ccu.h | 40 + 8 files changed, 1455 insertions(+), 633 deletions(-) create mode 100644 drivers/clk/sunxi-ng/ccu-sun7i-a20.c create mode 100644 drivers/clk/sunxi-ng/ccu-sun7i-a20.h create mode 100644 include/dt-bindings/clock/sun7i-ccu.h create mode 100644 include/dt-bindings/reset/sun7i-ccu.h -- 2.9.3 -- 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 3/4] ARM: sun7i: Convert to CCU
Convert sun7i-a20.dtsi to new CCU driver.
Signed-off-by: Priit Laes
---
arch/arm/boot/dts/sun7i-a20.dtsi | 719 +--
1 file changed, 86 insertions(+), 633 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 04c9977..6f80cb8 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -47,7 +47,8 @@
#include
#include
-#include
+#include
+#include
#include
#include
@@ -67,19 +68,19 @@
compatible = "allwinner,simple-framebuffer",
"simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0-hdmi";
- clocks = <&ahb_gates 36>, <&ahb_gates 43>,
-<&ahb_gates 44>, <&de_be0_clk>,
-<&tcon0_ch1_clk>, <&dram_gates 26>;
+ clocks = <&ccu CLK_AHB_LCD0>, <&ccu CLK_AHB_HDMI1>,
+<&ccu CLK_AHB_DE_BE0>, <&ccu CLK_DE_BE0>,
+<&ccu CLK_TCON0_CH1>, <&ccu CLK_DRAM_DE_BE0>;
status = "disabled";
};
- framebuffer@1 {
+ framebuffer@0 {
compatible = "allwinner,simple-framebuffer",
"simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0";
- clocks = <&ahb_gates 36>, <&ahb_gates 44>,
-<&de_be0_clk>, <&tcon0_ch0_clk>,
-<&dram_gates 26>;
+ clocks = <&ccu CLK_AHB_LCD0>, <&ccu CLK_AHB_DE_BE0>,
+<&ccu CLK_DE_BE0>, <&ccu CLK_TCON0_CH0>,
+<&ccu CLK_DRAM_DE_BE0>;
status = "disabled";
};
@@ -87,10 +88,10 @@
compatible = "allwinner,simple-framebuffer",
"simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0-tve0";
- clocks = <&ahb_gates 34>, <&ahb_gates 36>,
-<&ahb_gates 44>,
-<&de_be0_clk>, <&tcon0_ch1_clk>,
-<&dram_gates 5>, <&dram_gates 26>;
+ clocks = <&ccu CLK_AHB_TVE0>, <&ccu CLK_AHB_LCD0>,
+<&ccu CLK_AHB_DE_BE0>,
+<&ccu CLK_DE_BE0>, <&ccu CLK_TCON0_CH1>,
+<&ccu CLK_DRAM_TVE0>, <&ccu CLK_DRAM_DE_BE0>;
status = "disabled";
};
};
@@ -103,7 +104,7 @@
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <0>;
- clocks = <&cpu>;
+ clocks = <&ccu CLK_CPU>;
clock-latency = <244144>; /* 8 32k periods */
operating-points = <
/* kHzuV */
@@ -184,21 +185,11 @@
osc24M: clk@01c20050 {
#clock-cells = <0>;
- compatible = "allwinner,sun4i-a10-osc-clk";
- reg = <0x01c20050 0x4>;
+ compatible = "fixed-clock";
clock-frequency = <2400>;
clock-output-names = "osc24M";
};
- osc3M: osc3M_clk {
- #clock-cells = <0>;
- compatible = "fixed-factor-clock";
- clock-div = <8>;
- clock-mult = <1>;
- clocks = <&osc24M>;
- clock-output-names = "osc3M";
- };
-
osc32k: clk@0 {
#clock-cells = <0>;
compatible = "fixed-clock";
@@ -206,528 +197,6 @@
clock-output-names = "osc32k";
};
- pll1: clk@01c2 {
- #clock-cells = <0>;
- compatible = "allwinner,sun4i-a10-pll1-clk";
- reg = <0x01c2 0x4>;
- clocks = <&osc24M>;
- clock-output-names = "pll1";
- };
-
- pll2: clk@01c20008 {
- #clock-cells = <1>;
- compatible = "allwinner,sun4i-a10-pll2-clk";
- reg = <0x01c20008 0x8>;
- clocks = <&osc24M>;
- clock-output-names = "pll2-1x", "pll2-2x",
-"pll2-4x", "pll2-8x";
- };
-
- pll3: clk@01c20010 {
- #clock-cells = <0>;
- compatible = "allwinner,sun4i-a10-pll3-clk";
-
[linux-sunxi] [PATCH 1/4] clk: sunxi-ng: Add clocks and reset indices for sun7i-a20 SoC
Add preliminary list of exported clocks and reset indices for sun7i-a20 SoC, based on existing sun7i-a20 devicetree implementation. Signed-off-by: Priit Laes --- include/dt-bindings/clock/sun7i-ccu.h | 127 ++ include/dt-bindings/reset/sun7i-ccu.h | 40 +++ 2 files changed, 167 insertions(+) create mode 100644 include/dt-bindings/clock/sun7i-ccu.h create mode 100644 include/dt-bindings/reset/sun7i-ccu.h diff --git a/include/dt-bindings/clock/sun7i-ccu.h b/include/dt-bindings/clock/sun7i-ccu.h new file mode 100644 index 000..52c4f76 --- /dev/null +++ b/include/dt-bindings/clock/sun7i-ccu.h @@ -0,0 +1,127 @@ +/* + * Copyright 2017 Priit Laes + * + * Priit Laes + * + * 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. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef _DT_BINDINGS_CLK_SUN7I_H_ +#define _DT_BINDINGS_CLK_SUN7I_H_ + +#define CLK_HOSC 1 +#define CLK_PLL_PERIPH_SATA16 +#define CLK_CPU19 + +/* AHB Gates */ +#define CLK_AHB_OTG24 +#define CLK_AHB_EHCI0 25 +#define CLK_AHB_OHCI0 26 +#define CLK_AHB_EHCI1 27 +#define CLK_AHB_OHCI1 28 +#define CLK_AHB_SS 29 +#define CLK_AHB_DMA30 + +#define CLK_AHB_MMC0 32 +#define CLK_AHB_MMC1 33 +#define CLK_AHB_MMC2 34 +#define CLK_AHB_MMC3 35 + +#define CLK_AHB_NAND 37 + +#define CLK_AHB_EMAC 40 + +#define CLK_AHB_SPI0 42 +#define CLK_AHB_SPI1 43 +#define CLK_AHB_SPI2 44 +#define CLK_AHB_SPI3 45 +#define CLK_AHB_SATA 46 +#define CLK_AHB_HSTIMER47 + +#define CLK_AHB_TVE0 50 +#define CLK_AHB_LCD0 52 +#define CLK_AHB_HDMI1 57 +#define CLK_AHB_DE_BE0 58 + +#define CLK_AHB_GMAC 62 + +/* APB0 Gates */ +#define CLK_APB0_CODEC 65 +#define CLK_APB0_SPDIF 66 +#define CLK_APB0_I2S0 68 +#define CLK_APB0_I2S1 69 +#define CLK_APB0_PIO 70 +#define CLK_APB0_IR0 71 +#define CLK_APB0_IR1 72 +#define CLK_APB0_I2S2 73 + +/* APB1 Gates */ +#define CLK_APB1_I2C0 75 +#define CLK_APB1_I2C1 76 +#define CLK_APB1_I2C2 77 +#define CLK_APB1_I2C3 78 + +#define CLK_APB1_PS20 81 +#define CLK_APB1_PS21 82 +#define CLK_APB1_I2C4 83 +#define CLK_APB1_UART0 84 +#define CLK_APB1_UART1 85 +#define CLK_APB1_UART2 86 +#define CLK_APB1_UART3 87 +#define CLK_APB1_UART4 88 +#define CLK_APB1_UART5 89 +#define CLK_APB1_UART6 90 +#define CLK_APB1_UART7 91 + +/* IP blocks */ +#define CLK_NAND 92 + +#define CLK_MMC0 94 +#define CLK_MMC0_OUTPUT95 +#define CLK_MMC0_SAMPLE96 +#define CLK_MMC1 97 +#define CLK_MMC1_OUTPUT98 +#define CLK_MMC1_SAMPLE99 +#define CLK_MMC2 100 +#define CLK_MMC2_OUTPUT101 +#define CLK_MMC2_SAMPLE102 +#define CLK_MMC3 103 +#define CLK_MMC3_OUTPUT104 +#define CLK_MMC3_SAMPLE105 + +#define CLK_SS 107 +#define CLK_SPI0 108 +#define CLK_SPI1 109 +#define CLK_SPI2 110 +#define CLK_IR0112 +#define CLK_IR1113 +#define CLK_I2S0 114 + +#define CLK_SPDIF 116 + +#define CLK_USB_OHCI0 119 +#define CLK_USB_OHCI1 120 +#define CLK_USB_PHY121 +#define CLK_SPI3 122 +#define CLK_I2S1 123 +#define CLK_I2S2 124 + +/* DRAM Gates */ +#define CLK_DRAM_TVE0 130 +#define CLK_DRAM_DE_BE0134 + +/* Display Engine Clocks */ +#define CLK_DE_BE0 139 +#define CLK_TCON0_CH0 144 +#define CLK_TCON0_CH1 149 +#define CLK_CODEC 153 + +#endif /* _DT_BINDINGS_CLK_SUN7I_H_ */ diff --git a/include/dt-bindings/reset/sun7i-ccu.h b/include/dt-bindings/reset/sun7i-ccu.h new file mode 100644 index 000..b8709ab --- /dev/null +++ b/include/dt-bindings/reset/sun7i-ccu.h @@ -0,0 +1,40 @@ +/* + * Copyright 2017 Priit Laes + * + * Priit Laes + * + * 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 ver
[linux-sunxi] [PATCH 4/4] dt-bindings: List devicetree binding for the CCU of Allwinner A20
Allwinner A20 is now driven by sunxi-ng CCU driver. Add devicetree binding for it. Signed-off-by: Priit Laes --- Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt index bae5668..265262c 100644 --- a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt +++ b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt @@ -4,6 +4,7 @@ Allwinner Clock Control Unit Binding Required properties : - compatible: must contain one of the following compatibles: - "allwinner,sun6i-a31-ccu" + - "allwinner,sun7i-a20-ccu" - "allwinner,sun8i-a23-ccu" - "allwinner,sun8i-a33-ccu" - "allwinner,sun8i-h3-ccu" -- 2.9.3 -- 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: [sunxi-tools PATCH] fel: add smc command
On Mon, 27 Feb 2017 05:48:48 +0200 Siarhei Siamashka wrote: > On Mon, 27 Feb 2017 02:22:08 + > André Przywara wrote: > > > On 27/02/17 01:20, Siarhei Siamashka wrote: > > > On Wed, 22 Feb 2017 17:08:47 + > > > Andre Przywara wrote: > > > > > >> If an SoC has the "secure boot" fuse burned, it will enter FEL > > >> mode in non-secure state, so with the SCR.NS bit set. Since in > > >> this mode the secure/non-secure state restrictions are actually > > >> observed, we suffer from several restrictions: > > >> - No access to the SID information (both via memory mapped and > > >> "register"). > > >> - No access to secure SRAM (SRAM A2 on H3/A64/H5). > > >> - No access to the secure side of the GIC, so it can't be > > >> configured to be accessible from non-secure world. > > >> - No RMR trigger on ARMv8 cores to bring the core into AArch64. > > >> Those limitations make a board pretty useless for many > > >> applications. > > >> > > >> However it has been found out that a simple "smc" call will > > >> immediately return from monitor mode, but with the NS bit > > >> cleared, so access to all secure peripherals is suddenly > > >> possible. > > >> > > >> Add a sunxi-fel command called "smc" which will issue exactly > > >> this instruction to make those boards useful in "secure boot" > > >> FEL mode. > > >> > > >> It should be given early in the command queue to given > > >> subsequent code full access to the system: > > >> $ ./sunxi-fel -v -p smc spl sunxi-spl.bin ... > > >> > > >> Signed-off-by: Andre Przywara > > >> > > >> --- > > >> Hi, > > >> > > >> if that sounds vaguely useful (it definitedly is for me to get > > >> the Remix Mini PC started), I can follow the Github process if > > >> you prefer that. > > >> > > >> Cheers, > > >> Andre. > > > > > > Hi Andre, > > > > > > Why don't we just do this automatically without adding a new > > > special command? > > > > > > We are not allowed to read the SCR register for detecting this > > > state, right? But can we still use some other detection method? > > > For example, maybe try to read SID and assume that we need the > > > SMC workaround if it reads back as zero? > > > > Yes, indeed I was thinking about exactly that ;-) > > From actually using this feature I realized that its usage is error > > prone: non-secure boards crash on calling it, secure board just > > don't work without it. > > And indeed there is no architectural way of checking whether you are > > running secure or non-secure (as reading a secure-only register like > > NSACR or SCR will trap, which means crash in our case). > > > > So (trying to) read the SID is indeed the best workaround I came up > > with: If it's all zero, we are probably secure and need the smc. > > There is still a slight chance that the SID is all zero even on a > > non-secure board (I think this was the case for some older SoCs?), > > so maybe we need an option to suppress using this heuristic? > > At least we should report every taken action in the sunxi-fel verbose > log (about the SMC workaround getting applied) because it greatly > simplifies troubleshooting. > > And IMHO having any options to suppress this workaround is a bit > premature until we encounter a real A64/H64/H5 chip where it fails > in the wild. > > Another variant of the detection heuristics could just use SRAM A2 > (well, not quite "SRAM", but the OpenRISC reset vector area). I'm > getting the following output on my Jide Remix Mini (Allwinner H64): > > $ ./sunxi-fel readl 0x40004 > 0x > > $ ./sunxi-fel smc > > $ ./sunxi-fel readl 0x40004 > 0x1500 > > We are either reading zero from there, or it is a hardwired OpenRISC > instruction L.NOP. Yeah, that sounds even better, but would be restricted to SoCs which have an OpenRISC. Not sure if that is actually a super set of secure-boot capable chips. Only thing is that we need to add the address of "secure SRAM" to the per-SoC data structure, but that may become useful for other purposes in the future as well, I guess. Cheers, Andre. -- 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 v5 3/3] ARM: dts: sun8i: enable SID on Allwinner H3 SoC
As we have already made sunxi_sid driver support the SID controller on
H3, enable it.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-h3.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 27780b97c863..ed2eede5f1f0 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -206,6 +206,11 @@
#size-cells = <0>;
};
+ sid: eeprom@01c14000 {
+ compatible = "allwinner,sun8i-h3-sid";
+ reg = <0x01c14000 0x400>;
+ };
+
usbphy: phy@01c19400 {
compatible = "allwinner,sun8i-h3-usb-phy";
reg = <0x01c19400 0x2c>,
--
2.11.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 v5 2/3] nvmem: sunxi-sid: add support for H3's SID controller
The H3 SoC have a bigger SID controller, which has its direct read
address at 0x200 position in the SID block, not 0x0.
Also, H3 SID controller has some silicon bug that makes the direct read
value wrong at cold boot, add code to workaround the bug. (This bug has
already been fixed on A64 and later SoCs)
Signed-off-by: Icenowy Zheng
---
Changes in v5:
- Removed some bits in binding documentation.
- Removed some default values in cfg struct.
Changes in v4:
- Use readl_poll_timeout.
- Do register offset in sunxi_sid_read.
- Merge SUN8I_SID_OP_LOCK and SUN8I_SID_LOCK_SHIFT into one macro.
- Drop the result of register-based read operation.
.../bindings/nvmem/allwinner,sunxi-sid.txt | 6 ++-
drivers/nvmem/sunxi_sid.c | 62 ++
2 files changed, 67 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
index d543ed3f5363..ef06d061913c 100644
--- a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
+++ b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
@@ -1,7 +1,11 @@
Allwinner sunxi-sid
Required properties:
-- compatible: "allwinner,sun4i-a10-sid" or "allwinner,sun7i-a20-sid"
+- compatible: Should be one of the following:
+ "allwinner,sun4i-a10-sid"
+ "allwinner,sun7i-a20-sid"
+ "allwinner,sun8i-h3-sid"
+
- reg: Should contain registers location and length
= Data cells =
diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
index 69524b67007f..0d6648be93b8 100644
--- a/drivers/nvmem/sunxi_sid.c
+++ b/drivers/nvmem/sunxi_sid.c
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
#include
@@ -25,6 +26,15 @@
#include
#include
+/* Registers and special values for doing register-based SID readout on H3 */
+#define SUN8I_SID_PRCTL0x40
+#define SUN8I_SID_RDKEY0x60
+
+#define SUN8I_SID_OFFSET_MASK 0x1FF
+#define SUN8I_SID_OFFSET_SHIFT 16
+#define SUN8I_SID_OP_LOCK (0xAC << 8)
+#define SUN8I_SID_READ BIT(1)
+
static struct nvmem_config econfig = {
.name = "sunxi-sid",
.read_only = true,
@@ -34,11 +44,14 @@ static struct nvmem_config econfig = {
};
struct sunxi_sid_cfg {
+ u32 value_offset;
u32 size;
+ boolneed_register_readout;
};
struct sunxi_sid {
void __iomem*base;
+ u32 value_offset;
};
/* We read the entire key, due to a 32 bit read alignment requirement. Since we
@@ -63,12 +76,36 @@ static int sunxi_sid_read(void *context, unsigned int
offset,
struct sunxi_sid *sid = context;
u8 *buf = val;
+ /* Offset the read operation to the real position of SID */
+ offset += sid->value_offset;
+
while (bytes--)
*buf++ = sunxi_sid_read_byte(sid, offset++);
return 0;
}
+static int sun8i_sid_register_readout(const struct sunxi_sid *sid,
+ const unsigned int word)
+{
+ u32 reg_val;
+ int ret;
+
+ /* Set word, lock access, and set read command */
+ reg_val = (word & SUN8I_SID_OFFSET_MASK)
+ << SUN8I_SID_OFFSET_SHIFT;
+ reg_val |= SUN8I_SID_OP_LOCK | SUN8I_SID_READ;
+ writel(reg_val, sid->base + SUN8I_SID_PRCTL);
+
+ ret = readl_poll_timeout(sid->base + SUN8I_SID_PRCTL, reg_val,
+!(reg_val & SUN8I_SID_READ), 100, 25);
+ if (ret)
+ return ret;
+
+ writel(0, sid->base + SUN8I_SID_PRCTL);
+ return 0;
+}
+
static int sunxi_sid_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -86,6 +123,7 @@ static int sunxi_sid_probe(struct platform_device *pdev)
cfg = of_device_get_match_data(dev);
if (!cfg)
return -EINVAL;
+ sid->value_offset = cfg->value_offset;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
sid->base = devm_ioremap_resource(dev, res);
@@ -94,6 +132,23 @@ static int sunxi_sid_probe(struct platform_device *pdev)
size = cfg->size;
+ if (cfg->need_register_readout) {
+ /*
+* H3's SID controller have a bug that the value at 0x200
+* offset is not the correct value when the hardware is reseted.
+* However, after doing a register-based read operation, the
+* value become right.
+* Do a full read operation here, but ignore its value
+* (as it's more fast to read by direct MMIO value than
+* with registers)
+*/
+ for (i = 0; i < (size >> 2); i++) {
+ ret = sun8i_sid_register_readout(sid, i);
+ if (ret)
+ return ret;
+ }
+ }
+
econfig.size = si
[linux-sunxi] [PATCH v5 1/3] nvmem: sunxi-sid: read NVMEM size from device compatible
Sometimes the SID device have more memory address space than the real
NVMEM size (for the registers used to read/write the SID).
Fetch the NVMEM size from device compatible, rather than the memory
address space's length, in order to prepare for adding some
registers-based read support.
Signed-off-by: Icenowy Zheng
Acked-by: Maxime Ripard
---
Changes in v4:
- Added Maxime's ACK.
drivers/nvmem/sunxi_sid.c | 27 +++
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
index 1567ccca8de3..69524b67007f 100644
--- a/drivers/nvmem/sunxi_sid.c
+++ b/drivers/nvmem/sunxi_sid.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -32,6 +33,10 @@ static struct nvmem_config econfig = {
.owner = THIS_MODULE,
};
+struct sunxi_sid_cfg {
+ u32 size;
+};
+
struct sunxi_sid {
void __iomem*base;
};
@@ -72,18 +77,24 @@ static int sunxi_sid_probe(struct platform_device *pdev)
struct sunxi_sid *sid;
int ret, i, size;
char *randomness;
+ const struct sunxi_sid_cfg *cfg;
sid = devm_kzalloc(dev, sizeof(*sid), GFP_KERNEL);
if (!sid)
return -ENOMEM;
+ cfg = of_device_get_match_data(dev);
+ if (!cfg)
+ return -EINVAL;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
sid->base = devm_ioremap_resource(dev, res);
if (IS_ERR(sid->base))
return PTR_ERR(sid->base);
- size = resource_size(res) - 1;
- econfig.size = resource_size(res);
+ size = cfg->size;
+
+ econfig.size = size;
econfig.dev = dev;
econfig.reg_read = sunxi_sid_read;
econfig.priv = sid;
@@ -119,9 +130,17 @@ static int sunxi_sid_remove(struct platform_device *pdev)
return nvmem_unregister(nvmem);
}
+static const struct sunxi_sid_cfg sun4i_a10_cfg = {
+ .size = 0x10,
+};
+
+static const struct sunxi_sid_cfg sun7i_a20_cfg = {
+ .size = 0x200,
+};
+
static const struct of_device_id sunxi_sid_of_match[] = {
- { .compatible = "allwinner,sun4i-a10-sid" },
- { .compatible = "allwinner,sun7i-a20-sid" },
+ { .compatible = "allwinner,sun4i-a10-sid", .data = &sun4i_a10_cfg },
+ { .compatible = "allwinner,sun7i-a20-sid", .data = &sun7i_a20_cfg },
{/* sentinel */},
};
MODULE_DEVICE_TABLE(of, sunxi_sid_of_match);
--
2.11.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.
Re: [linux-sunxi] Toggeling LDO3 causes crash/shutdown of the AXP209. Some verification help needed.
Hey Lub On , Lyubcho Haralanov wrote: Hi, VR1 is not assembled (NA). It is not placed. Only pads are provided in case you don't want to power the camera from the AXP209 but externally, in which case you should place VR1 and disconnect the SMT jumper LDO3_2.8V_E. By original design the camera is powered only by the AXP209. Best regards, Lub Thanks for the explanation of the EVB :) Can you also elaborate on the 10 uF for all designs however? Some extra information, I ran some current tests on the LDO3 power-up/shutdown and while 200 mA max sourcing current is never reached, the chip does shut down before the max voltage has been reached. For example setting ldo3 to max ( i2c mw 0x34 0x29 0x7f ) we get screenshot 3v6.png where we can see the max voltage is only 2.32. Repeating the same test however with 2.3 V ( i2c mw 0x34 0x29 0x40 ) yields 2V3.png, which also causes an AXP209 failure. This supprised me a little, as I expected the 2.3V to actually work, as that is the voltage we failed before. Also failure happens sooner and max current is lower. After some trial and error, we find that 1.95 V, in this case, still works, but that I suppose really depends on the capacitance, but by no means reliably! Due to the small timebase (50 uS) we cannot clearly see the power rail dropping, but be assured, for the 2V3 and 3V6, power slowly drops as capacitors discharge. While this can and should be solved in hardware (smaller capacitor) there's hundreds of thousands of boards in the wild with this configuration and thus a software solution is needed. The AXP209 does have slew rate control, however this does not apply when toggling the LDO3 output switch. What I thus propose, is a quirk-flag, for buggy boards, where we set the minimal voltage, enable power and than set the desired voltage, letting the internal slew rate control slowly ramp up voltage. What I still would love to hear from you guys, is why this could be happening. The spec-sheet does say 200 mA of sourcing capability. But it seems this is not exactly true? At least not when toggling LDO3 via reg12 for sure. Olliver On Monday, February 27, 2017 at 2:33:08 PM UTC+2, Marcus Weseloh wrote: Hi, 2017-02-27 13:11 GMT+01:00 oliver : One is to remove C185 (10 microF) and the problem went away. Looking at other designs, cubieboard 1 for example, uses the same layout, but only 4.7 microF. So it seems that charging of all the capacitance (input C106) the board itself, the output (C185) may be too much for the AXP209. Great, that confirms my suspicion that the capacitance is the main problem on the A20-SOM. The reference design for the A20 from Allwinner also suggests 4.7uF on LDO3, Olimex probably used 10uF there to keep the BOM smaller? At least on the A20-SOM-EVB we have another problem though (as explained in an earlier mail): When then SOM is attached to the EVB, the LDO3_2.8V rail on the SOM is powered from the EVB via +5V and a DC converter. Even with the LDO3 voltage set to it's minimum, turning on LDO3 shuts down the AXP immediately. Probably because the AXP sees an external voltage applied to it's input, it might even see reverse current flowing into it's ouput. I'd say that this is a design flaw on the EVB. So at least on the A20-SOM-EVB combination, LDO3 should never be be allowed to be switched on. Cheers, Marcus -- 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] Toggeling LDO3 causes crash/shutdown of the AXP209. Some verification help needed.
Hi Lyubcho, 2017-02-27 15:36 GMT+01:00 Lyubcho Haralanov : > VR1 is not assembled (NA). It is not placed. Only pads are provided in > case you don't want to power the camera from the AXP209 but externally, in > which case you should place VR1 and disconnect the SMT jumper LDO3_2.8V_E. > By original design the camera is powered only by the AXP209. > Ah, thanks for that! I based my assumtion on the EVB schematic and didn't notice the "NA" in there (and didn't have a multimeter handy to check). So maybe the cause for the immediate AXP shutdown is the extra capacitance of C28 (22uF)? Cheers, Marcus -- 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] Toggeling LDO3 causes crash/shutdown of the AXP209. Some verification help needed.
Hi, VR1 is not assembled (NA). It is not placed. Only pads are provided in case you don't want to power the camera from the AXP209 but externally, in which case you should place VR1 and disconnect the SMT jumper LDO3_2.8V_E. By original design the camera is powered only by the AXP209. Best regards, Lub On Monday, February 27, 2017 at 2:33:08 PM UTC+2, Marcus Weseloh wrote: > > Hi, > > 2017-02-27 13:11 GMT+01:00 oliver >: > >> One is to remove C185 (10 microF) and the problem went away. Looking at >> other designs, cubieboard 1 for example, uses the same layout, but only 4.7 >> microF. So it seems that charging of all the capacitance (input C106) the >> board itself, the output (C185) may be too much for the AXP209. >> > > Great, that confirms my suspicion that the capacitance is the main problem > on the A20-SOM. The reference design for the A20 from Allwinner also > suggests 4.7uF on LDO3, Olimex probably used 10uF there to keep the BOM > smaller? > > At least on the A20-SOM-EVB we have another problem though (as explained > in an earlier mail): When then SOM is attached to the EVB, the LDO3_2.8V > rail on the SOM is powered from the EVB via +5V and a DC converter. Even > with the LDO3 voltage set to it's minimum, turning on LDO3 shuts down the > AXP immediately. Probably because the AXP sees an external voltage applied > to it's input, it might even see reverse current flowing into it's ouput. > I'd say that this is a design flaw on the EVB. So at least on the > A20-SOM-EVB combination, LDO3 should never be be allowed to be switched on. > > Cheers, > >Marcus > -- 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 v4 8/9] pwm: sunxi: Code cleanup.
Hi, 2017-02-27 12:32 GMT+03:00 Maxime Ripard : > On Fri, Feb 24, 2017 at 08:41:15AM +0300, lis8...@gmail.com wrote: >> From: Siarhei Volkau >> >> This patch removes macros, which are not use anymore and >> fixes two extra -Wsign-compare warnings. >> >> Signed-off-by: Siarhei Volkau > > You've been adding this code in your previous patches, why is that > even added there? > > Maxime > > -- > Maxime Ripard, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com Are you mean there are no needs in separate patch for that? Siarhei -- 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 0/6] sunxi: update Pine64/A64 DTs
Hi,
On Mon, Feb 27, 2017 at 5:53 PM, Andre Przywara wrote:
> Hi,
>
> On 27/02/17 03:30, Chen-Yu Tsai wrote:
>> On Mon, Feb 27, 2017 at 8:26 AM, Andre Przywara
>> wrote:
>>> Hi,
>>>
>>> in the wake of the sunxi DM enablement series it became apparent that
>>> the current device tree files for the A64 SoC and its board are outdated.
>>>
>>> Since Linux v4.10-rc1 there are now basic .dts files for the Allwinner
>>> A64 SoC and the Pine64 boards in the mainline kernel.
>>> Linux v4.11-rc1 added MMC and USB support.
>>> Because our preliminary device trees used in U-Boot differ significantly,
>>> let's update our copy with what's in the current Linus' master tree.
>>> Since in contrast to U-Boot the kernel still lacks support for Ethernet,
>>> we keep our preliminary nodes for that IP, but adjust it slightly to
>>> match the new clocks and reset bindings.
>>>
>>> As the sun8i-emac driver is actually using the DT for the pinmux setup,
>>> we teach it how to cope with the new pinctrl bindings in the first two
>>> patches. This is probably becoming somewhat obsolete very soon (with
>>> DM GPIO support on the list already), however I consider these two
>>> patches as merely fixes for the existing driver to maintain bisectability.
>>> It would make sense to merge the new DTs before the DM patches, so we
>>> need to have something in place which works meanwhile.
>>>
>>> Let me know what you think.
>>>
>>> Cheers,
>>> Andre.
>>>
>>> Andre Przywara (6):
>>> sunxi: GPIO: introduce sunxi_gpio_setup_dt_pins()
>>> net: sun8i-emac: use new, generic GPIO setup routine
>>> sunxi: dts: update sun50i-a64.dtsi from Linux
>>> sunxi: dts: update Pine64 .dts
>>> sunxi: dts: remove now obsolete pine64-common.dtsi
>>> sunxi: dts: add Bananapi M64 .dts
>>
>> Could we keep this simple, and just do a "sync with the kernel" commit for
>> sun50i, which also keeps the sun8i-emac specific bits. And also explicitly
>> mention the git commit or tag you are syncing to.
>
> So you mean to drop patch 1 and 2 and keep the old style pinctrl
> bindings around for the EMAC node?
> I can certainly do this (if others agree), but didn't want to dodge a
> more proper solution in the first place.
I've actually no preference on this. What I meant was you don't need
four patches to do the sync-up, just one, i.e. copy sun50i*.{dts,dtsi}
from the kernel, and patch back whatever the emac needs, since it's
not in mainline yet.
I guess you could update sun8i-emac to deal with generic pinconf,
or update the gpio driver, but that would be a separate series.
ChenYu
> Another alternative would be to squash the functionality of patch 1
> directly into sun8i_emac.c, so without the moving to pinmux.c. This
> would mean dropping patch 1/6 and just having a fix for the sun8i_emac.
>
> Let me know what's the preferred solution here.
>
> Cheers,
> Andre.
>
>>> arch/arm/dts/Makefile | 3 +-
>>> arch/arm/dts/sun50i-a64-bananapi-m64.dts | 135 +++
>>> arch/arm/dts/sun50i-a64-pine64-common.dtsi | 93 -
>>> arch/arm/dts/sun50i-a64-pine64-plus.dts| 16 +-
>>> arch/arm/dts/sun50i-a64-pine64.dts | 72 +++-
>>> arch/arm/dts/sun50i-a64.dtsi | 615
>>> +
>>> arch/arm/include/asm/arch-sunxi/gpio.h | 4 +
>>> arch/arm/mach-sunxi/pinmux.c | 77
>>> drivers/net/sun8i_emac.c | 38 +-
>>> include/dt-bindings/clock/sun50i-a64-ccu.h | 134 +++
>>> include/dt-bindings/reset/sun50i-a64-ccu.h | 98 +
>>> 11 files changed, 706 insertions(+), 579 deletions(-)
>>> create mode 100644 arch/arm/dts/sun50i-a64-bananapi-m64.dts
>>> delete mode 100644 arch/arm/dts/sun50i-a64-pine64-common.dtsi
>>> create mode 100644 include/dt-bindings/clock/sun50i-a64-ccu.h
>>> create mode 100644 include/dt-bindings/reset/sun50i-a64-ccu.h
>>>
>>> --
>>> 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 v4 4/9] pwm: sunxi: Customizable control and period register position.
Hi,
2017-02-27 12:30 GMT+03:00 Maxime Ripard :
> On Fri, Feb 24, 2017 at 08:41:11AM +0300, lis8...@gmail.com wrote:
>> From: Siarhei Volkau
>>
>> sun6i has same registers as sun4i compatible chips, but its position
>> in register map are different.
>>
>> This patch make register's position selectable for support sun6i in
>> next patches.
>>
>> Signed-off-by: Siarhei Volkau
>> ---
>> drivers/pwm/pwm-sun4i.c | 57
>> ++---
>> 1 file changed, 54 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
>> index 418a625..9ddc812 100644
>> --- a/drivers/pwm/pwm-sun4i.c
>> +++ b/drivers/pwm/pwm-sun4i.c
>> @@ -79,11 +79,17 @@ static const u32 sun4i_prescaler_table[] = {
>> 0, /* Actually 1 but tested separately */
>> };
>>
>> +struct sunxi_pwmch_data {
>> + unsigned int ctl_reg;
>> + unsigned int prd_reg;
>> +};
>> +
>
> Why don't you use regmap_fields for that too?
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
Period register contains 2 fields (duty cycle and active period),
A20 user manual says:
(C) Note: the active cycles should be no larger than the period cycles.
I just try to avoid situation when active cycles can have bigger value
than duty cycle. Regmap fields not allows update 2
or more fields simultaneously, or maybe i'm not found this.
Same situation with enable/disable bitmask in control register.
Updating these bits (clock gating and enable) in different moments
in time can produce some artefacts on pwm output signal.
Siarhei
--
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] Toggeling LDO3 causes crash/shutdown of the AXP209. Some verification help needed.
Hi, 2017-02-27 13:11 GMT+01:00 oliver : > One is to remove C185 (10 microF) and the problem went away. Looking at > other designs, cubieboard 1 for example, uses the same layout, but only 4.7 > microF. So it seems that charging of all the capacitance (input C106) the > board itself, the output (C185) may be too much for the AXP209. > Great, that confirms my suspicion that the capacitance is the main problem on the A20-SOM. The reference design for the A20 from Allwinner also suggests 4.7uF on LDO3, Olimex probably used 10uF there to keep the BOM smaller? At least on the A20-SOM-EVB we have another problem though (as explained in an earlier mail): When then SOM is attached to the EVB, the LDO3_2.8V rail on the SOM is powered from the EVB via +5V and a DC converter. Even with the LDO3 voltage set to it's minimum, turning on LDO3 shuts down the AXP immediately. Probably because the AXP sees an external voltage applied to it's input, it might even see reverse current flowing into it's ouput. I'd say that this is a design flaw on the EVB. So at least on the A20-SOM-EVB combination, LDO3 should never be be allowed to be switched on. Cheers, Marcus -- 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 v5 2/7] clk: sunxi-ng: rename sun8i-h3 driver to sunxi-h3-h5
Hi, On Sun, Feb 26, 2017 at 09:19:51AM +0800, Icenowy Zheng wrote: > As the CCU in the Allwinner H5 SoC is very similar to the one in H3, > rename the H3 driver to sunxi-h3-h5 so that it can be extended with H5 > support. > > Trasitional header symlinks are created, to ensure current device tree > files which included sun8i-h3-ccu.h can compile. > > Signed-off-by: Icenowy Zheng Just like for the R40, I wonder whether this is needed at all. We have a lot of other drivers that we don't have to rename to support new SoCs. This is kind of weird to make an exception for this one only. 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] Toggeling LDO3 causes crash/shutdown of the AXP209. Some verification help needed.
Hey all, top reply, sorry :) So after the test results I have received so far, for which I am grateful indeed, we did some more experiments here. One is to remove C185 (10 microF) and the problem went away. Looking at other designs, cubieboard 1 for example, uses the same layout, but only 4.7 microF. So it seems that charging of all the capacitance (input C106) the board itself, the output (C185) may be too much for the AXP209. Digging through the datasheet I also found the LDO3 Dynamic voltage scaling parameter settings, but it did not make a difference. So next, I will start doing current measurements to put some numbers there. Next will be to add a software voltage ramping of LDO3 (maybe behind a quirk) On , Marcus Weseloh wrote: Hi Oliver, 2017-02-24 23:13 GMT+01:00 Olliver Schinagl : It turns out, turning on LDO3, after it was turned off before, causes the PMIC to shut down. Even enabeling all interrupts and checking the interrupt pin, nothing could be found as to why however. It is thus my believe that there is a design flaw in the AXP209, that causes it to shutdown if LDO3 is enabled. This does however happen 'randomly' at 90% of the time. Sometime it does indeed work properly. I want to now know, before sending patches, if this happens on other boards next to the Olinuxino Lime2. A simple test can be performed to find out. I tested this on an Olimex A20-SOM-EVB board. It boots up with LDO3 and LDO4 disabled: => i2c md 0x34 0x12 1 0012: 17. After enabling LDO3 manually, it crashes instantly (i've tried it a few times, with the same result): => i2c mw 0x34 0x12 0x57 uboot unresponsive afterwards Toggling LDO4 works fine, though. LDO3 seems to be connected as power supply for CSI0 and is set to 2.8V: => i2c md 0x34 0x29 1 0029: 54T Hope this helps, Marcus -- 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 v4 2/9] pwm: sunxi: Use regmap fields for bit operations.
Hi,
2017-02-27 12:28 GMT+03:00 Maxime Ripard :
>
> Hi,
>
> On Fri, Feb 24, 2017 at 08:41:09AM +0300, lis8...@gmail.com wrote:
> > +static const struct reg_field
> > +sun4i_pwm_regfields[SUN4I_MAX_PWM_CHANNELS][NUM_FIELDS] = {
> > + {
> > + [FIELD_PRESCALER] = REG_FIELD(PWM_CTRL_REG, 0, 3),
> > + [FIELD_POLARITY] = REG_FIELD(PWM_CTRL_REG, 5, 5),
> > + [FIELD_CLK_GATING] = REG_FIELD(PWM_CTRL_REG, 6, 6),
> > + [FIELD_READY] = REG_FIELD(PWM_CTRL_REG, 28, 28),
> > + },
> > + {
> > + [FIELD_PRESCALER] = REG_FIELD(PWM_CTRL_REG, 15, 18),
> > + [FIELD_POLARITY] = REG_FIELD(PWM_CTRL_REG, 20, 20),
> > + [FIELD_CLK_GATING] = REG_FIELD(PWM_CTRL_REG, 21, 21),
> > + [FIELD_READY] = REG_FIELD(PWM_CTRL_REG, 29, 29),
> > + },
> > +};
> > +
>
> I'm not sure you need something that complicated.
>
> What about something like:
>
> struct sun4i_chan_fields {
>struct reg_field prescaler;
>struct reg_field polarity;
>struct reg_field clk_gating;
>struct reg_field ready;
> };
>
> And in sun4i_pwm_data add an array of this struct.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
Code with struct looks cleaner, but in this case need to be
written separate code for each reg_field entry allocation,
please look at the sunxi_alloc_reg_fields() function.
Current solution allows adding new fields slightly easier.
Siarhei
--
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 v4 1/9] pwm: sunxi: Use regmap API for register access.
Hi, Maxime
2017-02-27 12:17 GMT+03:00 Maxime Ripard :
> Hi Siarhei,
>
> On Fri, Feb 24, 2017 at 08:41:08AM +0300, lis8...@gmail.com wrote:
>> From: Siarhei Volkau
>>
>> The patch replaces iomem register access routines to regmap
>> equivalents.
>>
>> Signed-off-by: Siarhei Volkau
>> ---
>> drivers/pwm/Kconfig | 2 +-
>> drivers/pwm/pwm-sun4i.c | 143
>>
>> 2 files changed, 110 insertions(+), 35 deletions(-)
>>
>> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
>> index 2d0cfaa..6b4dc1a 100644
>> --- a/drivers/pwm/Kconfig
>> +++ b/drivers/pwm/Kconfig
>> @@ -416,7 +416,7 @@ config PWM_STMPE
>> config PWM_SUN4I
>> tristate "Allwinner PWM support"
>> depends on ARCH_SUNXI || COMPILE_TEST
>> - depends on HAS_IOMEM && COMMON_CLK
>> + depends on REGMAP_MMIO && COMMON_CLK
>> help
>> Generic PWM framework driver for Allwinner SoCs.
>>
>> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
>> index b0803f6..5565f03 100644
>> --- a/drivers/pwm/pwm-sun4i.c
>> +++ b/drivers/pwm/pwm-sun4i.c
>> @@ -9,7 +9,7 @@
>> #include
>> #include
>> #include
>> -#include
>> +#include
>> #include
>> #include
>> #include
>> @@ -74,7 +74,7 @@ struct sun4i_pwm_data {
>> struct sun4i_pwm_chip {
>> struct pwm_chip chip;
>> struct clk *clk;
>> - void __iomem *base;
>> + struct regmap *regmap;
>> spinlock_t ctrl_lock;
>> const struct sun4i_pwm_data *data;
>> };
>> @@ -84,18 +84,6 @@ static inline struct sun4i_pwm_chip
>> *to_sun4i_pwm_chip(struct pwm_chip *chip)
>> return container_of(chip, struct sun4i_pwm_chip, chip);
>> }
>>
>> -static inline u32 sun4i_pwm_readl(struct sun4i_pwm_chip *chip,
>> - unsigned long offset)
>> -{
>> - return readl(chip->base + offset);
>> -}
>> -
>> -static inline void sun4i_pwm_writel(struct sun4i_pwm_chip *chip,
>> - u32 val, unsigned long offset)
>> -{
>> - writel(val, chip->base + offset);
>> -}
>> -
>> static int sun4i_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
>> int duty_ns, int period_ns)
>> {
>> @@ -152,7 +140,11 @@ static int sun4i_pwm_config(struct pwm_chip *chip,
>> struct pwm_device *pwm,
>> }
>>
>> spin_lock(&sun4i_pwm->ctrl_lock);
>> - val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
>> + err = regmap_read(sun4i_pwm->regmap, PWM_CTRL_REG, &val);
>> + if (err) {
>> + dev_err(chip->dev, "failed to read from CTL register\n");
>> + goto err_cleanup;
>> + }
>
> I'm not sure you need those error checks. If there's an error when you
> write to an MMIO bus, you have much more important issues than your
> return code there.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
This probably overkill for MMIO, but it helps when wrong parameters passed
to regmap functions - mostly during debugging stage.
Siarhei
--
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 1/6] sunxi: GPIO: introduce sunxi_gpio_setup_dt_pins()
Hi,
On 27/02/17 10:07, Maxime Ripard wrote:
> On Mon, Feb 27, 2017 at 12:26:40AM +, Andre Przywara wrote:
>> Instead of hard-coding GPIO pins used for a certain peripheral, we
>> should just use the pinctrl information from the DT.
>> The sun8i-emac driver has some simple implementation of that, so
>> let's just generalize this and move the code into a more common
>> location.
>> On the way we add support for the new, generic pinctrl binding now
>> used by all Allwinner SoCs.
>>
>> Signed-off-by: Andre Przywara
>> ---
>> arch/arm/include/asm/arch-sunxi/gpio.h | 4 ++
>> arch/arm/mach-sunxi/pinmux.c | 77
>> ++
>> 2 files changed, 81 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
>> b/arch/arm/include/asm/arch-sunxi/gpio.h
>> index 85a4ec3..ba8c661 100644
>> --- a/arch/arm/include/asm/arch-sunxi/gpio.h
>> +++ b/arch/arm/include/asm/arch-sunxi/gpio.h
>> @@ -239,4 +239,8 @@ int axp_gpio_init(void);
>> static inline int axp_gpio_init(void) { return 0; }
>> #endif
>>
>> +int sunxi_gpio_parse_pin_name(const char *pin_name);
>> +int sunxi_gpio_setup_dt_pins(const void * volatile fdt_blob, int node,
>> + const char * mux_name, int mux_sel);
>> +
>> #endif /* _SUNXI_GPIO_H */
>> diff --git a/arch/arm/mach-sunxi/pinmux.c b/arch/arm/mach-sunxi/pinmux.c
>> index b026f78..f1e1e8f 100644
>> --- a/arch/arm/mach-sunxi/pinmux.c
>> +++ b/arch/arm/mach-sunxi/pinmux.c
>> @@ -9,6 +9,9 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>> +#include
>>
>> void sunxi_gpio_set_cfgbank(struct sunxi_gpio *pio, int bank_offset, u32
>> val)
>> {
>> @@ -69,3 +72,77 @@ int sunxi_gpio_set_pull(u32 pin, u32 val)
>>
>> return 0;
>> }
>> +
>> +int sunxi_gpio_parse_pin_name(const char *pin_name)
>> +{
>> +int pin;
>> +
>> +if (pin_name[0] != 'P')
>> +return -1;
>> +
>> +if (pin_name[1] < 'A' || pin_name[1] > 'Z')
>> +return -1;
>> +
>> +pin = (pin_name[1] - 'A') << 5;
>> +pin += simple_strtol(&pin_name[2], NULL, 10);
>> +
>> +return pin;
>> +}
>
> That function already exists, sunxi_name_to_gpio.
Indeed, I found this yesterday _after_ sending the patches ;-)
For some reasons I missed that when I originally wrote the patches,
sorry for that.
Cheers,
Andre.
--
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 1/6] sunxi: GPIO: introduce sunxi_gpio_setup_dt_pins()
On Mon, Feb 27, 2017 at 12:26:40AM +, Andre Przywara wrote:
> Instead of hard-coding GPIO pins used for a certain peripheral, we
> should just use the pinctrl information from the DT.
> The sun8i-emac driver has some simple implementation of that, so
> let's just generalize this and move the code into a more common
> location.
> On the way we add support for the new, generic pinctrl binding now
> used by all Allwinner SoCs.
>
> Signed-off-by: Andre Przywara
> ---
> arch/arm/include/asm/arch-sunxi/gpio.h | 4 ++
> arch/arm/mach-sunxi/pinmux.c | 77
> ++
> 2 files changed, 81 insertions(+)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
> b/arch/arm/include/asm/arch-sunxi/gpio.h
> index 85a4ec3..ba8c661 100644
> --- a/arch/arm/include/asm/arch-sunxi/gpio.h
> +++ b/arch/arm/include/asm/arch-sunxi/gpio.h
> @@ -239,4 +239,8 @@ int axp_gpio_init(void);
> static inline int axp_gpio_init(void) { return 0; }
> #endif
>
> +int sunxi_gpio_parse_pin_name(const char *pin_name);
> +int sunxi_gpio_setup_dt_pins(const void * volatile fdt_blob, int node,
> + const char * mux_name, int mux_sel);
> +
> #endif /* _SUNXI_GPIO_H */
> diff --git a/arch/arm/mach-sunxi/pinmux.c b/arch/arm/mach-sunxi/pinmux.c
> index b026f78..f1e1e8f 100644
> --- a/arch/arm/mach-sunxi/pinmux.c
> +++ b/arch/arm/mach-sunxi/pinmux.c
> @@ -9,6 +9,9 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
>
> void sunxi_gpio_set_cfgbank(struct sunxi_gpio *pio, int bank_offset, u32 val)
> {
> @@ -69,3 +72,77 @@ int sunxi_gpio_set_pull(u32 pin, u32 val)
>
> return 0;
> }
> +
> +int sunxi_gpio_parse_pin_name(const char *pin_name)
> +{
> + int pin;
> +
> + if (pin_name[0] != 'P')
> + return -1;
> +
> + if (pin_name[1] < 'A' || pin_name[1] > 'Z')
> + return -1;
> +
> + pin = (pin_name[1] - 'A') << 5;
> + pin += simple_strtol(&pin_name[2], NULL, 10);
> +
> + return pin;
> +}
That function already exists, sunxi_name_to_gpio.
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 v4 2/3] nvmem: sunxi-sid: add support for H3's SID controller
On Mon, Feb 27, 2017 at 12:10:02AM +0800, Icenowy Zheng wrote:
> The H3 SoC have a bigger SID controller, which has its direct read
> address at 0x200 position in the SID block, not 0x0.
>
> Also, H3 SID controller has some silicon bug that makes the direct read
> value wrong at cold boot, add code to workaround the bug. (This bug has
> already been fixed on A64 and later SoCs)
>
> Signed-off-by: Icenowy Zheng
> ---
> Changes in v4:
> - Use readl_poll_timeout.
> - Do register offset in sunxi_sid_read.
> - Merge SUN8I_SID_OP_LOCK and SUN8I_SID_LOCK_SHIFT into one macro.
> - Drop the result of register-based read operation.
>
> .../bindings/nvmem/allwinner,sunxi-sid.txt | 12 +++-
> drivers/nvmem/sunxi_sid.c | 66
> ++
> 2 files changed, 77 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
> b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
> index d543ed3f5363..9ab9e75a6351 100644
> --- a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
> +++ b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
> @@ -1,7 +1,11 @@
> Allwinner sunxi-sid
>
> Required properties:
> -- compatible: "allwinner,sun4i-a10-sid" or "allwinner,sun7i-a20-sid"
> +- compatible: Should be one of the following (depending on your SoC):
There's no need to add that it depends on the SoC, it's kind of obvious.
> + "allwinner,sun4i-a10-sid"
> + "allwinner,sun7i-a20-sid"
> + "allwinner,sun8i-h3-sid"
> +
> - reg: Should contain registers location and length
>
> = Data cells =
> @@ -19,3 +23,9 @@ Example for sun7i:
> compatible = "allwinner,sun7i-a20-sid";
> reg = <0x01c23800 0x200>
> };
> +
> +Example for sun8i-h3:
> + sid@01c14000 {
> + compatible = "allwinner,sun8i-h3-sid";
> + reg = <0x01c14000 0x400>;
> + };
And there's no need to add an example either, this is just as obvious
if you compare it to the other.
> diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
> index 69524b67007f..5179add54749 100644
> --- a/drivers/nvmem/sunxi_sid.c
> +++ b/drivers/nvmem/sunxi_sid.c
> @@ -17,6 +17,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -25,6 +26,15 @@
> #include
> #include
>
> +/* Registers and special values for doing register-based SID readout on H3 */
> +#define SUN8I_SID_PRCTL 0x40
> +#define SUN8I_SID_RDKEY 0x60
> +
> +#define SUN8I_SID_OFFSET_MASK0x1FF
> +#define SUN8I_SID_OFFSET_SHIFT 16
> +#define SUN8I_SID_OP_LOCK(0xAC << 8)
> +#define SUN8I_SID_READ BIT(1)
> +
> static struct nvmem_config econfig = {
> .name = "sunxi-sid",
> .read_only = true,
> @@ -34,11 +44,14 @@ static struct nvmem_config econfig = {
> };
>
> struct sunxi_sid_cfg {
> + u32 value_offset;
> u32 size;
> + boolneed_register_readout;
> };
>
> struct sunxi_sid {
> void __iomem*base;
> + u32 value_offset;
> };
>
> /* We read the entire key, due to a 32 bit read alignment requirement. Since
> we
> @@ -63,12 +76,36 @@ static int sunxi_sid_read(void *context, unsigned int
> offset,
> struct sunxi_sid *sid = context;
> u8 *buf = val;
>
> + /* Offset the read operation to the real position of SID */
> + offset += sid->value_offset;
> +
> while (bytes--)
> *buf++ = sunxi_sid_read_byte(sid, offset++);
>
> return 0;
> }
>
> +static int sun8i_sid_register_readout(const struct sunxi_sid *sid,
> + const unsigned int word)
> +{
> + u32 reg_val;
> + int ret;
> +
> + /* Set word, lock access, and set read command */
> + reg_val = (word & SUN8I_SID_OFFSET_MASK)
> + << SUN8I_SID_OFFSET_SHIFT;
> + reg_val |= SUN8I_SID_OP_LOCK | SUN8I_SID_READ;
> + writel(reg_val, sid->base + SUN8I_SID_PRCTL);
> +
> + ret = readl_poll_timeout(sid->base + SUN8I_SID_PRCTL, reg_val,
> + !(reg_val & SUN8I_SID_READ), 100, 25);
> + if (ret)
> + return ret;
> +
> + writel(0, sid->base + SUN8I_SID_PRCTL);
> + return 0;
> +}
> +
> static int sunxi_sid_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -86,6 +123,7 @@ static int sunxi_sid_probe(struct platform_device *pdev)
> cfg = of_device_get_match_data(dev);
> if (!cfg)
> return -EINVAL;
> + sid->value_offset = cfg->value_offset;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> sid->base = devm_ioremap_resource(dev, res);
> @@ -94,6 +132,23 @@ static int sunxi_sid_probe(struct platform_device *pdev)
>
> size = cfg->size;
>
> + if (cfg->need_register_readout) {
> + /*
> + * H3's SID controller have a
[linux-sunxi] Re: [PATCH 0/6] sunxi: update Pine64/A64 DTs
Hi, On 27/02/17 03:30, Chen-Yu Tsai wrote: > On Mon, Feb 27, 2017 at 8:26 AM, Andre Przywara > wrote: >> Hi, >> >> in the wake of the sunxi DM enablement series it became apparent that >> the current device tree files for the A64 SoC and its board are outdated. >> >> Since Linux v4.10-rc1 there are now basic .dts files for the Allwinner >> A64 SoC and the Pine64 boards in the mainline kernel. >> Linux v4.11-rc1 added MMC and USB support. >> Because our preliminary device trees used in U-Boot differ significantly, >> let's update our copy with what's in the current Linus' master tree. >> Since in contrast to U-Boot the kernel still lacks support for Ethernet, >> we keep our preliminary nodes for that IP, but adjust it slightly to >> match the new clocks and reset bindings. >> >> As the sun8i-emac driver is actually using the DT for the pinmux setup, >> we teach it how to cope with the new pinctrl bindings in the first two >> patches. This is probably becoming somewhat obsolete very soon (with >> DM GPIO support on the list already), however I consider these two >> patches as merely fixes for the existing driver to maintain bisectability. >> It would make sense to merge the new DTs before the DM patches, so we >> need to have something in place which works meanwhile. >> >> Let me know what you think. >> >> Cheers, >> Andre. >> >> Andre Przywara (6): >> sunxi: GPIO: introduce sunxi_gpio_setup_dt_pins() >> net: sun8i-emac: use new, generic GPIO setup routine >> sunxi: dts: update sun50i-a64.dtsi from Linux >> sunxi: dts: update Pine64 .dts >> sunxi: dts: remove now obsolete pine64-common.dtsi >> sunxi: dts: add Bananapi M64 .dts > > Could we keep this simple, and just do a "sync with the kernel" commit for > sun50i, which also keeps the sun8i-emac specific bits. And also explicitly > mention the git commit or tag you are syncing to. So you mean to drop patch 1 and 2 and keep the old style pinctrl bindings around for the EMAC node? I can certainly do this (if others agree), but didn't want to dodge a more proper solution in the first place. Another alternative would be to squash the functionality of patch 1 directly into sun8i_emac.c, so without the moving to pinmux.c. This would mean dropping patch 1/6 and just having a fix for the sun8i_emac. Let me know what's the preferred solution here. Cheers, Andre. >> arch/arm/dts/Makefile | 3 +- >> arch/arm/dts/sun50i-a64-bananapi-m64.dts | 135 +++ >> arch/arm/dts/sun50i-a64-pine64-common.dtsi | 93 - >> arch/arm/dts/sun50i-a64-pine64-plus.dts| 16 +- >> arch/arm/dts/sun50i-a64-pine64.dts | 72 +++- >> arch/arm/dts/sun50i-a64.dtsi | 615 >> + >> arch/arm/include/asm/arch-sunxi/gpio.h | 4 + >> arch/arm/mach-sunxi/pinmux.c | 77 >> drivers/net/sun8i_emac.c | 38 +- >> include/dt-bindings/clock/sun50i-a64-ccu.h | 134 +++ >> include/dt-bindings/reset/sun50i-a64-ccu.h | 98 + >> 11 files changed, 706 insertions(+), 579 deletions(-) >> create mode 100644 arch/arm/dts/sun50i-a64-bananapi-m64.dts >> delete mode 100644 arch/arm/dts/sun50i-a64-pine64-common.dtsi >> create mode 100644 include/dt-bindings/clock/sun50i-a64-ccu.h >> create mode 100644 include/dt-bindings/reset/sun50i-a64-ccu.h >> >> -- >> 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 v4 8/9] pwm: sunxi: Code cleanup.
On Fri, Feb 24, 2017 at 08:41:15AM +0300, lis8...@gmail.com wrote: > From: Siarhei Volkau > > This patch removes macros, which are not use anymore and > fixes two extra -Wsign-compare warnings. > > Signed-off-by: Siarhei Volkau You've been adding this code in your previous patches, why is that even added 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 v4 4/9] pwm: sunxi: Customizable control and period register position.
On Fri, Feb 24, 2017 at 08:41:11AM +0300, lis8...@gmail.com wrote:
> From: Siarhei Volkau
>
> sun6i has same registers as sun4i compatible chips, but its position
> in register map are different.
>
> This patch make register's position selectable for support sun6i in
> next patches.
>
> Signed-off-by: Siarhei Volkau
> ---
> drivers/pwm/pwm-sun4i.c | 57
> ++---
> 1 file changed, 54 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> index 418a625..9ddc812 100644
> --- a/drivers/pwm/pwm-sun4i.c
> +++ b/drivers/pwm/pwm-sun4i.c
> @@ -79,11 +79,17 @@ static const u32 sun4i_prescaler_table[] = {
> 0, /* Actually 1 but tested separately */
> };
>
> +struct sunxi_pwmch_data {
> + unsigned int ctl_reg;
> + unsigned int prd_reg;
> +};
> +
Why don't you use regmap_fields for that too?
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 v4 3/9] pwm: sunxi: Selectable prescaler table.
On Fri, Feb 24, 2017 at 08:41:10AM +0300, lis8...@gmail.com wrote: > From: Siarhei Volkau > > A31 SoC have a different set of prescalers than sun4i > compatible ASoCs, but its position and count in the control > register are the same. > > This patch make the table of prescalers customizable. > > Signed-off-by: Siarhei Volkau Acked-by: Maxime Ripard 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
[linux-sunxi] Re: [PATCH v4 2/9] pwm: sunxi: Use regmap fields for bit operations.
Hi,
On Fri, Feb 24, 2017 at 08:41:09AM +0300, lis8...@gmail.com wrote:
> +static const struct reg_field
> +sun4i_pwm_regfields[SUN4I_MAX_PWM_CHANNELS][NUM_FIELDS] = {
> + {
> + [FIELD_PRESCALER] = REG_FIELD(PWM_CTRL_REG, 0, 3),
> + [FIELD_POLARITY] = REG_FIELD(PWM_CTRL_REG, 5, 5),
> + [FIELD_CLK_GATING] = REG_FIELD(PWM_CTRL_REG, 6, 6),
> + [FIELD_READY] = REG_FIELD(PWM_CTRL_REG, 28, 28),
> + },
> + {
> + [FIELD_PRESCALER] = REG_FIELD(PWM_CTRL_REG, 15, 18),
> + [FIELD_POLARITY] = REG_FIELD(PWM_CTRL_REG, 20, 20),
> + [FIELD_CLK_GATING] = REG_FIELD(PWM_CTRL_REG, 21, 21),
> + [FIELD_READY] = REG_FIELD(PWM_CTRL_REG, 29, 29),
> + },
> +};
> +
I'm not sure you need something that complicated.
What about something like:
struct sun4i_chan_fields {
struct reg_field prescaler;
struct reg_field polarity;
struct reg_field clk_gating;
struct reg_field ready;
};
And in sun4i_pwm_data add an array of this struct.
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 RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check
Hi Sean,
On Thursday 23 Feb 2017 10:54:37 Sean Paul wrote:
> On Wed, Dec 07, 2016 at 11:48:55AM +0200, Laurent Pinchart wrote:
> > On Wednesday 07 Dec 2016 10:26:25 Chen-Yu Tsai wrote:
> >> On Wed, Dec 7, 2016 at 1:29 AM, Maxime Ripard wrote:
> >>> On Thu, Nov 24, 2016 at 07:22:31PM +0800, Chen-Yu Tsai wrote:
> The panels shipped with Allwinner devices are very "generic", i.e.
> they do not have model numbers or reliable sources of information
> for the timings (that we know of) other than the fex files shipped
> on them. The dot clock frequency provided in the fex files have all
> been rounded to the nearest MHz, as that is the unit used in them.
>
> We were using the simple panel "urt,umsh-8596md-t" as a substitute
> for the A13 Q8 tablets in the absence of a specific model for what
> may be many different but otherwise timing compatible panels. This
> was usable without any visual artifacts or side effects, until the
> dot clock rate check was added in commit bb43d40d7c83 ("drm/sun4i:
> rgb: Validate the clock rate").
>
> The reason this check fails is because the dotclock frequency for
> this model is 33.26 MHz, which is not achievable with our dot clock
> hardware, and the rate returned by clk_round_rate deviates slightly,
> causing the driver to reject the display mode.
>
> The LCD panels have some tolerance on the dot clock frequency, even
> if it's not specified in their datasheets.
>
> This patch adds a 5% tolerence to the dot clock check.
> >>>
> >>> As we discussed already, I really believe this is just as arbitrary as
> >>> the current behaviour.
> >>
> >> Yes. I agree. This patch is mainly to give something that works for
> >> people who don't care about the details, and to get some feedback
> >> from people that do.
> >>
> >>> Some panels require an exact frequency,
> >
> > There's no such thing as an exact frequency, there will always be some
> > tolerance (and if your display controller can really generate an exact
> > frequency I'd be very interested in that hardware :-)).
>
> There is such thing as exact frequency when you have to worry about panel
> warranty.
There's no such thing as exact frequency when you live in a world that has to
comply with the laws of physics :-) This would require an infinitely precise
clock, and there's no such thing.
> We are fortunate, since we can talk to the panel manufacturer and discuss
> which frequencies are tolerable inside the warranty. We usually hand pick a
> rate/mode within these constraints.
>
> Also, even though things *look* ok on the panel at a certain clock rate,
> running outside the specified clock could damage the hardware.
I'm curious, how so ? What happens to the panel if you feed it a clock outside
of that range ?
> I don't think it's unreasonable to add tolerances to drm_panel, since they
> will differ in what is acceptable. The tricky part is teasing out what the
> tolerances are.
More than tricky, in the vast majority of cases we don't have that information
at all :-/
> > This is something that has been bugging me for some time now. The problem
> > has been mostly ignored, or worked around in different ways by different
> > drivers. I'm afraid I have no generic solution available, but I think we
> > should try to agree on a common behaviour.
> >
> > I don't believe it would be reasonable to request each panel to report a
> > tolerance, as the value is most of the time not available from the
> > documentation (when documentation is available). Worse, I'm pretty sure
> > that most panels documented as fixed timing can actually accept a wide
> > range of timings. The timings reported in the datasheet are just the
> > nominal values.
> >
> > Panels that don't support multiple resolutions obviously require fixed
> > active h/v values. Even if they can tolerate some departure from the
> > nominal timings for the sync and porches lengths, it might not be very
> > useful to support that as I don't expect the display controllers and
> > encoders to be a limiting factor by not supporting the particular timings
> > that a panel considers as nominal. On the other hand, departing from the
> > nominal pixel clock frequency is needed as we can't achieve an exact
> > match, and even possibly to have some control over the frame rate
> > (although that might also require changing the sync and porches timings).
> > Without specific information about panel tolerance, do we have any option
> > other than picking an arbitrary value ?
> >
> >>> some have a minimal frequency
> >>> but no maximum, some have a maximum frequency but no minimal, and I
> >>> guess most of them deviates by how much exactly they can take (and
> >>> possibly can take more easily a higher frequency, but are less
> >>> tolerant if you take a frequency lower than the nominal.
> >>>
> >>> And we cannot remove that check entirely, since some bridges will
[linux-sunxi] Re: [PATCH v5 1/7] arm64: allwinner: Kconfig: add essential pinctrl driver for H5
On Sun, Feb 26, 2017 at 09:19:50AM +0800, Icenowy Zheng wrote: > H5 SoC has two pin controllers, one (in user manual called "CPUx") needs > a slightly advanced driver, and the other (called "CPUs") is just equal > to the on in H3, and the H3 driver can be just reused. > > Select the two necessary pinctrl drivers when building kernel for > Allwinner SoCs. > > Also add H5 in the option's description. > > Signed-off-by: Icenowy Zheng > --- > arch/arm64/Kconfig.platforms | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms > index 129cc5ae4091..81f0d6149c2e 100644 > --- a/arch/arm64/Kconfig.platforms > +++ b/arch/arm64/Kconfig.platforms > @@ -5,8 +5,11 @@ config ARCH_SUNXI > select GENERIC_IRQ_CHIP > select PINCTRL > select PINCTRL_SUN50I_A64 > + select PINCTRL_SUN50I_H5 > + select PINCTRL_SUN8I_H3_R Why not add those options as def_bool instead? Being able to remove them certainly have values if you want to strip them down. > help > - This enables support for Allwinner sunxi based SoCs like the A64. > + This enables support for Allwinner sunxi based SoCs like the A64 > + and H5. There's no point in having an ever growing list of SoCs here. You can just remove the mention of the A64. 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 v5 5/7] arm: dts: sun8i: split Allwinner H3 .dtsi
On 26/02/17 03:46, Chen-Yu Tsai wrote:
> Hi,
[...]
>> - gic: interrupt-controller@01c81000 {
>> - compatible = "arm,cortex-a7-gic",
>> "arm,cortex-a15-gic";
>> - reg = <0x01c81000 0x1000>,
>> - <0x01c82000 0x2000>,
>> - <0x01c84000 0x2000>,
>> - <0x01c86000 0x2000>;
>> - interrupt-controller;
>> - #interrupt-cells = <3>;
>> - interrupts = > IRQ_TYPE_LEVEL_HIGH)>;
>
> The gic bits seem to be the same for both SoCs, aside from the
> different compatible
> string. Marc had sent a series to change them all to arm,gic-400, which is the
> proper name for it, but it wasn't merged. I'm assuming the compatibles
> are equal?
> If so then it can also be shared.
The series was fixing the various GICv2 memory maps, and is now in
mainline. If you have a good indication that all these SoCs are indeed
featuring a gic-400, feel free to amend the DT.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
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.
