[linux-sunxi] Re: Some discussion about A64 clocks regulators support

2016-09-07 Thread maxime.ripard 
Hi,

On Tue, Sep 06, 2016 at 12:43:41AM +0100, André Przywara wrote:
> On 05/09/16 22:17, maxime.ripard wrote:
> 
> Hi Maxime,
> 
> thanks for your answer.
> 
> > I'm leaving aside the rest of your mail, since we apparently have a
> > very fundamental disagreement and will never reach an agreement. So,
> > let's agree to disagree.
> 
> I agree ;-)
> 
> > 
> > That being said...
> > 
> > On Mon, Sep 05, 2016 at 01:25:36AM +0100, André Przywara wrote:
> >> From thinking more about this I think we can have both approaches
> >> implemented:
> >> - An embedded design for people who either want full control or who
> >> don't care too much about the potential danger.
> >> - A server design which hides those bits from Linux, instead offers
> >> abstracted firmware interfaces to monitor (or control, if necessary) AXP
> >> functionality.
> >>
> >> The DT would then ultimately describe which version is used: A "server
> >> firmware" would switch the RSB to secure and would expose SCPI
> >> regulators and sensors in the DT. People in favour of the embedded
> >> design could load a different firmware (or somehow switch over) and use
> >> the "embedded" DT with a RSB node and have full control.
> > 
> > What I don't want is to wait for the year of SCPI on embedded
> > boards. We already wasted way too much time on this, and people are
> > asking for it.
> 
> I can see that and totally agree here.
> 
> > 
> >> I don't see how those should clash from a Linux perspective, as we just
> >> use different drivers and describe the wanted one in the DT, without
> >> having conflicting bindings.
> >>
> >> Yes, having different DTs for the same hardware may rise some eyebrows,
> >> but in the end we just describe firmware interfaces (like PSCI) and
> >> avoid describing some hardware (RSB).
> > 
> > But PSCI is actually a very good example. The implementation we have
> > right now just generates the right DT nodes if the bootloader is
> > PSCI-enabled, and the kernel just picks whatever is provided, without
> > having to actually declare anything.
> > 
> > I could imagine the same thing for SCPI. And it would even be easier
> > with sunxi-ng to modify the DT to basically drop the CCU node, and
> > insert the scpi-clocks node instead.
> > 
> > You would only need to keep the same phandle (which is trivial) and to
> > keep the same clock indices (which is not that hard either).
> > 
> > That would be the most obvious way to have things working I guess: if
> > you use an SCPI-enabled firmware, everything is just generated at
> > runtime depending on what the firmware supports.
> > 
> > And everything just works.
> 
> Excellent! You actually anticipate the suggestion I wanted to make in
> the reply to that other mail ;-)
> I guess I have no real stand against the sunxi-ng clocks anyway, since I
> seem to be the only opponent and maintainers seem to be happy with it.
> And similar to the regulator issue I think we don't clash on any binding.
> In the world I imagine the DT comes with the firmware anyway (EDK2 does
> it that way), so as long as the kernel works with both DTs ...
> 
> >> I really want to depart from this all-embedded approach which
> >> exposes every bit to Linux. So why not use the first 64-bit
> >> Allwinner chip as a test vehicle to prototype this? Could you live
> >> with a different approach living in parallel with the classic sunxi
> >> way?
> > 
> > If we don't have to maintain and ship several DTs depending on the
> > option, yes, sure.
> 
> Alright, I will try to go as far as I can with the firmware based
> approach. As SCPI services are requested by the OS, we can even use the
> very same firmware code, on a sunxi-ng based system SCPI will just never
> be used and I will try my best to keep it compatible.

Ok. I'll respin my sunxi-ng patches with a bunch of changes compared
to the first version (mostly to split the H3 and A64 drivers, as Jean
Francois and Chen-Yu suggested). Do you want to send your initial
patches on top, or should I do it?

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: Linux 3.4 and mainline uboot stuck at starting kernel

2016-09-07 Thread Saurabh Jain 

>
> -"Enable workarounds for booting old kernels" in U-Boot
> -manually setting machid  in u-boot : setenv machid 0x1029  , 0x1029 
> corresponds to "sunxi  MACH_SUNXI  SUNXI   4137"  in
> arch/arm/tools/mach-types
>

Eyad, your machid tip helped me boot my board from NAND. Thank you :-) 

-- 
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] sunxi: Endless musb_bus_suspend warnings when booting A23 tablet with OTG

2016-09-07 Thread wens Tsai 
On Wed, Sep 7, 2016 at 6:44 PM, Hans de Goede  wrote:
> Hi,
>
> On 06-09-16 17:31, wens Tsai wrote:
>>
>> On Tue, Sep 6, 2016 at 7:28 PM, Hans de Goede  wrote:
>>>
>>> Hi,
>>>
>>> On 06-09-16 13:02, wens Tsai wrote:


 Hi Hans,

 I've built the latest sunxi-next branches of Linux and U-boot and
 tried it on my Q8 A23 tablet. My tablet has an OTG adapter with a
 USB ethernet adapter connected all the time. Upon booting into
 Linux I get an endless stream of:

 musb_bus_suspend 2586: trying to suspend as a_wait_bcon while active

 messages. To get out of this I have to physically remove the OTG
 adapter. Booting without the OTG adapter to begin with also gets
 rid of the problem.

 Have you run into this problem? I wonder if we should disable VBUS
 just before leaving U-boot? Now that we support DRIVEVBUS this
 shouldn't be a problem.
>>>
>>>
>>>
>>> I've not seen such a problem. I'm fine with disabling Vbus when
>>> leaving u-boot, that certainly is the safe thing to do anyways.
>>
>>
>> Seems there's no distinction between "USB reset" and leaving
>> U-boot, as you mentioned in your patch removing the "power off"
>> code from the USB drivers. Are you OK with power cycling during
>> USB reset as well?
>
>
> I would prefer not too, but if it is hard to get around that
> I can live with it.

Unfortunately musb USB reset does not work. I tested without my
patch (the one I sent out today). So I think this point is
irrelevant, at least until someone fixes musb.

ChenYu

>>
>>> I guess I'll get a u-boot patch from you if that indeed fixes
>>> things ?
>>
>>
>> Yup. In progress. Though my ethernet adapter is acting up, so I'll
>> need to swap in something else to test it properly.
>
>
> Cool.
>
> Thanks & Regards,
>
> Hans

-- 
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] sunxi: Endless musb_bus_suspend warnings when booting A23 tablet with OTG

2016-09-07 Thread Hans de Goede 

Hi,

On 06-09-16 17:31, wens Tsai wrote:

On Tue, Sep 6, 2016 at 7:28 PM, Hans de Goede  wrote:

Hi,

On 06-09-16 13:02, wens Tsai wrote:


Hi Hans,

I've built the latest sunxi-next branches of Linux and U-boot and
tried it on my Q8 A23 tablet. My tablet has an OTG adapter with a
USB ethernet adapter connected all the time. Upon booting into
Linux I get an endless stream of:

musb_bus_suspend 2586: trying to suspend as a_wait_bcon while active

messages. To get out of this I have to physically remove the OTG
adapter. Booting without the OTG adapter to begin with also gets
rid of the problem.

Have you run into this problem? I wonder if we should disable VBUS
just before leaving U-boot? Now that we support DRIVEVBUS this
shouldn't be a problem.



I've not seen such a problem. I'm fine with disabling Vbus when
leaving u-boot, that certainly is the safe thing to do anyways.


Seems there's no distinction between "USB reset" and leaving
U-boot, as you mentioned in your patch removing the "power off"
code from the USB drivers. Are you OK with power cycling during
USB reset as well?


I would prefer not too, but if it is hard to get around that
I can live with it.




I guess I'll get a u-boot patch from you if that indeed fixes
things ?


Yup. In progress. Though my ethernet adapter is acting up, so I'll
need to swap in something else to test it properly.


Cool.

Thanks & Regards,

Hans

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